*If your organisation or implementation uses the openEHR EHR Extract
specification PLEASE READ THIS.*
Release-1.0.3 is getting close. For those with too much time on their
hands, you can follow progress here on Jira
<https://openehr.atlassian.net/projects/SPECRM/versions/10860>.
We have implemented a subset of Change Requests on the *EHR Extract
specification *(old Rel-1.0.2 PDF
<http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_extract_im.pdf>;
new-style latest draft HTML
<http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html>)
which contain breaking changes, as follows:
* SPECRM-10 <https://openehr.atlassian.net/browse/SPECRM-10>: Upgrade
EHR_EXTRACT to Release 1 of EHR IM
* SPECRM-13 <https://openehr.atlassian.net/browse/SPECRM-13>: Convert
various fields to coded in EHR Extract.
* SPECRM-14 <https://openehr.atlassian.net/browse/SPECRM-14>: Various
EHR Extract model improvements
* SPECRM-6 <https://openehr.atlassian.net/browse/SPECRM-6>: Correct
modelling inconsistency of every EXTRACT_CHAPTER being related to a
single Entity
The exact changes are described below, and are visible in the latest
draft of EHR Extract
<http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html>.
Most of them were in the 1.0.2 spec; some weren't except as notes; all
of them were designed some years ago. The changes are reasonably
extensive, and some are *technically breaking changes*. As far as we
know, this is not a problem because the EHR Extract is not in use (the
world seems to have moved on from the 'extract' idea). If that is true,
it should be acceptable to allow these changes through in Release 1.0.3
(since they are old changes anyway).
*However if there are users of this specification, we would like to
know, in order to determine whether to move these changes into another
release - please respond on this list if this is your case.*
thanks
- thomas
The detailed list of changes is as follows (by visiting the CRs above,
you can actually find the links into the Github diff view for each file).
SPECRM-10
- add X_VERSIONED_OBJECT class
- add template binding classes X_VERSIONED_FOLDER,
X_VERSIONED_COMPOSITION, X_VERSIONED_EHR_ACCESS, X_VERSIONED_EHR_STATUS,
X_VERSIONED_PARTY to accommodate specific types of openEHR content
within X_VERSIONED_OBJECT objects.
SPECRM-13
- EXTRACT_SPEC.extract_type is changed to DV_CODED_TEXT
- EXTRACT_ACTION_REQUEST.action is changed to DV_CODED_TEXT.
- EXTRACT_UPDATE_SPEC.trigger_events is changed to be of type
List<DV_CODED_TEXT>.
SPECRM-14
- remove EXTRACT_SPEC.includes_directory and directory_archetype; assume
that Extract spec and request pairs are modelled together, and that
EXTRACT_SPEC.extract_type will indicate what kind of extract should be
returned.
- remove EXTRACT_ENTITY_CONTENT class
- make EXTRACT_FOLDER classes the main containment structure; assumed to
be archetyped.
- move X_VERSIONED_OBJECT to openEHR Extract package.
- change EXTRACT.request_id to a HIER_OBJECT_ID
SPECRM-6
- a subtype of EXTRACT_CHAPTER is added to the model called
EXTRACT_ENTITY_CHAPTER
- the class EXTRACT_ENTITY_IDENTIFIER is removed
- the class EXTRACT_ENTITY_MANIFEST is augmented with the attributes:
- extract_id_key[1]: String // id by which this entity (usually a
patient or EHR) is known in the extract
- ehr_id[0..1]: String // EHR or EMR id
- subject_id[0..1]: String // patient id, UPI
- other_ids[0..1]: Hash<String, String> // other ids the subject or
record may be known by
- the class EXTRACT_ENTITY_CHAPTER has a copy of the attribute
extract_id_key, to mark each such chapter with a meaningful identifier
within the extract.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
