Where to put organisational levels that do not fit within health_care_facility

Implementation Platform
1

Hi!

In a national Swedish openEHR work group we are trying to (due to Swedish legal access filtering reasons) find the best place in a COMPOSITION+EVENT_CONTEXT to put some extra organisational levels that do not fit easily within EVENT_CONTEXT.health_care_facility.

  1. In the normal health_care_facility attribute (see diagram below) we would like to put the most granular and clinically relevant identifiable organisation level, e.g. the physiotherapist section of a certain health central (or a ward of a clinic).
  2. The health central (or clinic) is the next identified level…
  3. …and above that you have the caregiver organisation (e.g. Region X or sometimes hospital Y).

The question we have is where to put info about level 2 and 3!

For now our current main candidate is to add an Organisation archetype in the EVENT_CONTEXT.other_context slot to host level 2 (role=healtcare unit) and within the “parent organisation” slot (of that added archetype) add yet another instance of an Organisation archetype containing level 3 (role = healthcare provider organisation).

  • Pro: This seems like a reasonable intended use of both the EVENT_CONTEXT.other_context slot and the Organisation Archetype
  • Con: If anybody sets COMPOSITION.context --> EVENT_CONTEXT or its EVENT_CONTEXT.other_context --> ITEM_STRUCTURE attributes to prohibited (0…0) in a COMPOSITION archetype/template, then this won’t work
  • Con: a bit verbose in resulting data (possibly every composition ever made in Swedish healthcare)

Alternatives?

  • A: Abusing the multi-value-capable identifiers field of the healthcare_facility → PARTY_IDENTIFIED object to also contain the IDs of level 2 & 3 (see second diagram below)

    • Con: One PARTY_IDENTIFIED.nameabused for three different organisational levels
    • Con: Hard to differientiate roles of level 2 & 3 without further abuse of DV_IDENTIFIER.type

  • B: Abusing the EVENT_CONTEXT.participations to add level 2 & 3 (as siblings)

    • Pro: Has a nice functionattribute that can be coded with Snomed CT to differentiate level 2 & 3 the same way we would have done in the role attribute of the Organisation archetype
    • Con: We can’t really tell if this is a reasonable use of participations.

image
image857×781 55.6 KB

…

image

Any thoughts on this?
Current main proposal, alternative A, alternative B or something else?
What Pros and Cons have we missed?

2 Likes
2

Those are surely a strange things to do…

I’d say your analysis is right. Those alternatives will create weird data structures that no-one will expect.

But you will probably want a final structure that has logical paths like other_context/org_info, other_context/whatever_else etc, so that your Organisation archetype goes under that org_info, and not at the top level, where it will block the structure holding anything else.

So if we wanted to start standardising on more complex context - a bit - we should probably think about a structure like:

ITEM_TREE
    +--- CLUSTER [org context]
    +--- CLUSTER [xxx]
    +--- CLUSTER [yyy]

And we should try to agree some common values for those first level child names, i.e. the ‘org context’, ‘xxx’, ‘yyy’ and so on.

1 Like
3

@thomas.beale - Just to clarify - what are the “strange things”, the “main candidate” or alternative A or alternative B? I interpreted your reponse as saying that alternative A & B would be strange. Implcitly then also saying that EVENT_CONTEXT.participations is NOT suitable for carrying information-owner-organisation info.

Sorry for being a bit dense; regarding the last part:

Is it the fact that the other_context ITEM_STRUCTURE has cardinality [0…1] that would potentially block things? Does adding a cluster slot in all the COMPOSITION-based archeypes solve this? We saw that all official COMPOSITION archetypes had a slot named “Extension” like the one below:

image
image1092×765 49.9 KB

Does that mean that the potential problem is solved as long as there an extension slot like that one?

Rephrased question: Can more things now be added (as siblings) once we have put an Organisation archetype into that “extension” slot when creating a template? (The tooling seems to suggest that.)

4

The cons you list for the main candidate I would regard as pretty unlikely, so I think they are not strong arguments against your preferred approach.

No that’s fine; the multiplicity you need is one level down. You need to have first level children to each be distinct types of context, and one of those children may be the Org structure you want. You need (IMO) more than just one extension slot - that is a purely generic solution. There need to be a number of sibling slots like ‘org details’ etc. IN the ideal, these are widely agreed (and maybe progressively added to). In the very short term you could start that process. So you could define an archetype that plugs into that extension slot, which has at least one child slot ‘org details’, but can have other child slots added over time.

1 Like
5

In Catalonia we have more or less the same situation, and we are exploring a similar solution as your main candidate, using the other_context to expand that organization information.

Both the EVENT_CONTEXT.health_care_facility (being a monovalued attribute) and the EVENT_CONTEXT .setting (defined as “The setting in which the clinical session took place. Coded using the openEHR Terminology, setting group.”) do not fit for our needs.

2 Likes
6

Hey @erik.sundvall,

Just a quick reminder that the Organisation archetype misuse states:
“Not to be used to represent or replace formal identification management or for the purposes of maintaining an official demographic register or index. Use a formal Health Provider Index for this purpose, or archetypes based on the openEHR Demographic Information Model.”
It’s intended to be used mainly for recording the core subset of info about an Organisation within the health record. I suspect it may be used for weird ‘grey zone’ use cases as well and maybe this is one of them?

7

Hi! In this case it is not “maintaining an official demographic register or index”. The organisation indexes/registries are already existing external services. What we would be recording in the COMPOSITION is only a reference (ID) to an entry in such an index. (Plus the name of the organisation since it is mandatory in the archetype. Plus the Snomed coded role so that we can easily differentiate these exact roles in AQL queries etc. in case other instances of the Organisation archetype would be used in this spot, for other purposes)

2 Likes
8

No problem. Just checking. There is a slight tension about their existence so it’s good to see you finding yet another use case. Thank you

1 Like
9

Hi @thomas.beale!

Would the approach below cover what you meant?

In the archetype designer a design like this seems to work fine:

image
image1424×801 84.7 KB

And it is then possible to commit test data like the one below

image
image907×971 36.3 KB

1 Like
10

We use this approach all the time. I would actually avoid having too many ‘specific’ slots at least in the international compositions as we are still quite a long way from having good consensus/alignment on how to carry this kind of info - an awful lot is determined by local reporting policy but it would be good to see your local variants @Erik

2 Likes