Apologies that this is perhaps not the right forum, but
I sense there is a fair crossover between the CEN and
openehr communities so I thought this might reach
the right ears..
I have been perusing the draft cen 13606-1 specification
in my exploration of all things openehr related (given the
large overlap in ideas.. two level modelling etc). I was
wondering if anyone had any ADL archetypes based on
the 13606-1 reference model? I am going to hand craft
some as an experiment but would love some that
are more clinically valid than my idle musings..
On related notes -
I do not normally have any access to cen materials and
am completely in the dark as to the whole cen standards
process, but I take it that 13606-1 is in draft mode, awaiting
a vote on acceptance? From my brief reading, it seems
not ready for 'prime time'.. two that immediately came to
my attention were the ED support type that has
a compulsory "language" attribute (which means what
for a photo?) and URI reference? Maybe the UML diagram
is wrong or something but it seems to indicate that both
of them compulsory, when surely they have to be optional
attributes? (I have just read it again, and in their defence, it
does say they are waiting for a new datatypes standard to
be published so perhaps they have not looked too much at
this area)..
Why would any health standard be promoting an example
using 'magic' dates to indicate infinite time ranges?? Surely
these are open ended intervals rather than actually statements
that this ehr_system is going to cease to be valid in the year 3000?
I know its just a sample, but if the sample doesn't show the
proper techniques, what chance does any programmer reading
the spec have to do it correctly..
I also am under the impression that 13606-2 will be an
effort to standardise the expression of archetypes? Is ADL
in its current form a contender for that standard? How far along
is the standards process and are there any avenues to
review the work (for non-europeans)?
not ready for 'prime time'.. two that immediately came to
my attention were the ED support type that has
a compulsory "language" attribute (which means what
for a photo?) and URI reference? Maybe the UML diagram
is wrong or something but it seems to indicate that both
of them compulsory, when surely they have to be optional
attributes?
both are optional.
(I have just read it again, and in their defence, it
does say they are waiting for a new datatypes standard to
be published
yes, there will be something new, though it is not clear yet
exactly what that will be
so perhaps they have not looked too much at
this area)..
There is a very substantial overlap between OpenEHR and EN13606.
Both technically and personally.
But there are differences.
EN13606 EHRcom is the result of an European/Australian consensus process and can not be equated with OpenEHR.
EN13606 can be used to map to legacy systems and interact with OpenEHR conformant systems.
OpenEHR is a much richer specification that can be used to produce an EHR-system with real plug-and-play semantic interoperability.
Within the framework of OpenEHR it is (will be) possible to use the CEN EHRcom extract.
For all practical purposes I consider OpenEHR as a specific implementation specification of EN13606 with some important additional features.
My advice is to use OpenEHR as an implementable specification and make and use archetypes derived from OpenEHR.
The status of EN13606 EHRcom is that the parts 1,2,3 and 4 are stable. Part 1 is final and will be published soon, I expect.
Parts 2,3 and 4 will be voted on soon and published next year.
It is expected that soon ISO will adopt these standards as well.
Your technical comments I will refer to Dipak Kalra the task force leader.
I thought they had to be optional (given the ED datatype recursively
refers to itself it would be hard to implement if they were
mandatory!).. am I misreading the UML diagram notation
or are the diagrams not up to date?
It uses notation like
thumbnail: ED[1]
which I would read as a mandatory attribute. Or is the optionality
introduced using the null_flavour attribute on DATA_VALUE?
EN13606 EHRcom is the result of an European/Australian consensus process and
can not be equated with OpenEHR.
EN13606 can be used to map to legacy systems and interact with OpenEHR
conformant systems.
So 13606 EHRcom is very much a go-between format - something that
can be used to transfer clinical data between systems, but not something
around which you would build an actual running system i.e. a system sitting
in a GP's office? Is that the correct thinking?
Your technical comments I will refer to Dipak Kalra the task force leader.
ADL and part 2 of the EN13606 are identical.
How does the openehr governance and CEN process mesh? At the
moment, if we find a typo in the ADL spec, we mail Thomas and he
fixes it (I know there is an actual formal openEHR process but for
simple changes, that is what is boils down to :).
When it becomes an ISO standard, do changes to the
openEHR ADL spec automatically transfer across into the ISO standard?
Is there any chance in a divergence between the languages?
So 13606 EHRcom is very much a go-between format - something that
can be used to transfer clinical data between systems, but not something
around which you would build an actual running system i.e. a system sitting
in a GP’s office? Is that the correct thinking?
Yes, this is how I understand things.
Your technical comments I will refer to Dipak Kalra the task force leader.
ADL and part 2 of the EN13606 are identical.
How does the openehr governance and CEN process mesh? At the
moment, if we find a typo in the ADL spec, we mail Thomas and he
fixes it (I know there is an actual formal openEHR process but for
simple changes, that is what is boils down to :).
When it becomes an ISO standard, do changes to the
openEHR ADL spec automatically transfer across into the ISO standard?
Is there any chance in a divergence between the languages?
For quite some time I’m of the opinion that conformance testing of standards is useless.
We need to test conformance against an implementable specification.
In general the standard will be the most generic stable point of reference.
But in reality we all know that reality and experience evolve faster than any standardisation organisation is able to cope with.
For all practical purposes OpenEHR is the fast track, quick response, organisation taking care of a version of an implementable specification.
In the case of CEN13606 part 1 conformance testing should be done using the OpenEHR specification (the CEN Extract part)
In the case of CEN13606 part 2 conformance testing should be done using a designated version of the OpenEHR ADL specification.
It will be up to OpenEHR, the user community and possibly others (like governments) to decide when to correct, amend and update the standards.
Your e-mail, with some thoughtful questions, has generated some
interesting discussion inputs already.
The relationship between 13606 and openEHR is long-standing, since a
number of the openEHR family have been involved in this standard's
development but 13606 does, as you have gathered, have a different
and narrower scope. The openEHR Foundation is in the process of
reviewing how best to reflect the relationship as it is now, and if
you can wait a bit we shall be writing this up more clearly in future
documents.
You have also raised a couple of technical points. Graham has I think
responded clearly on the data types - in an ideal world the ISO data
type standard would be ready to use before 13606 is finalised, but as
this is not the case we have on a temporary basis referenced the CEN
TS 14796 (and included some explicit data types as you have seen).
These will eventually be superseded by the ISO ones). openEHR data
types are one of the input feeds to ISO.
The example OIDs in the worked sample in Annex C only have
placeholder illustrative attribute values for the validity, root and
extension attributes of the II data type. Ideally I should have found
an expert to give me more plausible values, but the main purpose of
the example was to show how the clinical hierarchy and revision works
and many of the attribute values for IDs and codes are very clearly
made up ones (such as the terminology ones). If you have the time to
send me some corrections (more plausible values) I can still
incorporate them. Most readers have accepted that examples such as
this inevitably have limitations in their completeness, but I agree
that it's not ideal.
Gerard has also responded to you on archetype specification currency
within openEHR and 13606. Standards need to be stable, and standards
organisations assume that this stability is reasonable and desirable
for the marketplace. A innovative organisation like openEHR has the
freedom to make changes more rapidly, but it also wishes for them to
be validated in real implementations. The rapid turn around that you
describe is for a document change, not for a field-validated
improvement!
You have also raised a couple of technical points. Graham has I think
responded clearly on the data types - in an ideal world the ISO data
type standard would be ready to use before 13606 is finalised, but as
this is not the case we have on a temporary basis referenced the CEN
TS 14796 (and included some explicit data types as you have seen).
These will eventually be superseded by the ISO ones). openEHR data
types are one of the input feeds to ISO.
yes, good.
extension attributes of the II data type. Ideally I should have found
an expert to give me more plausible values, but the main purpose of
the example was to show how the clinical hierarchy and revision works
and many of the attribute values for IDs and codes are very clearly
made up ones (such as the terminology ones). If you have the time to
send me some corrections (more plausible values) I can still
incorporate them. Most readers have accepted that examples such as
this inevitably have limitations in their completeness, but I agree
that it's not ideal.
Yes, I understand how difficult it is to put meaningful examples in
a spec and keep them accurate. I actually wasn't worried about the
OIDS or codes.. I had a philosophical problem with the use of
magic dates
to show that where no specific values are
meaningful, the standard still has ways to
represent the real intent - i.e. that this extract
has no restrictions on the time range in which
it is valid.
I think its important that examples show best
practice wherever possible - as a programmer,
there is always a temptation on my part, whenever
reading a specifcation, to go straight to the
examples section and see if there is an example
that matches what I want to do! And we'd hate
lazy programmers like me from getting the wrong
ideas..
Gerard has also responded to you on archetype specification currency
within openEHR and 13606. Standards need to be stable, and standards
organisations assume that this stability is reasonable and desirable
for the marketplace. A innovative organisation like openEHR has the
freedom to make changes more rapidly, but it also wishes for them to
be validated in real implementations. The rapid turn around that you
describe is for a document change, not for a field-validated
improvement!
True, but there have been some changes e.g. the quoting rules for
unicode, that have been more than cosmetic textual changes. I am just
concerned that the freedoms that openEHR has to change things
rapidly might be lost if the spec gets tied to the CEN/ISO process.
True, but there have been some changes e.g. the quoting rules for
unicode, that have been more than cosmetic textual changes. I am just
concerned that the freedoms that openEHR has to change things
rapidly might be lost if the spec gets tied to the CEN/ISO process.
This antagonism between:
the stability a formal consensus process and the need for quick responses to correct mistakes, make extensions, complete new version in the case of standards,
the need to do quick fixes and do innovative experiments with new features in the case of implementable code and specifications,
is not something that has been solved.
And then there is an other problem.
-Nowadays the standards in medical informatics are very complex, needing several parts, depending increasingly on other standards
The texts in the standards describe specifications for complex software used by large portions of society. These texts are becoming so complex that we need colours and drawings. This results in documents that when printed on paper (as is the rule in formal standardisation organisations) are not very handy to use. Implementers prefer to read code based on the standards and not these complex unwieldy standards texts
On top of rather stable parts of the standards specification we will see an increased need for many small or large lists with codes, or even an actively changing ontology. These lists with codes are part of the standard but can not be printed or changed via the formal processes used in standardisation organisations. In addition these lists can be maintained and published only using databases.
In summary we need new types of standards, standards producing mechanisms, standards publishing mechanisms and perhaps new, extra, types of standardisation organisations.
For the moment, I think that all problems can be solved by co-operation between the formal standardisation organisations (like CEN and ISO) plus a supporting Open Source organisation (like OpenEHR for implementable specifications) plus not-for-profit organisation (like the European Institute for the Health Record, EuroRec for the maintenance and publication of lists of codes)
I expect that in the near future we will need an extra function that will be added to the list. This is an organisation that is responsable for the testing and certification of applications that claim conformance to standards, implementable specifications and lists of codes. As many know EuroRec is executing a European project Q-REC (Quality labeling and Certification of EHR-systems)
At this moment they restrict themselves to functional requirements and criteria of EHR-systems. It is inescapable that semantic interoperability and patient safety demand more attention to conformance testing of implementations that claim conformance to standards and other documents. EurRec will be the most likely candidate to organise this in Europe.
Greetings,
Gerard Freriks
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
The development of openEHR is currently seen as an engineering process
similar to a software design process with full version control, issue
tracking and decisions on changes confined to experts rather than
committees. This has allowed the openEHR community to respond rapidly to
the community of users where issues arise that directly impinge on
implementation such as your example of the quoting rules for Unicode. These
changes are raised as issues and then resolved by incorporatng relevant
changes into the next release of the specification.
I agree with you that putting all of this under a standards body would
potentially slow down necessary development at this stage, however it is
certainly useful to imprimatur of a standards body with some aspects of the
work.
there were many questions concerning 13606 on this mailing list so I will
also post my questions here. YET wouldn´t it be possible to host an own
mailinglist via openEHR for CEN 13606. (compared to
technical/implementers). It doesn´t feel right to bother you and the
openEHR community with every small question concerning CEN 13606. It would
be great to share Information with the CEN community without feeling
guilty when posting at the wrong place.
looking at the example in Annex C of prEN13606-1 some questions arouse.
ENTRY rc_id.extension = 0251: this ENTRY has attributes based on
committal. Shouldn´t these attributes be based on the feeder_audit?
Shouldn´t "committal.ehr_sytem.extension" be named
feeder_audit.ehr_system.extension?
Nearly all the elements of the revision (second part of the example) are
copied from another part of the EHR. Why do only some have the
original_parent_ref attribute? (prEN13606-1 p.39). Why does for example
the ELEMENT rc_id.extension= 0251 not contain an original_parent_ref?
Is it a restriction of the (imaginary) information model, that created the
ehr_extract or of the 13606-1 standard to update the COMPOSITION (rc_id =
213) and ENTRY (rc_id=251)? Or would it also be allowed to update ONLY the
ELEMENT (rc_id=258) where the actual change took place??
ELEMENT (rc_id=258): why does this element not have the attribute
previous_version from the AUDIT_INFO (13606-1 p.46)? This element is a
revision of rc_id=158. It is the only element where change took place. Why
is it not indicated directly in this element?
It is our wish to support the 13606 adoption path, through a web
site, FAQ, discussion lists etc. Regrettably (with no formal
resources), all of us who are committed to this effort are already
stretched in the actual standards drafting activity. We are hopeful
of gaining funds for this in the future.
I think we should not take over the openEHR lists for 13606 technical
questions, and suggest that you all revert to mailing me personally
with questions as a short term measure. I am happy to share replies
with several people who wish to be involved, or see if we can set up
another list address if demand is there.
The example in Annex C might well be imperfect, for reasons that I
explained on Friday evening. I will look at it again in the next few
days and send you back a reply with answers. I'm also happy to have
some help with correcting and enhancing it. Examples can be very
helpful, but a spreadsheet is a lousy tool for such fine grained
fiddly work!
A few answers in addition to those provided by others here.
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:
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- 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.)
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…)1. 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.
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).