Mobile access to Health Documents - Supplement revision 2
This work item strives to revise the MHD profile supplement to align with the HL7 FHIR standard that has entered DSTU phase.
Current Status and Directions
- Mapping each XDS object/attribute to FHIR, and back
- Scope of MHD vs FHIR
- John Moehrke
- Reevaluation of target audience. Are the limitations we put into MHD still the right limitations, or should we relax them if we can?
- Rationalize IHE specifically only providing JSON, yet FHIR has both.
- MHD supports only one document in one submissionSet
- MHD does one transaction to publish
- do we add Options to MHD to support more complex interactions?
- FHIR Provenance Resource Mapping
- Rob Horn
- Transport Pattern Mapping
- Walco Van Loon
- FHIR has many transaction patterns -- REST, Mailbox, etc.
- Publication in MHD is one transaction
- Analysis of FHIR and IHE Lifecycle
- Erik Pupo
- How to handle PatientInfo, as FHIR would tend to simply update a master PatientInfo where in XDS this information is stored as is.
- Document relationships
- Tracking and Monitoring of business level changes (politics) and outreach
- Erik Pupo
Extensions
FHIR has a formal mechanism for transporting extensions, where XDS allows for additional slots with minimal management of namespace using well formed URN. Therefore we need to provide guidance on how a FHIR extension would be handled by an XDS environment; and also how an XDS extension would be handled in a proper FHIR extension. Going from FHIR to XDS is likely more deterministic, where as it is not clear how one would create a proper FHIR extension when a proxy implementation sees a proper XDS new slot.
There are three categories of extensions to be considered:
- Some FHIR extensions will be required to have the DocumentReference resource act as a suitable container for the existing DocumentEntry content. These are created in the base translation from ebRIM to FHIR.
- Translation of Extra Slots in the ebRIM binding to FHIR extensions.
- Translation of FHIR extensions (not including the first category above) to Extra Slots
It is possible to spec out a bi-directional translation mechanism that will not incur any loss. --bill
Queries
ITI-18 queries fall into two categories when viewed through FHIR: single return type and multiple return type. Single return type queries are those that return only a single object type. Examples are FindDocuments (returns only DocumentEntries) , FindSubmissionSets (return only SubmissionSets), GetDocuments (returns only DocumentEntries). Multiple return type queries are those that return a mixture of different object types. Examples are GetSubmissionSetAndContents (returns SubmissionSet, DocumentEntry, Folder, and Association types). Basic FHIR queries are defined on a resource type like DocumentReference. So a query anchored by DocumentReference only returns DocumentReferences. These single return type queries are defined on REST as HTTP GET. For multiple return type queries we must use a different FHIR mechanism called messages which has a more complicated style coding. We could define all queries on messages but then the value of simplicity of HTTP GET is lost.
Working directory
using the IHE ftp site ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/
Minutes are found on the Discussion
Sub-Workgroup meeting
- 8:00 AM – 9:30 AM CT
- MHD/FHIR Harmonization Working Session
- Every other Friday
- 90 minutes
- IHE ITI
- Starting on February 28th
Useful links into the HL7 FHIR specification
- The root http://hl7.org/fhir
- This is the library of all currently defined ‘resources’ http://hl7.org/implement/standards/fhir/resourcelist.html
- Specific to PDQm but will also be used in MHD
- Patient
- RelatedPerson
- Specific to MHD
- DocumentReference
- DocumentManifest
- Provenance
- List
- Specific to PDQm but will also be used in MHD
- Here is the “Profile” that Grahame did inside of FHIR of how FHIR can map to XDS
- Note also specific to a future effort on ATNA
- SecurityEvent