Thanks Diego, My mistake - that wasn't clear at David's demonstration or from the epSOS appendix.
Are the ENTRY level component archetypes available, and are they designed to be for epSos use only or do they support a much broader context of use e.g a full hospital or GP medication use? It would be interesting to compare with the openEHR equivalents, especially as we intend to use the NEHTA archetypes as the basis for the official openEHR medication archetypes before long and I have been doing various mapping exercises to ensure that they meet are broad set of use cases. 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 16:09, Diego Bosc? <yampeku at gmail.com> wrote: > Well, in all of our projects we use ENTRY level archetypes and slots, > but as epSOS defines that the requirement is a full document then it > made sense to put everything on the same archetype (to show that all > requirements could fit without problems) > > 2011/9/9 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: >> 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 >>> >> >> _______________________________________________ >> 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 >
