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

Correct security details in LOCATABLE and ARCHETYPED classes

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

Status

Assignee

JeffJ

Reporter

JeffJ

Change Description

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

Fix versions

Priority

Major