We’re looking into various options for implementing a FHIR based ‘record location service’. The intention is to return a summary of clinical records/resources and ‘sign-posts’ for any given patient. Very similar to the $everything operation but I’m concerned there could be practical complications (such as considering a federated/distributed environment, or ease of processing for consumers) when using this operation. I’ve noted that some record locator services are simply a DocumentReference search API, which is not what we’re looking for.
Is anyone aware of a (public) spec that serves this kind of use case?
That being said, it sounds like a custom operation might just be what you need or you could take the UK model and instead of making it DocumentReference centric you implement something more appropriate for your use case?
Yep, I’m aware of the NHS NRLS spec. I’m surprised it’s not been more publicly discussed/explored so looks like a custom operation will be the way to go.
The current models for “Record Locator Services” does get down to using DocumentReference. But that is just the current definition of “record”. The location services are around finding communities that have records on a specific subject. That functionality is not restricted to DocumentReference.
The main method today is to use IHE-XCPD to send out federated patient identity lookups. Those with records respond with their definition of the patient in question. The originating org can then determine how well that patient definition fits, and now it has a “location” to address further requests toward.
There is not yet a FHIR specific solution for this kind of nationwide federated identity query. Mostly because the problem has not been brought forward to IHE.
Further, I need to note that DocumentReference is not as limiting as many people presume it is. The ‘document’ in DocumentReference simply is defined as a set of bytes that have a mime-type. This could be a CDA document, but could be a FHIR-Document, or even a FHIR searchset Bundle. The limits are not fundimental to the DocumentReference, they are fundimental to the governing community that agrees to the kinds of information communicated. To this point, there are some communities that have defined things like the current medications in FHIR MedicationStatement form, which just returns a FHIR Bundle of MedicationStatement resources.
Thanks John, that’s food for thought. Or maybe a can of worms?!
Agreed that a location service shouldn’t necessarily constrain itself to DocumentReference, but you also note that DocumentReference can return almost any recordset… Are there any trends emerging anywhere that lean one way or the other (aside from the UKs use of DocumentReference), or is this a relatively immature use case for FHIR?
(whilst the IHE approach/model is sound, we’re required to support FHIR clients and unfortunately most of the systems in this environment dont support IHE specifications)
The Document Sharing concept is very broadly implemented globally. The NHS is not as mature as many other places. See the recently updated whitepaper which includes FHIR and a set of regional case-studies. https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html
Wondering if you ever came up with anything? We are looking into something similar it sounds like. I’d be interested to chat with you about if you have some time.
Our thinking evolved a little bit in that we felt Record Location (assuming “Record” meant every document, result, pathway, relationship, etc) wasn’t quite the use case we were trying to satisfy.
We are therefore considering modelling our FHIR operation more as a “Describe Care Record” API - the purpose being to inform the caller of the kind record currently held. It will still return a list of locations (FHIR Organisations) that have contributed to the Care Record, but also indicates most recent records (ie ‘currency’), number of records, and record categories (based on PRSB Core Information Standards) to aid data discovery.
However, progress is been due to workload constraints, so not got as far as defining a FHIR profile yet. I’ll drop my e-mail in your PM, should you want to discuss anything further.
Hi Folks! I’ve been thinking about record locator service a bit differently - more like an aggregation of where those records could be found when needed. Perhaps a series of steps, aggregation of event (?) information occurring after patient locations/registery (PMIR PIXm PDQm) and prior to the document sharing. Kind of an aggregation of events Hope this make sense.
