FHIR Chat · Search by document patient id · implementers

Stream: implementers

Topic: Search by document patient id

Elliot Silver (Jan 25 2022 at 20:40):

If I have a system with a patient /Patient/123 and a document bundle /Bundle/456 that is about the same person, am I correct that a search of Bundle?composition.patient.id=Patient/123 won't necessarily work, because the patient inside the bundle doesn't have to correspond to any known patient outside the bundle, and even if it is the same person, it doesn't have to have the same patient id? Searching by Bundle?composition.patient.identifier would be more robust?

Josh Mandel (Jan 25 2022 at 20:47):

I'll first note that I don't think Bundle?composition.patient.id=Patient/123 is quite a valid search.

You may need Bundle?composition.patient._id=123, which would be brittle if the reference doesn't resolve... but if instead you write Bundle?composition.patient=Patient/123, I think it should work even if the reference doesn't resolve or is bundle-internal.

Elliot Silver (Jan 25 2022 at 20:53):

(That's what I get for trying to compose a search off the top of my head.)

Sorry, can you clarify the distinction you see between your two searches?

Josh Mandel (Jan 25 2022 at 21:05):

One uses chaining syntax, chaining into a referenced Patient; the other evaluates the reference itself without chaining into the target of the reference. The . after "patient" indicates chaining into the target.

Josh Mandel (Jan 25 2022 at 21:06):

Now, my analysis here is a bit theoretical, based on this spec itself; I'm interested to know if real-world FHIR servers behave differently.

Elliot Silver (Jan 25 2022 at 21:19):

So, Bundle?composition.patient._id=123 looks for bundles with compositions that have a patient reference with a value of 123; and Bundle?composition.patient =Patient/123 look for bundles with compositions that have a patient that references the known-outside-the bundle patient Patient/123? (Did I somehow come up with the exact opposite conclusion from your original statement?)

Elliot Silver (Jan 25 2022 at 21:22):

My real focus here is to confirm that the search is entirely inside the bundle (the document bundle must contain the composition, and the composition requires all "primary" resources, such as patient, be included in the bundle as well) and the existence of any patient resource outside the bundle is completely irrelevant to the search.

Josh Mandel (Jan 25 2022 at 21:28):

Elliot Silver15:19 So, Bundle?composition.patient._id=123 looks for bundles with compositions that have a patient reference with a value of 123; and Bundle?composition.patient =Patient/123

Not quite -- I'm saying

• Bundle?composition.patient._id=123 Looks for a Bundle with a composition in .entry[0] where there's a subject that references a Patient, and where following that link and looking in the target Patient resource (whether the reference resolves to a Bundle-local resource or a resource elsewhere on the server)... you have a patient with an id property of 123.

• Bundle?composition.patient =Patient/123 looks a Bundle with a composition in entry[0] where there's a subject that is a reference to to "Patient/123" (where the reference might fail to resolve altogether, or might resolve to a Bundle-local resource, or a resource elsewhere on the server).

Josh Mandel (Jan 25 2022 at 21:30):

the existence of any patient resource outside the bundle is completely irrelevant to the search

Well, this is determined by the Bundle.entry.fullUrl on the Composition entry -- if that fullUrl indicates a Composition "based in" the sever like https://server.example.org/fhir/r4/Composition/123, then any relative reference in the Composition is interpreted as a reference to a resource on the server (see https://build.fhir.org/bundle.html#references)

Josh Mandel (Jan 25 2022 at 21:32):

Those reference resolution rules don't set any expectations that are particular to "document"-type Bundles.

Elliot Silver (Jan 25 2022 at 21:33):

A document Bundle (type = "document") consists of a series of entries, the first of which is a Composition. Each entry element SHALL contain a resource.

I read that as the resource must be in the bundle, not referenced.

Josh Mandel (Jan 25 2022 at 21:34):

I don't think so, though that may be a rule spelled out elsewhere. The language you quoted above just means no Bundle.entry is present that lacks a .resource property.

Elliot Silver (Jan 25 2022 at 21:34):

Also, https://build.fhir.org/documents.html#content.

Josh Mandel (Jan 25 2022 at 21:35):

https://build.fhir.org/documents.html#content states:

Other resources that these referenced resources refer to may also be included in the bundle if the document construction system chooses to do so.

Elliot Silver (Jan 25 2022 at 21:35):

Yes, after the composition, subject, author, etc. you can do references, but all the "primary" resources are in the bundle.

Josh Mandel (Jan 25 2022 at 21:36):

So some referenced resources have to be included, and others don't. But this is not actually relevant to your initial question, because when resources are included, they would have their fullUrl populated in a manner consistent with the reference, right?

Elliot Silver (Jan 25 2022 at 21:37):

But fullUrl doesn't come into the search, does it?

Josh Mandel (Jan 25 2022 at 21:37):

Like, you can find the subject in the bundle but that's just a shortcut -- you can also find it on the server, if the Composition.subject looks like {"reference": "Patient/123"}. Now, if the Composition.subject used a urn:uuid or something, it might be possible that that the subject is only available in the bundle.

Elliot Silver (Jan 25 2022 at 21:38):

Or patient/123 might refer to a patient 123 on a different server that has nothing to do with patient 123 on this server.

Josh Mandel (Jan 25 2022 at 21:40):

that would only be possible if the Bundle.entry[0].fullUrl reflected this, like "https://other-server.example.org/Composition/123", right?

Josh Mandel (Jan 25 2022 at 21:41):

And this is my point about Bundle reference resolution rules: if the server doesn't maintain a copy of the target, chaining will be very hard, but searches that can be evaluated against the reference itself are still easy. And in your example that's all you need.

Josh Mandel (Jan 25 2022 at 21:42):

For the sub-case of references to resources that will always be present in the Document bundle, chaining is at least possible, but your use case still doesn't require it, so I would try not to depend on it.

Elliot Silver (Jan 25 2022 at 21:45):

If I use Composition/x$document to create a document on one server, save it to disk, and up load it to another server, you're saying fullUrl will point to old-server, and Bundle?composition.patient=Patient/123 won't match because what the server should be doing is trying to match this-server.com/Patient/123 against old-server.com/Patient/123?

Elliot Silver (Jan 25 2022 at 21:50):

(Anyone else feel like a freshman who's just walked into a grad seminar?)

Oliver Egger (Jan 25 2022 at 22:09):

welcome to the wonderful word of resource id resolution in bundles :rolling_on_the_floor_laughing:

Paul Church (Jan 25 2022 at 22:21):

Part of the discussion has to be what happens before the search, i.e. when the bundle is ingested into the server by whatever method, does the reference get rewritten? Would it be accepted at all if it just said Patient/123 and the server didn't have that resource or know how to resolve it?

I would expect the search to match the bundle if the reference was stored as Patient/123, because it's not a search problem at that point.

Elliot Silver (Jan 25 2022 at 22:55):

Paul Church said:

Part of the discussion has to be what happens before the search, i.e. when the bundle is ingested into the server by whatever method, does the reference get rewritten? Would it be accepted at all if it just said Patient/123 and the server didn't have that resource or know how to resolve it?

Yes, but I don't think that doing a rewrite is required (or implied) in the base spec. As an IG author, if I want it done, do I need to specify something here?

Josh Mandel (Jan 25 2022 at 23:33):

If you store the exact bytes of a bundle like https://www.hl7.org/fhir/document-example-dischargesummary.json.html in your server ... and then a client retrieves this document and wants to resolve the subject of the Composition as expressed here:

        "subject": {
          "reference": "http://fhir.healthintersections.com.au/open/Patient/d1",
          "display": "Eve Everywoman"
        },

... the rules say:

1. Look for a bundle-local resolution -- this will succeed because the relative reference is in the same FHIR base as d1; the fullUrl elements are:

      "fullUrl": "http://fhir.healthintersections.com.au/open/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57",
      "fullUrl": "http://fhir.healthintersections.com.au/open/Patient/d1",

2. If the local resolution had failed, the client would have to go on to querying the origin server. But (1) succeeded and always will succeed for Document bundles when resolving Composition.subject, so we're OK.

Now, when your server is indexing this document, a whole bunch of questions come into play, as Paul notes. Servers could build support for indexing these in-Bundle resources, but frankly if the server is going to store this bundle at https://newserver.example.org/Bundle/123, then it's already rewriting Bundle.id, and it might choose to rewrite all the references as well. I don't think the FHIR API currently has a good way to store a full document byte-for-byte as it originated from the source and also allow search on top, because of this issue with Bundle.id not being globally unique.

Paul Church (Jan 26 2022 at 01:45):

I don't know much about document-specific concerns but isn't this similar to having an IG require referential integrity? Whatever the server does, it has to avoid ending up with a relative reference (Patient/123 with no fullUrl) that doesn't resolve.

Josh Mandel (Jan 26 2022 at 03:25):

I don't see any document specific concerns here. For any references that aren't included in the document Bundle, the receiving server might well be stuck without an ability to resolve. That needn't prevent the receiving server from storing the Document bundle and supporting search on the content it doesn't have.

Josh Mandel (Jan 26 2022 at 03:30):

Re: documents I'm just saying if you want to store/expose the raw source bytes (to support signature algorithms, hashes, etc) you can do so in a Binary, but clients won't be able to run searches like Elliot is asking about. Or you can store a Bundle at the Bundle endpoint and support search, but you won't be serving the original bytes. You can't have both features without storing the Document twice, as it currently stands.

Elliot Silver (Jan 26 2022 at 04:54):

Paul Church said:

I don't know much about document-specific concerns but isn't this similar to having an IG require referential integrity? Whatever the server does, it has to avoid ending up with a relative reference (Patient/123 with no fullUrl) that doesn't resolve.

Even if it isn't technically different, It feels to me qualitatively different. One of the supposed advantages of "documents" is that they are self-contained, however, that means that the contents of the document don't need be related to anything known to the server. I'm trying to understand what that translates to in practice.

Derek Ritz (Jan 26 2022 at 16:06):

It can differ based on the specific use case, of course, but one of the benefits of a FHIR document bundle (such as an IPS, for example) is that it provides an auditable, nonrepudiable, message exchange of point-in-time context. That said... again with the IPS example... it would be helpful for this exchange to also be able to 'sync' systems to a common context.
Following along with this idea, a context-syncing pattern could be something like:
ENCOUNTER BEGINS

1. EMR fetches IPS for Derek from HIE
2. EMR compares local content with IPS content
3. IF IPS represents a superset of the content in the EMR update Derek's record in the EMR with new data from the IPS

EXECUTE ENCOUNTER ACTIVITIES

4. update Derek's record in the EMR to reflect encounter data, outcomes, and orders
5. create an updated IPS for Derek from the EMR content and submit it to HIE (which would leverage it, as in step 3, to update Derek's shared health record)

ENCOUNTER ENDS
I think this valuable pattern could be undermined if it is difficult (or potentially patient-unsafe) to do .id resolution between content in the bundle and the FHIR server that this bundle is trying to sync with.

Elliot Silver (Jan 26 2022 at 18:56):

@Derek Ritz Following up on the IPS context:

• Patient obtains IPS from local (hospital, PCP, national system, etc) which identifies the patient by local identifiers, and uses a local URL for patient id.
• Patient is injured while travelling and goes to foreign hospital where a new patient resource is created in the foreign EMR.
• Patient provides foreign healthcare provider with their IPS which gets uploaded to the foreign EMR.

Now the question is, does the patient in the IPS get modified to match the foreign patient id? Do we update the patient resource in the EMR to match the content of the patient resource in the IPS? Do we update the patient resource in the IPS to match the patient resource in the EMR? Which changes break the "point-in-time" nature of a document? Is there some level of "tweak" to the content of a document that is accepted without "changing" the document? If we don't change the patient id (and potentially MRN, etc.) how do we later identify this document as belonging to the patient with a given (foreign) id?

Derek Ritz (Jan 26 2022 at 19:17):

So... I'm actually not thinking of cross-border use cases, here. I'm actually just thinking about multiple care delivery sites within the same province, and all connected to the same HIE-based shared health record. :smile:

Derek Ritz (Jan 26 2022 at 19:27):

My sense is that the exchange of a bundle within a single governance framework should be able to benefit from consistency in .identifier (and potentially, in .id) across a federation of FHIR servers... with the bundle being used as the way to do the syncing.

Elliot Silver (Jan 26 2022 at 19:30):

This is part of what I am getting at -- what are the built-in assumptions to using a document bundle? Do we need a common framework for patient id/identity?

Lloyd McKenzie (Jan 26 2022 at 19:41):

In the "within a province" scenario, ideally you'd be looking to share the data over a RESTful interface and not creating a plethora of document instances to wade through.

Derek Ritz (Jan 26 2022 at 19:53):

@Lloyd McKenzie maybe... there are useful medico-legal implications of the document exchange... and the evidence trail it operationalizes. (also... documents can be signed... and there are times where this is valuable, too).

Derek Ritz (Jan 26 2022 at 19:59):

even within a province

Derek Ritz (Jan 26 2022 at 20:10):

Elliot Silver said:

This is part of what I am getting at -- what are the built-in assumptions to using a document bundle? Do we need a common framework for patient id/identity?

I think we will have to expect that master data management of all kinds will be needed. Consistency in patient ids, provider ids, location ids, and even document ids for important things like prescriptions -- will all be the key to successfully being able to operationalize FHIR document exchange within a care delivery network.

Josh Mandel (Jan 26 2022 at 20:24):

I think a strong focus on

1) ensuring that all (important) related resources are part of a document Bundle and
2) populating Resource.identifier with cross-org-relevant values where possible

is going to be the best "bang for buck" in the @Derek Ritz use case. Aligning Resource.id across systems should be a non-goal in my opinion.

John Moehrke (Jan 27 2022 at 16:54):

in a pure FHIR world... there would be no Resource.identifier values, as nothing exists outside FHIR... right? So the Resource.id at the source is the unique identifier.

John Moehrke (Jan 27 2022 at 16:55):

definitely agree that aligning Resource.id across systems is a non-starter.

Last updated: Apr 12 2022 at 19:14 UTC