http://unstats.un.org/unsd/methods/m49/m49.htm
https://profiles.ihe.net/ITI/BALP/CodeSystem/BasicAuditEntityType
urn:ihe:event-type-code
This fragment is available on download.html
This publication includes IP covered under the following statements.
Type | Reference | Content |
---|---|---|
web | profiles.ihe.net | Recommend ATNA , encouraged IHE-IUA or SMART-app-launch |
web | profiles.ihe.net | Recommend ATNA , encouraged IHE-IUA or SMART-app-launch |
web | profiles.ihe.net |
![]() |
web | profiles.ihe.net |
![]() |
web | github.com | Patient Identifier Cross-referencing for mobile (PIXm), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 3.0.5-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.PIXm/ and changes regularly. See the Directory of published versions |
web | www.kereval.com | Provider: INRIA (Rennes, France), KEREVAL |
web | gazelle.ihe.net | Gazelle Patient Manager online |
web | gazelle.ihe.net | User Manual |
web | gazelle.ihe.net | Tool support |
web | gazelle.ihe.net | PIX Consumer test definition: PM_PIX_Query-Patient_Identity_Consumer |
web | gazelle.ihe.net | PIX Manager test definition: PM_PIX_Query-PIX_Manager |
web | www.kereval.com | Provider: INRIA (Rennes, France), KEREVAL , and Mallinckrodt Institute of Radiology (Saint Louis, USA) |
web | gazelle.ihe.net | User Manual |
web | gazelle.ihe.net | Tool support |
web | gazelle.ihe.net | The tests listed below are defined in Gazelle Master Model and are performed by systems testing PIXm at IHE Connectathons. |
web | www.ihe.net |
IG © 2020+ IHE IT Infrastructure Technical Committee
. Package ihe.iti.pixm#3.0.5-current based on FHIR 4.0.1
. Generated 2025-04-28
Links: Table of Contents | QA Report | New Issue | Issues Version History | ![]() ![]() |
web | github.com |
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
![]() ![]() |
web | github.com |
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
![]() ![]() |
web | profiles.ihe.net |
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
![]() ![]() |
web | www.ihe.net |
Links: Table of Contents
|
QA Report
| New Issue
| Issues
Version History
|
![]() ![]() |
web | profiles.ihe.net | should use a security framework. Recommend ATNA , encouraged IHE-IUA or SMART-app-launch |
web | profiles.ihe.net | should use a security framework. Recommend ATNA , encouraged IHE-IUA or SMART-app-launch |
web | profiles.ihe.net | See ITI TF-2: Appendix Z.8 “Mobile Security Considerations” , which includes guidance on the use of ATNA and IUA to protect the communication, access control, and audit logging. |
web | profiles.ihe.net | See ITI TF-2: Appendix Z.8 “Mobile Security Considerations” , which includes guidance on the use of ATNA and IUA to protect the communication, access control, and audit logging. |
web | profiles.ihe.net | See ITI TF-2: Appendix Z.8 “Mobile Security Considerations” , which includes guidance on the use of ATNA and IUA to protect the communication, access control, and audit logging. |
web | profiles.ihe.net | The Internet User Authorization (IUA) Profile provides support for user authentication, app authentication, and authorization decisions. When PIXm actors are grouped with IUA actors there are additional security and privacy functionality enabled by this grouping. There are additional requirements and functionality enabled through scope definitions that are transaction-specific. |
web | profiles.ihe.net | A Patient Identity Source, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identity Source, to provide notifications with the Patient Identity Feed FHIR [ITI-104] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72] . |
web | profiles.ihe.net | A Patient Identity Source, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identity Source, to provide notifications with the Patient Identity Feed FHIR [ITI-104] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72] . |
web | profiles.ihe.net | A Patient Identity Source, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identity Source, to provide notifications with the Patient Identity Feed FHIR [ITI-104] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72] . |
web | profiles.ihe.net | The Patient Identifier Cross-reference Manager, when grouped with an IUA Resource Server, shall require Incorporate Access Token [ITI-72] in all Patient Identity Feed FHIR [ITI-104] transactions, shall enforce the authorization decision in the token, and may further enforce policies beyond those made by the Authorization Server such as consent or business rules. |
web | profiles.ihe.net | The Patient Identifier Cross-reference Manager, when grouped with an IUA Resource Server, shall require Incorporate Access Token [ITI-72] in all Patient Identity Feed FHIR [ITI-104] transactions, shall enforce the authorization decision in the token, and may further enforce policies beyond those made by the Authorization Server such as consent or business rules. |
web | profiles.ihe.net | The requested format of the response from the mime-type value set. See ITI TF-2: Appendix Z.6 |
web | profiles.ihe.net |
See ITI TF-2: Appendix Z.2.2
for use of the token
search parameter type for patient identifiers.
|
web | profiles.ihe.net | The Patient Identifiers returned may be a subset based on policies that might restrict access to some Patient Identifiers. For guidance on handling Access Denied, see ITI TF-2: Appendix Z.7 . |
web | profiles.ihe.net | See ITI TF-2: Appendix Z.6 for more details on response format handling. |
web | www.ihe.net | The business identifier found. Shall include the assigning authority as specified in ITI TF-2: Appendix E.3 |
web | profiles.ihe.net | A Patient Identifier Cross-reference Consumer, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identifier Cross-reference Consumer to get corresponding identifiers with the Mobile Patient Identifier Cross-reference Query [ITI-83] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72] . |
web | profiles.ihe.net | A Patient Identifier Cross-reference Consumer, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identifier Cross-reference Consumer to get corresponding identifiers with the Mobile Patient Identifier Cross-reference Query [ITI-83] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72] . |
web | profiles.ihe.net | A Patient Identifier Cross-reference Consumer, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identifier Cross-reference Consumer to get corresponding identifiers with the Mobile Patient Identifier Cross-reference Query [ITI-83] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72] . |
web | profiles.ihe.net | The Patient Identifier Cross-reference Manager, when grouped with an IUA Resource Server, shall require Incorporate Access Token [ITI-72] in all Mobile Patient Identifier Cross-reference Query [ITI-83] transactions, shall enforce the authorization decision in the token, and may further enforce policies beyond those made by the Authorization Server such as consent or business rules. |
web | profiles.ihe.net | The Patient Identifier Cross-reference Manager, when grouped with an IUA Resource Server, shall require Incorporate Access Token [ITI-72] in all Mobile Patient Identifier Cross-reference Query [ITI-83] transactions, shall enforce the authorization decision in the token, and may further enforce policies beyond those made by the Authorization Server such as consent or business rules. |
web | ihe.net | FHIR Implementation Guide instead of PDF - Rev. 2.1 |
web | github.com |
Volume 1 Update Use Cases and introduced new Patient Identity Feed FHIRaccording to work item
|
web | github.com | IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Public Comment form . |
web | www.ihe.net | IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Public Comment form . |
web | github.com | As issues are submitted they will be managed on the PIXm GitHub Issues , where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later). |
web | wiki.ihe.net | As issues are submitted they will be managed on the PIXm GitHub Issues , where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later). |
web | www.ihe.net | As issues are submitted they will be managed on the PIXm GitHub Issues , where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later). |
web | github.com | PIXm allows for the parameters in the operation to be a string URL. The IG builder, when creating the narrative, presumes that these are clickable links. yet in one example we have put in a URN OID. This is recorded as an issue against the IG builder . |
web | www.ihe.net | In addition a Patient Identifier Cross-reference Manager could create a ‘golden patient’ where all information is consolidated by the Patient Identifier Cross-reference Manager rules and return also this targetId example . Could this id also be added in a $ihe-pix Query as a targetId (‘Patient/Patient-MohrAlice’)? Note: A golden patient is not the scope of PIXm, see the IHE ITI PMIR profile. |
web | www.ihe.net | The naming for the Patient Identity Feed FHIR [ITI-104] transaction is in discussion. It might change depending is applicability to other profiles, like the IHE PMIR ) profile. See profile considerations/testing of PIXm Patient Identifier Cross-Reference Manager and PMIR Patient Identity Registry. |
web | gazelle.ihe.net | The naming for the Patient Identity Feed FHIR [ITI-104] transaction is in discussion. It might change depending is applicability to other profiles, like the IHE PMIR ) profile. See profile considerations/testing of PIXm Patient Identifier Cross-Reference Manager and PMIR Patient Identity Registry. |
web | github.com | Should the Patient Identifier Cross-reference Manager have a requirement of filling in the assigningAuthority Name if the name is not provided in the Patient Identity Feed FHIR [ITI-104] as it is specified for PIX and PIX V3 Cross-reference Manager? Issue |
web | www.ihe.net | [ITI-83] references E.3 which is in PDF , see also github issue . |
web | github.com | [ITI-83] references E.3 which is in PDF , see also github issue . |
web | github.com | The source code for this Implementation Guide can be found on IHE ITI.PIXm Github Repo . |
web | www.google.com | Search this IG |
web | profiles.ihe.net | IHE uses the normative words: Shall, Should, and May according to standards conventions . |
web | profiles.ihe.net |
PIXm uses Must Support
in StructureDefinitions with the definition found in Appendix Z
. This is equivalent to the IHE use of R2
as defined in Appendix Z
.
|
web | profiles.ihe.net | Editor, Add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A : |
web | profiles.ihe.net | Editor, Add the following new or modified transactions to the IHE Technical Frameworks General Introduction Appendix B : |
web | profiles.ihe.net | The HTTP RESTful transactions in PIXm are an alternative to the transactions defined in the PIX and PIXV3 profiles. |
web | profiles.ihe.net | The HTTP RESTful transactions in PIXm are an alternative to the transactions defined in the PIX and PIXV3 profiles. |
web | profiles.ihe.net | Note: The Patient Identity Feed FHIR [ITI-104] and the Mobile Patient Identifier Cross-reference Query [ITI-83] transactions defined in this profile correspond to the transactions used in the PIX and PIXV3 Profiles (ITI TF-1: 5 and 23) and provide similar functionality. |
web | profiles.ihe.net | Note: The Patient Identity Feed FHIR [ITI-104] and the Mobile Patient Identifier Cross-reference Query [ITI-83] transactions defined in this profile correspond to the transactions used in the PIX and PIXV3 Profiles (ITI TF-1: 5 and 23) and provide similar functionality. |
web | profiles.ihe.net | The requirements on Patient Identifier Domain as defined for the PIX profile apply also for this profile. See ITI TF-1 Figure 5-1 and accompanying text. |
web | profiles.ihe.net | The Intensive Care system wants to get lab information associated with a patient that the Intensive Care system knows as patient ID = MC-123. Using its own patient ID = MC-123, requests that PIXm Manager return the patient’s ID in the Main Hospital domain [05] . Having previously cross-referenced this patient with a patient known by medical record number (e.g., 007) in the Main Hospital Domain [04] , the PIXm Manager returns that identifier for the patient. The Intensive Care system is now able to request laboratory results via MHD [06] , using the Patient Identifier in the Main Hospital Domain. The lab system finds lab documents and returns them to the Intensive Care system. |
web | profiles.ihe.net | Actors in PIXm may be grouped with an Audit Trail and Node Authentication (ATNA) Secure Node or ATNA Secure Application Actor. This grouping enables the Patient Identifier Cross-reference Manager to have policies that only highly trusted systems can communicate and that all changes are recorded in the audit log. |
web | profiles.ihe.net | Actors in PIXm may be grouped with an Internet User Authorization (IUA) Authorization Client or Resource Server as appropriate; with the ATNA - STX: HTTPS IUA Option . This grouping will enable more fine grain service side access control and more detailed audit logging. There are additional requirements and functionality enabled through scope definitions that are transaction specific. See the Security Considerations sections of the PIXm-defined transactions for guidance on scope definition when grouped with IUA actors. |
web | profiles.ihe.net | Actors in PIXm may be grouped with an Internet User Authorization (IUA) Authorization Client or Resource Server as appropriate; with the ATNA - STX: HTTPS IUA Option . This grouping will enable more fine grain service side access control and more detailed audit logging. There are additional requirements and functionality enabled through scope definitions that are transaction specific. See the Security Considerations sections of the PIXm-defined transactions for guidance on scope definition when grouped with IUA actors. |
web | profiles.ihe.net | Actors are expected to follow the recommendations and requirements found in ITI TF-2:Appendix Z.8 “Mobile Security Considerations” . |