Stream: DME Orders on FHIR
Topic: September 2020 Connectathon
Nandini Ganguly (Sep 10 2020 at 13:53):
All- link to the Implementation Guide: http://build.fhir.org/ig/HL7/dme-orders/restful_fhir_exchanges.html
We will be testing the RESTful message bundles during the Connectathon, please review the guide and posts questions and or comments here.
Nandini Ganguly (Sep 10 2020 at 14:53):
Home work for participants at this Connectathon: Prepare sample messages looking at the Implementation Guide to test it in the afternoon. We will be posting message bundles to see if they are ready to receive the bundle and or test it.
Homework for Observers: Review the guide and determine if you have any questions, send your questions here.
Wade Routen (Sep 10 2020 at 15:15):
In regards to the FHIR client/server interactions, to set up a DeviceRequest (for example) you need such resources as a Patient, and many more. I am setting up a FHIR server to handle such a request, but how do I know the workflow of the client? Is it standard practice for the client application to know that it needs to first lookup/create a patient, then use that patient in a DeviceRequest? Does the server need to implement search features for patients knowing that the reference to the patient will be needed, or is the workflow to require the developers of each application to just work closely with each other to identify what the needs of each would be?
Wade Routen (Sep 10 2020 at 15:22):
My second question is geared more towards the references in a resource. For instance, take the DeviceRequest resource. It has a property for Encounter. If the implementing FHIR server does not store encounters in the FHIR resource sense, but instead uses the information in other ways, can/should a "contained" reference be used for the encounter? Once again, does this decision need to be agreed upon by the client and server applications, or is this information something that can be gleamed from the capability statement?
Olivia Bellamou-Huet (Sep 10 2020 at 15:42):
While reading the IG I am wondering why there are 3 different communication patterns (FHIR Messaging, RESTful FHIR and Intermediary) instead of only 1? And how to choose which one to use?
Billy Waldrop (Sep 10 2020 at 15:58):
There are really only two use cases. Direct communication between the Ordering Provider and the Supply Provider is the first The second is using an Intermediary to stage the data so that multiple providers are able to access te order. In either case, data is exchanged via FHIR Messaging, which means JSON data formatted according to the FHIR spec. When transmitting that data, we use RESTful endpoints which are simply web-based APIs where you can post the data.
Billy Waldrop (Sep 10 2020 at 19:33):
DMEhub Postman Collection for Supply Side.
DMEhub_Postman_supplier.json
Billy Waldrop (Sep 10 2020 at 19:34):
DMEhub API Guide
DMEhub_API_Order-Details_2020-Q4_v1.3-Update_ZES_20200113-1800.docx
Vassil Peytchev (Sep 10 2020 at 19:45):
There are really only two use cases. Direct communication between the Ordering Provider and the Supply Provider is the first The second is using an Intermediary to stage the data so that multiple providers are able to access te order. In either case, data is exchanged via FHIR Messaging [...]
That is not what http://build.fhir.org/ig/HL7/dme-orders/restful_fhir_exchanges.html represents - it is meant as a high-level overview of data exchange using the FHIR RESTful API, and not FHIR Messaging.
Billy Waldrop (Sep 10 2020 at 19:54):
Yes, thank you for the comment, Bob clarified, FHIR Messaging and RESTful API are the two possible exchange protocols across the two use cases.
Wade Routen (Sep 11 2020 at 14:38):
This "request pattern" seems to explain the "workflow" of what a request profile needs to do: https://www.hl7.org/fhir/request.html
Vassil Peytchev (Sep 11 2020 at 15:30):
The Request pattern represents the common data model for various types of requests. That does not directly translate into "acting on the request" or into more complicated workflows. This is why there is the Task resource and a whole workflow section.
Last updated: Apr 12 2022 at 19:14 UTC
