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 >
