This page is for a proposal (or more than one) for the revision of ISO 13606 in 2012. One possibility is to develop a formal openEHR Foundation proposal to CEN and ISO, containing a fully worked up description of changes. The goal would be to have a single standard for an EHR and EHR Extract reference model (RM), a revised archetype specification, and a single methodology for building software and tools, regardless of which RM variant was in use.
There is a dedicated mailing list for discussions about ISO 13606 and openEHR.
Part 1 of the ISO 13606 standard has not changed since 2007 when it was accepted by CEN. It was derived from the combination of the earlier revision of the standard and the emerging openEHR information models of the time. A number of issues with its Extract model have been identified by users over the years. In openEHR, some 77 CRs relating to its RM have been processed in this time, which gives an idea of the number of lessons learned and the amount of evolution likely to be needed.
One thing that is clear so far is that 13606 has never been implemented literally according to the standard, but instead, in a variety of locally customised forms, each specific to the needs of the implementers. This essentially means that the current form of the standard is a 'useful starting point' but is not in fact acting as a proper standard in the sense of interoperable software or data.
With respect to the published form of the standard, a key issue historically has been the lack of a normative XML schema or other computable expression of the standard. This has resulted in a number of custom schemas being created in different locations.
Some of the major technical issues include:
There are also a number of minor technical issues, to do with various attributes:
Any new proposal needs to address these in an integrated fashion.
One proposal is to redefine the reference model to be more comprehensive than it is today, but with the possibility of enabling a choice of semantic richness, with fully defined mappings between parts of the model which are more semantically rich (the openEHR flavour) and less so (the 13606 flavour). Further, the openEHR EHR Extract and Demographic models could be used to provide flexible, fully archetypable structures in these areas. Simplifications to openEHR's current RM should aid the development of a single model.
TBC
The following are specific resources for use in defining a new 13606-1 model.
The primary requirement to safely identify information shared between systems is for a guaranteed globally unique identifier for COMPOSITIONs. It would be reasonable to require a GUID for all COMPOSITIONs. This provides a guarantee that any sharing party can agree on which instance (e.g. original or copy) of a COMPOSITION it has. openEHR does this, and it would therefore be easy to state the same rule for 13606 and openEHR.
For identifying nodes lower in the hierarchy: it would not be unreasonable to require GUIDs on the root of any ENTRY instance (in openEHR-speak, an OBSERVATION, ADMIN_ENTRY, ACTION, INSTRUCTION or EVALUATION). This would greatly ease the definition of LINKs that want to point to other ENTRYs, and may also make query return results less ambiguous, assuming that ENTRYs are the smallest unit of returned data across enterprise boundaries (see below for more on this).
The question then is how to identify nodes below COMPOSITION and ENTRY (other than the ENTRY root nodes themselves). To understand this question properly, we need to understand the reasons why node-level identification is thought to be needed. These are:
Some of the above will need to be reviewed. However we can probably assume at least some remaining need to refer to the finest grain of information. We can assume that every type of feeder system has its own method of doing this. All openEHR systems identify information nodes via archetype paths, in some cases with further predicates if there are multiples. Any system that is 13606- or openEHR-enabled, and using archetypes can do the same.
The difficulty for 13606 is that it can't assume all users of its specification actually use archetypes. Therefore, it may make sense for the new 13606 revision to state the following:
Issues:
The current form of ISO 13606 part 2 is from a snapshot of the openEHR ADL and AOM 1.4 specifications donated by openEHR to CEN in 2007. This was re-formatted into CEN and then later ISO document format. Extensive experience in the openEHR and 13606 communities has now been gained with this specification. It has been deployed both for openEHR archetypes in a number of national e-health programmes, as well as in production HIS systems around the world. Its limitations are now fairly well understood, and substantially addressed in the openEHR ADL/AOM 1.5 specifications, now in late draft (see link below).
Currently there is no query language in ISO 13606. However, a query language and methodology is probably the most critical part of the archetype-based framework relating to use and re-use of data. The openEHR Archetype Query Language (AQL) has been in production use for over 4 years, is implemented in C#, Java and Ruby, and is relatively stable and mature.
A related specification called a-path - an archetype form of Xpath - is also expected to be useful and may be integrated into ADL 1.5 and AQL eventually.
TBC