Mobile Health Document Sharing
2.3.1 - Trial-Implementation
Mobile Health Document Sharing
2.3.1 - Trial-Implementation
This page is part of the Mobile Health Document Sharing (v2.3.1: Publication) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions 
The MHDS Profile specifies how a collection of IHE profiles can be used by communities for exchanging health information. These IHE profiles include support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security. MHDS shows how several IHE profiles work together to provide a standards-based, interoperable approach to community health information sharing.
The central HIE infrastructure defined in this profile might be a single FHIR Server implementing all the defined central service actors or may be virtual cloud of the systems implementing the defined profile actors. These deployment models allow for modularity where each service function could be provided by different vendors, leveraging as much as possible from a reference implementation of a FHIR Server, and also leverage as much as possible of modularity enabled by defined profiles.
Core business functions provided by MHDS Profile:
The IHE IT Infrastructure Domain has published several resources to support document sharing:
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.
Figure 1:50-1: MHDS High Level View Diagram
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:
This profile orchestrates actors in many existing IHE profiles and creates one new actor. The actor defined in this profile is a Document Registry. The Document Registry has internal grouping with a set of actors from other profiles, and is responsible for persisting the Metadata and documents. Figure 1:50.1-1 shows a detailed actor diagram for the MHDS Document Registry.
Figure 1:50.1-1: MHDS Registry Actor Diagram
Table 1:50.1-1 lists the transactions for each actor directly defined in the MHDS Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”). This does not include the transactions defined in the grouped profiles, which are defined in those grouped profiles.
Table 1:50.1-1: MHDS Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Document Registry | (none) – transactions supported come from the grouped actors listed below | -- | -- | 1:50.1.1.1 Document Registry |
The Document Registry is grouped with a set of actors from other profiles:
HIE Central Infrastructure Requirements
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).
Figure 1:50.1-2: MHDS Document Sharing Health Information Exchange
The HIE Central Infrastructure is a set of Services based on IHE Profiles as shown in Figure 1:50.1-2:
There are other useful actors that are compatible with MHDS, but are not required by the MHDS Profile:
In addition to these IHE-defined actors, the Community will also select how they will manage Digital Certificates through a Certificate Authority, and other functionalities and non-functional requirements such as response-time, service-level-agreements, remediation-planning, remediation-access, etc.
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.
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.
The HIE authority is responsible for setting Patient Identity quality criteria including the minimally acceptable Patient identity constraints. This would set the data elements that describe the Patient within the Community and the quality of the identity proofing and identity confirmation necessary by all participants in the Community.
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.
The functions of the MHDS Document Registry rely on grouped actors from the other IHE Profiles; see Section 1:50.3., as defined in the Document Registry FHIR CapabilityStatement of Requirements (note that this CapabilityStatement is incomplete given that not all the grouped IHE Profile server actors are not yet defined in Implementation Guides).
The Document Registry SHALL include a configuration management function to enable configuration of the grouped actors, including Metadata rules, policy, and security.
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.
The Document Registry SHALL be grouped with an ATNA Secure Node or Secure Application:
Triggered by: a Provide Document Bundle [ITI-65] transaction.
Figure 1:50.1.1.1.1-1: Document Publication Process Flow
DocumentReference.relatesTo.code of replaces and DocumentReference.relatesTo.target pointing at the existing DocumentReference to be deprecated. The Document Registry sets the existing DocumentReference.status element to inactive.Triggered by: any Find Document Lists [ITI-66], Find Document References [ITI-67], and Retrieve Document [ITI-68] Transactions.
Figure 1:50.1.1.1.2-1: Discovery and Retrieval of Existing Document Process Flow
Triggered by: a Mobile Patient Identity Feed [ITI-93] transaction with a Merge:
Figure 1:50.1.1.1.3-1: Patient Merge Process Flow
The Document Registry SHALL search for any resources with the deprecated
_id value in the DocumentReference.subject,
and List.subject; and replace subject value in those resources with the surviving id value.
The Document Registry SHALL record a single audit event indicating the
Merge action, with an .entity element for each of the updated Document
Registry Resources updated. The Document Registry SHOULD create within
the Document Registry a single Provenance Resource indicating the Merge
action, with the .target element pointing at all of the resources
updated by the Document Registry.
No behavior is expected of the Document Registry on receipt of a feed containing create, delete, or update, although the Document Registry may consume and persist these to support the Document Registry requirements to validate Patient references as a recognized Patient within the Community.
There are two alternatives for storing the Binary Resource for documents stored in the community: (1) The Document Source includes the Binary Resource in the [ITI-65] transaction, and the Document Registry is required to store it. (2) The Community allows the Binary to be stored elsewhere in the Community.
The second alternative requires that the Community has the alternative
to store the Binary in a system in the Community other than the Document
Registry. This might be other centralized infrastructure, distributed
infrastructure, or within the system implementing the Document Source.
The [ITI-65] transaction does not include the Binary, and the
DocumentReference.content.attachment.url. value is a persistent URL to
the Binary content. When this is used by the Community, the service
hosting the Binary shall:
Options that may be selected for each actor in this profile, if any, are listed in the Table 1:50.2-1. Dependencies between options, when applicable, are specified in notes.
Table 1:50.2-1: MHDS – Actors and Options
| Actor | Option Name | Reference |
|---|---|---|
| Document Registry | Authorization Option | Section 1:50.2.1 |
| Consent Manager Option (Note 1) | Section 1:50.2.2 | |
| SVCM Validation Option | Section 1:50.2.3 | |
| Uncontained Reference Option | Section 1:50.2.4 |
Note 1: The Consent Manager Option requires the Authorization Option
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.
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.
Figure 1:50.2.1-1: Document Publication Process Flow with Authorization Option
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.
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.
An interaction where a Consent Manager decision to Permit the interaction would look just like Figure 1:50.2.1-1 above, where the ITI-71 would have also considered the Consent state. In Figure 1:50.2.2-1 below, the Document Registry (IUA Resource Server) denies access (403 Forbidden). This deny would be an IUA Resource Server enforcement action of the ITI-71 issued token. For example where the ITI-68 was requesting a document that was not within the authorization scope given in ITI-71.
Figure 1:50.2.2-1: Consent Management for Denied Disclosure Process Flow
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.
The Permit policy is specific to requests from an authorized Document Consumer from authorized identities (applications and/or users) with appropriate roles, and authorized Treatment PurposeOfUse.
Figure 1:50.2.2-2: Simple Consent state diagram
The IUA Authorization Server SHALL
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.
Note that this option does not protect Binary content stored outside of the Document Registry; see Section 1:50.1.1.2. When documents are stored outside of the Document Registry, the Document Source system takes on the burden of protecting the document.
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:
“PurposeOfUse” '.' PurposeOfUse
queryParam
For example, a simple request for Treatment access to patient f5c7395:
PurposeOfUse.TREAT
patient="http://myserver.example/fhir/Patient/f5c7395"
e.g., a request for Treatment, Payment, and Operations access to patient f5c7395 in addition to SMART-on-FHIR scopes for read access to DocumentReference, List, and Binary
user/DocumentReference.read user/List.read user/Binary.read
PurposeOfUse.TREAT PurposeOfUse.HPAYMT PurposeOfUse.OPERAT
patient="http://myserver.example/fhir/Patient/f5c7395"
The Document Registry that supports the SVCM Validation Option SHALL be grouped with a SVCM Terminology Consumer and uses this interface to do validation of submitted metadata codes in the [ITI-65] submission as being within in the community assigned valueSet. If any of the codes are found to be not valid then Document Registry SHALL reject the [ITI-65] transaction.
By default in [ITI-65], an MHD Document Source is required to include
by containment the information in the DocumentReference.author,
the DocumentReference.authenticator,
the DocumentReference.context.sourcePatientInfo, and
the List.source. This requirement encourages the persisting of
the information at the time the document is published. This supports
lifecycle management that recognizes that these identities change over
time, and often become invalid due to individual retirement or other
reasons to no-longer be active (e.g., the document is utilized 20 years
after it was first published, and thus the original author has long
since retired and would therefore not be in an active provider
directory.)
The UnContained Reference Option recognizes that a Community may choose to longitudinally maintain their mCSD provider directory and PMIR Patient Identity Registry. When this longitudinal consistency is managed, then the entries in the MHDS Document Registry do not need to make a copy of the information known at the time of publication since a Reference to the information in these directories will be valid over the full lifecycle of the Document Registry entries.
The UnContained Reference Option requires the grouped MHD Document
Recipient to support the MHD UnContained Option. An MHD Document Source
may implement the MHD UnContained Option so as to be able to send
UnContained References. The MHD and MHDS UnContained Option allows
DocumentReference.author, DocumentReference.authenticator,
DocumentReference.context.sourcePatientInfo, and List.source
to be a Reference to a
(Practitioner|PractitionerRole|Organization|Patient) Resource, where the
referenced resource is published in the associated centrally managed
mCSD Care Services Selective Supplier, or PMIR Patient Identity Registry.
Figure 1:50.2.4-1: Author Reference Process Flow
The mCSD Care Services Selective Supplier and the PMIR Patient Identity Registry are persisting long term the data so that the Resources within the MHDS Document Registry are available for the life of the Document Registry entry.
The Document Registry shall validate publication requests to ensure that
all DocumentReference.author, DocumentReference.authenticator,
DocumentReference.context.sourcePatientInfo, and
List.author; elements are either contained or are references
to valid and active entry in the mCSD Care Services Selective Supplier
or PMIR Patient Identity Registry. The Document Registry shall validate
this by use of mCSD Care Services Selective Consumer using the Find
Matching Care Services [ITI-90] transaction, and Patient identity
either internal Patient identity cache or possibly by PMIR Patient Identity Registry using the PDQm Query [ITI-78].
An actor from this profile (Column 1) shall implement all of the required transactions in this profile in addition to all of the requirements for the grouped actor (Column 3).
Section 1:50.5 describes some optional groupings that may be of interest for security considerations and Section 1:50.6 describes some optional groupings in other related profiles.
Table 1:50.3-1: Required Actor Groupings
| MHDS Actor | Grouping Condition | Actor(s) to be grouped with | Reference |
|---|---|---|---|
| Document Registry | Required | CT / Time Client | ITI TF-1: 7 |
| Required | ATNA / Secure Node or Secure Application with the STX: TLS 1.2 with the BCP195 Option and the ATX: FHIR Feed Option | ITI TF-1: 9 | |
| Required | MHD / Document Responder | ITI TF-1: 33 | |
| Required | MHD / Document Recipient with the Comprehensive Metadata Option | ITI TF-1: 33 | |
| Required | PMIR / Patient Identity Consumer | ITI TF-1: 49 | |
| if the Authorization Option | IUA / Resource Server with the The IUA Authorization Server Metadata Option | ITI TF-1: 34 | |
| if the Authorization Option | IUA / Authorization Server with the The IUA Authorization Server Metadata Option | ITI TF-1: 34 | |
| if the UnContained References Option | mCSD / Care Services Selective Consumer | ITI TF-1: 46 | |
| if the SVCM Validation Option | SVCM / Terminology Consumer | ITI TF-1: 51 |
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.
The MHDS Profile supports Document Sharing utilizing only FHIR infrastructures. This is similar functionality to XDS but using the FHIR standard and not SOAP. The advantage of the FHIR infrastructure is that it is based on more accessible technology, especially for mobile devices; but the solution is not limited to mobile devices.
This use case utilizes MHD Document Source using the Provide Document Bundle [ITI-65] transaction to the Document Recipient that is grouped with the MHDS Document Registry. The Document Registry validates the publication request and persists the information if approved. The MHD Comprehensive Metadata Option is required of the MHD Document Source as the MHD Document Recipient within the MHDS Document Registry will implement the Comprehensive Metadata Option. See Section 1:50.1.1.1.1.
This use case utilizes the grouped PMIR Patient Identity Consumer to enable the Document Registry to receive updates of Patient Identity, so that when a Merge is authorized, the Document Registry will update any of the references to the former Patient Identity with the Patient Identity that survives. See Section 1:50.1.1.1.3.
The MHD Document Consumer is supported by the Document Registry grouped with the MHD Document Responder to allow for the Document Consumer to discover and retrieve document metadata and content. See Section 1:50.1.1.1.2.
With the use of the Consent Management Option the Document Registry supports simple Allow and Deny patient privacy consents for disclosure. These controls are available to prevent unauthorized disclosure. These Consent Management function does not prevent publication from Use Case #1 to enable documentation longitudinal consistency and for accesses not mediated by Patient Privacy Consent. See Section 1:50.2.2.
The security considerations for a content module are dependent upon the security provisions defined by the grouped actor(s).
This section will discuss how a community that leverages the MHDS Profiles for document sharing can protect patient privacy and information security.
An especially important aspect that is beyond the scope of IHE is the definition of the overall policies of the community. There are white papers and handbooks from IHE (see Section 1:50.1), but there is no single policy that must be put in place by an IHE based community to ensure privacy and security. In this section, we will discuss potential policy decisions and positions with regard to the profiles. It is especially important for the reader to understand that the scope of an IHE profile is only the technical details necessary to ensure interoperability. It is up to any organization building a community to understand and carefully implement the policies of that community and to perform the appropriate risk analysis. Although this section is not going to define the policies that a community should have, it will explore some of the policy building activities to demonstrate how such policies can be supported.
The Policy Environment is made up of many layers of policies. These policies work together in an interlocking hierarchy. We will introduce some of these layers in this section and show how they influence the technology. At the highest layer are international policies, like the International Data Protection Principles. Countries or regions will have specific policies. Some examples are USA HIPAA Security and Privacy Rules, with further refinement by individual states. There are horizontal policies that are common among a specific industry, such as those from medical professional societies. There are business driven policies that might further control specific information. As shown in this section, the IHE Profiles offer not only the means to exchange information, but to do so in a way that is supportive of many of the policies mentioned.
The policy landscape that the community is built on needs to be defined well before the community is built.
IHE solves interoperability problems via the implementation of technology standards. It does not define Privacy or Security Policies, Risk Management, Healthcare Application Functionality, Operating System Functionality, Physical Controls, or even general Network Controls.
While community Policies and Risk Management are outside its scope, IHE does recognize that these elements are a necessary piece of a system implementation. IHE IT Infrastructure technical white paper, “Template for XDS Affinity Domain Deployment Planning” outlines some of the issues that should be evaluated for inclusion in the local Policy creation and Risk Management decisions. It is therefore the duty of system implementers to take this guidance into account as part of their Risk Management practices.
Implementers need to be aware of different kinds of policies that need to be harmonized with those policies of the local health enterprises connected to the community. The following is a list of sample policy fragments to stimulate discussion:
These policies are not a flat set, but often interlock and at other times cascade. An important set of policies are those around emergency modes. There are wide definitions of cases that are referred to as emergency mode. These emergency modes need to be recognized for the risks they present. When these use cases are factored in up-front, the mitigations are reasonable.
Often times being in the emergency department is considered as an emergency mode, but the emergency department is really a normal mode for those scheduled to work there. When looked at as normal mode, the proper privileges and workflow flexibility can be specified.
Policy development often is frustrated by apparent conflicts in the goal or effect of multiple layers of policies. These conflicts are often only on the surface and can be addressed upfront once the details of the policy are understood. A good example of a policy conflict is in records retention requirements at the national level vs. at the Medical Records level. Medical Records regulatory retention is typically fixed at a short period after death, but there may be exceptions (e.g., if the patient has black lung then the records must be preserved well beyond.)
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.
Based on the experience of the IHE participants in implementing community environments there is a common set of Security and Privacy controls that have been identified. These controls are informed by a combination of the OECD data protection principles, experience with explicit policies at community implementations, and Security Risk Management.
These security and privacy controls are:
IHE does not set policies but is policy sensitive. Therefore, we now discuss the policy enabling technologies but not the policies themselves.
This section shows how the existing security controls in the local health IT system are leveraged and extended when they become interconnected through document sharing.
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:
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.
Once it is known that the system will enforce Access Controls and Audit Controls then it can be connected to other systems that have also been assessed positively. In this way these systems only talk to other systems that also agree to enforce the common policies. This creates a basis for a chain of trust through accountability among all of the systems participating in the Document Sharing exchange. The communications between these trusted systems is also encrypted.
The IHE Document Sharing profiles, like MHDS, allow for many different types of documents to be shared. These documents are likely to have different levels of confidential information in them. For instance, one document might contain the very basic health information that the patient considers widely distributable. Another document might be made up totally of information necessary for proper billing such as insurance carrier and billing address. Yet another document might carry the results of a very private procedure that the patient wishes to be available only to direct care providers. This differentiation of the types of data can be represented using a diagram like found in Table 50.5.3.2-1: Sample Access Control Policies, showing an ‘X’ where the defined Role (rows) would have permitted access to data tagged with the given (columns) ConfidentialityCode (U-Unrestricted, L-Low, M-Moderate, N-Normal, R-Restricted, V-Very Restricted).
Table 1:50.5.3.2-1: Sample Access Control Policies
| Confidentiality vs Role | U | L | M | N | R | V |
|---|---|---|---|---|---|---|
| Administrative Staff | X | X | ||||
| Dietary Staff | X | |||||
| General Care Provider | X | X | ||||
| Direct Care Provider | X | X | X | X | ||
| Emergency Care Provider (e.g., EMT) | X | |||||
| Researcher | X | |||||
| Patient or Legal Representative | X | X | X | X |
Then documents can be labeled with one or more of the codes on the columns, and results in the specified Functional Roles to be given access to that type of document. In this way, the document sharing metadata informs the Role-Based Access Control (RBAC) decisions through self-describing sensitivity, known as confidentialityCode.
In the same way that the Document Sharing metadata ‘doctype’ defines what the document is in terms of the clinical/administrative content, the confidentialityCode defines what the document is in terms of privacy/security content, sometimes referred to as sensitivity. The confidentialityCodes should be looked at as a relatively static assessment of the document content privacy/security characteristics. Some documents are so sensitive in nature that they simply should not be shared or published.
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.
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.
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.
Some examples of the type of policy that can be necessary for Patient Privacy Consents are:
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.
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.
Let’s further examine what happens when the patient changes their decision. For example, the patient is moving to a totally different region that is not served by this community. The patient can acknowledge the Opt-Out policy. This policy would then be registered as a replacement for the previous Opt-In policies including the research policy. Thus, now if that research application tries to access the patient’s data, it will be blocked as the patient does not have a current acknowledgement of the research policy.
The IHE security and privacy model supports both centralized and distributed control. The entities that are allowed to participate in community-based document sharing need to be evaluated to assure that they have the capability to enforce the policies they are expected to enforce. This may mean that access control is enforced at the edge systems, at the center, or more likely in both places.
In healthcare, beyond the basic security principles, we must additionally be sensitive to patient care and safety. The applications closest to the patient are best informed for determining the context of the current situation. It is primarily at this level that emergency mode can be handled in a robust way (often called break-glass).
The IHE security and privacy model is very careful to include security while allowing for flexible and safe provision of healthcare by individual participants.
The following is a breakdown of the security and privacy controls and in what way the IHE profiles can help. The following table shows the set of identified Controls (identified in above) as columns and the supportive IHE Profiles as rows. In this table a ‘√’ indicates a direct relationship. A direct relationship means that the Profile addresses the security and/or privacy principle. An ‘.’ indicates an indirect relationship, meaning that the Profile assists with the principle. Further details on the ‘√’ direct and ‘.’ Indirect relationships can be found in the profile text or through other webinars.
Table 1:50.5.4-1: Profiles relationship to Controls
| Function vs Profile | Audit Log | Identification and Authentication | Data Access Control (Authorization) | Secrecy | Data Integrity | Non-Repudiation | Patient Privacy |
|---|---|---|---|---|---|---|---|
| Audit Trails and Node Authentication | √ | √ | √ | √ | √ | √ | √ |
| Consistent Time | √ | ∙ | √ | ||||
| Internet User Authorization | √ | √ | ∙ | ∙ | |||
| Cross-Enterprise User Assertion | √ | ∙ | ∙ | ∙ | |||
| Basic Patient Privacy Consents | ∙ | √ | |||||
| Mobile Care Services Discovery | √ | ∙ | ∙ | ||||
| Document Digital Signature | √ | √ | √ | ||||
| Document Encryption | √ | √ | ∙ |
This section includes interactions between systems, with details at the actor and transaction level:
Figure 1:50.6.1-1 shows a simplified view, where the following simplified components are defined:
The diagram has groupings with actions of a
Figure 1:50.6.1-1: FHIR MHDS Controlled Exchange (100% FHIR)
This section shows a typical client system design. This is informative to help explain how these various actors interact.
The actors and transactions are not fully explained here, please see the formal profiles referenced for details on the actual actor and transaction functionality, responsibility, and interoperability.
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).
This system can publish documents using the MHD Document Source. The other actors shown are there to support this primary function.
System that publishes documents - Integration Statement
| Profiles Implemented | Actors Implemented | Options Implemented |
|---|---|---|
| MHD | Document Source | |
| CT | Time Client | |
| PMIR | Patient Identity Source | |
| PIXm | Patient Identity Consumer | |
| PDQm | Patient Demographics Consumer | |
| SVCM | Terminology Consumer | |
| ATNA | Secure Node | STX: TLS 1.2 Floor using BCP195 Option |
| ATX: FHIR Feed Option | ||
| IUA | Authorization Client | |
| mCSD | Care Service Selective Consumer | |
| NPFS | File Consumer |
This system can consume documents using the MHD Document Consumer. The other actors shown are there to support this primary function.
System that consumes documents - Integration Statement
| Profiles Implemented | Actors Implemented | Options Implemented |
|---|---|---|
| MHD | Document Consumer | |
| CT | Time Client | |
| PMIR | Patient Identity Source | |
| Patient Identity Cross-Reference Consumer | ||
| Patient Demographics Consumer | ||
| SVCM | Terminology Consumer | |
| ATNA | Secure Node | STX: TLS 1.2 Floor using BCP195 Option |
| ATX: FHIR Feed Option | ||
| IUA | Authorization Client | |
| mCSD | Care Service Selective Consumer | |
| NPFS | File Consumer |
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.
System that consumes clinical data elements - Integration Statement
| Profiles Implemented | Actors Implemented | Options Implemented |
|---|---|---|
| QEDm | Clinical Data Consumer | |
| MHD | Document Consumer | |
| CT | Time Client | |
| PMIR | Patient Identity Source | |
| Patient Identity Cross-Reference Consumer | ||
| Patient Demographics Consumer | ||
| SVCM | Consumer | |
| ATNA | Secure Node | STX: TLS 1.2 Floor using BCP195 Option |
| ATX: FHIR Feed Option | ||
| IUA | Authorization Client | |
| mCSD | Care Service Selective Consumer | |
| NPFS | File Consumer |
This is a system that contains all of the Central Infrastructure defined in MHDS as supporting services. These actors do not need to be combined into one system. This combined system is provided for informational purposes.
Central Infrastructure Integration Statement
| Profiles Implemented | Actors Implemented | Options Implemented |
|---|---|---|
| MHDS | Document Registry | Authorization Option |
| Consent Manager Option | ||
| UnContained Option | ||
| SVCM Validation Option | ||
| MHD | Document Responder | |
| MHD | Document Recipient | |
| PMIR | Patient Identity Consumer | |
| CT | Time Client | |
| SVCM | Terminology Consumer | |
| Terminology Repository | ||
| IUA | Resource Server | Authorization Server Metadata Option |
| Authorization Server | Authorization Server Metadata Option | |
| ATNA | Secure Node | STX: TLS 1.2 Floor using BCP195 Option |
| ATX: FHIR Feed Option | ||
| BPPC | Content Consumer | |
| CT | Time Server | |
| PMIR | Patient Identity Registry | |
| ATNA | Audit Record Repository | STX: TLS 1.2 Floor using BCP195 Option |
| ATX: FHIR Feed Option | ||
| IUA | Authorization Server | Authorization Server Metadata Option |
| Resource Server | Authorization Server Metadata Option | |
| mCSD | Care Service Selective Supplier | |
| NPFS | File Server | |
| mXDE | Data Element Extractor | |
| QEDm | Clinical Data Source |
IG © 2021+ IHE IT Infrastructure Technical Committee. Package ihe.iti.mhds#2.3.1 based on FHIR 4.0.1. Generated 2023-08-04
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change