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. 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. So although I mostly agree with Thomas's definitions as they apply to a pure openEHR system, there are other circumstances where the overall context of openEHR use is the key determinant. The original design decision to make a clear separation between the EHR and Demographics models makes perfect sense in the context of a pure openEHR implementation, but we may have to explore the possibility of being able to show some aspects of the Demographics model within an archetype tree, to cope with legacy PAS and design-only contexts of openEHR use. 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>: > > General principles: > EHR: > > clinical data > clinically relevant demographic details, e.g. sex, date of birth, occupation > but otherwise, identifying information, and even patient id(s) can be > avoided completely in the openEHR EHR, or they can be put in; see Common IM > for discussion - > http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf > clinically relevant admin data, e.g. admission, discharge, transfer, birth, > death, .... > > Demographic: > > demographic data of any complexity, including personal contact information, > professional qualifications > relationships, typically for relating professionals together into teams, > groups and to employing organisations > > - thomas beale > > > Oxford Partnership wrote: > > Are there any defining rules as to what data should exist within the EHR vs > Demographic models ?. > > regards > OP > >> Quoted : >> >> It should be noted that the Demographics Model restricts itself to >> very 'pure' demographics i.e. person and other party identifiers and >> contact details, as would be expected in a patient register. Anything >> else e.g Housing details, language requirements etc should be modelled >> in the EHR Model (though again, in reality, there may be some local >> variation in implementation.) >> > > ________________________________ > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- > Thomas Beale > Chief Technology Officer, Ocean Informatics > > Chair Architectural Review Board, openEHR Foundation > Honorary Research Fellow, University College London > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
