[cen13606] openEHR - specification for its EHR Extract

  • From: "Christoph Rinner" <ch.ri@xxxxxxx>
  • To: "cen13606@xxxxxxxxxxxxx" <cen13606@xxxxxxxxxxxxx>
  • Date: Wed, 08 Nov 2006 11:40:54 +0100

mail from Thomas Beale (copied from openEHR)

A few answers in addition to those provided by others here.

1. openEHR will soon (< 4 weeks) release a draft specification for its EHR Extract. The openEHR Extract is designed for use into and out of openEHR systems, as well
as non-openEHR systems. Main features:

a) It uses a generic model of the concepts "Request" and "Extract" upon which 3
concrete types of Extract are based:

an openEHR EHR Extract, giving faithful representation of openEHR Versions,
supporting distributed version merging etc.

a generic Extract, designed to act as a close mapping to the CEN Extract. This
is simpler, and is designed to allow CEN 13606 Extracts to be exported or
imported from openEHR systems. It can also simply be used as a replacement for
the CEN Extract. Most likely the openEHR GENERIC_ENTRY will be used in
Compositions in this Extract type.

an openEHR synchronisation Extract, that supports the request "give me all
Contributions (i.e. change sets) since the last synchronisation for EHR 1234"
between two openEHR system - i.e. EHR-level mirroring

b) it uses the openEHR data types. (My hope is that the CEN 13606 specification will one day use these as well, since there is a lot of software support and
tools already built for them, whereas the CEN data types are currently
disconnected, due to the unsuitability of the HL7v3 data types, and the
perceived non-applicability of the openEHR data types due to not being issued by
an official standards organisation.)

c) the Request part of the specification includes concepts that will also be useful
in defining an Extract webservice:

a specification of the content required in the Extract

what versions are required (all, latest only, specific ones, revision histories

update basis (persist in server, repeat, event-driven, once-only...)

2. openEHR can respond quickly to things via a defined change control process, more in the mode of Apache.org than a standards organisation. Currently, although we have a problem report database, we naturally follow up on ideas and suggestions on this technical list - since often the final request for change only becomes clear after a discussion. Soon we will change the tools over to (we think at this stage) the Atlassian/Jira tracking tools, which will formalise the process more effectively (e.g. proper assignment of tasks to persons etc). We also have a release process for each project ("specification" is just one project); this means that no matter how fast the relevant project group responds, any given
release will be self-consistent and users can always choose to stay on a
particular release rather than having to take on changes they don't yet want. Of
course this is not yet perfect, and for the implementation projects we are
adding continuous integration tools to improve the management of build products,
versions and so on.

3. We don't at this stage see any reason to put openEHR under the control of any standards organisation - indeed, I believe this would be detrimental, since the development mode of most standards organisations is hardly designed to create
good quality technical artifacts (due to design by committee, sporadic
attendance and involvement, lack of design process, undisciplined requirements gathering, nearly non-existent change management process and so on). This is in no way a comment on the efforts and dedication of people involved in this work (myself included for about 5 years), but rather an observation about the unsuitability
of (some) current standards organisations processes for creating detailed
technical artifacts which instead need to be engineered in an open community context. (BTW these observations apply far less to organisations like OMG and
- thomas beale

Other related posts: