dear all ,
how could i explain to someone difference and relationship between openEHR and EN13606
thx
Maybe this would help:
http://search.informit.com.au/documentSummary;dn=950616334398351;res=IELHEA
it says 2006 .as days go on ,if there is any offical statements ,that will be great help
(attachments)
ATT00003.txt (192 Bytes)
This might help a little
http://www.slideshare.net/atalagk/implementation-and-use-of-iso-en-13606-and-openehr
Similarities:
Both use archetypes and ADL and two-level information modelling.
Both share the EHR, FOLDERS,COMPOSITIONS, ENTRY, ELEMENT classes.
Some archetype tools can work with both styles of archetype e.g LinkEHR and Archetype Workbench.
The just announced ADL2 Archetype editor/ template designer tools (beware!!! Early developer versions!!)
http://ehrscape.marand.si/designer/template-editor.html
http://ehrscape.marand.si/designer/archetype-editor.html
should be relatively easy to adapt to 13606 or other archetype-based reference models such as CIMI. They will be open sourced very soon.
Differences:
The EHR reference models are different
In spite of sharing the classes above, the attributes within those classes differ
openEHR sub-classes ENTRY into ADMIN_ENTRY, OBSERVATION, EVALUATION, INSTRUCTION and ACTION
The datatypes are different
The demographic models are different
The EHR Extract formats are different
13606 is intended primarily for the communication of EHR extracts across systems but some persistence repositories exist.
openEHR is intended primarily for data persistence and querying within systems but it is possible to message openEHR data.
13606 does not (currently) support templates but ADL/AOM2 is being considered
13606 does not support AQL Archetype Query Language
13606 is formal ISO standard but is closed source i.e. behind a paywall, as in normal for ISO published material
openEHR is open source and freely available
There is a great deal of cross-communication between the two communities and a number of people work with both formalisms. It is possible to transform data between the two formalisms but they are not directly compatible.
I hope that is accurate and non-contentious!
Ian
See my earlier response. I think that is probably as official as you can expect for now!!
13606 and openEHR share some aspects of their design, there are many formal and informal links between the two communities e.g. Thomas Berale and I are both invited experts to the 13606 group, and there are opportunities for shared development especially around tooling but 13606 and openEHR do need to be regarded as two different solutions to different problems, with different licensing and development/maintenance models.
Ian
Hi,
I would say that the main difference is that 13606 is for data communication and openEHR is for EHR architecture, both based on archerypes.
For detailed differences just look at both information models, you will see that 13606 IM is much simple.
About the specs, 13606 has 5 “chapters”, including communication and security, and openEHR specs don’t have those.
The best way of knowing the differences is just to download the specs of both and compare them.
Hope that helps,
Cheers,
Pablo.
Dear Pablo,
According to the scope statement: the 13606 is for the creation of the EHR-EXtract for communication between IT-systems
and
for the definition of the Information Viewpoint in Interfaces with system services.
Gerard
Gerard Freriks
+31 620347088
gfrer@luna.nl
I agree with most of the points, but I’m curious why you say that 13606 does not support AQL (and in any case wouldn’t be “AQL does not support 13606”?)
Yes, that is a good question, I did not know that AQL was considered to be OpenEHR specific.
In my opinion it was a bound to the archetype model, not to the reference model.
Hi Diego,
I was not aware of any 13606 implementations that support AQL , although I am sure there is some sort of path-based querying. AFAIK AQL is not part of the 13606 scope.
Happy to be corrected.
Ian
Well, technically, it is not part of the openEHR scope either. Happy to be corrected 
It is definitely on the openEHR Specifications Roadmap. That was a clear decision at the Oslo meeting a year ago. There are at least 3 implementations that I know of and more back-end vendors are intending to implement but I know what you mean ‘technically’
I agree that AQL is RM agnostic but am not aware of any non-openEHR implementations @Diego/ Gerard??
Ian
Is there a Xhosa implementation of 13606 or OpenEHR?
Does that mean OpenEHR or 13606 are not able to support Xhosa?
I would leave it with: AQL is an archetype bound query language, and every system which is build on archetypes is able to implement AQL.
Hi Bert,
“I would leave it with: AQL is an archetype bound query language, and every system which is build on archetypes is able to implement AQL.”
That is fair enough but we were asked to characterise the differences between 13606 and openEHR and I am comfortable that the actual and formal adoption of AQL is one of those differences.
AQL is on the openEHR specifications roadmap but AFAIK this is not the case for 13606. Of course that does not stop 13606 vendors implementing AQL but in terms of actual differences between the 2 communities the adoption, or intention to adopt AQL seems (from the outside) somewhat different both at a practical and formal level.
Although AQL adoption in the openEHR community is far from universal, most of the vendors/developers that I have spoken to see it as something they want to implement, particularly as GDL is somewhat dependent on AQL.
I am just trying to ascertain if there is similar enthusiasm/intention amongst 13606 vendors, or if AQL forms part of the current 13606 refresh discussions.
Ian
I’d agree with Ian here.
While both could possibly support AQL, the difference I see is in intent, scope and actual implementation.
As Gerard says, 13606’s main aim is to communicate between IT-systems and for this, AQL may not be quite as fundamental as it is to openEHR.
Sebastian
If you see it from the formal point of specifications, you are right, but as you say, ISO13606 is in a renewal process, and it is hard to foresee what will come out of that.
You write yourself that support for ADL/AOM 2.0 is being considered, I am very happy to read that.
Then it is a small step to AQL based on AOM 2.0 adoption.
I couldn't think of a strong reason why they should not adopt AQL when they adopt AOM2.0.
Untill now, there has only been AOM 1.4, also for OpenEHR, and the AQL for AOM 1.4 has always been a moving target.
That is why I never implemented it, but also because I did not really need it.
So we could say, that there is no formal specification for AQL based on AOM 1.4 and that OpenEHR, technically said, like ISO13606, does not support AQL.
How about filtering messages?
Messaging is a process, in the cloud it will become very important, it will become more then two system interchanging information.
It doesn't matter were your medical data are, but how they come to you matters, and I can imagine usecases for filtering.
(just a quick example)
Hi,
I must repeat the scope of 13606 verbatim once more.
It is NOT only for messaging but also for Interfaces
Gerard Freriks
+31 620347088
gfrer@luna.nl
- Scope
This standard is for the communication of part or all of the electronic health record (EHR) of a single identified subject of care between EHR systems, or between EHR systems and a centralised EHR data repository.
It may also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components) that need to access or provide EHR data.
This standard will predominantly be used to support the direct care given to identifiable individuals, or to support population monitoring systems such as disease registries and public health surveillance. Uses of health records for other purposes such as teaching, clinical audit, administration and reporting, service management, research and epidemiology, which often require anonymisation or aggregation of individual records, are not the focus of this standard but such secondary uses might also find the standard useful.
This Part 1 of the multipart standard is an Information Viewpoint specification as defined by the Open Distributed Processing – Reference model (ISO/IEC 10746). This standard is not intended to specify the internal architecture or database design of EHR systems.
Dear All,
This is an interesting discussion, and I would like to stress the complementarity of the two.
openEHR is, as others have said, an important consolidator of the state-of-the-art in best practices for the design of an electronic health record architecture, repositories and the underpinning of EHR systems. An important advantage is that it specifications are publicly accessible, and of course it has a vibrant community and a large number of tools to support its use.
13606 has always had a good relationship with openEHR, but is primarily intended to be an interface standard between heterogeneous EHR systems, and is therefore optimised for that purpose (e.g. for mappings), which means its reference model is definitely simpler. There are many countries and situations where it is essential to have a formal international standard in order for it to be acceptable as part of a national strategy. Some vendors have also indicated that they like the inevitable stability of a standard, which changes infrequently. 13606 also has a community and tools, and of course many of its community are also part of openEHR, and vice versa.
If one takes a high-level look at the many different globally-used representations of health data, it is easy to see that these two reference models are indeed very similar. Whilst near to the ground we can easily be tempted to focus on their minor differences, I believe it is of greater value to society and to our field if we can regard them - and champion them - as a mutually reinforcing pair of models.
The specification of archetypes is very mature, and during the revision we expect to upgrade to the latest AOM (which is 2.0). This part of the standard will also remain focused on a logical representation supporting archetype interchange.
As has been pointed out, AQL could in theory have been added to the standard, since it could “work" with 13606. However, another important imperative for a standard is that it has reached a sufficient level of maturity and stability. It was also felt important by the working groups of CEN and ISO that we do not introduce something very novel into this revision process. I did suggest that we consider adding a sixth part to the standard to support the distributed analysis of electronic health records (such as communicating queries). It was felt wiser, and I support this view, not to introduce something new to these five parts of the standard, but once it has finished its revision to propose a new work item to CEN and ISO on the querying of EHRs. AQL will inevitably be an important contribution to that new work item, and hopefully by the time we are ready for it the AQL specification will be very mature and there will be much more experience of its use, making it an ideal specification to standardise.
Thank you all for your excellent contributions in different areas of EHR representation, communication and implementation - to keep advancing our field and the quality of EHRs world wide.
With best wishes,
Dipak
Dear Gerard, IMO “communication” includes the interfaces, I didn’t excluded them 