Stream: implementers
Topic: Composition Identifier
AbdulMalik Shakir (Nov 17 2018 at 18:53):
The composition resource identifier has a cardinality of (0..1). My project has a need for multiple identifiers for the same instance of composition as there are multiple stakeholders for the composition and each stakeholder assigns it their own identifier in addition to the identifier assigned by the original author. Has anyone else had the need to have more than one instance of composition.identifier? If so, how did you get around the (0..1) cardinality constraint?
Richard Townley-O'Neill (Nov 18 2018 at 23:46):
Maybe DocumentReference, thought that only mentions documents and not compositions.
Yunwei Wang (Nov 19 2018 at 02:09):
Don't know what is your workflow. Is this resource passed to different stakeholder at different stage? Sounds like you can use AuditEvent.
AbdulMalik Shakir (Nov 19 2018 at 02:14):
The composition is passed from one stakeholder to another. The recieving stakeholder then assigned its own identifier to the composition.
Yunwei Wang (Nov 19 2018 at 02:17):
Do you need to know who assigned an identifier?
Lloyd McKenzie (Nov 19 2018 at 02:36):
What kind of document is it?
AbdulMalik Shakir (Nov 19 2018 at 06:25):
Yes, I do need to know who assigned the identifier. But I can get that from Identifier.assigner
AbdulMalik Shakir (Nov 19 2018 at 06:27):
@Lloyd McKenzie It is the Death Certificate. It is assigned an identifier by the author (medical examiner or coroner) and when received by the Public Health Agency it is assigned an additional identifier.
John Moehrke (Nov 19 2018 at 14:11):
if a recipient is assigning an identifier, this would be a typical use of DocuementReference. They would own the DocumentReference, so they can put whatever .identifier on it they want. The one true identifier, Composition.identifier, would be stored in DocumentReference.masterIdentifier... as it is the master identifier of the Binary... the Composition...
AbdulMalik Shakir (Nov 19 2018 at 15:27):
Thanks @John Moehrke . That is the solution I went with. I did not think of repeating the Composition.identifier as the DocumentReference.masterIdentifier, but it sound like a good idea. Thanks. pasted image
John Moehrke (Nov 19 2018 at 15:44):
yes, see the mapping between Composition and DocumentReference -- http://build.fhir.org/documentreference-mappings.html#fhircomposition
Lloyd McKenzie (Nov 20 2018 at 01:03):
Having both Composition and DocumentReference need to be shared to tell the full story is odd. DocumentReference is supposed to be an index of the information in the document. It actually doesn't make sense for the "index" resource to allow more identifiers than the base resource. Do we have any idea why this is the case?
John Moehrke (Nov 20 2018 at 13:45):
The Identifier in a DocumentReference is the identifier of the DocumentReference... NOT of the document. The identifier of the document is the DocumentReference.masterIdentifier.
Lloyd McKenzie (Nov 20 2018 at 15:53):
That also seems weird to me. In what situations do you assign "extra" identifiers to an index entry that aren't considered to be identifiers of the target of the index entry?
Elliot Silver (Nov 20 2018 at 17:25):
Well specifically, XDS separates the two, recognizing that the metadata can be updated and tracked separately from the document itself. You can also index the same content in more than one context--once for the mother, once for the child; once when supplied by one system, once when supplied by another; etc. (I'm not suggesting that the latter is a good pattern, but one that is supported.)
Lloyd McKenzie (Nov 20 2018 at 18:26):
So if you have a document whose subject is the mother, you could have an index indicating that the subject of the document is the child? And add extra identifiers?
Elliot Silver (Nov 20 2018 at 18:36):
A perinatal document would be relevant to the health of both the mother and baby, and should be added to the record of both. However the indexing information -- such as subject -- might be different.
Richard Townley-O'Neill (Nov 21 2018 at 05:46):
The Identifier in a DocumentReference is the identifier of the DocumentReference... NOT of the document.
DocumentReference.identifier is 0..* and there is no business identifier for the DocumentReference.
The definition of DocumentReference.identifier is "Other identifiers associated with the document, including version independent identifiers.", and the short is "Other identifiers for the document".
That text conflicts with @John Moehrke 's explanation.
John Moehrke (Nov 21 2018 at 13:54):
I don't know that it conflicts, as an identifier of the metadata is indirectly an identifier of the thing the metadata describes. The use of .identifier is available in this way, it does not need to be used this way. The zulip chat stream started with a specific usecase, that is the use-case I was responding to. -- I would be happy for you to submit a change request with recommendations.
In xds the equivalent (and mapped) .identifier is just a technical identifier (That is the XDS entryUUID, a guid that is assigned by the registry). Much like the _id is in FHIR.
John Moehrke (Nov 21 2018 at 13:58):
thus .identifier is much like all FHIR Resources with regards to the equivalent business identifier, at 0..*. This pattern is demanded by the FHIR core modeling. So, I just offered a method to address the use-case that started this stream.
John Moehrke (Nov 21 2018 at 14:03):
As Elliot points out, it is not uncommon for a unique document to be registered in various ways. Mostly because it is registered by multiple parties as a document they have in their possession (presuably the non-author does indicate the proper author). The mother/child is unique, and has other characteristics to differentiate and align. There is also the case of documents that are not single-patient based. A document from the scene of an accident, etc. There are many reasons why a document might need to be registered multiple times. The model enables these, it does not demand that you must support or ever use it that way.
Last updated: Apr 12 2022 at 19:14 UTC
