Skip to end of metadata
Go to start of metadata

Attendees: Ralf Herzog, Andrea Pitkus, Benjamin Flessnet, Matt Lord, Craig Newman, Kathy Walsh, Hans Buitendijk, Keith Boone, Sean Muir, Toby Hu, Robert Worden, David Burgess

Topics:

  • Connectathon - 2019-05 v2-to-FHIR Tooling Track
    • The track has been approved.
    • We will need to provide more content.
    • The track will start Saturday PM (immediately following lunch) and run through Sunday.
  • WGM:
    • Thursday Q0
    • Thursday Q1 - PA?
    • ?? - SOA
    • Data Types - Conformance
    • ?? - FM, OO, Pt Care/Rx/ (OBX-to-??), StrucDoc (MDM)
  • Segment Review:
    • MSH / HD
      • MSH-3 thru 6
        • Agreed that both MessageHeader and Provenance need to be valued.
        • When using the progression A to B to C where in A the v2 message is created with C as the intended recipient, then B is the hop where the transformation from v2 to FHIR would occur
        • B would create a Provenance instance to represent the event that created the v2 message in A, and it also would create a Provenance instance to represent the transofrmation in B to FHIR. 
        • Review v2-to-FHIR Provenance for further considerations.
        • Apply similarly to 4-6.
      • MSH-7 Still surprised this is an extension, but will use it.
      • MSH-8 will be discussed together with ARV to understand how it is to be used before and v2.9 onward.
      • MSH-9  will require mapping to FHIR defined message structures.  That will be a downstream step.
      • MSH-10 - We will request addition of MessageHeader.identifier as .id is not sufficient.b
      • MSH-12 - There was discussion on whether to map this into MessageHeader or not:
        • Some believe that it does not apply to the FHIR MessageHeader (and related resources for that message) as MessageHeader.meta.versionId is about the FHIR version used to express the MessageHeader instance, not what the source may have been.
        • Others believe there still would be value to hold on to it.
        • In Provenance one can already include the full, original v2 message in Provenance.entity.what as a binary.  One could also use the MessageHeader.identifier (once included as an attribute or extension) to point back and then figure out the version.
        • However, one cannot easily just convey the version ID of the originating v2 message.  There would need to be an extension on Provenance in some way to capture that (e.g., Provenance.entity.#ext-v2VersionId#)
        • We decided to not map it into MessageHeader, but either one can populate Provenance.entity.what with a binary of the original message, or use the proposed MessageHeader.identifier.
        • Further discussion required whether we want to create an extension in Provenance to just capture version ID.
      • Continue with MSH-13.
  • Would be interesting to define an API to call the transformation.  Would be a separate PSS>