Stream: implementers
Topic: Fhir-Documents
Jayashree Surnar (Sep 26 2017 at 12:50):
shall I use Provenance Resource to capture a signature of a person(practitioner)who create and updates a document?
John Moehrke (Sep 26 2017 at 13:12):
Yes, that is a use-case intention for Provenance.
Jayashree Surnar (Sep 27 2017 at 04:19):
okay @John Moehrke .
Jayashree Surnar (Sep 27 2017 at 05:01):
what is the use of Bundle.Signature?
John Moehrke (Sep 27 2017 at 14:09):
In the case of a FHIR Document, there is indeed some question of use of Provenance.signature and/or Bundle.signature. The Bundle.signature is there for protection of the Bundle, while it is a Bundle. But I think the issue is that a FHIR Document will be decomposed into the composed Resources, and thus the Bundle.signature will not be usable. Where the Provenance.signature would survive... This is not fully true either, but we have much to work on with digital signatures. http://build.fhir.org/security.html#signatures I welcome the experimentation, and the recommendations for improvement (Change Requests).
Richard Kavanagh (Sep 27 2017 at 21:50):
But I think the issue is that a FHIR Document will be decomposed into the composed Resources, and thus the Bundle.signature will not be usable. Where the Provenance.signature would survive...
Really? - I don't think that will happen in all cases. We have scenarios where documents are persisted as Bundles and never decomposed into individual resources. Not all FHIR document will end up on a FHIR server/
Lloyd McKenzie (Sep 28 2017 at 04:25):
If you post to Bundle, the document should be stored as-is. Decomposing will likely break the Provenance signature too as there's no canonical ordering to the entries - and the Bundle signature would care. If you care about signature validity for documents, you need to store them as a binary.
Richard Kavanagh (Sep 28 2017 at 08:40):
As further consideration. FHIR Documents may be delivered my multiple means. Sometimes by "POSTing" to a FHIR server and sometimes delivered by other means. There will be numerous patterns of deployment.
John Moehrke (Sep 28 2017 at 12:40):
A Signature data type has a digital signature a blob using a signature standard, such as XML-Signature. The XML-Signature standard has mechanisms for defining the manifest of objects, ordering of the various objects (Resources), their encoding, their canonicalization, and xpath exclusions of elements that should be allowed to change. Using these 'standards' one can have a signature that covers the important parts, while not relying on the Bundle representation. The difference with Bundle signature vs Provenance signature is the reliance on Bundle to be the manifest of everything it contains, where Provenance itemizes them. Thus Provenance is intended to be persisted even when decomposed. This however has not been tested. Not because i isn't possible, but because far more important things need to be tested and improved before we worry about a nice stable standard written by another SDO... Defining the exclusion, and the ramifications of exclusions, will be an important exercise. An exercise that needs more than academic interest, it needs a driving use-case that a majority of systems need...
John Moehrke (Sep 28 2017 at 12:42):
@Lloyd McKenzie is the Bundle.signature intended to be a signature on the whole composed and serialized Bundle as canonicalized? Meaning it is intended to cover only that one instant? It is not intended to address Resource-by-Resource?
Lloyd McKenzie (Sep 28 2017 at 14:39):
The Bundle signature signs the whole Bundle - including the Bundle.identifier, type, total, etc. as well as the entries. You run the same canonicalization algorithm on Bundle as you would on any other resource.
Grahame Grieve (Oct 03 2017 at 02:04):
right. Bundles can be signed, and documents are bundles, and are stored as such. But Documents can also be be decomposed - you might want a signature that can persist after this. Though, in fact, it's not really the document case that is the deal here; once a document is constructed and signed, most use cases around signature validation are inherently based on the complete document. The tracking signatures thing across the RESTful API (which as @John Moehrke says is experimental yet) that Provenance supports is more applicable to general workflow than to documents. @Lloyd McKenzie note that order is generally sorted by the fact that provenance lists resources in a particular order. What we don't really know is whether signatures are any use in that context given the fact that data is very often manipulated...
Jayashree Surnar (Oct 03 2017 at 13:15):
hello all,
i'm little bit confusing with the Document identifiers i.e Bundle and Composition identifiers.
given A document must have an identifier with a system and a value (expression : type = 'document' implies (identifier.system.exists() and identifier.value.exists()))
here my doubt is from where to get the Identifier's value and system? ,to which end point we need to send the document i.e bundle or composition? and what is the method we should use ? POST or PUT?
Thank you.
Yunwei Wang (Oct 03 2017 at 19:08):
The value and system are in Bundle.identifier
Jayashree Surnar (Oct 04 2017 at 05:00):
yes, it's Bundle.identifier. but at the time of submitting the document as a bundle via advance rest client it's asking for System and value for Bundle.identifier.
Jayashree Surnar (Oct 04 2017 at 11:55):
after reading the content of the fhir documentation, what I understood was
1. we need to create a Composition(ex: History-and-physical doc) which consists all the required entries like AI,Patient,medications etc.
2.create the Bundle whith type= document which has the Composition as 1st entry and follwed by the other entries which we have specified in the Composition. is this correct? or i'm I missing anything?
and here we must specify Bundle.identifier.system and value.but... from where to get these values? any suggesion please.
Thank you.
René Spronk (Oct 04 2017 at 13:02):
The values are assigned by the system that creates/assembles the document. After all, that system creates the document so it has to assign a unique id to it.
As for (2) above: as well as ..... followed by any Resources referenced by "the resources referenced by Composition", although it's up to the creator of the document to decide whether or not (and what Resource types) to include. Minimalistically it should include the Resources referenced in the sections of the Composition.
Jayashree Surnar (Oct 05 2017 at 04:45):
here system means is it client side or server side? in our case we have both server and app. so to which side we need to implement?
Jayashree Surnar (Oct 05 2017 at 04:47):
dose bundle available after processing of documents? or dead
Jayashree Surnar (Oct 05 2017 at 08:22):
can we store a document within one step?
Jayashree Surnar (Oct 05 2017 at 08:24):
is it necessary to provide the fullUrl and resource content in the bundle entries while posting the document to the server? or else just full url itself is enough? any suggession ?
thank you.
Yunwei Wang (Oct 05 2017 at 20:15):
It depends on server implementation. Bundle is the container/carrier for a document. It can be saved as a whole in server's storage. Or it can be constructed at run time.
Yunwei Wang (Oct 05 2017 at 20:18):
Though a client/app can generate a document, but I think it is more common for the server to generate a document and passes to client/app for user review. In such case, the system/id are created by server. If you do have a situation for client generated document, then the system/url are created by client. Butserver may or may not honor client generated system/id based on server's implementation.
Jayashree Surnar (Oct 06 2017 at 05:21):
thank you @Yunwei Wang
Jayashree Surnar (Oct 13 2017 at 04:37):
hello,
if I change the patient details while sending the Bundle as document then it's getting updated in the Bundle only. but the original resource is not updating. and if access an instance ex: patient/id then getting the old details.any suggesions how to solve this issue.
Thank you.
Lloyd McKenzie (Oct 13 2017 at 15:49):
You're getting expected behavior. Sending a document is not expected to trigger updates to records. Receiving systems can choose to update records if they wish, but there's no guarantee that the information in the document is "newer" or "better" than what the receiving system already has. If you want to update a resource, you need to send a direct update or submit a batch or a transaction.
Jayashree Surnar (Oct 17 2017 at 04:15):
tnq @Lloyd McKenzie
Jayashree Surnar (Oct 17 2017 at 04:22):
We are interested to generate a pdf or a text file by clubing all the Composition.sections's narritive and the indivisual entry's(allergy resource,medication etc) narrative any help how to do this.
Jayashree Surnar (Oct 17 2017 at 04:28):
here (http://build.fhir.org/documents.html)given
When the document is presented for human consumption, applications SHOULD present the collated narrative portions in order:
The subject resource Narrative
The Composition resource Narrative
The section.text Narratives
here subject means is it patient?
Jayashree Surnar (Oct 17 2017 at 04:29):
and little bit confusing what should be includend in the respective narrative part.
Lloyd McKenzie (Oct 17 2017 at 14:29):
Subject would be Composition.subject. That'll be Patient for patient-centric documents (but remember that FHIR documents don't have to be about patients). What appears in the narrative for a given resource is up to the author of the resource - it's the "essential" information a human would want to see, but that's subjective and dependent on context.
Lloyd McKenzie (Oct 17 2017 at 14:29):
So you'll have to figure it out on a case-by-case basis in consultation with your users.
Jayashree Surnar (Oct 18 2017 at 04:18):
thank you @Lloyd McKenzie
any suggesion how to get all the narrative(subject narrative, composition narrative, composition.sections narrative and individual entries narrative in the composition)and then generate a text file or pdf etc.
Lloyd McKenzie (Oct 19 2017 at 13:28):
All the resources are inside the Bundle, so getting the narratives isn't hard. The content is XHTML, so turning it into an XHTML document isn't hard either. There are lots of tools that can turn an XHTML document into a PDF.
Richard Townley-O'Neill (Feb 08 2018 at 06:27):
The text for Composition.identifier is confusing. It has
Definition Logical identifier for the composition, assigned when created. This identifier stays constant as the composition is changed over time.
and
Note This is a business identifer, not a resource identifier (see discussion)
Which is it? Business or logical?
Vadim Peretokin (Feb 08 2018 at 10:17):
Business I'd say, since Composition.id claims the other one.
Richard Townley-O'Neill (Feb 28 2018 at 01:40):
The docco on FHIR documents says that the document date is mandatory and is stored in _Bundle.meta.lastUpdated_ (See Document Content)
Is this enforced by anything?
Richard Townley-O'Neill (Feb 28 2018 at 01:42):
The docco also says "a Bundle of resources of type "document" that has a Composition resource as the first resource in the bundle".
Is this enforced by anything?
Richard Townley-O'Neill (Feb 28 2018 at 01:43):
They both could be invariants on Bundle.
Lloyd McKenzie (Feb 28 2018 at 03:27):
Feel free to submit a change proposal. The first resource rule is currently enforced by the Java validator I know.
Richard Townley-O'Neill (Feb 28 2018 at 04:43):
Ta.
#15676
Aaron Seib (Feb 28 2018 at 20:37):
Is anyone aware of a parser that ingest a CCDA and outputs FHIR resources?
Lloyd McKenzie (Feb 28 2018 at 20:49):
You might want to ask on the #cda to fhir stream
Last updated: Apr 12 2022 at 19:14 UTC
