As you may have noticed, the new release of the ADL Workbench enables exploration of multiple reference models and their classes. Although the 13606 schema is not yet complete (in particular the data types require work), it is now possible to see the differences and similarities of the 13606 and openEHR reference models. Similarly, archetypes based on both reference models can be viewed, validated and compared.
I see various possibilities:
convergence of 13606 and openEHR onto one reference model. The opportunity to do this is coming up in May 2012, where 13606-1 and 13606-2 reach their 3 year review point, at which ISO has to decide to either retire them or continue their use, depending on their use in industry. I don’t know what use in industry they have to date, but let’s assume the decision is made to continue - it is clear that changes could be made. Implementers of both openEHR and 13606 have now had some 3 years to discover real problems and deficiencies. In openEHR there are around 150 Problem Reports and Change Requests generated over this time; clearly some of these would apply equally to 13606. Some possible changes:
it is now possible to see how 13606 and openEHR could be merged into one reference model at the Entry level, e.g. with changes like:
openEHR has richer ‘design-based’ Entry types like Observation, Instruction and Action, but also a generic type called Integration_entry, which nearly a mirror image of the EN13606 ENTRY. A future standard could support all of these types, with the users choosing which ones best supported their data.
openEHR’s data structures (ITEM_STRUCTURE, ITEM_TREE, ITEM_TABLE) etc may be able to be retired in lieu of the only simpler CLUSTER/ELEMENT structure in use by both standards, and a ‘structure marker’ as used by 13606 - this would further ease merging of the reference models.- a common data types model could be found. At the moment, openEHR’s data types work very well and have been shaped by archetyping as well as normal software considerations. For 13606, in theory the ISO 21090 data types are supposed to be used. In their current state, they cannot be, and are both completely normalised and optimised for HL7v3 use, as well as suffering from key modelling problems. It has been stated that an ISO 21090 ‘profile’ will be developed for 13606, although this has not yet been done. In my view, the HL7 ‘profiling’ process is almost unworkable, and I think a completely different set of data types is needed for 13606 - a far simpler set, e.g. based on a simplified version of openEHR, or Grahame Grieve’s Resources for Health data types (which include both openEHR and HL7 influences, as well as using proper object modelling).
a few useful Change Requests have been made based on CDA. Once these are done, the merged RM would be a superset of all models in use today, with the added value of being more rigorously defined and therefore usable for tool-based code generation, data transformation and the like.
adoption of ADL/AOM 1.5 as a new 13606 part 2. Although it seems as if ADL 1.5 is taking a long time (it is it is being continuously tested in real software on the way, so that what emerges will be something close to a ‘stable’ standard (openEHR might decide to give it DSTU status from the outset for example) rather than an untested set of proposals. It is backwardly compatible with ADL 1.4, while fixing all the main problems and limits of 1.4. It includes many (in fact almost only) features proposed by people working with real archetypes in real environments, so I think it is safe to say that the 40 or so changes (most very small) really reflect the last 4-5 years’ industry validation rather than any kind of theorising. If ADL/AOM 1.5 were to become the next version of 13606-2, then we can contemplate:
shared tooling: doing this would mean that all 13606 efforts can use the openEHR tooling, which is growing by the day, and that people working with openEHR can use tooling that is currently 13606 ADL specific.
shared archetypes: if the reference models were merged then ‘13606 archetypes’ and ‘openEHR archetypes’ are just the same thing - it is just a question of different parts of the same reference model being archetyped.
How could we go about this work?
we can all run back to our comfort zones and stick with our current models, and make the usual half-hearted attempt at harmonisation within the official standards processes, OR
we could, starting today, develop a hybrid RM, using the schema definition capability of the ADL Workbench, and analyse it, build some test archetypes against it and so on. In this way, we could come up with a proposal that could more or less be directly used by the ISO process to update 13606.
now, doing this is not just a case of - let’s build a new model - we probably need a strategy where copies were made of both the current 13606 and current openEHR models, and agreed changes applied to each that brought them closer together, with the impact of the changes being known for existing users of the current models. But with a bit of discipline, I think it is doable.
At this point, I would like to see what interest there is in an initiative like the above. If there is interest, we could create a dedicated mailing list and project workspace for it, and start to do some work on it.
Great initiative. Let’s go for it. Even though I agree with your previous remarks that this probably won’t provide a long term solution, IMHO it’s absolutely necessary in order to secure short term progress.
Maybe a dumb question, but is there a way we can involve people form other standard initiatives (DCM, HL7) in order to speed up harmonisation. More specific: is there a mutual interest for all of us to invest in this.
My experience is: the instant we ‘involve every stakeholder’ and set up some large forum / club / organisation, everything becomes paralysed and political, and tasks that should take 3 months take 3 years. So we need to be careful…
Specifically:
myself and some others on this list are directly involved in an international DCM effort, led by Dr Stan Huff (Intermountain Health), and this should yield results before the end of the year
HL7 - here it depends on what we are talking about:
HL7v2 messages - there are specific approaches emerging to map v2 messages to openEHR, and I would see this as a seperate initiative (although hopefully taking advantage of the same tooling)
CDAr2 - this has its own UML model (recently) and we may be able to define some mapping rules / approaches. However, since the differences with openEHR / 13606 are far greater than between the latter two, it is a bigger effort- epSOS - this is a simple CCD that can easily be mapped to archetypes, and maybe representing it as an RM might be useful.
My feeling is to get the 13606 / openEHR question sorted out first, because that is by far the easiest. If we stay focussed, unofficial (for now), and make progress on that then we can tackle bigger beasts…
Are the archetypes online anywhere?
As an aside, it is an interesting document - 45 pages about archetypes,
including a lot of directly copied openEHR material, and no attribution
at all to openEHR! Lucky it is not an academic paper....
Yes. I saw David Moner's presentation on these at the MIE conference
in Oslo, and he and Gerard Freriks gave a very powerful account of the
power of archetype development in messaging production.
However, these archetypes also point to a somewhat different approach
(at least for now) between the 13606 and openEHR communities, in that
the 13606 epSos archetypes are COMPOSITION archetypes, directly
modelled against the epSos requirement.
In openEHR we would take a rather different approach, by re-using more
generic Entry-level archetypes and building up the epSos requirement
via a template. In many respects this is somewhat closer to the CCD
approach where each CCD (medication, problem,etc) roughly equates to a
single archetype. Although this is more complex than David's approach,
it does let us re-use the archetypes in very different contexts. As
one example, I am currently involved in a project which uses the NEHTA
medication archetypes templated in a local vendor system, but will
re-use the same archetypes to create the epSOS Prescribing summary and
the Emergency summary.
Both approaches are valid and both are still much easier than
developing CDA but there is different design paradigm. Three-level
modelling, rather than two-level modelling?
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
Well, in all of our projects we use ENTRY level archetypes and slots,
but as epSOS defines that the requirement is a full document then it
made sense to put everything on the same archetype (to show that all
requirements could fit without problems)
My mistake - that wasn't clear at David's demonstration or from the
epSOS appendix.
Are the ENTRY level component archetypes available, and are they
designed to be for epSos use only or do they support a much broader
context of use e.g a full hospital or GP medication use?
It would be interesting to compare with the openEHR equivalents,
especially as we intend to use the NEHTA archetypes as the basis for
the official openEHR medication archetypes before long and I have been
doing various mapping exercises to ensure that they meet are broad set
of use cases.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
I’m the main author of that document. As you said, it is a 45 pages document of which only two and a half are a summary description of ADL to understand the proposed archetypes. And only there we can see some examples of ADL structures (yes, openEHR ones) taken directly from EN13606-2, which is the norm referenced at the document, and not from the openEHR specifications.
I really think that your affirmation is misleading and unfair.
As Diego said, the epSOS case is a different case but a case that surely can happen quite often.
The normal approach, as you mention, should be define first the generic archetypes and then reuse and constrain them for specific uses through specialisations or templates. At epSOS the specifications of the data set were previously defined and in those cases it is extremely complicated to cover 100% of initial requirements just reusing existing archetypes (if they existed at all!). It is much more easy to create a specific archetype for that case. Obviously they do not pretend to be clinical concept reference archetypes, but just a archetypes for documentation in a controlled scenario. I think this approach is also a realistic one that will be needed many other times.
Regarding the archetypes as reusable concepts, if you remember, at MIE last week we had a poster about medication reconciliation. There we defined a Cluster medication archetype, an it that case it is based on archetypes from openEHR, from NeHTA specifications, from epSOS and also from the existing systems at the hospital. Those are reusable archetypes and we use them in that way, since the LinkEHR Editor is able to work with slots and resolve them when we “compile” an archetype.
sorry - you are right, there is not 'a lot' of copied material, only p
11 & 12. But I do find it funny that there is no mention of openEHR,
because it means that readers of the document won't realise that they
should go to openEHR to see ongoing developments in the specification
and tools (I am not saying the only development in tools of course, but
since 13606-2 is a snapshot of an openEHR spec, it would make sense to
make this clear, one would have thought).
Ok, but again, the referenced documents at that epSOS annex are CEN EN 13606 part 1 and CEN EN 13606 part 2. If openEHR has to be mentioned is in those documents, not in this annex since it only deals with 13606 and the archetype/ADL summary is just for clarifying concepts for the reader and not a complete history about the technology behind.
I just tried to compile the archetype CEN-DEMOGRAPHIC-IDENTIFIED_HEALTHCARE_PROFESSIONAL.HCP_Dispenser.v1 in the ADL Workbench… I had to make a few changes:
IDENTIFIED_HEALTHCARE_PROFESSIONAL has an attribute ‘scopingOrganisation’ in the standard, but the archetype had ‘scoping_organisation’ (the standard bizarrely mixes camelCase and underscore_form)
HEALTHCARE_PROFESSIONAL_ROLE has an attribute ‘specialty’ in the standard, but it was called ‘speciality’ in the archetype (admittedly an easy confusion in English)
At the moment, the version of the 13606 and 21090 schemas available inthe openEHR SVN has the strange mix of attribute name styles in the published standard. The archetypes have used a consistent naming approach - the more_readable_form, from my point of view. What is the consensus on this aspect of the standard? Do we follow it slavishly or use a modified variant, as you have presumably done for your epSOS work?
It may be that my copy of 13606 is out of date, and was superseded by some later update - I have a version from 2006-06-13. Were there later changes?
As Dipak has explained, the attribution in ISO is not available. I believe attribution is a distraction from the task - I have seen lots of slides from others used in this space and ideas transferred here and there. Let's appreciate all work and try and build on it efficiently.
no offence was intended (at all). I was trying to point out (badly) in the context of the current discussions on licensing and openEHR that, if CC-BY had been in place in the past, then:
the CEN 13606-2 standard, being a copy of work done by openEHR (with adaptations done to wording as required by CEN/ISO), would have been required to acknowledge the original authors and copyright, AND
that further derivative works would also have to do this.
As I don’t work in academia, I don’t care as much about ‘being recognised as the author’ as some people might, but I do care about the impression being given of an organisation having invented something when this is not the case - mainly because it prevents readers from understanding where the technology came from in the first place, and referring back to it, e.g. to find more recent versions, software, and community.
I currently don't have the norm with me, I'll check it on Monday morning.
Second case looks like a typo on the schema, thanks for pointing it
out. We will check it and correct it.
We created a 13606 XML Schema (because there was none available)
trying to follow the specifications (as we also did with openEHR
demographic model). You can find both through linkEHR website. Just
notice that those are not official XML schemas yet.
I don't know the consensus about naming on the standard, as I'm just a
user of it
However using CamelCase is preferred in most programming languages as
when you print code the underscore can be confused with '-' (and also,
is faster to write CamelCase variables
I personally prefer CamelCase.
I agree it would look prettier if everything had the same case, but as
you know in 99% of the specifications this is mixed.
This kind of problems has given us a lot of problems when using ADL to
work with other models like HL7 CDA or CDISC ODM, where there isn't
any kind of rule (for example, in ADL CLASSES must be upercase and the
attributes lowercase, and in CDA this is not true)
actually there is no rule in ADL. You can use CamelCase, and it has been
working for the entire lifetime of the tools. Indeed you will see it in
the 13606 and 21090 schemas, which are processed by the ADL Workbench.
It's just that the documents use a particular convention which happens
to be the underscore convention, for better readability. My view is that
any given model should stick to one or the or the convention
consistently, whatever convention that may be.
yes, what I mean is attributes like ID or even invalid characters in
the names (like ':'). This is a problem with the parser (and also with
classes identifiers)
I am not sure I understand that one - ‘:’ is indeed illegal in most class / property identification systems - are you saying it should be allowed? Which parser do you mean?
it is being continuously tested in real software on the way, so that what emerges will be something close to a ‘stable’ standard (openEHR might decide to give it DSTU status from the outset for example) rather than an untested set of proposals. It is backwardly compatible with ADL 1.4, while fixing all the main problems and limits of 1.4. It includes many (in fact almost only) features proposed by people working with real archetypes in real environments, so I think it is safe to say that the 40 or so changes (most very small) really reflect the last 4-5 years’ industry validation rather than any kind of theorising. If ADL/AOM 1.5 were to become the next version of 13606-2, then we can contemplate:
