Uploaded image for project: 'Specification'
  1. SPEC-162

Allow party identifiers when no demographic data

    Details

    • Change Description:
      Hide
      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.
      Show
      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:
      ARB

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              OLDthomasbeale OLDthomasbeale
              Reporter:
              OLDsamheard (Sam Heard) inactive (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: