Skip to end of metadata
Go to start of metadata

Attendees: Riki Merrick (Vernetzt, LLC / APHL), Gary Bartlett (Brightree), Briana Barnes (EDMI), Pallavi Talekar (EDMI), Nadini Ganguli (EDMI), Zane Shott (DMEhub), James Fetters (microsoft), David Bruinsma (colonialmed), Matt Pestritto (Parachute Health), Bob Dieterle, Hans Buitendijk (Cerner)

  • Bob is working on migrating this information into trifolia
  • Exchange methods – vision diagrams
    • Option 1: Using subscription and task and order <ADD LINK>
      • We currently don't have topic in R4, so what would we use here – the backport solution for topic?
      • In R5 terms it would be topic to task with subscriptionResponse and topic to task with message as notification
  • Option 2: Message bundle, task, order, doc <ADD LINK>
    • What generates the sending of the task update (handled by internal system rules) – that is not dependent on the subscription rewrite – can current systems already handle this flow?
      • Microsoft: not out of the box, but that could be resolved with additional logic outside the FHIR server
      • Cerner: we are already used to need to track who sent the order and who to keep sending data to (outside of FHIR), FHIR is just used as the mechanism instead of v2 messaging
  • Mixing both subscription and messaging – think either or in most situations – Lloyd said send subscription along with the task, order and document, so that subscription is trigger for sending a message back (would the subscription indicate to use either message or subscriptionResponse)
  • Mixing could be: messaging is used with the ordering provider and use of subscription to other copy to situations, so that they can query, if interested
  • Ask for explicit feedback from balloters and at connectathon
    • Pure messaging
    • Pure subscription
    • Mixed approach
    • And ask for what subscription approach (R4 or R5)
  • Planning on virtual connectathon in January (or add to the CMS connectathon
  • Option 3 shows intermediary <ADD LINK>
    • How the intermediary communicates with the service provider is OOS
      • But if the service provider can handle FHIR, would just pass on same FHIR bundle, or value add
      • Should the IG clarify how that communication between hub and provider is done?
        • Maybe just allowing the use of what is already in place as well as using the same specs in the IG
  • Spreadsheet: <ADD LINK>
    • Added in exchange summary
      • Message bundle for the order
        • messageHeader (use DaVinci messageHeaderProfile?)
        • task
        • subscription (depending on what R4/R5)
        • Order information
          • ServiceRequest or DeviceRequest (if you are ordering only a device – maybe with instructions on how to use it) – for DME only
          • ServiceRequest when the request is for a service, that may or may not use a device – home Health service for sure
          • Encounter during which the order is placed UScore (not required)
          • Patient UScore
          • Practitioner UScore
          • PractionerRole UScore
          • Location UScore
          • Ordering organization UScore
        • Service Provider
          • Organization (filler) UScore
          • PractionerRole UScore
          • Location UScore
        • Additional documentation (using supportingInformation with reference to any)
          • documentReference UScore (C-CDA/pdf)
          • do we also need to support composition to support CDA on FHIR rather than using documentReference where the document is a composition
  • Bob will be working on IG over the weekend
  • No labels