By the way feel free to add some of the onsdag 26 augusti 2015 skrev Erik Sundvall <[email protected]>:
> 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>: > >> 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 <[email protected]> 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: [email protected] >> twitter: @ianmcnicoll >> >> Co-Chair, openEHR Foundation [email protected] >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> On 26 August 2015 at 15:33, Kalra, Dipak <[email protected]> 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 <[email protected]> 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: [email protected] >>> twitter: @ianmcnicoll >>> >>> Co-Chair, openEHR Foundation [email protected] >>> Director, freshEHR Clinical Informatics Ltd. >>> Director, HANDIHealth CIC >>> Hon. Senior Research Associate, CHIME, UCL >>> >>> On 26 August 2015 at 13:28, Bert Verhees <[email protected]> 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 >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> > > -- > Sent from mobile. > -- Sent from mobile.
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
