We're updating the issue view to help you get more done.Learn more

Allow party identifiers when no demographic data

In an environment where an openEHR EHR server is deployed, there is often an
existing demographics service of some kind, such as a Patient Master Index.

However, the EHR needs to identify not just the patient, but also provider
organisations and individuals. Currently openEHR uses the PARTY_REF and
OBJECT_ID approach to do this in the ENTRY.provider and ENTRY.
other_participations attributes, but this assumes that the relevant
parties will be represented in the demographic service.

A problem occurs if there is no demographic data for the referenced
party beyond human readable and computable ids (e.g. "Wesley Hospital"
and "HIC provider number 123456789"), even though there is an openEHR
demographic service. The EHR still needs to have references to these
real world entities, even though they are not represented in the
demographic server.

A second scenario is where patient relatives need to be referred to in
ENTRY.subject (of type RELATED_PARTY), but only with informal identifiers
such as "uncle george"; also no other demographic information for such
people will be in the PMI anyway (i.e. only registered patients are there).

Another place in the model where PARTY_REF is used is AUDIT_DETAILS,
as the type of the committer attribute. The problem here is that it
implies that all EHR system users have some kind of entry in a
demographic system, which will clearly not be the general case. They
may have an entry in an identity service, or just a simple
network login.





(Sam Heard) inactive

Change Description

The general flavour of the solution is it needs to be possible to put some demographic entity identifying information in the EHR when there is no representation of the entity in the demographic service. In the case of clinical providers (i.e. entities with publicly known demographics or at least names), the information is: name and/or provider id (sometimes id is not available). In the case of patient relatives, it is a relation type (aunt, uncle, friend, village shaman etc) + a name ('george', 'dmitri', etc). In both cases, PARTY_REF does not currently cover the need, since it contains an OBJECT_ID which has nothing to point to. The solution is to create three new classes as follows: (abstract) class PARTY_PROXY external_ref: PARTY_REF [0..1] end class PARTY_IDENTIFIED inherit PARTY_PROXY names: Hash <String, DV_TEXT> [0..*] -- name keyed by meaning identifiers: Hash <DV_IDENTIFIER, DV_TEXT> [0..*] invariant: Basic_validity names /= Void or identifiers /= Void or external_ref /= Void Names_validity: names /= Void implies not names.is_empty Identifiers_validity: identifiers /= Void implies not identifiers.is_empty end PARTICIPATION is altered so that its party attribute is of type PARTY_PROXY rather than PARTY_REF. RELATED_PARTY is altered so it now inherits from PARTY_IDENTIFIED. This allows PARTY_PROXY to be used as the type of ENTRY.subject, enabling both the record subject ('self') and other ENTRY subjects to be referred to in a safe way. Note that relationship type is already covered by RELATED_PARTY, so does not need anything special here. ENTRY is changed so that: - a new function ENTRY.subject_is_self: Boolean is added, returning True when the subject is a PARTY_SELF PARTY_PROXY is also used in AUDIT_DETAILS.committer, allowing for both for system user identifiers and a reference to user details in an Identity Management service, where it exists. PARTY_PROXY is also used in the EVENT_CONTEXT class, as the type of composer (moved to COMPOSITION in CR 180). PARTY_IDENTIFIED is used as the type of EVENT_CONTEXT.health_care_facility. Clearly the same logic applies as for elsewhere: these entities might have no demographic data recorded for them so that the only information is an identifer in the EHR itself. PARTY_SELF is used in the EHR class as the type of subject, forcing the subject of the record to be an instance of PARTY_SELF but still making the use of PARTY_SELF.external_ref optional. The last modification is that the invariant in the PARTY_REF class to do with the system being the 'demographic' system has to be removed: clearly Party information could be stored in other services, e.g. 'identity_manager', 'patient_admin' and so on. Forcing the service always to be 'demographic' is too restrictive.

Approved By


Fix versions