Mobile Health Document Sharing (MHDS) Profile

This profile shows how to build a Document Sharing Exchange using IHE profiled FHIR® standard, rather than the legacy IHE profiles that is dominated by XDS and HL7® v2. This profile will assemble profiles and define a Document Registry.

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 IHE IT Infrastructure Domain has published several resources to support document sharing:

• ITI Technical Framework: Vol. 3 - Section 4.0 Metadata used in Document Sharing
• Health Information Exchange: Enabling Document Sharing Using IHE Profiles
• Document Sharing Metadata Handbook
• Template for XDS Affinity Domain Deployment Planning

Document Sharing on FHIR

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 whitepaper. This Document Sharing exchange requires the same management of metadata as described in the Document Sharing Metadata Handbook.

more...

The MHDS Document Registry

This profile orchestrates actors in many existing IHE profiles and creates one new actor. The actor that is specific to this profile is a Document Registry. The following Figure shows a detailed Actor diagram for the MHDS Document Registry.

The Document Registry is grouped with a set of actors from other profiles to provide the following functionality.

• MHD - Document Responder supports publication requests by the MHD Document Source. The Comprehensive Metadata Option is required.
• MHD - Document Recipient supports the discovery and retrieval of documents by MHD Document Consumer.
• PMIR - Patient Identity Consumer provides patient identity synchronization and specifically the merge function to be applied to any data managed in the Document Registry.
• SVCM - Consumer enables the Document Registry to gain access to ValueSets that the Registry is enforcing Metadata consistency.
• mCSD - Consumer enables the Registry to have access to Organization and Practitioner resources.
• IUA – Authorization Server and Resource Server enforces access control decisions.
• ATNA - Secure Node enable the Document Registry to be secure, record audit records, and support secure transactions.
• CT - Time Client assures that all records of time done by the Document Registry are aligned with the Time Source.

MHDS Options

• SVCM Validation Option -- The Document Registry will do metadata validation against ValueSets managed in the SVCM Terminology Repository
• UnContained Reference Option -- The Document Registry will allow author, authenticator and patient references rather than forcing contained resources
• Authorization Option -- authorization using IUA is included in the Document Registry
• Consent Manager Option -- Patient Privacy Consent Management is included in the Document Registry for simple Permit and Deny (requires Authorization Option)
  

HIE Central Infrastructure

In MHDS, the Document Registry is part of a Document Sharing Health Information Exchange (HIE). 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 Document Sharing Health Information Exchange will also host a set of Services based on IHE Profiles as shown in the figure. These provide services to the Document Sharing Community (aka Community):

• CT Time Server – to provide consistent time to all participant systems
• ATNA – Audit Record Repository with support for the ATX: FHIR Feed Option – to capture audit events and provide appropriate audit log access for security and privacy use-cases
• PMIR – Patient Identity Source and Patient Identity Manager – to provide patient identity lookup by demographics or identity, and to receive create and update of patient identity from participants
• SVCM – Terminology Repository – Provide vocabulary and value set management within the Community
• mCSD – Care Services Selective Supplier – a Provider Directory to enable endpoint lookup and optionally provider identity management

There are other useful actors that are compatible with MHDS, but are not required by the MHDS Profile:

• NPFS – File Manager – Provide files that are needed in the community but are not patient specific such as policy documents
• mXDE – Data Element Extractor – to enable QEDm access to data elements derived from published documents
• QEDm – Clinical Data Source – to enable access to data elements (aka FHIR clinical Resources)
• mACM – Alert Communication Manager – to enable community supported alert communications

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.

Consuming Resources, not Documents

Additionally, the mXDE profile may be used to make the information in the Document Sharing infrastructure more consumable as FHIR Resources using QEDm. These client of the MHDS services use the existing profiles and are not specifically constrained by the MHDS profile. See section X.6 for more details on Cross Profile Considerations of System that publishes documents, System that consumes documents, and System that consumers clinical data elements.

Public Comment #2

This supplement will be in Public Comment in March. This is a second public comment phase in order to assure it gets broad and deep review.