Unattributed Code Systems

Copyright Fragment

This fragment is available on index.html

No use of external IP (other than from the FHIR specification)

Copyright and Registered Trademark Uses

External References

Type Reference Content
web profiles.ihe.net IUA - Authorization Server and Resource Server
web profiles.ihe.net ATNA - Secure Node
web profiles.ihe.net ATNA - Secure Node
web profiles.ihe.net CT - Time Client
web profiles.ihe.net
web profiles.ihe.net
web github.com Mobile Health Document Sharing, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 2.3.2-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.MHDS/ and changes regularly. See the Directory of published versions
web www.ihe.net IG © 2021+ IHE IT Infrastructure Technical Committee . Package ihe.iti.mhds#2.3.2-current based on FHIR 4.0.1 . Generated 2025-05-30
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 github.com The source code for this Implementation Guide can be found on IHE ITI.MHDS Github Repo .
web profiles.ihe.net Consumption side can be further refined using mXDE and QEDm
web www.ihe.net Consumption side can be further refined using mXDE and QEDm
web profiles.ihe.net ITI Technical Framework : Vol. 3 - Section 4.0 Metadata used in Document Sharing
web profiles.ihe.net ITI Technical Framework : Vol. 3 - Section 4.0 Metadata used in Document Sharing
web profiles.ihe.net Health Information Exchange: Enabling Document Sharing Using IHE Profiles
web profiles.ihe.net Document Sharing Metadata Handbook
web www.ihe.net Template for XDS Affinity Domain Deployment Planning
web profiles.ihe.net This MHDS Profile defines a Document Sharing Exchange that is based around the HL7 ® FHIR ® standard, following the principles described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper. This Document Sharing exchange requires the same management of metadata as described in the Document Sharing Metadata Handbook .
web profiles.ihe.net This MHDS Profile defines a Document Sharing Exchange that is based around the HL7 ® FHIR ® standard, following the principles described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper. This Document Sharing exchange requires the same management of metadata as described in the Document Sharing Metadata Handbook .
web profiles.ihe.net Readers that need background on high level concepts of Document Sharing should first review the white paper Health Information Exchange: Enabling Document Sharing Using IHE Profiles . The MHDS Profile is described in the following sections:
web profiles.ihe.net In MHDS, the Document Registry is part of a Document Sharing Health Information Exchange (HIE) . See Figure 1:50.1-2. The Document Registry relies upon services that would be hosted within the HIE Central Infrastructure with a set of Service endpoints as illustrated in the yellow “HIE Central Infrastructure”. The HIE also contains systems, illustrated in green, that submit and consume documents. The combination of MHDS Document Registry (white), HIE Central Infrastructure (yellow), and Systems that publish or consume documents (green) make up the Document Sharing Community (aka Community).
web profiles.ihe.net CT - Time Server
web profiles.ihe.net ATNA – Audit Record Repository
web profiles.ihe.net ATNA – Audit Record Repository
web www.ihe.net mXDE – Data Element Extractor – to enable QEDm access to data elements derived from published documents
web www.ihe.net QEDm – Clinical Data Source
web profiles.ihe.net The Document Registry and the supporting services listed above provide a set of services that make up a Document Sharing Infrastructure that is based on FHIR. This set of services enable systems that publish documents and systems that consume documents. Additionally, the mXDE Profile may be used to make the information in shared documents more consumable as FHIR Resources using QEDm Profile. See Section 1:50.6 Cross Profile Considerations for more details.
web www.ihe.net The Document Registry and the supporting services listed above provide a set of services that make up a Document Sharing Infrastructure that is based on FHIR. This set of services enable systems that publish documents and systems that consume documents. Additionally, the mXDE Profile may be used to make the information in shared documents more consumable as FHIR Resources using QEDm Profile. See Section 1:50.6 Cross Profile Considerations for more details.
web profiles.ihe.net This profile assumes that some Health Information Exchange (HIE) authority manages the configuration of the Community. This includes specification of an appropriate Certificate Authority, Time Source, Domain Name Service, Valueset Management, Provider Directory, Audit Record Repository, Patient Identity Registry, and Authorization Service.
web profiles.ihe.net The HIE authority is responsible for setting Document Sharing Metadata rules, following the metadata rules and using the Metadata Handbook to set specific metadata element requirements including the specification of mandatory ValueSets. See the Document Sharing Metadata Handbook .
web profiles.ihe.net The Document Registry SHALL be grouped with CT – Time Client to keep internal clocks synchronized to the identified Time Source so that records of time are correlated.
web profiles.ihe.net The Document Registry SHALL be grouped with an ATNA Secure Node or Secure Application:
web profiles.ihe.net The Document Registry SHALL support at least the ATNA “STX: TLS 1.2 Floor using BCP195” Option.
web profiles.ihe.net The Document Registry SHALL record all security relevant events to ATNA Audit Record Repository with the “ATX: FHIR Feed” Option. This SHALL include all IHE-defined audit events that are in the control of the Document Registry, including its grouped actors.
web profiles.ihe.net The Document Registry SHALL record all security relevant events to ATNA Audit Record Repository with the “ATX: FHIR Feed” Option. This SHALL include all IHE-defined audit events that are in the control of the Document Registry, including its grouped actors.
web profiles.ihe.net The Document Registry SHALL confirm its identity to the requesting system by use of the ATNA Secure Node or Secure Application TLS protocol using a Certificate assigned to the Document Registry.
web profiles.ihe.net The Document Registry SHALL confirm its identity to the requesting system by use of the ATNA Secure Node or Secure Application TLS protocol using a Certificate assigned to the Document Registry.
web profiles.ihe.net When the Authorization Option (Section 1:50.2.1 ) is implemented and enabled, the Document Registry SHALL confirm the client identity using the IUA Profile.
web profiles.ihe.net The Document Registry SHALL record success and failure events into the ATNA Audit Record Repository .
web profiles.ihe.net When the Authorization Option is implemented and enabled, the Document Registry SHALL confirm the client identity using the IUA Profile.
web profiles.ihe.net The Document Registry SHALL record a success or failure event into the ATNA Audit Record Repository .
web profiles.ihe.net The Document Registry SHALL be grouped with an IUA Resource Server and the IUA Authorization Server Actors. The IUA Authorization Server Metadata Option shall be supported.
web profiles.ihe.net The Document Registry SHALL be grouped with an IUA Resource Server and the IUA Authorization Server Actors. The IUA Authorization Server Metadata Option shall be supported.
web profiles.ihe.net The IUA Resource Server enforces OAuth Authorization decisions made by the grouped IUA Authorization Server. Thus, all accesses to the Document Registry must have a token issued by the IUA Authorization Server. These IUA Authorization Server decisions protect both requests from MHD Document Source Actors for publication, and from MHD Document Consumer actors for access and disclosure. The rules used for this authorization decision are not defined in the MHDS Profile. See the Consent Manager Option for specific access control rules associated with that option.
web profiles.ihe.net The Consent Manager Option requires support of the Authorization Option. The Document Registry SHALL be grouped with an IUA Resource Server and the IUA Authorization Server in order to enforce simple Permit and Deny access patient specific privacy disclosure consents. The Consent Manager Option does not affect publication by Document Source to the Document Registry, but rather only affects disclosure activities between a Document Consumer and the Document Registry.
web profiles.ihe.net The grouped IUA Authorization Server would be used to manage the consent status and make authorization decisions based on the consent status. The changing of the status is a functional requirement that is not defined by IHE. The IUA Resource Server that is grouped with the MHDS Document Registry would enforce these decisions.
web profiles.ihe.net The grouped IUA Authorization Server SHALL support consent configuration to enable Implied Consent and Explicit Consent environments. Implied Consent environments allow disclosure when no Consent has been recorded for that patient, Explicit Consent environments Deny disclosure when no Consent has been recorded for that patient.
web profiles.ihe.net The IUA Authorization Server SHALL
web profiles.ihe.net The IUA Resource Server enforcement point grouped with the MHDS Document Registry SHALL enforce the security authorization decision. This includes confirming all data requested are for the specific patient. This prevents a Document Consumer from requesting access to resources outside the scope of the security token given it by the IUA Authorization Server.
web profiles.ihe.net In order to support this Consent Manager Option, the following IUA constraint is defined. This constraint impacts the Document Consumer grouped IUA Authorization Client, and the IUA actors within the Document Registry. The important elements for the Document Consumer to convey are the scope values for PurposeOfUse and the identity of the Patient. This OAuth Scope specification does not require the use of SMART-on-FHIR but is compatible with it. There are two defined scope values that are included in the scope separated by a space and repeated as necessary:
web profiles.ihe.net ITI TF-1: 7
web profiles.ihe.net ITI TF-1: 9
web profiles.ihe.net ITI TF-1: 34
web profiles.ihe.net ITI TF-1: 46
web profiles.ihe.net The MHDS Profile provides a Document Registry that persists, manages, and provides access using the MHD access methods. This is in support of IHE Document Sharing as described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper.
web oecdprivacy.org In 1980, the Organization for Economic Cooperation and Development (“OECD”) developed Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. These guidelines were intended to harmonize national privacy laws, uphold human rights, and promote the free flow of information among its 30 member countries. The OECD guidelines have served as a basis for data protection laws in the United States, Europe, Canada, Japan, Australia, and elsewhere. Together, these principles and laws provide a useful framework for developing general data protection requirements for health information systems. For more information see http://oecdprivacy.org .
web profiles.ihe.net IHE recognizes that in healthcare, with patient lives at stake, audit control is the primary method of accountability enforcement. The profile that provides this basic security principle is Audit Trail and Node Authentication ( ATNA ). This profile requires three things of each system:
web profiles.ihe.net The Security Audit Logging includes a set of security relevant events that must be audited. When one of these events happens the record of the event must be described a specific way. The systems are expected to support the recording of all of the security relevant events that might happen in the system. The ATNA Profile offloads the recording, filtering, alerting, and reporting to an audit service. The more centralized this audit log analysis can be, the easier it is to prove accountability across the whole Document Sharing exchange.
web profiles.ihe.net The rows are showing a set of functional roles. These roles would be conveyed from the requesting organization through the use of the Internet User Authorization ( IUA ) Profile. This profile defines how a user and the security/privacy context of the request is defined. Additional information can be carried such as the PurposeOfUse, what the user intends to use the data for. Note that Privacy Policies and Access Control rules can leverage any of the user context, patient identity, or document metadata discussed above.
web profiles.ihe.net The topic of Patient Privacy Consent (Authorization) to collect, use, and disclose is a complex topic. This complexity does not always need to be exposed in full detail across a Document Sharing exchange. That is, a request for information does need to consider the current status of any Patient Privacy Consent that the patient has given, but most of the time explaining the detail of this Privacy Consent to the requesting system/individual adds no value. Most often the requesting system/individual is either fully empowered to receive and use the content, or not authorized at all. In these cases, the use of user identity context, as discussed above around the IUA Profile, is sufficient to make the Access Control decision. The trust relationship of the Document Sharing exchange includes background governance on appropriate use, as discussed above around the ATNA Profile.
web profiles.ihe.net The topic of Patient Privacy Consent (Authorization) to collect, use, and disclose is a complex topic. This complexity does not always need to be exposed in full detail across a Document Sharing exchange. That is, a request for information does need to consider the current status of any Patient Privacy Consent that the patient has given, but most of the time explaining the detail of this Privacy Consent to the requesting system/individual adds no value. Most often the requesting system/individual is either fully empowered to receive and use the content, or not authorized at all. In these cases, the use of user identity context, as discussed above around the IUA Profile, is sufficient to make the Access Control decision. The trust relationship of the Document Sharing exchange includes background governance on appropriate use, as discussed above around the ATNA Profile.
web profiles.ihe.net Privacy Consents may need to be expressed in a way that all parties in a Document Exchange can understand. IHE has published the Basic Patient Privacy Consents (BPPC) Profile that can be used to enable basic privacy consent controls, and Advanced Patient Privacy Consents (APPC) that can encode more complex rules specific to a patient consent. The encoding of Consent and advanced rules in FHIR “Consent” resource is possible but has not yet been profiled by IHE.
web profiles.ihe.net Privacy Consents may need to be expressed in a way that all parties in a Document Exchange can understand. IHE has published the Basic Patient Privacy Consents (BPPC) Profile that can be used to enable basic privacy consent controls, and Advanced Patient Privacy Consents (APPC) that can encode more complex rules specific to a patient consent. The encoding of Consent and advanced rules in FHIR “Consent” resource is possible but has not yet been profiled by IHE.
web profiles.ihe.net The BPPC Profile can be used as a gate-keeper to the document sharing community. BPPC does not define the policies but does allow for a community that has defined its set of policies to capture that a patient has chosen one or more of those policies.
web profiles.ihe.net For example: Let’s say that the above set of sample policy fragments was available to a patient sharing in a community. The patient could agree to Opt-In, and also agree to a specific research project. This set of acknowledgments would be captured as one or more BPPC documents. These documents would indicate the policy that is being acknowledged, the date it is being acknowledged, an expiration date if applicable, etc. Then the systems involved in the document sharing can know that the patient has acknowledged these policies and thus the patient’s choices can be enforced. A system that is doing research can see that this patient has acknowledged participation in the research project, while other patients have not.
web profiles.ihe.net Following the sections outline sample IHE Integration Statements for systems of various functionality. For more details on the full use and format of an IHE Integration Statement ( see Appendix F ).
web www.ihe.net This system can consume data elements using the QEDm Profile that have been extracted from the documents published in the MHDS by way of the mXDE Profile. The other actors shown are there to support this primary function. Further details can be found in the referenced profiles.
web profiles.ihe.net This system can consume data elements using the QEDm Profile that have been extracted from the documents published in the MHDS by way of the mXDE Profile. The other actors shown are there to support this primary function. Further details can be found in the referenced profiles.

Internal Images

Slide10.PNG
Slide10.PNG
Slide11.PNG
Slide11.PNG
Slide2.PNG
Slide2.PNG
Slide3.PNG
Slide3.PNG
Slide4.PNG
Slide4.PNG
Slide5.PNG
Slide5.PNG
Slide6.PNG
Slide6.PNG
Slide7.PNG
Slide7.PNG
Slide8.PNG
Slide8.PNG
Slide9.PNG
Slide9.PNG