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

Correct security details in LOCATABLE and ARCHETYPED classes

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

Status

Assignee

JeffJ

Reporter

JeffJ

Raised By

None

Priority

Major