Difference between revisions of "Mobile Health Document Sharing (MHDS)"
JohnMoehrke (talk | contribs) |
m (→Specification) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 21: | Line 21: | ||
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. Figure X.1-1 shows a detailed Actor diagram for 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. Figure X.1-1 shows a detailed Actor diagram for the MHDS Document Registry. | ||
| − | [[File:MHDS-Document-Registry.PNG| | + | [[File:MHDS-Document-Registry.PNG|400px]] |
The Document Registry is grouped with a set of actors from other profiles. | The Document Registry is grouped with a set of actors from other profiles. | ||
| Line 34: | Line 34: | ||
==Systems Affected== | ==Systems Affected== | ||
| − | + | In MHDS, the Document Registry is part of a Document Sharing Health Information Exchange (HIE). See Figure X.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. | |
| − | + | [[File:MHDS-Detailed.PNG|1000px]] | |
| − | |||
| − | |||
| − | |||
| − | + | The Document Sharing Health Information Exchange will also host a set of Services based on IHE Profiles as shown in Figure X.1.1-2. 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. 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. | ||
| + | |||
| + | ===Options=== | ||
| + | * 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) | ||
| + | * 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 | ||
==Specification== | ==Specification== | ||
| − | '''Profile Status:''' [[Comments| | + | '''Profile Status:''' [[Comments| Trial Implementation]] |
| − | |||
'''Documents:''' | '''Documents:''' | ||
| + | https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHDS.pdf | ||
| − | '' | + | '''Video Introduction: '''' |
| − | + | [https://youtu.be/CX8q4hThmII Youtube intro] | |
| − | [ | ||
| − | |||
| − | |||
| − | |||
'''Underlying Standards:''' | '''Underlying Standards:''' | ||
| − | + | * FHIR | |
| − | |||
| − | |||
| − | |||
| − | |||
==See Also== | ==See Also== | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
See https://github.com/IHE/IT-Infrastructure/tree/master/MHDS for draft under development | See https://github.com/IHE/IT-Infrastructure/tree/master/MHDS for draft under development | ||
| Line 106: | Line 85: | ||
[[Category:FHIR]] | [[Category:FHIR]] | ||
[[Category:DocShare]] | [[Category:DocShare]] | ||
| − | |||
Revision as of 14:05, 29 May 2020
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.
Summary
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
Benefits
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.
Details
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. Figure X.1-1 shows a detailed Actor diagram for the MHDS Document Registry.
The Document Registry is grouped with a set of actors from other profiles.
- 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.
Systems Affected
In MHDS, the Document Registry is part of a Document Sharing Health Information Exchange (HIE). See Figure X.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 Document Sharing Health Information Exchange will also host a set of Services based on IHE Profiles as shown in Figure X.1.1-2. 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. 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.
Options
- 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)
- 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
Specification
Profile Status: Trial Implementation
Documents: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHDS.pdf
Video Introduction: ' Youtube intro
Underlying Standards:
- FHIR
See Also
See https://github.com/IHE/IT-Infrastructure/tree/master/MHDS for draft under development
This page is based on the Profile Overview Template