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