Hi Thomas, > TB: >We still don't want to pollute individual patient EHRs > with multiple redundant copies of information about various carers etc. >
In principle, I absolutely agree, but if in an existing PAS is to be interfaced/mirrored, we must accept that the faciliites e.g to record carers, may simply not be available. As an EHR vendor, I can see the attraction of just getting on with modelling this in my EHR . >TB >but this is faulty modelling - archetype is not the place to do such modelling >- it is being misused in this instance to express the >requirement / >aspiration of having a form on the screen with a fully populated demographic >items. The requirement is reasonable of >course, but needs to be modelled >elsewhere - it is the job of a virtual EHR service to integrate information >from EHR, demographics and >other services and present it on the screen in appropriate forms. Again, I cannot disagree but whilst the openEHR architecture and tooling has been largely successful in appopriately obscuring the technical aspects of modelling from clinical modellers, this is an aspect that we have not got quite right as yet. First off we need to be able to develop Demographics model archetypes via clinically useable tools (which is happening and is where this thread started) and then we must be able to display them within the tools in an understandable and contextually appropriate fashion. Whilst much of this could be done at template level, there are situations where, from a user perspective, this is counter-intuitive. As I said before, the strength of openEHR has been to be able to present clinical information in an immediately understandable fashion, no matter that the underlying technical model is quite different. As an example, perhaps we have an operation note archetype, where the surgeon and any assistants should be defined. This is, of course already handled by Participations and ideally could be shown explicitly in the template, complete with Demographics archetypes to define the exact participant data required e.g .Name , Address, Grade, Role . However, perhaps there is also a legal/training requirement that the lead operator start/stop time is captured i.e when the assistant takes control. This clearly forms part of a per-patient record but relates at node-level to a particular Participant. Possibly this is just a tooling issue but I have wondered whether it might be helpful to allow some sort of 'design-time' attribute to be applied to a node which indicates that the node should not be instantiated in data but is simply there as a placeholder for e.g a reference to a particular participant or indeed to another part of the underlying Ref model which is clinically important but not archetypeable e.g Date performed in the ACTION class, but which is important for clinicians to see. It could also be used to allow assertions to be made visible and editable within correct clinical context. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org 2009/4/5 Thomas Beale <thomas.beale at oceaninformatics.com>: > Ian McNicoll wrote: > > Hi Thomas, > > > Good summary which I would agree with in principle, but this only > properly applies where openEHR is being used to completely define the > information requirements. In practice, openEHR is really being used in > 3 slightly different contexts... > > 1. Where applications are being developed with a pure openEHR > 'back-end' covering both the EHR and Demographics models. In this > context, a clear separation of models with the spilt of content you > have defined above, is the correct design. > > 2. Where applications are being designed with an openEHR back-end to > cover the EHR content but integrated with an existing Patient Admin > system (PAS) or other pre-defined Demographics model e.g a national > standard, HL7-CDA. In this case, the pure separation you defined > above may not be acheivable e.g. the PAS or national model may include > some aspects thatshould be in EHR such as Sex or Occupation. > Alternatively, it may be that the existing model will not allow some > 3rd parties such as carers or other contacts to be stored in the PAS, > so these will have to be modelled in the EHR. > > > well there will clearly be overlaps between the EHR and PAS - sex, date of > birth and occupation seem unavoidable. As a general approach, I believe an > openEHR demographic service should always be deployed, usually as an > interface to / mirror of a PAS or other PMI (but providing versioning, and > proper archetyping). We still don't want to pollute individual patient EHRs > with multiple redundant copies of information about various carers etc. > > 3. Where openEHR is used purely to gather and define clinical > content, with no expectation that either the EHR or Demographics > models will utlimately be modelled as openEHR within consuming > applications. This can cause some difficulties since, for instance, > while an archetype for surgical procedure does not need to explicitly > model the surgeon and any assistants as this is already catered for > within by the Participants attribute, clinical reviewers of the > archetype or templates, do like to be able to see this represented, > often structured within the main definition of the archetype. This was > the main reason that for the NHS modelling, we created some CLUSTER > archetypes, representing concepts like Organisation, Address,Carer > etc. > > > but this is faulty modelling - archetype is not the place to do such > modelling - it is being misused in this instance to express the requirement > / aspiration of having a form on the screen with a fully populated > demographic items. The requirement is reasonable of course, but needs to be > modelled elsewhere - it is the job of a virtual EHR service to integrate > information from EHR, demographics and other services and present it on the > screen in appropriate forms. > > - thomas > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
