Difference between revisions of "Mobile access to Health Documents - Supplement revision 2"

From IHE Wiki
Jump to navigation Jump to search
Line 35: Line 35:
 
* Translation of FHIR extensions (not including the first category above) to Extra Slots
 
* 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
 
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 ==
 
== Working directory ==

Revision as of 13:55, 6 May 2014

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

Retrieved from "http://wiki.ihe.net/index.php?title=Mobile_access_to_Health_Documents_-_Supplement_revision_2&oldid=76674"