Safeguard API for Smart FOX
4.2.3-current - ci-build
Safeguard API for Smart FOX
4.2.3-current - ci-build
Safeguard API for Smart FOX - Local Development build (v4.2.3-current) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
For the Smart FOX Projekt the Safeguard was invented, an anonymization and pseudonymization gateway, using tools like MaLaC-HD and EUPID to retrieve original health data, process it and store it in a FOX BOX.
For the API of the Safeguard, a slightly adapted IHE MHD profile is beeing used and published here, adding the Consent resource to the entry level.
As the IHE MHD profile is closed on the entry level, no further elements can be added if a official baseDefinition would be used to derive the original profiles. For that reason this fork has been created.
The only change can be found under the MHD Minimal Provide Document Bundle.
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 Health Information Exchange 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 document sharing (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, smart-phones, 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.
The transactions defined here leverage the document content- and format-agnostic metadata concepts that were initially developed for XDS but simplify them for access in constrained environments including mobile devices.
The MHD Profile can be used as an API to a Document Sharing exchange using XDS or XCA. The MHD Profile is used by the MHDS Document Sharing solution. The MHD Profile can be used in push solutions alone or as an API to solutions like XDR or XDM. These are further elaborated in Cross Profile Considerations.
The Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile combines MHD with the PCC Query for Existing Data for Mobile (QEDm) Profile to provide element level access to the medical information available in a Document Sharing exchange. More details can be found in the white paper on Document Sharing Health Information Exchange.
MHD is part of IHE – IT-Infrastructure Domain and part of the IHE Document Sharing Health Information Exchange solution.
| Significant Changes, Open and Closed Issues |
MHD is updated by Internet User Authorization (IUA) to add specific scope values to be used when grouped with IUA.
This guide is organized into the following sections:
Click on any of the links above, see the Table of Contents, or if you are looking for a specific artifact, see the index of Artifacts.
MHD defines Must Support in StructureDefinition profiles as the element, when the minimal cardinality is zero, is R2 Required if Known, as found in Appendix Z. Must Support when the element minimal cardinality is not zero means R.