Stream: implementers
Topic: Composition.identifier
Nick George (Jan 29 2021 at 23:55):
Hello - I'm curious why Composition.identifier is singular, when it's repeated for almost all other resources
Nick George (Jan 29 2021 at 23:55):
for reference:
http://hl7.org/fhir/composition-definitions.html#Composition.identifier
http://hl7.org/fhir/patient-definitions.html#Patient.identifier
Vassil Peytchev (Jan 30 2021 at 00:23):
This is the explanation: http://hl7.org/fhir/composition.html#cda
Which brings up the question, is composition solely intended to be used for documents, and to always exist within a Bundle of type document?
A related issue is that ClinicalDocument.id should match Bundle.identifier, and not Bundle.id - FHIR#30766
Rik Smithies (Jan 30 2021 at 12:38):
From FHIR-30766: "ClinicalDocument.id (since both are business identifiers)."
is ClinicalDocument.id a business identifier? That would be in contrast to the normal use of id.
Lloyd McKenzie (Jan 30 2021 at 14:48):
ClinicalDocument.id shouldn't be considered a business identifier. @Rick Geimer
Giorgio Cangioli (Jan 31 2021 at 18:36):
I agree with you @Lloyd McKenzie that the ClincialDocument.id is not a "pure" business identifier, but - as far as I can see - it is neither a resource identifier.
In my understanding a ClincialDocument.id will not change during the document instance lifecycle (independently on where it is stored) ; while the bundle.id representing that document may change.
Giorgio Cangioli (Jan 31 2021 at 18:38):
In that sense it seems to me reasonable that it is represented by the bundle.identifier as described in the "FHIR Documents" page.
"The document identifier (mandatory). This is found in Bundle.identifier and is globally unique for this instance of the document, and is never re-used, including for other documents derived from the same composition
The Composition identifier (optional). This is found in Composition.identifier, and is the same for all documents that are derived from this composition"
Lloyd McKenzie (Jan 31 2021 at 20:46):
ClinicalDocument.id is absolutely a resource identifier when the content exists RESTfully. If it's just stand-alone in a document with no RESTful location, then it's a UUID. In neither case is it a "business identifier".
Lloyd McKenzie (Jan 31 2021 at 20:46):
I.e. not something you'd ever want to show a typical end-user.
Rob Hausam (Jan 31 2021 at 20:51):
Are we mixing things up a bit here? There isn't a ClinicalDocument resource and so there isn't a ClinicalDocument.id element in FHIR.
Lloyd McKenzie (Jan 31 2021 at 21:46):
Sorry, right. I was referring to Composition.id
Peter Jordan (Jan 31 2021 at 22:36):
In this context ClinicalDocument is a Profile on the Composition Resource. The IPS Composition Profile derives from the ClinicalDocument Profile - both profiles retain the cardinality of the identifier element of the Composition Resource which, as stated above, is 0..1.
The big question for IPS implementers is what should be placed in the following elements (with values from one of the examples in the IPS IG )..
Bundle.id ("IPS-examples-Bundle-01")
Bundle.identifier ( <system value="urn:oid:2.16.724.4.8.10.200.10"/> <value value="175bd032-8b00-4728-b2dc-748bb1501aed"/>)
Composition.id ("30551ce1-5a28-4356-b684-1e639094ad4d")
Composition.identifier ( <system value="urn:oid:2.16.724.4.8.10.200.10"/> <value value="3f69e0a5-2177-4540-baab-7a5d0877428f"/>)
Jean Duteau (Jan 31 2021 at 22:39):
Here is my $0.02: whenever I map Clinical Documents or Product Documents to a FHIR Document Bundle, I map the ClinicalDocument identifier which identifies that specific version of that specific document to the Bundle.identifier; I map the Clinical Document set Identifier which is an identifier of the document across all of its versions to Composition.identifier. I don't map anything to the Bundle.id or the Composition.id as those are FHIR-specific ids of the resources and generally not something I have in my source data.
Vassil Peytchev (Feb 01 2021 at 02:00):
And that is exactly what FHIR#30766 is about.
Last updated: Apr 12 2022 at 19:14 UTC
