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

From IHE Wiki
Jump to navigation Jump to search
 
(47 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
This work item strives to revise the [[MHD]] profile supplement to align with the HL7 FHIR standard that has entered DSTU phase.  
 
This work item strives to revise the [[MHD]] profile supplement to align with the HL7 FHIR standard that has entered DSTU phase.  
  
−
== Areas where details need to be worked out ==
+
== Working directory ==
 +
using the IHE ftp site
 +
ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr13-2015-2016/Technical_Cmte/Workitems/MHD2/
 +
 
 +
Minutes are found on the [http://wiki.ihe.net/index.php?title=Talk:Mobile_access_to_Health_Documents_-_Supplement_revision_2 Discussion]
 +
 
 +
Discussion on a google group mailing list https://groups.google.com/forum/#!forum/ihe-mhd-implementors
 +
 
 +
historic directory from 2014 on the IHE ftp site
 +
ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/
 +
 
 +
== Current supplement development Status ==
 +
 
 +
Current revision
 +
ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr13-2015-2016/Technical_Cmte/Workitems/MHD2/IHE_ITI_Suppl_MHD_20141211.docx
 +
 
 +
This text was approved December 15th by the ITI Technical Committee for "Public Comment".
 +
 
 +
== T-Con ==
 +
Next meeting: January 16, 2014
 +
 
 +
* Bi-Weekly: Fridays at 8:00am Central Time
 +
* Meeting Number: 923 974 696
 +
* Meeting Password: Meeting1
 +
* Go to https://himss.webex.com/himss/j.php?MTID=m9baa09403beb70859f87d353622f515c
 +
* Call-in toll-free number (US/Canada): 1-866-469-3239
 +
* Call-in toll number (US/Canada): 1-650-429-3300
 +
* Global call-in numbers: https://himss.webex.com/himss/globalcallin.php?serviceType=MC&ED=278021212&tollFree=1
 +
* Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf
 +
 
 +
== Connectathon - New Directions ==
 +
At Connectathon in Cleveland, there will be a 2 day "New Directions" testing of MHD. The MHD profile is not yet in Trial Implementation, so it can't be part of the full Connectathon, however we want to get some testing done so that we can make the MHD profile better. There are a few companies signed up for this testing, with various commitments of actors they will implement.
 +
 
 +
Bill has an MHD Document Recipient ready to be tested against by anyone implementing an MHD Document Source
 +
* http://ihexds.nist.gov:12093/xdstools3/#TabPlace:MHD_VALIDATOR
 +
 
 +
Those Signed up for New Directions testing
 +
* Relay Health
 +
** MHD Document Consumer
 +
* Qvera
 +
** MHD Document Source
 +
** MHD Document Recipient
 +
* Allscripts
 +
** MHD Document Source
 +
** MHD Document Consumer
 +
* CareEvolution
 +
** MHD Document Source
 +
* Caradigm
 +
** Unknown
 +
 
 +
== Decisions ==
 +
* Supplement published on the external IHE web site -- www.ihe.net -- will be updated with the new Volume 1 material, and have Volume 2 material removed so as to not cause people to implement original MHD transaction model. The new supplement will point at [[MHD Status]] for status updates.
 +
* We presume current DSTU must be used as-is.
 +
** MHD will need to use extensions where current DSTU is insufficient
 +
* Only FindDocuments, FindDocumentsByReferenceId and FindSubmissionSets will be supported on query.
 +
* Current focus on Volume 2 transactions and minimal guidance to data element cross-reference
 +
** Detailed data element text will continue to be developed on the wiki
 +
** [[MHD-rev2-vol-3|MHD Volume 3 (draft)]]
 +
 
 +
== Detailed work and notes ==
 
* Mapping each XDS object/attribute to FHIR, and back
 
* Mapping each XDS object/attribute to FHIR, and back
 
** Bill Majurski
 
** Bill Majurski
 +
** [[FHIR-XDS-terminology|FHIR Terminology for XDS Dummies]]
 +
** [[Bills-FHIR-page|Bills FHIR Page]]
 +
** [[XDS-FHIR-mapping|Mapping XDS Attributes to FHIR]]
 +
** [[MHD-rev2-vol-3|MHD Volume 3 (draft)]]
 +
** [[MHD Implementation Guide]]
 
* Scope of MHD vs FHIR
 
* Scope of MHD vs FHIR
 
** John Moehrke
 
** John Moehrke
Line 13: Line 77:
 
* FHIR Provenance Resource Mapping
 
* FHIR Provenance Resource Mapping
 
** Rob Horn
 
** Rob Horn
−
* Transport Pattern Mapping
+
* [[Transport Pattern Mapping]]
 
** Walco Van Loon
 
** Walco Van Loon
 
** FHIR has many transaction patterns -- REST, Mailbox, etc.
 
** FHIR has many transaction patterns -- REST, Mailbox, etc.
Line 24: Line 88:
 
** Erik Pupo
 
** Erik Pupo
  
−
== Working directory ==
+
==Extensions==
−
using the IHE ftp site
+
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.
−
ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/
+
 
 +
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
 +
 
 +
The MHD profile is a 'profile' of FHIR to meet the XDS use-cases. Therefore it will constrain the use of FHIR to only those use-cases and support of XDS. Therefore any 'extra' stuff that is not explicitly included  in the MHD specification can/should/shall be ignored or cause an error. I would suggest we recommend failure, allowing success.
 +
--John
 +
 
 +
== 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.
 +
 
 +
I recommend that for MHD we only try to support FindDocuments and FindSubmissionSets. This is what Volume 1 has already scoped. This doesn't mean that the other stored queries can't be supported, but it is not clear the urgency of them. Note that FHIR can handle multiple type returns fine, as each resource is self-describing. -- John
  
−
Minutes are found on the [http://wiki.ihe.net/index.php?title=Talk:Mobile_access_to_Health_Documents_-_Supplement_revision_2 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 ==
+
=HL7 FHIR=
 
* The root http://hl7.org/fhir
 
* The root http://hl7.org/fhir
 
* This is the library of all currently defined ‘resources’ http://hl7.org/implement/standards/fhir/resourcelist.html
 
* This is the library of all currently defined ‘resources’ http://hl7.org/implement/standards/fhir/resourcelist.html
Line 50: Line 119:
 
*** List
 
*** List
 
* Here is the “Profile” that Grahame did inside of FHIR of how [http://www.hl7.org/implement/standards/fhir/xds-profile.html FHIR can map to XDS]  
 
* Here is the “Profile” that Grahame did inside of FHIR of how [http://www.hl7.org/implement/standards/fhir/xds-profile.html FHIR can map to XDS]  
 +
* David Hay has produced some very nice blog articles on the topic of MHD. These were written back last year so might have some old concepts. They are good to guide us as David has a very strong understanding of FHIR.
 +
** [http://fhirblog.com/2013/11/19/getting-documents-from-a-fhir-xds-infrastructure/ FindDocuments description]
 +
** [http://fhirblog.com/2013/11/12/the-fhir-documentreference-resource/ DocumentReference description]
 +
** [http://fhirblog.com/2013/11/06/fhir-and-xds-submitting-a-document-from-a-document-source/ ProvideDocumentResources description]
 +
** more at http://fhirblog.com/category/xds/
 
* Note also specific to a future effort on ATNA
 
* Note also specific to a future effort on ATNA
 
** SecurityEvent
 
** SecurityEvent
 +
 +
== FHIR Change Proposals ==
 +
 +
* There are some [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677&tracker_query_id=4972 HL7 FHIR Change Proposals] proposed to DSTU1 for fixing items
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3728 #3728 Replace Atom with a FHIR specific bundle that is not based or constrained by Atom]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3452 #3452 DocumentReference should include practiceSettingCode ]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3213 #3213 DocumentReference author needs to be multiple]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=2972 #2972 DocumentReference.description be renamed to DocumentReference.title for consistency with Composition.title]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3281 #3281 better description of hash]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3359 #3359 documentreference should support structured]
 +
** [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3771 #3771 DocumentReference use of class and type need better alignment with IHE XDS]

Latest revision as of 06:43, 11 July 2017

This work item strives to revise the MHD profile supplement to align with the HL7 FHIR standard that has entered DSTU phase.

Working directory

using the IHE ftp site ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr13-2015-2016/Technical_Cmte/Workitems/MHD2/

Minutes are found on the Discussion

Discussion on a google group mailing list https://groups.google.com/forum/#!forum/ihe-mhd-implementors

historic directory from 2014 on the IHE ftp site ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/

Current supplement development Status

Current revision ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr13-2015-2016/Technical_Cmte/Workitems/MHD2/IHE_ITI_Suppl_MHD_20141211.docx

This text was approved December 15th by the ITI Technical Committee for "Public Comment".

T-Con

Next meeting: January 16, 2014

Connectathon - New Directions

At Connectathon in Cleveland, there will be a 2 day "New Directions" testing of MHD. The MHD profile is not yet in Trial Implementation, so it can't be part of the full Connectathon, however we want to get some testing done so that we can make the MHD profile better. There are a few companies signed up for this testing, with various commitments of actors they will implement.

Bill has an MHD Document Recipient ready to be tested against by anyone implementing an MHD Document Source

Those Signed up for New Directions testing

  • Relay Health
    • MHD Document Consumer
  • Qvera
    • MHD Document Source
    • MHD Document Recipient
  • Allscripts
    • MHD Document Source
    • MHD Document Consumer
  • CareEvolution
    • MHD Document Source
  • Caradigm
    • Unknown

Decisions

  • Supplement published on the external IHE web site -- www.ihe.net -- will be updated with the new Volume 1 material, and have Volume 2 material removed so as to not cause people to implement original MHD transaction model. The new supplement will point at MHD Status for status updates.
  • We presume current DSTU must be used as-is.
    • MHD will need to use extensions where current DSTU is insufficient
  • Only FindDocuments, FindDocumentsByReferenceId and FindSubmissionSets will be supported on query.
  • Current focus on Volume 2 transactions and minimal guidance to data element cross-reference

Detailed work and notes

  • 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

The MHD profile is a 'profile' of FHIR to meet the XDS use-cases. Therefore it will constrain the use of FHIR to only those use-cases and support of XDS. Therefore any 'extra' stuff that is not explicitly included in the MHD specification can/should/shall be ignored or cause an error. I would suggest we recommend failure, allowing success. --John

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.

I recommend that for MHD we only try to support FindDocuments and FindSubmissionSets. This is what Volume 1 has already scoped. This doesn't mean that the other stored queries can't be supported, but it is not clear the urgency of them. Note that FHIR can handle multiple type returns fine, as each resource is self-describing. -- John


HL7 FHIR

FHIR Change Proposals

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