Stream: implementers
Topic: Merged Media into DocRef for R5
Eric Haas (Jun 18 2019 at 20:00):
here is a build branch that shows how media is merged into DocumentReference: http://build.fhir.org/branches/moehrke-docRef/
Eric Haas (Jun 18 2019 at 20:02):
Based on this outline here: http://confluence.hl7.org:8090/display/IMIN/Draft+of+Change+Proposal+to+merge+Media+and+Document+Reference
Eric Haas (Jun 18 2019 at 20:02):
Several HL7 workgroups will be voting on pushing these changes into the FHIR specification for Version R5 in the next 2 weeks.
Eric Haas (Jun 18 2019 at 20:04):
If anybody is really against this then let me know here.
Eric Haas (Jun 18 2019 at 20:06):
Updates to the DocumentReference Description and Scope and Usage have been made to reflect the merge and several new elements have been added to the Attachment data type ( non breaking changes ) as well.
Eric Haas (Jun 18 2019 at 20:09):
Any discussion on renaming of the resource has been pushed off until after the proposed merge. And SHOULD NOT be discussed in this stream as is off topic.
Lloyd McKenzie (Jun 19 2019 at 01:20):
The changes to Attachment don't differentiate what's normative and what's not. That needs to happen. I have to admit that DocumentReference feels super-heavy for the purpose of Media. Some of the elements that are "core" for the XDS use-case become more and more questionable as we generify the purpose of the resource to be metadata for 'everything' rather than just documents, and sometimes to not even be a reference at all. The name is also now horrible. I really want it to change before it gets locked down. Yes, it's widely used under the old name, but the name doesn't reflect the scope at all anymore and it's super confusing and non-intuitive to most users.
Eric Haas (Jun 19 2019 at 15:06):
we have updated the introduction. However Git is being fussy and unable to display it on the branch. My local copy is below...
Eric Haas (Jun 19 2019 at 15:09):
Lloyd McKenzie (Jun 19 2019 at 16:00):
The problem is that we're defining the term "document" here in a way that's completely different from how we defined "document" here: http://build.fhir.org/documents.html. And the only reason we're doing that is to avoid changing the name. In my opinion, it's going to cause tremendous confusion for FHIR to overload the term 'document' that way. Avoiding a name change is not a sufficient rationale to introduce such confusion. "RecordReference", "ArtifactReference" or something else would avoid the need to overload the term 'document' and be much less confusing.
John Moehrke (Jun 19 2019 at 16:06):
The problem is that we're defining the term "document" here in a way that's completely different from how we defined "document" here: http://build.fhir.org/documents.html. And the only reason we're doing that is to avoid changing the name. In my opinion, it's going to cause tremendous confusion for FHIR to overload the term 'document' that way. Avoiding a name change is not a sufficient rationale to introduce such confusion. "RecordReference", "ArtifactReference" or something else would avoid the need to overload the term 'document' and be much less confusing.
I have recommended a rename for this reason... but got pushback from the FHIR Product Manager, with the indication that the resource is in wide use today and thus rename would be too big of a change.
John Moehrke (Jun 19 2019 at 16:07):
The changes to Attachment don't differentiate what's normative and what's not. That needs to happen. I have to admit that DocumentReference feels super-heavy for the purpose of Media. Some of the elements that are "core" for the XDS use-case become more and more questionable as we generify the purpose of the resource to be metadata for 'everything' rather than just documents, and sometimes to not even be a reference at all. The name is also now horrible. I really want it to change before it gets locked down. Yes, it's widely used under the old name, but the name doesn't reflect the scope at all anymore and it's super confusing and non-intuitive to most users.
Extra elements are all optional. Which elements specifically do you see as 'heavy'?
Good point on Attachment, I didn't think about this... I can look at how that happens.
Grahame Grieve (Jun 19 2019 at 22:09):
what I said about the renaming was that I insist we consult the community on it. I predict they will not find Lloyd's argument persuasive.
Grahame Grieve (Jun 19 2019 at 22:10):
because Document is a generic term like template with a 1000 meanings anyway
Rob Hausam (Jun 20 2019 at 02:32):
I'll bet that there aren't very many people (implementers or otherwise) outside of those in the FHIR community who have heard of this specific issue who would consider an audio file to be a document (just as one example).
Lloyd McKenzie (Jun 20 2019 at 02:58):
Or a picture of a wound. Or a training video.
René Spronk (Jun 20 2019 at 07:01):
The IHE XDS community is already well aware that what XDS calls a "document" is in effect a "Blob". As such renaming shouldn't be an issue to them. I'd be in favor of a name change.
John Silva (Jun 20 2019 at 12:04):
Late to the game here so I don't understand the subtleties of the arguments (for/against) but back before the days of even IHE XDS I remember the discussions about being able to represent and transport "blobs" of data in a payload, not just so-called "documents". The idea back then was to be able to transport the artefacts of any medical procedure (or observation) that just so happens to be captured in an opaque binary format. I tend to think of these as "blobs" and the stuff (yes, technical term ;-) ) around them as metadata describing the "blob". Even V2 had the notion of 'text documents" (MDM^T02) and reference documents (MDM^T01) that provided a distinction between the content of the document and its representation.
Lloyd McKenzie (Jun 20 2019 at 12:29):
I'd be ok with BlobReference too :)
Eric Haas (Jun 20 2019 at 14:03):
Discussing the name is off topic for this stream. Whatever the name will be, we want comments to any opposition to the rolling Media into The thing currently known as DocumenReference that John spent quite a bit of time putting together.
René Spronk (Jun 20 2019 at 14:26):
Except for basedOn, http://build.fhir.org/branches/moehrke-docRef/documentreference.html is no different from http://build.fhir.org/documentreference.html
John Moehrke (Jun 20 2019 at 14:28):
Correct Rene, there is very little need to change DocumentReference. There have been some changes to the narrative, specifically scope.
René Spronk (Jun 20 2019 at 14:32):
The renaming will help with the scope discussion. But that's off topic (officially)
René Spronk (Jun 20 2019 at 14:32):
http://build.fhir.org/branches/moehrke-docRef/datatypes.html#Attachment why "pages"? And why duration in seconds instead of a normal time data type?
John Moehrke (Jun 20 2019 at 14:33):
because that is what they were in Media... I was just asked to move them into Attachment.
John Moehrke (Jun 20 2019 at 14:33):
further refinement can be done post the agreement of the merger
René Spronk (Jun 20 2019 at 14:36):
Well, we should really be asking those that have implemented Media. Coming from the DocumentReference side this merger doesn't seem to be a big deal. From the Media side the metadata options 'explode' by having this merger.
John Moehrke (Jun 20 2019 at 14:38):
yes that seems the actionable question... I would point out that additional elements that are optional should not be seen as 'explosion', as if you don't use them then you have the same number of elements.
René Spronk (Jun 20 2019 at 14:40):
I'm aware of that, but given that we aim to go for the 80% it doesn't really make sense to provide tons of metadata options if implementers are not going to (most of the time) implement them.
John Moehrke (Jun 20 2019 at 14:51):
I am not against identifying these extra for discussion. I am not against moving them to core extensions... just don't like the "too many elements" argument that is not backed by details supporting that argument.
John Moehrke (Jun 20 2019 at 14:52):
<humor> https://www.youtube.com/watch?v=dCud8H7z7vU </humor> -- "There are simply too many notes."
Lloyd McKenzie (Jun 20 2019 at 14:59):
It's not so much a question of "too many elements" as a lot of elements that are quite esoteric and XDS-specific which makes less sense given that the scope of the resource is so much broader. Specifically:
- masterIdentifier is the most bothersome. It doesn't even really make sense in a general document sense and is very much an IHE thing. We don't define "master" identifiers anywhere else. Suggest putting an extension on one of the other identifiers
- docStatus - entered-in-error is redundant with status.
- perhaps group docStatus, authenticator, custodian under a grouper so they can be excluded as a group if we don't want to make them extensions?
- securityLabel - the situations where the constraints on the reference and the constraints on the target differ seems pretty essoteric
John Moehrke (Jun 20 2019 at 15:09):
excellent points. I would agree that there are issues with these, even in an XDS world. So don't blame XDS for all problems. So lets discuss solutions.
John Moehrke (Jun 20 2019 at 15:09):
masterIdentifier could very easily go to an extension only used with XDS.. It is essentially XDS equivilant of the FHIR .id value...
John Moehrke (Jun 20 2019 at 15:10):
it is also not all that useful for a client to get the masterIdentifier except for making relationships... which in FHIR the relationships are done with .id values... so it is just a business identifier
John Moehrke (Jun 20 2019 at 15:13):
The docStatus and securityLabel are important as the lifecycle of the Binary is not perfectly aligned with the lifecycle of the DocumentReference. Thus the .meta.security is the security labels on the DocumentReference, where .securityLabel is the security labels on the Binary. and .status is the status of the DocumentReference while docStatus is the status of the Binary.
John Moehrke (Jun 20 2019 at 15:18):
note .custodian is NOT at all an XDS item. No idea why it is there or how it is expected to be used.
John Moehrke (Jun 20 2019 at 15:19):
.docStatus is also NOT an XDS item...
John Moehrke (Jun 20 2019 at 15:20):
.docStatus seems to come from mapping with Composition - http://build.fhir.org/documentreference-mappings.html#fhircomposition
John Moehrke (Jun 20 2019 at 15:22):
ah, oops -- masterIdentifier is the identifier of the Binary (I forgot and thought it was the XDS DocumentEntry.entryUUID but it is not http://build.fhir.org/documentreference-mappings.html#xds
So is .masterIdentifier better renamed to .attachmentIdentifier and move it into the .content group?
John Moehrke (Jun 20 2019 at 15:23):
or should the datatype Attachment have an .identifier element?
Lloyd McKenzie (Jun 20 2019 at 16:14):
docStatus would be meaningless for most binaries - even for many PDFs. It really only applies to 'true' documents. If we need to retain docStatus, custodian and authenticator as core, it'd be nice to group them and make clear "these things are only relevant if you're doing 'true' documents. And the dual places for "entered-in-error" is definitely a problem.
Can you explain where the binary security labels and the reference security labels would be different?
For masterIdentifier, I don't understand why it wouldn't just be another identifier in the collection
John Moehrke (Jun 20 2019 at 16:18):
so masterIdentifier is the identifier of the Binary. It would be wrong to say that identifier is the same identifier as the DocumentReference. ---- at least this is the explaination that I can come up with. I might be convinced that it could be just an .identifier... just want to make it clear that if someone looks for that identifier they need to know that they have found a metadata object (DocumentReference) that describes the thing they were looking for, and that if they really want that identifier they need to deference the attachment.
John Moehrke (Jun 20 2019 at 16:20):
as to securityLabel... A container can carry a more restrictive label than the data within. Also, a security assessment can downgrade (de-classify) data.
John Moehrke (Jun 20 2019 at 16:22):
is it exceptional? Yes, it is... but the point is that the Binary needs a securityLabel... if it is not different, then don't fill it out. it has cardionality 0..*
John Moehrke (Jun 20 2019 at 16:22):
grouping as you mentioned (twice) is a fine recommendation..
Lloyd McKenzie (Jun 20 2019 at 16:24):
Why would it be wrong?
John Moehrke (Jun 20 2019 at 16:26):
well that is indeed my operational question... is it wrong to have DocumentReference.identifier that is equal to Composition.identifier (or CDA uniqueId)? it seems that identifier is identifiying something one step away from DocumentReference
Lloyd McKenzie (Jun 20 2019 at 16:26):
The placer numbers and filler numbers for a given order commonly exist on the same instance even though they're talking about different things. In terms of a reference, there's really no reason for it to have any identifiers that are distinct from the thing it's indexing. It'll have a resource id, but I can't conceive of any reason why something would need to reference a reference by a "business" identifier that's distinct from a business identifier associated with the referenced item.
Lloyd McKenzie (Jun 20 2019 at 16:27):
Also, I'd expect the binary to be the thing that would typically have multiple identifiers - i.e. the CDA document, the PDF, the diagnostic image, etc.
John Moehrke (Jun 20 2019 at 16:27):
Also, I'd expect the binary to be the thing that would typically have multiple identifiers - i.e. the CDA document, the PDF, the diagnostic image, etc.
what?
John Moehrke (Jun 20 2019 at 16:28):
those all have one unique identifier of an instance.
John Moehrke (Jun 20 2019 at 16:29):
if you revise them, you get a new unique identifier... which is a new DocumentReference.... where the new DocumentReference.relatesTo points at the previous version.
John Moehrke (Jun 20 2019 at 16:32):
If you don't have this kind of a unique ID per Binary (blob), then you could use FHIR Version management of DocumentReference.. but if you have this case then you don't have a Binary that is unique ID per instance (like CDA).
John Moehrke (Jun 20 2019 at 16:33):
this is why DocumentReference has both version vectors... FHIR Versions of DocumentReference, and new instance versions through DocumentReference.relatesTo
John Moehrke (Jun 20 2019 at 16:34):
note.. you are getting me more convinced that .masterIdentifier should just be a use of .identifier... Im fine with that... not sure if others are.
John Moehrke (Jun 20 2019 at 16:35):
i have never liked .masterIdentifier... especially never liked the name (I always must remind myself that it is actually attachment identifier).
Lloyd McKenzie (Jun 20 2019 at 16:41):
Documents, images, etc can be assigned identifiers by anyone who takes them into custody. If you send a document to multiple systems, they could each assign their own "business" id to it. (In some cases, more than one.) No changes to the document made.
Lloyd McKenzie (Jun 20 2019 at 16:41):
On the other hand, the index entry wouldn't have any business identifier of its own.
Grahame Grieve (Jun 20 2019 at 19:29):
it sounds to me like we should just remove masterIdentifier.
Elliot Silver (Jun 20 2019 at 22:50):
One challenge with master identifier, is if two DocumentReference point to the same document. Shouldn't each DocRef have an identifier, which is different and distinct from the think it points to?
We had discussions in II about whether an accession number is an identifier of an imaging study or an identifier associated with the study. Our conclusion was the latter, and thus should not be stuffed into ImagingStudy.identifier. For DocRef, masterIdentifier is not an identifier of the DocRef, but of the thing being referenced, and similarly should be in a separate element.
I agree though, the element name sucks.
Grahame Grieve (Jun 20 2019 at 23:01):
each docRef has a different id....
René Spronk (Jun 21 2019 at 06:42):
Catching up - in general it seems a good idea to critically review the new DocumentReference, both to identify things that should be XDS-specific extensions, and to see if generalisations/groupings of similar elements are possible. identifier/Masteridentifier, type/category, facilityType/PracticeSetting (used interchangably in almost all XDS implementations) ?
Last updated: Apr 12 2022 at 19:14 UTC
