Hi Diego, Yes. I saw David Moner's presentation on these at the MIE conference in Oslo, and he and Gerard Freriks gave a very powerful account of the power of archetype development in messaging production.
However, these archetypes also point to a somewhat different approach (at least for now) between the 13606 and openEHR communities, in that the 13606 epSos archetypes are COMPOSITION archetypes, directly modelled against the epSos requirement. In openEHR we would take a rather different approach, by re-using more generic Entry-level archetypes and building up the epSos requirement via a template. In many respects this is somewhat closer to the CCD approach where each CCD (medication, problem,etc) roughly equates to a single archetype. Although this is more complex than David's approach, it does let us re-use the archetypes in very different contexts. As one example, I am currently involved in a project which uses the NEHTA medication archetypes templated in a local vendor system, but will re-use the same archetypes to create the epSOS Prescribing summary and the Emergency summary. Both approaches are valid and both are still much easier than developing CDA but there is different design paradigm. Three-level modelling, rather than two-level modelling? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 9 September 2011 15:28, Diego Bosc? <yampeku at gmail.com> wrote: > There are already epSOS EN13606 archetypes > http://www.epsos.eu/uploads/tx_epsosfileshare/D3.5.2_Appendix_G_EN13606_Implementation.pdf > > 2011/9/9 Thomas Beale <thomas.beale at oceaninformatics.com>: >> On 09/09/2011 14:01, Stef Verlinden wrote: >> >> Great initiative. Let's go for it. Even though I agree with your previous >> remarks that this probably won't provide a long term solution, IMHO it's >> absolutely necessary in order to secure short term progress. >> Maybe a dumb question, but is there a way we can involve people form other >> standard initiatives (DCM, HL7) in order to speed up harmonisation. More >> specific: is there a mutual interest for all of us to invest in this. >> >> My experience is: the instant we 'involve every stakeholder' and set up some >> large forum / club / organisation, everything becomes paralysed and >> political, and tasks that should take 3 months take 3 years. So we need to >> be careful... >> >> Specifically: >> >> myself and some others on this list are directly involved in an >> international DCM effort, led by Dr Stan Huff (Intermountain Health), and >> this should yield results before the end of the year >> HL7 - here it depends on what we are talking about: >> >> HL7v2 messages - there are specific approaches emerging to map v2 messages >> to openEHR, and I would see this as a seperate initiative (although >> hopefully taking advantage of the same tooling) >> CDAr2 - this has its own UML model (recently) and we may be able to define >> some mapping rules / approaches. However, since the differences with openEHR >> / 13606 are far greater than between the latter two, it is a bigger effort >> >> epSOS - this is a simple CCD that can easily be mapped to archetypes, and >> maybe representing it as an RM might be useful. >> >> My feeling is to get the 13606 / openEHR question sorted out first, because >> that is by far the easiest. If we stay focussed, unofficial (for now), and >> make progress on that then we can tackle bigger beasts... >> >> - thomas >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
