FHIR Chat · Handling Contained Resources · implementers

Stream: implementers

Topic: Handling Contained Resources

Tom C (Nov 28 2016 at 16:42):

According to FHIR specification around references and contained resources, https://www.hl7.org/fhir/references.html, I can send to a FHIR server a resource such as an Observation reference an embedded patient resource if it is listed in the contained section of the Observation resource or within a Bundle. And I can successfully do this today against the HAPI server. My question is what does the FHIR server do with the "contained" resources after receiving such a message?

Can I tell the FHIR server to always create the contained resource if it's missing in the FHIR server? Because if it doesn't create the resource, I won't be able to do search for the Observation by the embedded patient identifiers specified in the contained resource.

Grahame Grieve (Nov 28 2016 at 18:49):

if you post to my server, it will allow you to search like that. This is limitation built into HAPI. But there's no way to *tell* the FHIR server to create the contained resource, because the only circumstance where you should use a contained resource is that one where it is impossible for either the client or the server to create an actual resource because there is not enough information

Tom C (Nov 28 2016 at 19:00):

So let's say I am interfacing with a FHIR server and trying to send Observation messages to that server. Are you recommending that before I add any Observation to the FHIR server that I need to make a query to the FHIR server first to see if the Patient resource exists or not and if it doesn't exist, make sure that it's created before submitting the Observation?

Grahame Grieve (Nov 28 2016 at 19:01):

that's one option. Another is to to submit a transaction.

Grahame Grieve (Nov 28 2016 at 19:02):

with a conditional create

Tom C (Nov 28 2016 at 22:06):

So Graphame, your server handles "contained" resources by creating the missing resources in the database and enabling search that way or are you handling queries for resources differently than HAPI by creating other search indexes?

Grahame Grieve (Nov 28 2016 at 22:12):

that's a false dichotomy. technically, I index contained resoruces like I index any other resources; they have a dual identity, their container id and their id, so I know they are contained resources from the index

Tom C (Dec 02 2016 at 21:14):

Your implementation makes sense. What I don't understand is why aren't contained resources are not used more often for handling of references. It eliminates the back and forth chatter between the FHIR server and client for retrieval of internal identifiers for references . As a client I shouldn't have to know what the internal identifiers are of a FHIR server. Take the example of source health care system sharing data with potential interested parties. As the source system, I have my own identifiers for resources in my system. When I broadcast data changes to other systems, I shouldn't have to alter my message for each interested party to make sure that they can process it.

Tom C (Dec 02 2016 at 21:17):

Transactions with conditional create doesn't quite help either. Once again, we are asking FHIR client to take responsibility of how resources are created in the FHIR server. What if two FHIR clients use different conditions for resolving of identifiers during conditional create? You can end up with data is not in sync.

Grahame Grieve (Dec 03 2016 at 01:13):

You can ask the server to package things up using _include.

Grahame Grieve (Dec 03 2016 at 01:13):

but contained resources are a fail as soon as you start handling inforrmation repeatedly, or in different contexts

Grahame Grieve (Dec 03 2016 at 01:13):

or you have to update it

Grahame Grieve (Dec 03 2016 at 01:13):

"When I broadcast data changes to other systems, I shouldn't have to alter my message for each interested party to make sure that they can process it." - that's for sure, but why would you think you need to?

Tom C (Dec 05 2016 at 17:06):

How does _include help with the insertion of data with multiple references? Isn't _include used more for queries? The broadcast message scenario can be the following. Let's say I am an EMR system that currently works with HL7 v2 as means of sharing information and that now I wish push my Observation messages to other interested parties which are FHIR servers. The EMR system however is not a FHIR server. So the EMR sends FHIR messages to those FHIR servers using external FHIR references then it needs to craft a different message for each interested FHIR server.

Tom C (Dec 05 2016 at 17:15):

If not using external references, then as you said, it can be a Transaction with conditional create but that requires quite a bit more resources to be sent across then just references to identifiers. And the calling client is also specifying the condition on how the server matches the identifiers for conditional create. As just a client broadcasting message, why is it the client's job to dictate how the data is stored on the server

John Moehrke (Dec 05 2016 at 17:30):

Tom, yes _include is a query parameter. It is not a concept in messaging, except to the extent you mention that a sender can 'include' things that it thinks the recipient need (likely Profile - IG have defined to happen). It is this that needs to be decided, what is the IG that the sender will follow that tells it what to include. This would be influenced by knowledge of shared accessibility of a common REST service, such as a Patient Registry. With a shared service, like Patient, one can just use references to persistent Resources. BUT if you don't have shared REST services, then you must convey all appropriate information.

Grahame Grieve (Dec 05 2016 at 19:43):

I still don't follow why a different message is required for each servrer

Tom C (Dec 05 2016 at 20:41):

Example: Observation with patient MRN = 123. In FHIR Server 1, patient MRN=123 is represented as Patient/1. In FHIR Server 2, the same patient is represented as Patient/2. When you send the Observation with a link to the patient, you need to specify the subject. So which reference do you specify Patient/1 or Patient/2 ? Hence a different message per server

Grahame Grieve (Dec 05 2016 at 21:11):

you should do what you'd do in v2: send the patient resource (= PID segment). Give it the identity of your own patient id, and put the identifiers in the patient resource (=PID-3)

Grahame Grieve (Dec 05 2016 at 21:12):

then, the recipient server can
- use your id, since that's what it does
- use it's own id, and do reconciliation based on Patient.identifier - just like now

Grahame Grieve (Dec 05 2016 at 21:12):

no need for a different message per server

Tom C (Dec 05 2016 at 22:35):

Yes, that's what we are doing. putting the PID-3 elements inside Patient.identifier.value field and assigning the appropriate system. You are not talking about assigning the Patient resourcce's logical id to PID-3 correct? And if the server decides to use its own logical "id" instead of what you are passing in then when you setup the subject reference in the Observation it will still need to link to this newly generated logical "id".

Grahame Grieve (Dec 05 2016 at 22:37):

no, I'm not saying to use the logical id of the resource in the Patient.identifier.

Tom C (Dec 05 2016 at 22:37):

Maybe I am missing something fundamental here. Is there an example of taking a HL7 v2 Observation message and breaking that down into a collection of FHIR resources that can be sent to any FHIR server without modification?

Grahame Grieve (Dec 05 2016 at 22:38):

yes. see http://build.fhir.org/diagnosticreport-micro1.xml.html

Grahame Grieve (Dec 05 2016 at 22:38):

no. I excluded the patient from that

Grahame Grieve (Dec 05 2016 at 22:46):

so let's just take this little fragment:

MSH|^~\&|Source|Source2|Dest|Dets2|20110620103832||ORU^R01^ORU_R01|2039068|D|2.3.1|||AL|NE|AU|ASCII|ENG
PID|1||124320^^^Source|124320^^^Source|TestPatient^Test^^^^^L|||M||||||||||||||||||||||N
PV1||O|AN^^^AN^^^^^A place|||||ID^Doctor^D^^^Dr^^||||||||||||P

Grahame Grieve (Dec 05 2016 at 22:50):

you're going to get a bundle like this:

bundle
  type = collection
  entry
    fullUrl = http://[source]/Patient/xxxx
    resource = Patient
      id = xxxx
      identifier
        system = [source]
        value = 124320
      name
        family = TestPatient
        given = Test
      gender = M
  entry
    fullUrl = http://[source]/Encounter/yyyy
    resource = Encounter
      patient      
        reference = Patient/xxxx
        participant
          etc
  entry
    fullUrl = http://[source]/Observation/1234
    resource = Observation
      subject
        reference = Patient/xxxx
      code
        LOINC etc      

Grahame Grieve (Dec 05 2016 at 22:50):

short hand there...

Grahame Grieve (Dec 05 2016 at 22:51):

the question is the value of xxxx. The correct value for xxxx is 'something from the source that will be constant each time the same patient is referenced' .

Grahame Grieve (Dec 05 2016 at 22:51):

the recipients can use xxxx, or not.

Tom C (Dec 05 2016 at 22:54):

So id = xxxx may or may not be the logical id depending on FHIR server implementation

Grahame Grieve (Dec 05 2016 at 22:58):

now I'm not sure what you mean by 'logical id'

Grahame Grieve (Dec 05 2016 at 22:58):

in FHIR terms, it *is* the logical id by definition

Tom C (Dec 05 2016 at 22:59):

The logical id as defined here: https://www.hl7.org/FHIR/resource.html. Which states "Each resource has an "id" element which contains the logical identity of the resource assigned by the server responsible for storing it"

Tom C (Dec 05 2016 at 23:00):

I though that was what you are setting with id = xxxx

Grahame Grieve (Dec 05 2016 at 23:08):

indeed, xxx is the logical id, by definition.

Grahame Grieve (Dec 05 2016 at 23:08):

so I don't know what you meant when you said 'may not be the logical id'

Tom C (Dec 05 2016 at 23:19):

What I'm trying to say is how the FHIR server handles the "logical id" xxxx is up to the implementer. It can choose to store xxxx as the logical id in its Patient resource or it may choose a completely different identifier that it generates for the id field. If the FHIR server chooses the latter option would the FHIR client still be able to query for that specific patient using Patient/xxxx?

Grahame Grieve (Dec 05 2016 at 23:23):

are you talking about the server processing the bundle? Then yes, it can choose to use xxxx or it can make up it's own. If it makes up it's own, then 2 questions arise:
- how will it recognise the same patient resource next time, and match it to the same id?
- what impact will that have on other systems

Grahame Grieve (Dec 05 2016 at 23:24):

so the answer to your last question is, pretty much no. In general, it's not safe to assume that resources will keep their logical id when they are moved from server to server unless you have independent confirmation that they will be kept the same

Last updated: Apr 12 2022 at 19:14 UTC