Stream: IPS
Topic: Patient Logical identifier
Alex Goel (Nov 17 2020 at 15:12):
Hi, a few of us wanted to confirm that for the Immunization.patient.identifier in the IPS it should be a literal reference, and logical should be used when literal is not available. The wording is not clear. Is then Immunization.patient.reference the literal and Immunization.patient.identifier the logical only if the literal is unavailable? Does that mean if we fill reference, we do not need identifier? @Nityan Khanna @Mo Ibrahim @Derek Ritz https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Immunization-uv-ips.html
IPSImmunizationQuestion.png
Giorgio Cangioli (Nov 17 2020 at 17:39):
Hi @Alex Goel for some kinds of elements (including subject/patient) in the IPS we expect that a reference to an actual FHIR resource is provided. That the reason why the reference is 1..1 This doesn't exclude that you can provide a 'display' or an 'identifier' if you wish to ..but you are not obliged to do it ...
Alex Goel (Nov 17 2020 at 18:03):
@Giorgio Cangioli thanks for the clarification. so that means that Immunization.patient.identifier in the IPS could be equivalent to the Patient.id?
Giorgio Cangioli (Nov 17 2020 at 18:34):
the Patient.id is the id for that Patient resource; not the "identifier" of that patient (see https://www.hl7.org/fhir/resource.html#identification).
business identifiers of the patient are in Patient.identifier
if the patient.id = "ips-patient-1", a possible Immunization.patient.reference might be something like "http://myserver.foo/Patient/ips-patient-1" .
Derek Ritz (Nov 18 2020 at 20:50):
Giorgio Cangioli said:
if the patient.id = "ips-patient-1", a possible Immunization.patient.reference might be something like "http://myserver.foo/Patient/ips-patient-1" .
So... the composition.subject.reference and the immunization.patient.reference MUST be identical... right? It makes sense that these will all be the same... but it also is a bit awkward that we're normatively replicating the patient reference for various elements inside the IPS composition, and the composition also normatively mandates the patient reference. I'm sure this is true for other resources, too, that are in the IPS composition. (I'm curious... would a FHIR server throw an exception if all of these patient references were NOT identical?)
Also... as you illustrate... the patient.id is a necessary part of the reference... or is it? Is it possible to create a valid reference that doesn't include the id in it?
Lastly... as has been getting discussed on another thread... although it isn't mandated that the reference should be a fully formed URL -- is sure could be considered as a "best practice" (especially in cases where there may be an EMPI server separate from the shared health record repository). :smile:
Christof Gessner (Nov 18 2020 at 21:03):
Interesting. I just notice that (at least in the context of a "Clinical Document") the rules for Context Conduction within a CDA Clinical Document were quite useful. In FHIR the idea is more like "each resource provides the fully qualified context"?
David Hay (Nov 19 2020 at 02:32):
They could also be quite tricky. FHIR takes that position that all references must be explicit...
Morten Ernebjerg (Nov 19 2020 at 08:48):
I only recently discovered the comparisons between FHIR and other standards in the FHIR spec, but found them quite illuminating (especially as someone who never worked directly with the older standards). The comparison between FHIR & v3/RIM offers the following argument for explicit references (along the lines of what David said)
In FHIR, no context is conducted - everything is explicit. (...). One of the benefits of this approach is that each resource can be safely consumed and examined without concern for the context in which that resource was communicated. The meaning of each resource instance is fully self-contained.
Giorgio Cangioli (Nov 19 2020 at 09:12):
So... the composition.subject.reference and the immunization.patient.reference MUST be identical... right? It makes sense that these will all be the same... but it also is a bit awkward that we're normatively replicating the patient reference for various elements inside the IPS composition, and the composition also normatively mandates the patient reference. I'm sure this is true for other resources, too, that are in the IPS composition.
Yes it is highly probable that all the information inside a IPS belong to the same patient :-)
and, as explained by others, no context conduction is the way FHIR has been (IMHO correctly) designed.
Giorgio Cangioli (Nov 19 2020 at 09:13):
(I'm curious... would a FHIR server throw an exception if all of these patient references were NOT identical?)
It might be a test to be done ...
Giorgio Cangioli (Nov 19 2020 at 09:14):
Also... as you illustrate... the patient.id is a necessary part of the reference... or is it? Is it possible to create a valid reference that doesn't include the id in it?
Lastly... as has been getting discussed on another thread... although it isn't mandated that the reference should be a fully formed URL -- is sure could be considered as a "best practice" (especially in cases where there may be an EMPI server separate from the shared health record repository).
there are different options for managing the references, in particular with bundles where you can use a sort of 'Temporary Resource identifier' in case you don't know yet what is the 'real' id. In that case is the receiving server that will assigned the right ids and references to the resources, as needed.
[Removed wrong example, thanks Olivier]
Oliver Egger (Nov 19 2020 at 09:57):
Are this references correct for a bundle which is not coming from a RESTFul API? I would have thought that the references should be in above example to the fullUrl: <reference value="urn:uuid:2b90dd2b-2dab-4c75-9bb9-a355e07401e8"/> maybe with the resource type added below the reference and that the id element is not added in the resource.
Oliver Egger (Nov 19 2020 at 09:59):
with the example above I think the Patient entry would not be found according to the spec 2.36.4.1 Resolving references in Bundles
Oliver Egger (Nov 19 2020 at 10:04):
see also the example in the spec "reference to a locally identified resource" http://hl7.org/fhir/bundle-references.xml.html
Morten Ernebjerg (Nov 19 2020 at 10:20):
@Giorgio Cangioli Maybe one comment on the IPS requirement that certain patient references be literal. I think this might be slightly awkward for certain use cases that use IPS as a "foundational library". For instance, we are using IPS as a basis for our profiles. These are also used in scenarios where the data is ingested piece by piece, rather than as a complete IPS document Bundle. In some scenarios, the relevant patient is only identified by the business context (e.g. through the authorization mechanism or via an ID on the source system). The data source does not (and cannot) know the id of the corresponding FHIR Patient resource on the server, only the server can make that connection. Hence , the source could provide an identifier but not a reference to a FHIR resource, i.e. they would always have to "wiggle out" of the requirement by filling display (or they would redundantly have to send along an own Patient resource with every piece of data).
Giorgio Cangioli (Nov 19 2020 at 12:13):
Oliver Egger said:
Are this references correct for a bundle which is not coming from a RESTFul API? ...
Sure, thank you for pointing this out :-)
Giorgio Cangioli (Nov 19 2020 at 12:23):
Morten Ernebjerg said:
I think this might be slightly awkward for certain use cases that use IPS as a "foundational library".
Hi @Morten Ernebjerg as you know the IPS has been (mainly) designed for being used within the IPS document, but this is a discussion that I think we should have for the evolution of the IPS, as for example distinguishing IPS document specific constraints from IPS constraints.
Last updated: Apr 12 2022 at 19:14 UTC
