Hi Gerard, I think this is theoretically and philosophically correct. However,for the moment, given the difficulties I have described above, on achieving a clear separation between Demographic and EHR entities in practice, that at present, this would only confuse things further. At present it is helpful to be able to model Device explicitly and visibly within archetypes. We use a CLUSTER archetype so that this is reusable and extensible.
We do already have external catalogs for e.g. lab tests, procedures and medications etc but the problem (as for the Demographics entities) is that the internal requirements for the catalog are usually a mismatch for the requirements in the clinical record. It would of course be possible to use the maximal dataset approach to define, for instance, an archetype for device which encompassed a variety of different perspectives - use in the clinial record, manufacturer's requirements, servicing records, scheduling etc but as ever, it is question of resources.It is going to be hard enough to model the clinical record requirements without taking on this extra work. 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 Gerard Freriks <gfrer at luna.nl>: > Shouldn't we consider to extend the Demographics to ?Resources? > Isn't a person one of many types of resources we need to document in and > around the EHR? > (e.g. devices, catalogs with lab tests or procedures, rooms, beds, ad-hoc > lists, etc) > > Gerard > > > -- <private> -- > Gerard Freriks, MD > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > T: +31 252544896 > M: +31 620347088 > E:? ? ?gfrer at luna.nl > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 > > > > > On 5, Apr, 2009, at 11:13 , Thomas Beale wrote: > > 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
