FHIR Chat · Dedupe patients · cql

Stream: cql

Topic: Dedupe patients

Richard Stanley (Jan 11 2022 at 19:20):

This is a follow-up from external discussion. I have a use case where a patient receives care twice in a clinic but also registers twice, so is seen as a different person in clinical records. Our service (OpenCR) can create a third Patient record that has links to the others, so we have a master patient ID. I'd like to help to understand how to union across all patients linked to that master patient ID. An example master patient id resource is here: https://github.com/intrahealth/simple-hiv-ig/blob/master/opencr/opencr_goldenrecord.json @Bryn Rhodes @Jenny Thompson

Derek Ritz (Jan 12 2022 at 13:52):

@Richard Stanley -- is there a potential problem with "deep hierarchies" being created over time? I'm just thinking that, if this scenario happens again, then another golden ID will be created that will now need to reference the "old golden ID", plus the new dupe... and now there is the start of a hierarchy.

Richard Stanley (Jan 12 2022 at 16:38):

Great question. The way our record linkage works is that there isn't a nesting of golden IDs. So, no, I don't think it will be an issue but I don't know about other implementations of patient registries.

Bryn Rhodes (Jan 25 2022 at 00:03):

Hi @Richard Stanley , with apologies for the delays here, there are two approaches to following patient links like this. The first is to related context retrieves to access the information from related patients:

library PatientLinks

using FHIR version '4.0.1'

include FHIRHelpers version '4.0.1'

context Patient

define RelatedPatients:
  Patient P
    return (P.link L where L.type = 'seealso' return L.other)

define AllProcedures:
  [Procedure]
    union [RelatedPatients -> Procedure]

Bryn Rhodes (Jan 25 2022 at 00:04):

The second is to use an unfiltered context:

library PatientLinksUnfiltered

using FHIR version '4.0.1'

include FHIRHelpers version '4.0.1'

context Unfiltered

define AllPatientProcedures:
  from [Patient] P, [Procedure] PR
    where PR.subject = P.reference()
      or PR.subject in (P.link L where L.type = 'seealso' return L.other)

Bryn Rhodes (Jan 25 2022 at 00:07):

Unfortunately, the Java engine does not currently have support for related-context retrieves, and the support for unfiltered context is limited, so there is some implementation work to be done before either of these approaches would work in the Java stack (and likely the JavaScript stack as well).

Bryn Rhodes (Jan 25 2022 at 00:07):

So it is possible to express de-duplication queries, but evaluating them will take some work.

Richard Stanley (Jan 25 2022 at 02:01):

Thanks so very much @Bryn Rhodes!

KC (Jan 27 2022 at 17:17):

Hey @Bryn Rhodes - a quick follow up to this, I am interested in running CQL queries using the execution service using the unfiltered context rather than the patient context (for example querying all patients with a given condition code), is there a way to not just query for one patient id?

Bryn Rhodes (Jan 28 2022 at 18:37):

CQL does support expressing these types of queries with the Unfiltered context, but the execution stacks currently don't support this very well. For example, running this library in the Atom plugin:

library UnfilteredScratchpad

using FHIR version '4.0.1'

include FHIRHelpers version '4.0.1'

context Unfiltered

define Patients: [Patient]

Gives the error UnknownType: Could not resolve type Unfiltered., the IDE plugins just don't know how to run Unfiltered context queries yet. It's an area we would certainly welcome contributions on. In the case of the file-based providers that the IDE plugins are using, it would probably be pretty straightforward to support, but we just haven't gotten to that yet.

KC (Jan 28 2022 at 19:25):

Thanks for the response - makes sense I just want to confirm!

Last updated: Apr 12 2022 at 19:14 UTC