Link multiple Compositions to a single Visit

Clinical
19

Much-needed discussion! I want to contribute by adding a few other options on how this can be done. I feel like the directory approach explained very well by @birger.haarbrandt here is the “official” way to do this. However, I am going to be heavily critiquing the directory approach since I think it has many issues. These issues have also been brought up in more detail here by @pablo and @thomas.beale.

My main issues with the directory approach

  1. There can only be one directory per EHR: So every time you need to update it, you need to retrieve it, update parts that you want, and then post it back. I don’t like doing this since it increases the burden on applications to update the folders correctly. And giving full access to every app to update the root folder is just waiting for things to go wrong. And it’s a nightmare to implement Access Control policies on Directories and Folders based on the content.
  2. If you want to filter an AQL to a specific folder, you can’t do it in AQL directly (yet): You’ll need to get the directory first, run through all the compositions in a tree search, then use a MATCHES clause and include all the composition IDs there. I don’t like this too mostly because the directories can grow extremely large sometimes and having to get all the composition IDs manually only to feed it into an AQL doesn’t feel “well-integrated”. It’ll be easier to just store the directory information in an external database since it’ll at least solve problem 1.

Alternatives that solve both the above problems while still only using existing openEHR APIs

I’m all for the changes proposed here. But until that’s widely implemented and there’s support for executing AQLs on folders, this is what I’m doing:

1. Using other context
Include an archetype in the other_context part of a Composition to record the encounter information - You can probably use an existing archetype to store the Encounter/Visit identifier within this archetype.

It solves problem 1 since visit information is stored in the same transaction as the composition and problem 2 since you can now easily query this using AQL.

2. Somehow stuff the visit identifier in the composition. Somewhere. :grimacing:
Although the above approach works, I wanted to find a solution to this, WITHOUT changing any of our existing templates. That’s when I kinda started misusing the health_care_facility attribute which is part of the Compositions class in the RM. So we’ll do something like (in ECIS flat):

"opdvisitpdj.v0/context/_health_care_facility|name": "Medblocks Hospital",
"opdvisitpdj.v0/context/_health_care_facility|id": "b9ee9eae-84be-4a4f-9018-2014d8c5341a",
"opdvisitpdj.v0/context/_health_care_facility|id_scheme": "Encounter",
"opdvisitpdj.v0/context/_health_care_facility|id_namespace": "FHIR"

and query like:

SELECT c/context/health_care_facility FROM COMPOSITION c WHERE c/context/health_care_facility/external_ref/id/value='b9ee9eae-84be-4a4f-9018-2014d8c5341a

I know that I’m probably misusing the intent of the “health_care_facility” attribute in the composition. But it solves both my above-mentioned issues and works without having to change any templates to include special archetypes. And I’ve never really stored useful information in the health_care_facility anyway.

Maybe consider adding another attribute to the COMPOSITION class to uniformly record the visit information? Since it feels much better integrated with the system and the visit identifier is mostly just another context data point.

I welcome suggestions and corrections if I am wrong in taking this approach.

1 Like