Party-actor-folder relationships in hierarchy

Technical (archive)
1

Hi, I have a lot of practical questions to ask :slight_smile:

Let's imagine that I have an EHR database which is shared by several organizations, and each organization manages one or more EHR systems, and each EHR system manages it's own hierarchy of folders. Something like that:

- Database
  [C] ACME company (1.1.1.1)
    [S] EHR System 1 (1.1.1.1.1)
     - Root folder 1
       - Folders
       - Items
     - Root folder 2
       - Folders
       - Items

    [S] EHR System 2 (1.1.1.1.2)
     - Root folder 1
       - Folders
       - Items
     - Root folder 2
       - Folders
       - Items

  [C] Good Health Company (1.1.1.2)
    [S] EHR System 3 (1.1.1.2.1)
     - Root folder 1
       - Folders
       - Items
     - Root folder 2
       - Folders
       - Items

    [S] EHR System 4 (1.1.1.2.2)
     - Root folder 1
       - Folders
       - Items
     - Root folder 2
       - Folders
       - Items

The question is: how could I implement such a hierarchy using pure 1.0.1/1.0.2 classes not using custom object model extensions?

As far as I understand, a company can be described either by PARTY_IDENTIFIED or ORGANIZATION (by the way, where is Demographic.xsd in official releases?) and identified by OID.
How could I describe a EHR system? In which role is it (probably AGENT)?
And how do I link a FOLDER to a PARTY/PARTY_IDENTIFIED?
Thanks in advance

2

My two cents,

I believe OpenEHR is patient-centric, and a patient can have treatment in more healthcare-centra.

So the patient should be on the root of an EHR, and the healthcare-organisation should somewhere appropriate being linked to a specific treatment/composition, received in that organization.

Bert

3

OK Bert, let's say that an EHR system manages a graph of objects and my idea is just a representation of such a graph.

PARTY_IDENTIFIED (Patient) - OBJECT_ID (Patient) - COMPOSITION - OBSERVATION - FOLDER - PARTY_IDENTIFIED (Organizaion)

If you like :slight_smile:

4

OK Bert, let's say that an EHR system manages a graph of objects and my idea is just a representation of such a graph.

PARTY_IDENTIFIED (Patient) - OBJECT_ID (Patient) - COMPOSITION - OBSERVATION - FOLDER - PARTY_IDENTIFIED (Organizaion)

If you like :slight_smile:

I don't get your question in the way you ask it. Let me explain it my way, maybe it becomes clear then.

The root of an patient-EMD is the EHR (with rootfolder), and there is the patient linked to.
If an EHR system is shared by more organizations, there share also patients, I guess. Else I don't get the point from sharing. There is no root where all patients/EHRs are together, so there is no organization-root.
As said, it is patient centric.

So a patient retrieves treatments, in the organizations, in the compositions and the accompanying audit-activity is notated by whom that specific treatment was given.

Now about the folders, there is some documentation about how to use them, I forgot which document, but you can think of grouping compositions which have something specific in common, for example diabetics-related.

Beside treatments, a patient can have longer term professional relationships with healthcare professionals, you can arrange that with party-relationships and roles. Those information exists outside the EHR, but is connected the the patients and healthcare professionals. See in the demographic reference-model where you can find attributes to store this information, in the PARTY class (base of person(patient/healthcare-professional) and organization, I think.

I must say I do it all out of my head, I know the reference model, but I do not know it exactly in all details.

But ask if it is not clear, maybe I know the answer, or someone else knows it better.

Bert

5

Hi Dmitry,

Consider that the folder structure is defined for each EHR, and can vary vary between ehrs inside the same company.

I would use LINK to link the org to the ehr folder struct.

6

The root of an patient-EMD is the EHR (with rootfolder), and there is
the patient linked to.
If an EHR system is shared by more organizations, there share also
patients, I guess. Else I don't get the point from sharing.

1. It often occurs that few medical institutions share same building, same territory and same database server (as for example a hospital, an out-patient clinic and a laboratory), but they are different legal persons.
2. It is easier to administer and support

There is no root where all patients/EHRs are together, so there is no organization-root.
As said, it is patient centric.

EHR management system is patient-centric from the physician's point of view, but it is definitely organization-centric from the DBA/sysadmin/software developer point of view, I believe. For example, a clinician can act as an in-patient clinic surgeon in the morning and as traumatologist in the out-patient clinic in the nighttime. Such a functional role is related to a surgeon logon context, and logon context is definitely bound to an organization.

Logically splitted database may share patient information between organizations, or may not, it doesn't matter

Beside treatments, a patient can have longer term professional
relationships with healthcare professionals, you can arrange that with
party-relationships and roles. Those information exists outside the EHR,
but is connected the the patients and healthcare professionals. See in
the demographic reference-model where you can find attributes to store
this information, in the PARTY class (base of
person(patient/healthcare-professional) and organization, I think.

I discovered the demography.xsd just yesterday, accidentally, on LiU github :slight_smile:
For some reason it is missing here - http://www.openehr.org/releases/1.0.2/reference-models/openEHR/XSD/

7

Hi Dmitry,

Consider that the folder structure is defined for each EHR, and can vary vary between ehrs inside the same company.
I would use LINK to link the org to the ehr folder struct.

(ORGANIZATION as LOCATABLE).links[0] points to a folder/versioned folder through URI?

Thank you Pablo, good idea. Hard to guarantee referential integrity, but...
Why is it no class to link two entities using theirs OBJECT_ID? :slight_smile:

8

I think it is very easy to solve.

The premise is that several legal entities are sharing patients, and also share an EHR system, and you want to distinguish which treatment is given by which legal institution.

It is easy, build your system so, that all compositions are also placed in folders pointing to the legal institutions which gave the treatment.
As you maybe know, a composition can be in several folders simultaneously.

So you can have a folder-system representing legal institutions that share the EHR-system, and folder systems on medical reasons.

In this way it is easy to organize authorizations related to the legal entities, and also other queries

I discovered the demography.xsd just yesterday, accidentally, on LiU github :slight_smile:
For some reason it is missing here - http://www.openehr.org/releases/1.0.2/reference-models/openEHR/XSD/

That is something funny, demographics are something which are treated as a stepchild, not only in OpenEHR, but also in EN13606. In EN13606, demographics can't even be archetype.
In OpenEHR, I remember a message on the list, some years ago, I thought written by Sam Heard, that it should be replaced by non semantical generic structures, which also exist in OpenEHR.

But fact is indeed that there is always something with it.

In LinkEHR-archetype-editor they have a demographics.xsd, you can download it when you download their editor. In LinkEHR they also have a demographics.xsd for EN13606, although this should not be archetypable at all.

I would be interested what people think about this way demographics are treated as a kind of inferior information-structure.

I think we need an answer from the OpenEHR foundation as it must be a defined policy to do it this way.

Bert

9

That is something funny, demographics are something which are treated as a stepchild, not only in OpenEHR, ......

It is even so that in CKM for long time where no demographics archetypes at all. Until a moment, some years ago, in 2009, Sergio Miranda Freire posted them, a Brazilian version.
In Spanish/Portuguese orientated countries they treat lastnames different, so the archetypes were not really good usable in other countries.
But it remained like this for years.
You can still see its roots in Portuguese, and the name-handling is not well adjusted *).

Look at the history, it has been like that since 2010.
The question is, why is that?

Not for accusing or something stupid, but I want to know why this is.
Can someone explain this?

*)
To avoid a distracting discussion I explain it here:
In the archetype is:
ELEMENT[at0003] occurrences matches {0..*} matches { -- Family Name
                          value matches {
                              DV_TEXT matches {*}
                         }
                     }
                     ELEMENT[at0004] occurrences matches {0..*} matches { -- Name Title
                           value matches {
                               DV_TEXT matches {*}
                          }
                     }
                     ELEMENT[at0005] occurrences matches {0..*} matches { -- Name Suffix
                           value matches {
                               DV_TEXT matches {*}
                          }
                     }

Because in Spanish speaking countries people often use their mothers name as second last-name. In non Spanish speaking countries this never done.
So, the archetype is right to give opportunity to have more family-names, but the archetype fails in connecting name-suffixes to family-names.

It should have been like this (every last-name can have a name-suffix and maybe also a name-title:
CLUSTER occurrences matches {0..*} matches {-- Family Name
     ELEMENT[at0003] occurrences matches {1} matches { -- Family Name
                          value matches {
                              DV_TEXT matches {*}
                         }
                     }
                     ELEMENT[at0004] occurrences matches {0..*} matches { -- Name Title
                           value matches {
                               DV_TEXT matches {*}
                          }
                     }
                     ELEMENT[at0005] occurrences matches {1} matches { -- Name Suffix
                           value matches {
                               DV_TEXT matches {*}
                          }
                     }
}

10

I agree that demographic details can be expressed via archetypes.
Actors/Participation/Names etc are elaborated well in HL7 CDA spec, by the way

11

That is a point, why is it not like that in OpenEHR or EN13606?

12

Hi Bert,

there is no ‘policy’ about treating the Demographics specification as ‘inferior’. The practical point about demographics is that it is often not implemented because many clinical IT environments already have an MPI, so an openEHR EHR system typically implements the PARTY_PROXY.external_ref pointers from the EHR data instead.

But some environments need an openEHR demographic service, and I predict more will, even when they have an MPI, because the MPI data is not versioned or extensible.

Release 1.0.3 of the ITS component will have XSDs for everything. This release is likely to be out by the end of the year or very soon afterward.

  • thomas
13

If people want specific changes to the specifications, please raise a Problem Report in the usual place. Otherwise we don’t know what the specific shortcomings are.

  • thomas
14

…or if it is for an archetype, you can raise a Change Request directly for that archetype on CKM, e.g. for the Patient name archetype here: http://openehr.org/ckm/#showArchetype_1013.1.477_CHANGEREQUESTS

Regards

Sebastian

15

I would do that, now it comes to mind, but first I wanted to discuss it, because the different approach to demographics through the years, also in 13606, made me unsure about their

16

as ultrastructure.???

Must be "information-structure" (sorry)

17

I just did it, thanks for the tip Bert

18

I think I need to explain how and why I thought that.

I found the message which caused my recollection that demographic information structures were regarded as inferior structures.
It was related to the OpenEHR Archetype Editor
My memory was not 100% correct regarding to this. But it had some point, see following messages.

Sam said that demographics were not part of the EHR, and so there was no need for the archetype-editor to support them.

http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-March/004423.html

In this message he also indicates that in the EHR can generic cluster-structures be used to store names and addresses.

http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-March/004437.html

Anyway, the Ocean Archetype-Editor (does it support demographics now?) is not the OpenEHR specification, it is just an implementation.

Sorry for my misunderstanding. It lived in my head for six years, and the message of Dimitry brought it to conscious level again.

:wink:

No harm done, I hope

Bert

19

Hi Dmitry, OBJECT_ID can point to the uid inherited from LOCATABLE, but as you can see in the model (http://openehr.org/releases/1.0.2/architecture/rm/common_im.pdf page 13), uid is optional. I wouldn’t like to have my references rely on an optional attribute. I didn’t designed the model, but that seems reasonable to me.

20

A couple of words of advice: normally, EHR and demographics ‘databases’ would be separated for security and operational reasons. EHRs are not normally ‘inside’ any demographic entities. This section in the openEHR Architectural Overview may be helpful; also this one.

If you are cohosting what are logically separate EHR repositories on a cloud service, openEHR does not say anything much about how to organise them, although you should consider carefully implementing an ‘EHR / subject cross-reference’ service as briefly described here.

You also need to consider how to implement RBAC, and ‘legitimate relationship’ so that only the right people can see the right EHRs.

  • thomas