As you may have noticed, the new release of the ADL Workbench
<http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html>enables
exploration of multiple reference models and their classes. Although the
13606 schema
<http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/cen_EN13606_0.95.bmm>
is not yet complete (in particular the data types require work), it is
now possible to see the differences and similarities
<http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/apps/adl_workbench/doc/web/images/rm_schema_tool_duplex_classes.png>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:
o 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.
o 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
<http://www.healthintersections.com.au/?p=364>, as well as
suffering from key modelling problems
<http://wolandscat.net/2011/05/24/ontologies-and-information-models-a-uniting-principle/>.
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
<http://www.healthintersections.com.au/rfh/datatypes.htm> (which
include both openEHR and HL7 influences, as well as using proper
object modelling).
o 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
<http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes>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:
o *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.
o *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.
o 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.
So - what are people's thoughts on this?
- thomas beale
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/fa73512b/attachment.html>
