Talk:Mobile access to Health Documents - Supplement revision 2

From IHE Wiki
Revision as of 09:05, 19 December 2014 by JohnMoehrke (talk | contribs)
Jump to navigation Jump to search

February 28, 2014

attendees:

  • John Moehrke
  • Bill Majurski
  • Eric Heflin
  • Mauro Zanardini
  • Rob Horn
  • Gila Pyke

Topics:

  • Reveal Wiki page and work through operating mechanism
  • Attribute Mapping - Bill
    • Author cardionality mismatch
      • might be deeper solution
    • architecture difference
    • Bill to post link to google document he is using for tracking
    • analysis doing broad assessment first, starting with XDS focus
  • Scope - John
    • have not done
  • Provenance Resource - Rob
  • Transport Pattern -- Walco
    • Noted FHIR has concept of many transports, but HTTP REST is only one clear
    • looking into other
    • Will focus on Publishing including multiple documents and submission sets.
    • should also look into defining this simply as a service that invokes FHIR resources
    • Note that a "Profiling" tool is being developed. Not clear if it is accepted inside of HL7 FHIR yet.
  • FHIR vs IHE lifecycle
    • See W3C discussion

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.

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


September 12, 2014

attendees:

  • John Moehrke
  • Bill Majurski
  • Justin Fyfe
  • Karen Witting
  • Dragon
  • Sungkee Lee
  • Walco van Loon
  • Ben Kraufmann
  • Lynn Felhofer

Notes

  • Justin
    • will be able to provide a few hours a week under a new contract he has with OpenHIE
    • Will be at HL7 FHIR Hackathon
  • John has gotten no progress
    • Will be at HL7 FHIR Hackathon
  • Bill
    • has been working on a few of the key difficult attributes and how to translate (e.g. URI)
    • Working on the example. Need to validate that it fits spec, and that spec fits the example
      • We can rely on the HL7 FHIR code-base to do the XML to JSON format translations
      • concept of "code first". Try to have a reference system and test tooling, that will help drive spec accuracy
      • cleaning up the wiki page for attribute mapping
    • Will not be at Hackathon, but will be at HL7 meeting
  • Walco
    • has been working on the Provide transaction
    • Not liking the Mailbox model, likely will end up using it
    • Concern around FHIR principle of everything being a referencable
      • Discussion: We can and should use the 'contained' concept of FHIR when we really need it (e.g. PatientSourceInfo)
    • Mailbox issues
      • it is a very underspecified thing
      • therefore conformance is really only testable with a profile
      • note we can add transactional behaviors to core mailbox behavior
      • What is the difference between Transaction and Mailbox?
        • Walco: Message exchange pattern (messaging, REST, mailbox)
      • John: I think there is a concept of "Transaction" that is being developed. It is not well exposed to the broader community.
      • John: Lets just focus on Mailbox only as a way to allow us to focus on the bundle content and encoding inside the transaction. We will likely use a totally newly invented URL for our Provide endpoint. It will have as many characteristics from FHIR as we can take, but will not likely be a FHIR endpoint.
    • Will work on the Provide trasaction. Focus first on the bundle content profiling. secondary on HTTP transactional characteristics.
  • Gila has forwarded the shortened MHD supplement to Mary for publication on the external www.ihe.net web site.

October 10, 2014

Attendee: John Moehrke, Bill Majurski, Elliot Silver, Jim McInnis, Karen Witting, Laura Bright, Lynn Felhofer, Peter Bernhardt, Walco van Loon, Derrick Evans,

Topics:

  • FHIR DSTU2 is going to be delayed. So we should continue to focus on using DSTU1
    • This will allow IHE-HL7 workgroup to be created and better support us inside HL7
    • This will allow us to focus on DSTU1, while evolving DSTU2
    • We should focus on IHE profiling, thus not trying to us the FHIR Profile or Conformance resources
    • We will need to use FHIR extensions as needed for our work.
  • Connectathon
    • Minimal support will be available for "New Directions" (aka Hackathon)
    • Bill is looking for a java implementation that he can standup for connectaton use
  • Provide and Register
    • Walco has provided an example published through a google document link
    • We should spend more time on the bundle content definition
    • Given the current direction we should focus on creating a new service. This will not be usable with existing FHIR servers.
    • We should ask the FHIR core team to review our proposed service
    • Could leverage MHD original Provide transaction


October 24, 2014

attendees:

  • John Moehrke
  • Bill Majurski
  • Walco van Loon
  • Lynn Felhofer
  • Alex Lippitt
  • Dave Franken
  • Chris Stehno
  • geojaya
  • Mick Talley
  • Mauro
  • Mohammad Jafari (VHA, ESC)
  • Rinil
  • Eric Heflin (THSA)

notes:

  • Justin is too busy to help, so John will mock up the FindDocuments transaction
    • Please review critically
  • Walco
    • has mocked up Provide Document resources transaction
    • This was discussed on the call
    • Question: Is the grouping behavior between MHD and XDS clear enough? Would a MHD publisher expect the results to show in XDS?
      • This should already be defined in Volume 1 under grouping behavior.
      • Does this need correction or elaboration?
    • Question: Should we support Provide transactions to already published binary documents?
      • Yes, this is just a fully qualified URI rather than a internal-to-the-bundle relative URI
    • What would the return result on a success look like?
      • Would it just return the documentmanafest ID?
      • would it be a list of all resources created?
    • Is an interest in help from Dave Pyke to do technical writing on this transaction
  • Bill
    • No time to work on spec, but working on tooling
      • Tooling deadline is Dec 15th
      • using the java tooling from the FHIR spec
        • means we get xml vs json translation free
      • Will have tooling to do metadata validation (Resource content)
      • Not likely to have source available in the short time
    • Will there be test data?
      • Yes, bill can take existing test data and make it available
  • Mick
    • Michigan is prototyping RESTful access to their HIE. They are following the IHE specifications as much as possible
    • Mick asks what about Security and Privacy?
    • John - we have that in IUA
      • We have a few vendors signed up for PDQm
      • No one has signed up for IUA
    • some Resources regarding Security and Privacy and the MHD profile
  • Eric
    • New Directions
    • Going to follow upon the success last year with HPD work
    • IHE-USA is the sponsor
    • Should we setup an independant call to plan virtual connectathon?
      • Will use this timeslot, taking the last 30 minutes or more if technical gets done early
    • Virtual connectathon is open to ALL, not limited to connectathon participation
    • Roadmap of Milestones
      • Create a basecamp for the virtual connectathon
        • Was used for HPD last year, seems people willing
      • Will reach out to find greater participation
      • Connectathon participation might be limited to a small number, like 6
    • I would like to use the MHD Status page as the front-door.
      • So add the basecamp to that page

Summary

  • 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.


November 7, 2014

Attendees: John Moehrke, Bill Majurski, Dave Franken, Dave Pyke, Denise Probst, Eric Heflin, Paul Lomayesva, Peter Bernhardt, Rob Horn, Walco van Loon, Eric Heflin

Notes:

  • FindDocumentReferences is sketched out, but many deep details are left as TODO (marked with comments).
  • ProvideDocumentReferences has made little improvement


  • Note that FHIR in DSTU2 will be replacing the Atom based bundle with a bundle that is not based on Atom
    • Which also moves metadata
  • Bill
    • Has commitment for Connectathon for FindDocumentReferences.
    • Theory is that FindDocumentReferences and FindManafests can be executed against a otherwise normal FHIR server, provided magic happened to get the resources there.
  • Connectathon
    • Will soon send out the call for participation draft.

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:
    1. Supplement
      1. FindManifests has a table FHIR.DocumentManifest-> XDS.SubmissionSet
      2. FindDocuments has a table FHIR.DocumetReference->XDS.DocumentEntry
      3. Volume 3 has a table XDS.DocumentEntry->FHIR.DocumentReference
      4. Volume 3 has a table XDS.SubmissionSet->FHIR.DocumentManifest
      5. Volume 3 has a table XDS.Folder->FHIR.List
    2. 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
    1. Care must be taken with _include as it is likely not desirable to always _include superseded DocumentReferences.
    2. Might be useful with FindManifests to _include any DocumentReferences.
    3. 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.
    1. 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).
    2. 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.
    3. 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
    4. 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
    1. It might be expected to be mashuped up with facilityType
    2. we can create an extension but then can’t support the query parameter from ITI-18 FindDocuments.
    3. 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.
  11. Given that created seems closer, I am using that primarily. But given that indexed is mandatory, I made that carry the same value.
  12. 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.
  13. 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.
  14. 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.

December 19, 2014

Attendees:

Purpose: These meetings will continue. Their priority agenda will shift for the next month. The focus between now and Connectathon is on the small group of people that have signed up for the MHD “New Directions” testing at connectathon. We will be creating understanding among that group, working on test scenarios, working through technical issues, working through specification issues, etc. The meetings will continue to be open, although we need to operate under the “Safe to Fail” rules of Connectathon so as to allow people to be creative and daring.

Agenda:

  • Status of New Directions signup -- Eric
  • Operating Mechanism
    • Tools
  • Questions
Retrieved from "http://wiki.ihe.net/index.php?title=Talk:Mobile_access_to_Health_Documents_-_Supplement_revision_2&oldid=82722"