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

Correct security details in LOCATABLE and ARCHETYPED classes

    Details

    • Change Description:
      Hide
      Changes are as follows:

      - all access control and privacy settings in openEHR now go in a new
        class EHR_ACCESS, referenced by the root EHR object, in the same manner
        as the EHR_STATUS class. This is documented in the EHR IM and Architecture
        Overview.
      - this class uses a class called ACCESS_CONTROL_SETTINGS, which will be
        defined in a new package called "security"; a new Security IM document
        will be written in a future release to contain the new class(es).
      - the access_control attribute is removed from ARCHETYPED class.
      Show
      Changes are as follows: - all access control and privacy settings in openEHR now go in a new   class EHR_ACCESS, referenced by the root EHR object, in the same manner   as the EHR_STATUS class. This is documented in the EHR IM and Architecture   Overview. - this class uses a class called ACCESS_CONTROL_SETTINGS, which will be   defined in a new package called "security"; a new Security IM document   will be written in a future release to contain the new class(es). - the access_control attribute is removed from ARCHETYPED class.
    • Approved By:
      ARB

      Description

      This CR originally was about rationalising the root class attributes
      of CEN and openEHR, as per the text below. After some analysis, its
      scope is now limited to the security attributes, i.e. the question of
      what to do about the access_control attribute in openEHR's ARCHETYPED
      class, and whether to add a sensitivity and/or policy_ids as in the
      CEN model, both shown below.


      Original Text:
      There are some small but important changes we can do to
      EHRcom and openEHR, which will make them closer, reduce naming
      differences, and really enable a) EHRcom users to have confidence
      that an openEHR implementation could underpin an EHRcom-enabled
      system; b) openEHR users to know that they will definitely be able
      to generate and receive EHRcom EHR Extracts. The point is not to
      have the models the same, but to have them as compatible as
      possible, so for example where there are attributes and functions
      with the same purpose, they are named the same way, and have
      compatible if not the same types. What follows is prompted by
      Philippe Lagouarde's very sharp review of the latest CEN part 2,
      part 1 and data modelling done in Paris mid 2004. Note also that
      the Windows for change are closing for both CEN and openEHR
      (which is putting out release 1.0 in March).

      Current Situation
      openEHR currently has the following root class:

      class LOCATABLE
          uid[0..1]: OBJECT_ID
          archetype_details[0..1]: ARCHETYPED
          archetype_node_id[1]: String
          name: DV_TEXT
      end

      class ARCHETYPED
          archetype_id[1]: ARCHETYPE_ID
          rm_version[1]: String
          access_control[0..1]: ACCESS_GROUP_REF
      end

      Note that meaning is now a function in openEHR, evaluated by
      extracting the term description from the relevant archetype,
      using the archetype_node_id. Archetype_node_id is now just a
      String, and contains the id of the relevant archetype node,
      e.g. "at0004". The change was done to reduce the unnecessary
      data in the XML and other forms of data representation (the
      full CODED_TEXT form of the archetype node id is not needed
      in the data - it can always be obtained from the archetype,
      and/or the archetype terms can be included in EHR Extracts
      if necessary).

      EHRcom has the top class:

      class RECORD_COMPONENT
          rc_id[1]: II
          archetype_id[0..1]: II
          meaning[0..1]: CV
          name[1]: TEXT
          ..
          archetype_root: BL
          ...
          policy_ids: Set<II>
          ...
      end

        Attachments

          Activity

            People

            • Assignee:
              OLDthomasbeale JeffJ
              Reporter:
              OLDthomasbeale JeffJ
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: