> 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.
Right. that would be very nice. > 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. right. Agree with this, though I suspect it doesn't quite cover all my issues. > 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. I thought this was in ADL 1.5? Grahame
