Stream: implementers
Topic: Strategy for push based interaction
Ashwin Djorai (Sep 15 2020 at 14:13):
We are looking into a push scenario where loosely coupled systems send each other contra-indications on a patient they both have in their system. We are examining options for sending this data (Flag. Patient, Practitioner, PractitionerRole, Organization). Transaction Bundle seems be the best match. Questions: 1. Is there any IG that discusses this type of scenario? 2. We anticipate that at least some of the uploaded resources could exist on the target system and expect to need conditional create for that: what is the current state of support for that? 3. Are there alternatives to transaction Bundle that could apply here?
Lloyd McKenzie (Sep 15 2020 at 14:41):
When you say "sends each other contra-indications" - do you mean specific detected contraindications (i.e. issues identified with specific planned/existing activities) or do you mean clinical information that could trigger contraindications (which might include a variety of resources)?
Alexander Henket (Sep 15 2020 at 15:45):
Hi Lloyd. We are hoping that the answer to that question is irrelevant. The contra-indications use case merely serves as setting the stage for "a pattern for uploading data to a system where some of that data may already exist".
Lloyd McKenzie (Sep 15 2020 at 15:47):
If you're trying to figure out "what is the best exchange mechanism for this use-case?", suggest you start here: https://build.fhir.org/ig/HL7/davinci-ehrx/exchanging.html
Alexander Henket (Sep 15 2020 at 15:53):
That looks really helpful indeed. It is a nice overview of methods. For our use case we have a focal resource (Flag) and 'related' resources like Patient/Practitioner. That sounds like a clear cut case for transaction Bundle, which is what the IG points to as well.
So transaction Bundle it is. The core spec however notes that conditional create/update is not very well supported. The IG does not really allude to that. Are we to understand that this is, or is not an issue to worry about these days?
John Moehrke (Sep 15 2020 at 15:57):
@Lloyd McKenzie how can I get Document Sharing added to this?
Lloyd McKenzie (Sep 15 2020 at 16:03):
@John Moehrke Can you explain what you mean by 'Document Sharing'?
Vassil Peytchev (Sep 15 2020 at 16:08):
And yet, transaction bundle is not the only approach. Since you have two systems with similar data, what you are asking for is how each system can take only the data that it needs, without overriding the data it already has.
An alternative approach is for the initiating system to use the same trigger that you plan for "pushing" the data to 'ping' the recipient that there is data available, and the recipient retrieves the data they are interested in, and process it as their business rules specify. This way, you are not dependent on the FHIR capabilities of the recipient (as you note, conditional update/create, and even transactions are not that widely implemented, and aligning he FHIR API with business rules may not be straight forward), and relying the core FHIR capabilities of the initiator (+ subscriptions to allow for the 'ping' notification).
David Pyke (Sep 15 2020 at 16:51):
Lloyd McKenzie said:
John Moehrke Can you explain what you mean by 'Document Sharing'?
You HL7 People... He means XDS/MHD and such
Lloyd McKenzie (Sep 15 2020 at 16:52):
Sure - but how is that not covered by what's there?
Lloyd McKenzie (Sep 15 2020 at 16:52):
MHD is still just using RESTful posts and queries, no?
René Spronk (Sep 16 2020 at 07:06):
As could messaging, as do documents. So using HTTP isnt much of a criterium when selecting paradigms. But you're aware of that. That having been said, the burden is probably on the fans of 'document sharing' to propose what should be added, and how that paradigm differs from any of the others shown.
John Moehrke (Sep 16 2020 at 12:55):
MHDS is just a RESTful document sharing exchange around one center. MHD is the API that clients use to any scale of document sharing exchange.
John Moehrke (Sep 16 2020 at 12:59):
Document Sharing, when viewed by the consumer, is simply a Query and Retrieve. Well represented by DocumentReference and query against it. What is missing from this perspective is the focus on "documents". The principles of a document are very powerful in a cross-community exchange. A Document Sharing is a transport for FHIR Documents and Collection Bundles; but also supports non-FHIR documents such as CDA, PDF, DICOM, etc.
John Moehrke (Sep 16 2020 at 13:05):
Document Sharing, when viewed by the publisher, allows for publication of completed works for discovery by consumers. This might be implemented as a REST create of a DocumentReference, but might also be recognizing distributed responsibility (repository vs registry vs federation gateway). This publication might be of a completed work, or might be a promise to produce a completed work, or might be a promise to produce a current work of a given type. Always a document with the principles of a document.
Lloyd McKenzie (Sep 16 2020 at 14:34):
There's discussion in the decision tree about when it's appropriate to store information as documents vs. not (generally when it's important to store the data as a group and necessary to tell a story). If those requirements don't hold, then documents is probably not the best way to share the data.
Last updated: Apr 12 2022 at 19:14 UTC
