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.sundv...@liu.se>: > By the way feel free to add some of the > > onsdag 26 augusti 2015 skrev Erik Sundvall <erik.sundv...@liu.se > <javascript:_e(%7B%7D,'cvml','erik.sundv...@liu.se');>>: > >> 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.ka...@ucl.ac.uk>: >> >>> 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 >>> >>> On 26 Aug 2015, at 17:20, Ian McNicoll <i...@freshehr.com> wrote: >>> >>> 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 >>> >>> Dr Ian McNicoll >>> mobile +44 (0)775 209 7859 >>> office +44 (0)1536 414994 >>> skype: ianmcnicoll >>> email: i...@freshehr.com >>> twitter: @ianmcnicoll >>> >>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >>> Director, freshEHR Clinical Informatics Ltd. >>> Director, HANDIHealth CIC >>> Hon. Senior Research Associate, CHIME, UCL >>> >>> On 26 August 2015 at 15:33, Kalra, Dipak <d.ka...@ucl.ac.uk> wrote: >>> >>>> 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 >>>> ________________________________________________________ >>>> Dipak Kalra >>>> Clinical Professor of Health Informatics >>>> Centre for Health Informatics and Multiprofessional Education >>>> University College London >>>> >>>> President, The EuroRec Institute >>>> Honorary Consultant, The Whittington Hospital NHS Trust, London >>>> >>>> On 26 Aug 2015, at 14:44, Ian McNicoll <i...@freshehr.com> wrote: >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> Dr Ian McNicoll >>>> mobile +44 (0)775 209 7859 >>>> office +44 (0)1536 414994 >>>> skype: ianmcnicoll >>>> email: i...@freshehr.com >>>> twitter: @ianmcnicoll >>>> >>>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >>>> Director, freshEHR Clinical Informatics Ltd. >>>> Director, HANDIHealth CIC >>>> Hon. Senior Research Associate, CHIME, UCL >>>> >>>> On 26 August 2015 at 13:28, Bert Verhees <bert.verh...@rosa.nl> wrote: >>>> >>>>> On 26-08-15 14:23, Ian McNicoll wrote: >>>>> >>>>>> but am not aware of any non-openEHR >>>>>> implementations >>>>>> >>>>> 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. >>>>> >>>>> >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> openEHR-technical@lists.openehr.org >>>>> >>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>>> >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical@lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical@lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> >> >> -- >> Sent from mobile. >> > > > -- > Sent from mobile. > -- Sent from mobile.
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
