Unattributed Code Systems

Copyright Fragment

This fragment is available on download.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

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 | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web www.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
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
  • Added Security Considerations
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” .

Internal Images