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

From IHE Wiki
Jump to navigation Jump to search
Line 8: Line 8:
  
 
== Current supplement development Status ==
 
== Current supplement development Status ==
 +
=== November 15 ===
 +
Latest document:
 +
ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/IHE_ITI_Suppl_MHD_20141115.docx
 +
 +
I have not addressed the Provide transaction.
 +
 +
From Walco --- If you could also look at the Provide Document Resources transaction in progress, and provide the same level of feedback, that would be great: http://wiki.ihe.net/index.php?title=MHD_Implementation_Guide#Transactions
 +
 +
Some detailed open questions:
 +
1) Currently just FindSubmissionSets and FindDocuments is modeled. Seems other Find*** queries might also already be satisfied…
 +
2) I have come across lots of fine details. I am suspecting there is still some things hiding.  We have many cross-references. I have documented below some differences that I couldn’t resolve.  The Supplement document is consistent internally, but not necessarly with Bill’s Wiki. I welcome others checking this work and identifying issues. The following is all these cross-references:
 +
a. Supplement
 +
i. FindManifests has a table FHIR.DocumentManifest-> XDS.SubmissionSet
 +
ii. FindDocuments has a table FHIR.DocumetReference->XDS.DocumentEntry
 +
iii. Volume 3 has a table XDS.DocumentEntry->FHIR.DocumentReference
 +
iv. Volume 3 has a table XDS.SubmissionSet->FHIR.DocumentManifest
 +
v. Volume 3 has a table XDS.Folder->FHIR.List
 +
b. Bill Wiki has description XDS -> FHIR
 +
3) How do we profile the use of _include for the Find transactions? I have explicitly defined it as NOT included in the profile
 +
a. Care must be taken with _include as it is likely not desirable to always _include superseded DocumentReferences.
 +
b. Might be useful with FindManifests to _include any DocumentReferences.
 +
c. Might be useful with FindDocuments to _include the document.
 +
4) Note there is still no way provided in this profile to query for Folders. I suggest we continue without this  capability for now. This was not part of MHD originally either.
 +
5) Seems the search parameter ‘date’ might need to be further explained in appendix Z. Today we rely on FHIR documentation alone. I suggest we leave this until after Public Comment. Unless someone wants to offer up text.
 +
6) Extension???? We need to resolve this difference. Bill has defined many extensions, where I have documented use of existing FHIR attributes.
 +
a. Bill, your volume 3 says that “comments” doesn’t map and needs an extension, but I think it maps nicely to “text” (both for DocumentEntry and SubmissionSet). 
 +
b. Bill, your volume 3 says that “homeCommunityId” doesn’t map and needs an extension, but I think it maps nicely to “identifier” with IdentiferUse=secondary.
 +
c. Bill, your volume 3 says that ‘sourcePatientId” and “sourcePatientInfo” doesn’t map and needs an extension, but for DocumentManifest I think it maps nicely to “subject” with a use of “official’ and ‘usual’. It does NOT work so well for DocumentReference. So later I started to think your solution was more consistent… Hmmm
 +
d. I think the only extensions we need are DocumentReference practiceSettingCode and referenceIdList.
 +
7) Notice  FindDocuments does not include a way to query for referenceIdList. This was not in original MHD scope, and because we need to use an extension to hold these values, we can’t query for them anyway.
 +
8) I noticed that there is no obvious way to support on-demand documents. So I just profiled them OUT!
 +
9) DocumentEntry PracticeSettingCode is missing from FHIR. It is not clear how to handle this
 +
a. It might be expected to be mashuped up with facilityType
 +
b. we can create an extension but then can’t support the query parameter from ITI-18 FindDocuments.
 +
c. I documented it as an extension, and thus not queryable.
 +
10) DocumentReference has both created and indexed. One is a dateTime the other an Instant. One is optional the other is mandatory. Not clear how to map this to creationTime.
 +
a. Given that created seems closer, I am using that primarily. But given that indexed is mandatory, I made that carry the same value.
 +
11) Dave noted that FHIR allows for _format values to be a broader list, where as we constrained the list in PDQm. The current MHD just follows the pattern given in PDQm. I didn’t want to deviate unless we do the change to both.
 +
12) Dave notes that more advice might be needed on bundle. MHD is just referring to the text that PDQm created for Appendix Z. I have no idea what more is needed, so I await someone to craft some language.
 +
13) I ran into a major problem around Patient Identifier in DocumentReference. FHIR set subject to 1..1. This leaves us with very little room to put the various patient information we have. I thin Bill solution might need to be
 +
 +
Our next meeting is Friday the 21st. We have two meetings left to complete this work and get it out to Public Comment in preparation for Connectathon/New-Directions.
 +
 
=== October 24 ===
 
=== October 24 ===
 
* Walco made progress on Provide transaction, see [http://wiki.ihe.net/index.php?title=MHD_Implementation_Guide#Provide_Document_Resources_.28ITI-.3F.3F.29 Mockup]
 
* Walco made progress on Provide transaction, see [http://wiki.ihe.net/index.php?title=MHD_Implementation_Guide#Provide_Document_Resources_.28ITI-.3F.3F.29 Mockup]

Revision as of 09:27, 18 November 2014

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/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/

Minutes are found on the Discussion

Current supplement development Status

November 15

Latest document: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr12-2014-2015/Technical_Cmte/Workitems/MHD2/IHE_ITI_Suppl_MHD_20141115.docx

I have not addressed the Provide transaction.

From Walco --- If you could also look at the Provide Document Resources transaction in progress, and provide the same level of feedback, that would be great: http://wiki.ihe.net/index.php?title=MHD_Implementation_Guide#Transactions

Some detailed open questions: 1) Currently just FindSubmissionSets and FindDocuments is modeled. Seems other Find*** queries might also already be satisfied… 2) I have come across lots of fine details. I am suspecting there is still some things hiding. We have many cross-references. I have documented below some differences that I couldn’t resolve. The Supplement document is consistent internally, but not necessarly with Bill’s Wiki. I welcome others checking this work and identifying issues. The following is all these cross-references: a. Supplement i. FindManifests has a table FHIR.DocumentManifest-> XDS.SubmissionSet ii. FindDocuments has a table FHIR.DocumetReference->XDS.DocumentEntry iii. Volume 3 has a table XDS.DocumentEntry->FHIR.DocumentReference iv. Volume 3 has a table XDS.SubmissionSet->FHIR.DocumentManifest v. Volume 3 has a table XDS.Folder->FHIR.List b. Bill Wiki has description XDS -> FHIR 3) How do we profile the use of _include for the Find transactions? I have explicitly defined it as NOT included in the profile a. Care must be taken with _include as it is likely not desirable to always _include superseded DocumentReferences. b. Might be useful with FindManifests to _include any DocumentReferences. c. Might be useful with FindDocuments to _include the document. 4) Note there is still no way provided in this profile to query for Folders. I suggest we continue without this capability for now. This was not part of MHD originally either. 5) Seems the search parameter ‘date’ might need to be further explained in appendix Z. Today we rely on FHIR documentation alone. I suggest we leave this until after Public Comment. Unless someone wants to offer up text. 6) Extension???? We need to resolve this difference. Bill has defined many extensions, where I have documented use of existing FHIR attributes. a. Bill, your volume 3 says that “comments” doesn’t map and needs an extension, but I think it maps nicely to “text” (both for DocumentEntry and SubmissionSet). b. Bill, your volume 3 says that “homeCommunityId” doesn’t map and needs an extension, but I think it maps nicely to “identifier” with IdentiferUse=secondary. c. Bill, your volume 3 says that ‘sourcePatientId” and “sourcePatientInfo” doesn’t map and needs an extension, but for DocumentManifest I think it maps nicely to “subject” with a use of “official’ and ‘usual’. It does NOT work so well for DocumentReference. So later I started to think your solution was more consistent… Hmmm d. I think the only extensions we need are DocumentReference practiceSettingCode and referenceIdList. 7) Notice FindDocuments does not include a way to query for referenceIdList. This was not in original MHD scope, and because we need to use an extension to hold these values, we can’t query for them anyway. 8) I noticed that there is no obvious way to support on-demand documents. So I just profiled them OUT! 9) DocumentEntry PracticeSettingCode is missing from FHIR. It is not clear how to handle this a. It might be expected to be mashuped up with facilityType b. we can create an extension but then can’t support the query parameter from ITI-18 FindDocuments. c. I documented it as an extension, and thus not queryable. 10) DocumentReference has both created and indexed. One is a dateTime the other an Instant. One is optional the other is mandatory. Not clear how to map this to creationTime. a. Given that created seems closer, I am using that primarily. But given that indexed is mandatory, I made that carry the same value. 11) Dave noted that FHIR allows for _format values to be a broader list, where as we constrained the list in PDQm. The current MHD just follows the pattern given in PDQm. I didn’t want to deviate unless we do the change to both. 12) Dave notes that more advice might be needed on bundle. MHD is just referring to the text that PDQm created for Appendix Z. I have no idea what more is needed, so I await someone to craft some language. 13) I ran into a major problem around Patient Identifier in DocumentReference. FHIR set subject to 1..1. This leaves us with very little room to put the various patient information we have. I thin Bill solution might need to be

Our next meeting is Friday the 21st. We have two meetings left to complete this work and get it out to Public Comment in preparation for Connectathon/New-Directions.

October 24

  • Walco made progress on Provide transaction, see Mockup
  • John will draft FindReferences transaction given the FindManifests transaction
  • Bill is working on tooling for Connectathon/Hackathon/New-Directions
  • Eric is organizing the Connectathon/Hackathon/New-Directions

next call Nov 7th -- will be limited to one hour as it overlaps with ITI CP processing.

August 16

John has updated the latest draft to include the 2x appendix shell from PDQm, informing the reader to refer to current PDQm supplement for FHIR definitions. John has also included a Volume 3 mapping tables for DocumentEntry, SubmissionSet, and Folder.

Justin will work on Find Document References.

Need someone to work on Provide Document Resources: A use of the FHIR Mailbox with an IHE-MHD defined Profile. This Profile will define a Bundle containing

  • 1..1 DocumentManifest resource (representing XDS SubmissionSet object)
    • The DocumentManifest.content carries 1..* pointers to DocumentReferences
  • 0..* DocumentReference resources (representing XDS DocumentEntry objects)
    • The DocumentReference.location pointing at the Binary resource described
  • 0..* List resources (representing Folder objects)
    • The List.entry.item carries 0..* pointers to the DocumentReference objects exiting or contained
  • 0..* Binary resources (representing the Document objects that are referenced by the DocumentReferences

August 15

Justin has prototyped the Find Manifest transaction, this is the latest version on the FTP site. This is a complete transaction definition, so is ready for review. He will work to complete the Find Documents transaction in similar form. This form does include the specific resource metadata cross-reference table as well as aid on query parameters. This leverages PDQm.

We need someone to work on the Provide transaction. It should leverage the metadata cross-reference tables that Justin has created in the Find Manifest and Find Documents transaction. The Provide transaction should focus on the construction of the Provide transaction. Use of Bundle, 1..* Manifests, 1..* Document Resources, and 1..* Documents. It seems to me that we would be using the Mailbox resource from FHIR, and adding the transactional completeness requirements of XDS. The reason I think Mailbox is the right solution is because it doesn't have any behavior expectations. This means that our Provide transaction is using FHIR "messaging".

Work on Folders using FHIR List is a lesser priority. Would be glad to have someone work on it, however it will raise complexity on Query given that we have only prototyped FindDocument and FindManifest. We could use _include. The complexity could come during the Trial Implementation.

It is expected that the XDS associations are going to be a mixture of FHIR based URL linkages where FHIR natively supports the specific kind of association. Associations beyond these should be seen as a lesser priority.

Keeping with our latest discussion, we will not likely have a Volume 3, but rather point at Bills excellent Wiki page as ‘work in progress’. We might want to move the metadata cross-reference tables into Volume 3, but for now let’s not complicate the editing.

T-Con

Next meeting: November 7, 2014

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 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=81621"