Hi Gerard,
Agreed - I was using messaging loosely - ‘interfacing between systems’ is better.
Thanks Dipak,
A very clear and helpful statement of current and future intent. I too agree that we should not focus negatively on the differences and that they are mutually reinforcing but people do ask and it’s important that we are clear that while 13606 and openEHR share a number of tools, technologies, philosophies and even people + good relationships), they are not currently interchangeable or directly interoperable.
From a high-level perspective they are indeed very similar but the detailed differences do matter to implementers, and I think we need to be clear to the market about these differences.
Thanks too for the perspective on AQL adoption - makes complete sense to me in the 13606 context.
Ian
Dear Ian,
Thanks also for your helpful reflections. I agree that once the standard is close to final we should perform and publish a detailed comparison and cross mapping between the reference models, as an aid to system implementers and tool makers.
With best wishes,
Dipak Kalra
We are in agreement, then. 
Gerard Freriks
+31 620347088
gfrer@luna.nl
Hi!
Where can one find proposals/diagrams describing the refreshed RM (reference model) in the new 13606 revision? Will 13606 keep using the old data types or harmonize more with CIMI or OpenEHR?
Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? If so, great!
When it comes to “simplifying” the RM (or perhaps moving complexity to another meta/design-pattern layer) I think CIMI has gone further than 13606. Are there any plans of aligning 13606 with CIMI?
//Erik Sundvall
onsdag 26 augusti 2015 skrev Kalra, Dipak <d.kalra@ucl.ac.uk>:
By the way feel free to add some of the
onsdag 26 augusti 2015 skrev Erik Sundvall <erik.sundvall@liu.se>:
Thanks Dipak, for announcing this, it is great news. And also thanks for explaining the current position of AQL in relation to 13606 and the way it is planned to integrate in the standard.
Best regards
Bert
Oh, that got sent too early, sorry. I meant to say:
Feel free to add some of these descriptions to the stack overflow question:
http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve
Two people thought the question was bad enough to down-vote it, but I think this discussion shows it to be useful, so maybe that can change.
//Erik
onsdag 26 augusti 2015 skrev Erik Sundvall <erik.sundvall@liu.se>:
Technical, the original grammar for AQL was bound to openEHR RM classes, composition, version, observation, etc. theoretically it could be generalised to be a RM agnostic and should be the goal of the current AQL specification work if it hasn’t already been done in the antlr grammar.
Regards
Heath
Hi,
Next week we will meet in Brussels and discuss the proposals, discussion papers by the various working parties.
I think that the RM and data types will be simplified.
leaving semantics to be dealt with at the archetype level using standardised archetype patterns.
(participations, demographics, and things like ranges and more)
On behalf of the EN13606 Association I take part in the CIMI working group.
CIMI will help create archetype patterns.
CIMI models will be able to be converted to EN13606 artefacts.
And all in spite of the fact that CIMI has a very simple and strange RM derived from 13606-1. (At least that is the way I look at it)
The strange thing being the fact that they have defined a ‘Super ENTRY’ class that can contain the ‘normal’ ENTRY class.
They designed this because of the need to model for instance panels as one entity and each of its components.
(I’m of the opinion that the present 13606 RM can deal with all the CIMI requirements. This is how I create panels usually.)
Gerard Freriks
+31 620347088
gfrer@luna.nl
Like the Ocean Archetype editor. It only supports the OpenEhr RM only. That is understandable and no problem. The market will fill in that gap.
Presumably the outline syntax, SELECT, CONTAINS etc is generalisable?
Ian
All of it is very, very generalizable
openEHR has an EHR Extract specification <http://www.openehr.org/releases/RM/latest/ehr_extract.html>as well, which is more flexible than the 13606 one e.g. it can include information from more than one patient, and accommodates both openEHR and non-openEHR content.
- thomas
It's not. It's exactly the same no matter what the reference model. Of course, to properly check AQL queries and execute them in a specific environment, access to a representation of the RM being used will be needed.
- thomas
I would suggest that CIMI has been simiplified to the point of not being directly usable as an RM by openEHR or 13606 - most of the needed context information is gone in CIMI, and it doesn’t distinguish any kind of ‘Entry’ or clinical statement. This was a conscious choice in the CIMI community, designed to get buy-in from a much wider range of stakeholders than openEHR or 13606 deals with. Technically, the CIMI approach is to soft-model nearly everything in ‘reference archetypes’. - thomas
could we just add a page on openEHR website to illustrate these points
thx
if you search on the , with either ‘13606’ or ‘CIMI’ you will find a lot of material. - thomas
Sorry, but I have to ask: are you doing a homework?