Stream: implementers
Topic: XDS/MHD + Transaction Semantics
Grahame Grieve (Sep 09 2017 at 20:40):
"If the server assigns a new id to any resource in the bundle as part of the processing rules above, it SHALL also update any references to that resource in the same bundle as they are processed"
@James Agnew there seems to be some confusion about this sentence, in regard to DocumentReference.content.attachment.url. If this references a binary in the bundle, then it SHALL be updated
diego kaminker (Sep 09 2017 at 20:59):
I tried it to in Furore's Vonk Server, and it does not replace the url with the url for the binary.
diego kaminker (Sep 09 2017 at 21:05):
And also tried with http://test.fhir.org/r3 (Grahame's server) and cannot make it replace the url with the Binary resource location/id inside of the transaction[XDS_EXAMPLE_BINARY_URL_REPLACE.xml] is what I posted.
Maybe I am posting it wrong? Any ideas?
(https://chat.fhir.org/user_uploads/10155/_68YuSUtcikFSVpXcQyIvopl/XDS_EXAMPLE_BINARY_URL_REPLACE.xml)
Michele Mottini (Sep 09 2017 at 21:11):
The patient and practitioner references seem wrong
Michele Mottini (Sep 09 2017 at 21:11):
Shouldn't Patient/a2 actually be urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce35 (the patient that is in the bundle) ?
diego kaminker (Sep 09 2017 at 21:16):
I edited all references from the example in the FHIR STU3 spec, forgot that one. But even correcting it, content.attachment.url is not replaced with the id assigned to the Binary resource by the server.
Michele Mottini (Sep 09 2017 at 21:17):
Yes, but that's an actual URL to data (or should be) - it is not an id to a resource
Michele Mottini (Sep 09 2017 at 21:17):
I don't think it should be replaced
diego kaminker (Sep 09 2017 at 21:19):
I think that's the issue with the IHE MHD IG, it asks us to send the Binary as part of the transaction hoping that the URL will be replaced. It's not replaced by any of the reference servers I tried. Maybe NO server will ever replace the URL, and we should do TWO trips one for the binary, one for the DocumentReference). I just want to know.
Michele Mottini (Sep 09 2017 at 21:21):
Never quite understood that in the spec - you can just put the binary data directly in the DocumentReference - why even use a separate Binary resource?
Michele Mottini (Sep 09 2017 at 21:27):
Fixing a bit the practitioners that bundle works on our server
Michele Mottini (Sep 09 2017 at 21:27):
Michele Mottini (Sep 09 2017 at 21:27):
<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir">
<id value="xds"/>
<type value="transaction"/>
<entry>
<fullUrl value="urn:uuid:3fdc72f4-a11d-4a9d-9260-a9f745779e1d"/>
<resource>
<DocumentReference>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<a href="http://vonk.furore.com/Binary/1e404af3-077f-4bee-b7a6-a9be97e1ce32">Document: urn:oid:129.6.58.92.88336</a> undefined, created 24/12/2005
</div>
</text>
<masterIdentifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:oid:129.6.58.92.88336"/>
</masterIdentifier>
<status value="current"/>
<type>
<coding>
<system value="http://ihe.net/connectathon/classCodes"/>
<code value="History and Physical"/>
<display value="History and Physical"/>
</coding>
</type>
<class>
<coding>
<system value="http://loinc.org"/>
<code value="47039-3"/>
<display value="Inpatient Admission history and physical note"/>
</coding>
</class>
<subject>
<reference value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce35"/>
</subject>
<created value="2005-12-24"/>
<indexed value="2013-07-01T23:11:33+10:00"/>
<author>
<reference value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce34"/>
</author>
<author>
<reference value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce33"/>
</author>
<description value="Physical"/>
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality"/>
<code value="N"/>
<display value="normal"/>
</coding>
</securityLabel>
<content>
<attachment>
<contentType value="text/plain"/>
<language value="en-us"/>
<url value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce32"/>
</attachment>
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:pcc:handp:2008"/>
</format>
</content>
<context>
<period>
<start value="2004-12-23T08:00:00+10:00"/>
<end value="2004-12-23T08:01:00+10:00"/>
</period>
<practiceSetting>
<coding>
<system value="http://ihe.net/connectathon/practiceSettingCodes"/>
<code value="General Medicine"/>
<display value="General Medicine"/>
</coding>
</practiceSetting>
</context>
</DocumentReference>
</resource>
<request>
<method value="POST"/>
<url value="DocumentReference"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce35"/>
<resource>
<!-- if the server can find a matching resource, use that, else create a new
resource with these details -->
<Patient>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">Person DOE, John, M, dob: 27/05/1956</div>
</text>
<identifier>
<use value="usual"/>
<value value="MRN"/>
</identifier>
<name>
<use value="usual"/>
<text value="DOE, John"/>
<family value="Doe"/>
<given value="John"/>
</name>
<birthDate value="1956-05-27"/>
</Patient>
</resource>
<request>
<method value="POST"/>
<url value="Patient"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce34"/>
<resource>
<Practitioner>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">Author Gerald Smitty @ Cleveland Clinic</div>
</text>
<identifier>
<use value="usual"/>
<value value="GeradSmitty"/>
</identifier>
<name>
<use value="usual"/>
<family value="Smitty"/>
<given value="Gerald"/>
</name>
</Practitioner>
</resource>
<request>
<method value="POST"/>
<url value="Practitioner"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce33"/>
<resource>
<Practitioner>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">Author Person @ Cleveland Clinic</div>
</text>
<identifier>
<use value="usual"/>
<value value="SherryDoplemeyer"/>
</identifier>
<name>
<use value="usual"/>
<family value="Dopplemeyer"/>
<given value="Sherry"/>
</name>
</Practitioner>
</resource>
<request>
<method value="POST"/>
<url value="Practitioner"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:1e404af3-077f-4bee-b7a6-a9be97e1ce32"/>
<resource>
<Binary>
<contentType value="text/plain"/>
<content value="YXNkYXNkYXNkYXNkYXNk"/>
</Binary>
</resource>
<request>
<method value="POST"/>
<url value="Binary"/>
</request>
</entry>
</Bundle>
Michele Mottini (Sep 09 2017 at 21:28):
See results at https://fhir.careevolution.com/apitest/fhir/DocumentReference/209a001c-7d09-4b3c-a0cf-0df44a398f20
diego kaminker (Sep 09 2017 at 21:35):
I discussed this with Ewout and James. We created a hot topic to recommend using content.attachment.data instead of a binary resource to overcome this problem. Let's see what is the outcome of the discussion.
Michele Mottini (Sep 09 2017 at 21:39):
...yes, and the bundle will also be smaller / simpler
Grahame Grieve (Sep 09 2017 at 23:06):
that hot topic ducks the underlying issue. The server writers are just kicking the can down the road...
Grahame Grieve (Sep 09 2017 at 23:07):
there's really compelling engineering reasons for using a binary not base64 attachment data
Michele Mottini (Sep 09 2017 at 23:08):
...but if you put the Binary resource in the bundle you still have to use base64 ?
Grahame Grieve (Sep 09 2017 at 23:09):
yes, but you can fetch it directly as a binary
Grahame Grieve (Sep 09 2017 at 23:09):
and you can reference it from html
Michele Mottini (Sep 09 2017 at 23:12):
Yes, the attachment can reference a URL that serves directly the binary data - and then you do not even need the Binary resource at all
Michele Mottini (Sep 09 2017 at 23:13):
...but that works only if the system that is POSTing the bundle can host the binary content somewhere accessible from the receiving system
Grahame Grieve (Sep 09 2017 at 23:54):
no it works for FHIR servers too
Grahame Grieve (Sep 09 2017 at 23:54):
post as binary using the binary format
Grahame Grieve (Sep 09 2017 at 23:54):
get as binary using the binary format
Grahame Grieve (Sep 09 2017 at 23:54):
use base64 if you need to do it in a transaction
Michele Mottini (Sep 09 2017 at 23:56):
ah OK - sure - then you POST the binary first, get back the id and use that in the DocumentReference
Grahame Grieve (Sep 09 2017 at 23:56):
but you can do that in a transaction too
Michele Mottini (Sep 09 2017 at 23:56):
how?
Grahame Grieve (Sep 10 2017 at 00:06):
post it as a bas64, and then get it as a binary - that's why MHD does it as a binary not an attachment
Michele Mottini (Sep 10 2017 at 00:10):
I don't get it - you are still sending the data over as base64. The target FHIR server does not have to get the data - as binary or otherwise - it already has it
Michele Mottini (Sep 10 2017 at 00:11):
if it is in the transaction as base64
Grahame Grieve (Sep 10 2017 at 01:18):
yes but if you put it in the Attachment as base64, you can only get it as base64, where as if you post it in binary, you post it in base64, but you get it in binary
Michele Mottini (Sep 10 2017 at 16:04):
I see what you mean now - but isn't this an internal implementation detail of the server?
Michele Mottini (Sep 10 2017 at 16:04):
The way it renders the DocumentReference when GETing it does not have to depend on the way it has been created originally
Michele Mottini (Sep 10 2017 at 16:05):
i.e. it can be rendered with the data as a separate Binary resource even if it has been created with data embedded as base64 - or vice-versa
Michele Mottini (Sep 10 2017 at 16:06):
as a matter of fact our servers does the 'vice-versa': regardless on how the DocumentReference is created it always renders it with embedded base64 data
Michele Mottini (Sep 10 2017 at 16:07):
(and we should probably do the opposite)
Grahame Grieve (Sep 10 2017 at 16:08):
if you have the binary(s) embedded inside the DocumentReference, then you can't get the content as a native binary. that's not an internal implementation detail
Michele Mottini (Sep 10 2017 at 16:09):
mhhh why not? we could surely do it in our server (although as I said we are doing the opposite now)
Grahame Grieve (Sep 10 2017 at 16:10):
because how? when we discussed this in FHIR-I it rapidly started to get complicated.
Michele Mottini (Sep 10 2017 at 16:10):
if you have the data stored in binary somewhere in your db you can always render that data as a Binary resource and put a url to it in the DOcumentReference
Grahame Grieve (Sep 10 2017 at 16:11):
that's as a binary... that's exactly what MHD is doing.
Grahame Grieve (Sep 10 2017 at 16:11):
we seem to have come around in a circle back to the logical thing that MHD is doing
Michele Mottini (Sep 10 2017 at 16:11):
yes - but that does not have to have anything to do on how the DocumentReference has been created
Michele Mottini (Sep 10 2017 at 16:12):
you can do it regardless
Grahame Grieve (Sep 10 2017 at 16:12):
yes it does. if you inline the data in the DocumentReference, then you return it that way too. irrespective of how you store it
Michele Mottini (Sep 10 2017 at 16:13):
mhh...for a spec reason or a technical reason?
Michele Mottini (Sep 10 2017 at 16:13):
I don't see a technical reason
Grahame Grieve (Sep 10 2017 at 16:14):
technical reason? for what?
Michele Mottini (Sep 10 2017 at 16:14):
'if you inline the data in the DocumentReference, then you return it that way too. '
Michele Mottini (Sep 10 2017 at 16:15):
why?
Grahame Grieve (Sep 10 2017 at 16:16):
well, it's allowed for the server to un-inline data. Typically, that's really difficult but this is one case where it would be technically possible. It's an MHD rule in this case. But I think that it would be better for the servers to be fixed to follow the spec than for MHD to mandate posting in one format, and the server converting to another
Michele Mottini (Sep 10 2017 at 16:17):
I would not mandate MHD to do one or the other - I would just allow both
Michele Mottini (Sep 10 2017 at 16:18):
and suggest that the server returns data as separate Binary
Michele Mottini (Sep 10 2017 at 16:18):
(that is not really part of MHD in any case - MHD is only for the POSTing part isn't it?)
Grahame Grieve (Sep 10 2017 at 16:20):
I thought it did reading too. Argonaut does the read part, and that is harmonised...
Grahame Grieve (Sep 10 2017 at 16:20):
but you want it to work whichever ways are allowed
Michele Mottini (Sep 10 2017 at 16:24):
...seems better ... and from what @diego kaminker wrote above it seems that most server do not really like the separate binary resource in the bundle
Michele Mottini (Sep 10 2017 at 16:24):
our server does handle it because we did some work to be MHD compliant
Michele Mottini (Sep 10 2017 at 16:24):
(with the current specs)
Michele Mottini (Sep 10 2017 at 16:25):
(...but then we ran into other problems - mostly Practitioner without identifiers - that are OK for the specs and our server does not like)
Michele Mottini (Sep 10 2017 at 16:26):
(and we gave up )
diego kaminker (Sep 10 2017 at 16:55):
We have further discussed this with @John Moehrke , we will present the issues in our report for this connectathon track today. You can see the presentation here: https://www.dropbox.com/s/hrbuj69fs1x61er/MHD_STU3_TRACK.pptx?dl=0
John Moehrke (Sep 10 2017 at 22:03):
@Michele Mottini MHD includes both the publication side, and the consumption side. It is published here http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf
John Moehrke (Sep 10 2017 at 22:11):
I will propose a CR that tries to address this need, while keeping the solution general use, and not being overly hard to implement. Thus only asking that the same fixup that is done for Resource references be done with URL datatype.
John Moehrke (Sep 10 2017 at 22:17):
See GF#13823
John Moehrke (Sep 11 2017 at 18:11):
I wrote a summary of the IHE-MHD at FHIR Connectathon https://healthcaresecprivacy.blogspot.com/2017/09/fhir-connectathon-of-ihe-mhd-profile.html
Ewout Kramer (Sep 14 2017 at 22:52):
Another thing that is relevant here is that Attachment.url is of type Uri, and our server will not replace the content of uri's in a bundle to point to the newly inserted resource in the same way we do with References. Should Attachment.url into something like Attachment.link[x] where x can be Uri or Reference?
Grahame Grieve (Sep 14 2017 at 23:10):
your server should do that
Ewout Kramer (Sep 14 2017 at 23:20):
your server should do that
Not in general: I should not do that for Coding.system for example, which is also a Uri. So how would my server know Attachment is a special case? Hand code it in? We could do that of course, but it's not really clear from the spec we should do it currently (or me and James look in the wrong place)...
Grahame Grieve (Sep 14 2017 at 23:21):
it should not arise for Coding.system, but that is an interesting point.
Grahame Grieve (Sep 14 2017 at 23:21):
the wording in question is
Grahame Grieve (Sep 14 2017 at 23:22):
Servers SHALL replace all matching links in the bundle, whether they are found in the resource ids, resource references, url elements, or <a href="" & <img src="" in the narrative
John Moehrke (Sep 18 2017 at 14:14):
That seems constrained (is within same Bundle), would work for DocumentReference, and seems to me it would work for any URI anywhere. Relying on uniqueness of unique ID generation...
Grahame Grieve (Sep 18 2017 at 21:11):
well, you do need to get that bit right
Brian Postlethwaite (Sep 20 2017 at 07:57):
I missed that text, I only interpretted resource references (and in narrative), not uri datatypes.
Grahame Grieve (Sep 20 2017 at 13:14):
it might be a little clearer, I guess
Ewout Kramer (Sep 26 2017 at 11:08):
it should not arise for Coding.system, but that is an interesting point.
I think StructureDefinition.uri and maybe a few others are vulnerable too. I remember doing it in Spark in exactly this way, but getting error reports and pushback. Obviously, in Vonk (and HAPI), we're more cautious.... @Christiaan Knaap @James Agnew
Grahame Grieve (Sep 27 2017 at 22:15):
how would it be a problem for StructureDefinition.uri ?
Ewout Kramer (Sep 28 2017 at 07:40):
how would it be a problem for StructureDefinition.uri ?
I would not want the server to alter the canonical - if I am posting a bundle of structuredefinitions where initially the fullUrl and the uri's match to a conformance server, the server will most probably assign a new technical id to the SD, but I would not want the fullUrl to be changed.
John Moehrke (Sep 28 2017 at 12:54):
Ewout, the rule we are indicating is only when the unique value is of an object that is also in the same Transaction Bundle. It is a fixup requirement, not a general requirement for the datatype.
Grahame Grieve (Oct 01 2017 at 23:09):
So it seems like an edge case to me, but given the definition of the canonical uri, we can say that it, and references to it, shouldn't be changed. That complicates matters, but there's lots of cases where you wnat/need uri references to be updated
Ewout Kramer (Oct 02 2017 at 15:10):
Most of the examples that I can think of or uri's that should not be updated are uri's representing canonicals in the conformance resources....And Coding.system. Quantity.system...... extension.url, Signature.whoUri (?), maybe quite some more....
Ewout Kramer (Oct 02 2017 at 15:11):
All corner cases....that's for sure. Very unlikely you'd have a clash here....
Grahame Grieve (Oct 03 2017 at 01:39):
well, you could create a task for s to clarify this special exception to the rules
Ewout Kramer (Oct 03 2017 at 08:23):
Ok! GF#13990.
Last updated: Apr 12 2022 at 19:14 UTC
