Stream: implementers
Topic: On-demand Documents
Grahame Grieve (Mar 07 2017 at 04:04):
I am looking at an implementation guide where a summary document is being accessed through a FHIR API. The document is generated on the fly by an HIE type arrangement when the client requests a summary view of a set of data held by the HIE.
The document is returned as a bundle that contains a composition, and a bunch of sections referring to other content. I have several questions from this:
- is IHE working on something like this?
- this would be an ettension on the $generate operation, yes?
- the composition that comes back, should it be identified? Should it have a version identifier?
Lloyd McKenzie (Mar 07 2017 at 05:15):
What's the purpose of it being a document rather than just a bundle of related information? Is there a value to instructing the recipient to consume the content in a particular order?
Grahame Grieve (Mar 07 2017 at 07:44):
it's not that important. It is a composition, and it's in a bundle. And it has a few propereries of documents - wholeness, integrity....
Jose Costa Teixeira (Mar 07 2017 at 10:33):
IHE had some discussions around medication lists. The idea was to send out a query "give me medicationList, flavour=simplified, dates=last2months..." the result would be a document of sorts.
John Moehrke (Mar 07 2017 at 12:57):
It would be good to ask this question on the IHE stream... IHE is not working on this topic, nor is it aware of the current solution. I was introduced to it a few weeks ago, and it looks interesting. I would agree that it is missing various capabilities/constraints that would make it more useful and align it better with what a source could do, and what a consumer might want. I thus think it might be a useful thing to have some trial-implementation investigate.
John Moehrke (Mar 07 2017 at 13:02):
My guess as to why a Document is the target is so that the consuming system gets some assurance of completeness, authenticability, context, stewardship, etc... Where FHIR REST api is very helpful to get results, these additional attributes are not part of a REST contract. If this guess is indeed what is driving this operation, then it needs to be more clearly said. Else the server is simply assembling the same data into a potentially less easy package to manipulate, which I don't understand why a client would choose a document over a REST api in that case.
Jose Costa Teixeira (Mar 07 2017 at 14:06):
Indeed, there is no active work item. Hopefully when we get there, we have some clarity from these discussions. There is quite a difference between "get me a medication list" and "get me the patient's medication data". That was not clear at first, so we ended up putting the project on hold.
Lloyd McKenzie (Mar 07 2017 at 18:23):
A $everything query response also has wholeness and integrity. (And attestation too - if you think of the server as a device capable of attestation). That doesn't make a query response a document.
Last updated: Apr 12 2022 at 19:14 UTC
