Hi Grahame, Some, actually most, of the issues you mentioned in the context of the NEHTA work are familiar, and I think apply to many implementation situations. Thomas and I have been discussing some possible solutions.
1. The ability to expose parts of the RM which are of particular significance to a particular audience, clinical or technical, to assist in clinical review or implementation guidance, along with contextual descriptions or name overrides. e.g If in a Dischage document we are using the ACTION.time attribute to carry the "Date Procedure performed" as described in the original requirements, I want to be able to express that in a template, so it is clear to developers and clinical reviewers. One option we discussed was to allow an RM attribute to be annotated and associated with an at-code, which would allow a local name"Date of Procedure" and a description to be overlaid. This would be in design-time i.e the name overlay would not appear in data. 2. The problem of openEHR archetype constructs being over-granular for summarised reports, mostly in the integration space but we do also need this in the EHR space at times. As an example I might want to record a Medication instruction in a summary, along with a couple of key events e.g Date of first prescription, Date of last prescription. Currently we need to use a further 2 ACTION archetypes, which feels clunky to developers and looks clunky in the tooling, as it requires encapsulation within a SECTION or written documentation. I think we can largely resolve this with better tooling but we do lack any easy way of asserting the relationship between the Instruction archetype and the child Action archetypes. We can do this with links but I think we should explore a very simple link concept that asserts a 'contains' relationship between a parent and child ENTRIES and is regarded as equivalent to a slot containment in querying terms. I think that might also help the similar situation where novice modellers always want to nest height and weight within a BMI, if there are good reasons not to allow nested entries. We still need tooling to flatten out and hide the unwanted child detail but that is relatively simple if we can assert or simulate the parent-child relationship The committment to model archetypes for EHR implementation is IMO correct but we do need to recognise and support the need to provide a summarised. flattened representation, even within EHRs. I think this is doable and will resolve a lot of resistance from integration-focused developers who feel the openEHR approach is over complex, particularly once we get ADL1.5 going properly. Ian On 27 March 2012 12:37, Grahame Grieve <grahame at healthintersections.com.au>wrote: > >> well, currently, that means that we have to break up what is a simple > single > >> archetype otherwise into a set of archetypes, and we have poor binding > between > >> them. > > > > I don't think Thomas was suggesting multiple archetypes. I think he was > saying that you would have multiple data instances of the one OBSERVATION > archetype. > > That's what I thought he meant. And that would mean that we'd need to > take what is one logical and actual archetype now and break it into > several parts to allow this to happen. > > Grahame > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- 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 *Primary Health Info 23 ? 25th April in Warwick ? are you coming?<http://www.primaryhealthinfo.org/> * Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/0d0a1572/attachment-0001.html>
