[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
only...)
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
IETF).
- thomas beale
Other related posts: