Difference between revisions of "Mobile access to Health Documents (MHD)"

From IHE Wiki
Jump to navigation Jump to search
(31 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
__TOC__
 
__TOC__
 +
 +
 +
==Status==
 +
The IHE MHD profile and the HL7 FHIR activities are working together to revise and enhance the transactions profiled here. For details on HL7 FHIR See http://hl7.org/fhir
  
  
 
==Summary==
 
==Summary==
  
−
'''Mobile access to Health Documents (MHD)''' profile defines a simple HTTP interface to an XDS like environment. It defines transactions to a) submit a new document and metadata from the mobile device to a document receiver, b) get the metadata for an identified document, c) find document entries containing metadata based on query parameters, and d) retrieve a copy of a specific document. 
+
'''Mobile access to Health Documents (MHD)''' profile defines a simple HTTP interface to a [[Document Sharing]] environment. The MHD profile is intended for any system that prefers the simplified HTTP RESTful technology rather than the more robust technology used in XDS. It defines transactions to
−
These transactions leverage the document content and format agnostic metadata concepts from XDS, but simplify them for access by constrained environments such as mobile devices. The MHD profile does not replace XDS.  It can be used to allow mobile devices constrained access to an XDS health information exchange. The following figure shows one possible way to implement MHD with a document sharing environment (that may, but is not necessarily, XDS based). This implementation choice is not mandatory and we recognize other architectures will be implemented. An Implementation Guide is being maintained at [http://wiki.ihe.net/index.php?title=mHealthDossier_Guide mHealth Dossier Guide].
+
# submit a set of documents and metadata from the mobile device to a document receiver,  
 +
# find the document submission set metadata based on query parameters;
 +
# find document entries containing metadata based on query parameters, and  
 +
# retrieve a copy of a specific document.
  
 +
These transactions leverage the document content and format agnostic metadata concepts from XDS, but simplify them for access by constrained environments such as mobile devices, or other resource constrained systems. The MHD profile does not replace XDS.  It can be used to allow mobile devices, or other resource constrained systems, access to an XDS health information exchange. The following figure shows one possible way to implement MHD with a document sharing environment (that may, but is not necessarily, XDS based). This implementation choice is not mandatory and we recognize other architectures will be implemented.
  
 
==Benefits==
 
==Benefits==
  
 
'''RESTful interface to XDS and other Document Sharing environments'''
 
'''RESTful interface to XDS and other Document Sharing environments'''
−
The XDS profile is specifically designed to support the needs of Cross-Enterprise security, privacy, interoperability, and includes characteristics to support this level of policy and operational needs. The MHD profile has simplified the interactions in ways that are more consistent with a single policy domain use. The MHD transactions are not specifically tied to XDS, and some of the system implementations envisioned would interface directly to an organizational EHR, or a multi-national PHR.
 
  
−
The following lists a few examples of the environments which might choose to use the MHD profile instead of the XDS profile. The MHD profile supports a broad set of the XDS use cases and functionality while keeping the technology as simple as possible. The MHD profile is focused on a useful subset of the use-cases that XDS supports and does not try to reproduce the full scalability, flexibility, privacy, or security supported by the more robust XDS infrastructure.
+
The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. The transactions defined here leverage the document content- and format-agnostic metadata concepts from XDS, but simplify them for access in constrained environments including mobile devices. The MHD Profile does not replace XDS. Mobile devices, and other resource-constrained systems, can use MHD to access to an XDS Repository. The following figure shows one possible way to implement MHD within a document sharing environment (that may be, but is not necessarily, XDS-based). This implementation choice is not mandatory and we recognize other architectures will be implemented.
 +
 
 +
The XDS Profile has separated Document Registry and Document Repository to support the needs of Cross-Enterprise deployment architectures and enable robustness, security, privacy, and interoperability. The MHD Profile has simplified the interactions in ways that are more consistent with use within a single policy domain. MHD transactions are not specifically tied to XDS; some of the system implementations envisioned may interface directly to an organizational EHR, or a multi-national PHR.
 +
 
 +
The MHD Profile supports a broad set of XDS use cases and functionality while keeping the technology as simple as possible. MHD focuses on a useful subset of the XDS use cases and does not try to reproduce the full scalability, flexibility, privacy, or security supported by the more robust XDS infrastructure. The following are examples of environments which may choose the MHD Profile over the XDS Profile:
 +
 
 
* Medical devices such as those targeted by the Patient Care Devices (PCD) domain or Continua organization, submitting data in the form of documents.
 
* Medical devices such as those targeted by the Patient Care Devices (PCD) domain or Continua organization, submitting data in the form of documents.
 
* Kiosks used by patients in hospital registration departments, where it is anticipated that a hospital staff member will review, edit, and approve the document before it is allowed into the hospital system.  
 
* Kiosks used by patients in hospital registration departments, where it is anticipated that a hospital staff member will review, edit, and approve the document before it is allowed into the hospital system.  
 
* PHR publishing into a staging area for subsequent import into an EHR or HIE.
 
* PHR publishing into a staging area for subsequent import into an EHR or HIE.
−
* Patient or provider application that is configured to securely connect to a PHR in order to submit a medical history document.
+
* Patient or provider application that is configured to securely connect to a PHR in order to submit a medical history document. (For example BlueButton+)
 
* Electronic measurement device participating in an XDW workflow and pulling medical history documents from an HIE.
 
* Electronic measurement device participating in an XDW workflow and pulling medical history documents from an HIE.
 
* A General Practitioner physician’s office with minimal IT capabilities using a mobile application to connect to an HIE or EHR.
 
* A General Practitioner physician’s office with minimal IT capabilities using a mobile application to connect to an HIE or EHR.
Line 23: Line 35:
 
==Details==
 
==Details==
  
−
Applications specific to mobile device is an emerging platform for healthcare enhancing software. These devices are resource and platform constrained, which drives the implementer to use simpler network interface technology. There are numerous uses of documents, for example hosted by a Health Information Exchange (HIE), large health provider electronic health record (EHR), or personal health record (PHR).  
+
Applications specific to resource-constrained and mobile devices are an emerging platform for healthcare-enhancing software. The MHD Profile is not limited to mobile devices, using the term “mobile” only as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained. These constraints may drive the implementer to use simpler network interface technology. There are numerous deployed implementations of Document Sharing that need a simpler network interface technology, for example those hosted by a Health Information Exchange (HIE), large health provider electronic health record (EHR), or personal health record (PHR).  
 +
 
 +
The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. In this context, mobile devices include tablets, smartphones, and embedded devices including home-health devices. This profile is also applicable to more capable systems where needs are simple, such as pulling the latest summary for display. The critical aspects of the ‘mobile device’ are that it is resource-constrained, has a simple programming environment (e.g., JSON, JavaScript), simple protocol stack (e.g., HTTP), and simple display functionality (e.g., HTML browser). The goal is, in part, to avoid burdening the client with additional libraries such as those that are necessary to process SOAP, WSSE, MIME-Multipart, MTOM/XOP, ebRIM, and multi-depth XML.
 +
 
 +
The Mobile access to Health Documents (MHD) Profile defines one pair of actors and a transaction to submit or push new “document entries” from the mobile device to a receiving system. Another set of actors and transactions is used to query a list of “document entries” having specific metadata, and to retrieve a document.
 +
 
 +
This profile leverages the metadata concepts from XDS, but simplifies the transaction requirements for access by mobile devices.
 +
The MHD Profile does not replace XDS. Rather, it enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.
 +
 
  
−
The Mobile access to Health Documents (MHD) profile defines one standardized interface to health documents for use by mobile devices so that deployment of mobile applications is more consistent and reusable. In this context, mobile devices include tablets and smart-phones, plus embedded devices like home-health devices. This profile is also applicable to larger systems where the needs are simple, such pulling the latest summary for display. The critical aspects of the ‘mobile device’ are that it is resource constrained, has a simple programming environment (e.g., JSON, javascript), simple network stack (e.g., HTTP), and simple display functionality (e.g., HTML browser). The goal is to limit the additional libraries that are necessary to process SOAP, WSSE, MIME-Multipart, MTOM/XOP, ebRIM, and multi-depth XML.  
+
===Options===
 +
Two options are defined
 +
* Comprehensive Metadata -- Indicates that the actors will abide by the XDS definition of metadata cardinality (not minimal metadata)
 +
* XDS on FHIR -- Indicates that the actors are expecting XDS implementation behind the Document Responder and Document Recipient.  
  
−
The Mobile access to Health Documents (MHD) profile defines actors and transactions. There is one set of actors and a transaction used to submit a single new document entry from the mobile device to a receiving system. The other set of actors and transactions is used to get a list of document entries containing metadata, and to retrieve a copy of a specific document. 
+
===Proxy Service===
  
−
These transactions leverage the metadata concepts from XDS, but simplify the technology requirements for access by mobile devices. The MHD profile defines a Document Dossier that is focused on the Document Entry as defined by XDS with all the related metadata including Submission Sets, Folders, and Associations. The MHD profile does not replace XDS. It enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.
+
One deployment model is to use the MHD as a FHIR based API to XDS, thus more friendly to applications. This is defined as the "XDS on FHIR" Option. In this option the MHD Document Responder is responsible for converting the XDS metadata into MHD metadata. This Document Responder is thus responsible for setting the DocumentReference.content.attachment.url so that a Document Consumer simply requests the document from that URL. This URL is fully in the control of the Document Responder. Thus the Document Responder might choose to encode the XDS Document Repository ID and the Document UniqueID into the URL. It might encode them as query parameters in a URL. The Document Responder might alternatively use UUIDs that it keeps a mapping table. The URL might be rooted at the same or a different server endpoint as the Document Responder. The important point is that the Document Responder is empowered to fill the URL anyway it wants. The URL must simply be used by the Document Consumer, meaning the Document Consumer shall not try to interpret the URL, it should just GET.
  
 +
[[Image:Slide1.PNG]]
  
 
==Systems Affected==
 
==Systems Affected==
Line 40: Line 64:
 
'''Actors & Transactions:'''
 
'''Actors & Transactions:'''
  
−
[[image:MHD_Actors_Transactions.png|thumbnail|center|600px|'''Figure 33.1-1 MHD Actor Diagram''']]
+
[[file:MHD_Actors_Transactions.PNG|thumbnail|center|400px|'''Figure 33.1-1 MHD Actor Diagram''']]
  
 
==Specification==
 
==Specification==
Line 47: Line 71:
  
 
'''Documents:'''  
 
'''Documents:'''  
−
[http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_MHD.pdf MHD Supplement]
+
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement]
 +
 
 +
'''Additional Supplements:'''
 +
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]
  
 
'''Underlying Standards:'''
 
'''Underlying Standards:'''
 +
* HL7 FHIR STU3 http://hl7.org/fhir/STU3
 +
** DocumentReference
 +
** DocumentManifest
 +
** List
 +
** Patient
 +
** Practitioner
 +
** OperationOutcome
 +
** Bundle
 
* RFC2616 IETF Hypertext Transfer Protocol – HTTP/1.1
 
* RFC2616 IETF Hypertext Transfer Protocol – HTTP/1.1
 
* RFC3986 IETF Uniform Resource Identifier (URI): Generic Syntax
 
* RFC3986 IETF Uniform Resource Identifier (URI): Generic Syntax
 
* RFC4627 The application/json Media Type for JavaScript Object Notation (JSON)
 
* RFC4627 The application/json Media Type for JavaScript Object Notation (JSON)
 
* RFC6585 IETF Additional HTTP Status Codes
 
* RFC6585 IETF Additional HTTP Status Codes
−
* RFC4287 The Atom Syndication Format
+
 
 +
==FHIR Implementation Guide==
 +
Informatively this profile is also published on Simplifier as a set of StructureDefinitions
 +
* [https://simplifier.net/IHEPatientDemographi/IHEMHD IHE MHD Implementation Guide]
 +
* [https://simplifier.net/IHEPatientDemographi/IHEMHDProvideDocumentBundle IHE MHD Provide Document Bundle Transaction]
 +
* [https://simplifier.net/IHEPatientDemographi/IHEMHDDocumentReference-2 IHE MHD DocumentReference] as XDS DocumentEntry
 +
* [https://simplifier.net/IHEPatientDemographi/IHEMHDDocumentManifest-2 IHE MHD DocumentManifest] as XDS SubmissionSet
 +
* [https://simplifier.net/IHEPatientDemographi/IHEMHDList-2 IHE MHD List] as XDS Document Folder
 +
 
 +
The conformance resources are also available on the [[Implementation Material]] folder.
 +
 
 +
==Test Tools==
 +
See [[IHE Test Tool Information]]
  
 
==See Also==
 
==See Also==
  
−
This profile supports the security/privacy model discussed in [[IHE Security and Privacy for HIE]] white paper.
+
This profile supports the security/privacy model discussed in [[Health Information Exchange: Enabling Document Sharing Using IHE Profiles]] white paper.
−
 
 
−
This is a work item in 2012. The draft documents can be found on the FTP in the following folder
 
−
* ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr10-2012-2013/Technical_cmte/WorkItems/DocumentsForMobileHealthSupplement/
 
  
−
An Implementation Guide is being maintained at [http://wiki.ihe.net/index.php?title=mHealthDossier_Guide mHealth Dossier Guide].
 
  
 
'''Related Profiles'''
 
'''Related Profiles'''
  
−
* Profile Proposal for 2013 on Mobile Application Authentication and Authorization.
+
* [[PDQm]] -- provides HTTP (RESTful) equivalent to [[PDQ]] and [[PDQv3]]; and basis set of FHIR methods and data-types
 +
* [[IUA]] -- provides user token security for HTTP (RESTful) transactions
  
 
This page is based on the [[Profile Template]]
 
This page is based on the [[Profile Template]]
Line 73: Line 117:
 
[[Category:Profiles]]
 
[[Category:Profiles]]
 
[[Category:ITI Profile]]
 
[[Category:ITI Profile]]
 +
[[category:FHIR]]
 +
[[Category:DocShare]]
  
 
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].
 
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].

Revision as of 14:59, 3 November 2017


Status

The IHE MHD profile and the HL7 FHIR activities are working together to revise and enhance the transactions profiled here. For details on HL7 FHIR See http://hl7.org/fhir


Summary

Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to a Document Sharing environment. The MHD profile is intended for any system that prefers the simplified HTTP RESTful technology rather than the more robust technology used in XDS. It defines transactions to

  1. submit a set of documents and metadata from the mobile device to a document receiver,
  2. find the document submission set metadata based on query parameters;
  3. find document entries containing metadata based on query parameters, and
  4. retrieve a copy of a specific document.

These transactions leverage the document content and format agnostic metadata concepts from XDS, but simplify them for access by constrained environments such as mobile devices, or other resource constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource constrained systems, access to an XDS health information exchange. The following figure shows one possible way to implement MHD with a document sharing environment (that may, but is not necessarily, XDS based). This implementation choice is not mandatory and we recognize other architectures will be implemented.

Benefits

RESTful interface to XDS and other Document Sharing environments

The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. The transactions defined here leverage the document content- and format-agnostic metadata concepts from XDS, but simplify them for access in constrained environments including mobile devices. The MHD Profile does not replace XDS. Mobile devices, and other resource-constrained systems, can use MHD to access to an XDS Repository. The following figure shows one possible way to implement MHD within a document sharing environment (that may be, but is not necessarily, XDS-based). This implementation choice is not mandatory and we recognize other architectures will be implemented.

The XDS Profile has separated Document Registry and Document Repository to support the needs of Cross-Enterprise deployment architectures and enable robustness, security, privacy, and interoperability. The MHD Profile has simplified the interactions in ways that are more consistent with use within a single policy domain. MHD transactions are not specifically tied to XDS; some of the system implementations envisioned may interface directly to an organizational EHR, or a multi-national PHR.

The MHD Profile supports a broad set of XDS use cases and functionality while keeping the technology as simple as possible. MHD focuses on a useful subset of the XDS use cases and does not try to reproduce the full scalability, flexibility, privacy, or security supported by the more robust XDS infrastructure. The following are examples of environments which may choose the MHD Profile over the XDS Profile:

  • Medical devices such as those targeted by the Patient Care Devices (PCD) domain or Continua organization, submitting data in the form of documents.
  • Kiosks used by patients in hospital registration departments, where it is anticipated that a hospital staff member will review, edit, and approve the document before it is allowed into the hospital system.
  • PHR publishing into a staging area for subsequent import into an EHR or HIE.
  • Patient or provider application that is configured to securely connect to a PHR in order to submit a medical history document. (For example BlueButton+)
  • Electronic measurement device participating in an XDW workflow and pulling medical history documents from an HIE.
  • A General Practitioner physician’s office with minimal IT capabilities using a mobile application to connect to an HIE or EHR.

Details

Applications specific to resource-constrained and mobile devices are an emerging platform for healthcare-enhancing software. The MHD Profile is not limited to mobile devices, using the term “mobile” only as a grouping for mobile applications, mobile devices or any other systems that are resource and platform-constrained. These constraints may drive the implementer to use simpler network interface technology. There are numerous deployed implementations of Document Sharing that need a simpler network interface technology, for example those hosted by a Health Information Exchange (HIE), large health provider electronic health record (EHR), or personal health record (PHR).

The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. In this context, mobile devices include tablets, smartphones, and embedded devices including home-health devices. This profile is also applicable to more capable systems where needs are simple, such as pulling the latest summary for display. The critical aspects of the ‘mobile device’ are that it is resource-constrained, has a simple programming environment (e.g., JSON, JavaScript), simple protocol stack (e.g., HTTP), and simple display functionality (e.g., HTML browser). The goal is, in part, to avoid burdening the client with additional libraries such as those that are necessary to process SOAP, WSSE, MIME-Multipart, MTOM/XOP, ebRIM, and multi-depth XML.

The Mobile access to Health Documents (MHD) Profile defines one pair of actors and a transaction to submit or push new “document entries” from the mobile device to a receiving system. Another set of actors and transactions is used to query a list of “document entries” having specific metadata, and to retrieve a document.

This profile leverages the metadata concepts from XDS, but simplifies the transaction requirements for access by mobile devices. The MHD Profile does not replace XDS. Rather, it enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.


Options

Two options are defined

  • Comprehensive Metadata -- Indicates that the actors will abide by the XDS definition of metadata cardinality (not minimal metadata)
  • XDS on FHIR -- Indicates that the actors are expecting XDS implementation behind the Document Responder and Document Recipient.

Proxy Service

One deployment model is to use the MHD as a FHIR based API to XDS, thus more friendly to applications. This is defined as the "XDS on FHIR" Option. In this option the MHD Document Responder is responsible for converting the XDS metadata into MHD metadata. This Document Responder is thus responsible for setting the DocumentReference.content.attachment.url so that a Document Consumer simply requests the document from that URL. This URL is fully in the control of the Document Responder. Thus the Document Responder might choose to encode the XDS Document Repository ID and the Document UniqueID into the URL. It might encode them as query parameters in a URL. The Document Responder might alternatively use UUIDs that it keeps a mapping table. The URL might be rooted at the same or a different server endpoint as the Document Responder. The important point is that the Document Responder is empowered to fill the URL anyway it wants. The URL must simply be used by the Document Consumer, meaning the Document Consumer shall not try to interpret the URL, it should just GET.

Slide1.PNG

Systems Affected

Systems involved in this profile are:

  • Any application or service that would like to use RESTful interactions for Document Sharing.

Actors & Transactions:

Figure 33.1-1 MHD Actor Diagram

Specification

Profile Status: Trial Implementation

Documents: MHD Supplement

Additional Supplements: Appendix Z on HL7 FHIR

Underlying Standards:

  • HL7 FHIR STU3 http://hl7.org/fhir/STU3
    • DocumentReference
    • DocumentManifest
    • List
    • Patient
    • Practitioner
    • OperationOutcome
    • Bundle
  • RFC2616 IETF Hypertext Transfer Protocol – HTTP/1.1
  • RFC3986 IETF Uniform Resource Identifier (URI): Generic Syntax
  • RFC4627 The application/json Media Type for JavaScript Object Notation (JSON)
  • RFC6585 IETF Additional HTTP Status Codes

FHIR Implementation Guide

Informatively this profile is also published on Simplifier as a set of StructureDefinitions

The conformance resources are also available on the Implementation Material folder.

Test Tools

See IHE Test Tool Information

See Also

This profile supports the security/privacy model discussed in Health Information Exchange: Enabling Document Sharing Using IHE Profiles white paper.


Related Profiles

  • PDQm -- provides HTTP (RESTful) equivalent to PDQ and PDQv3; and basis set of FHIR methods and data-types
  • IUA -- provides user token security for HTTP (RESTful) transactions

This page is based on the Profile Template

Current: IT Infrastructure Technical Framework.

Retrieved from "http://wiki.ihe.net/index.php?title=Mobile_access_to_Health_Documents_(MHD)&oldid=105692"