Christine and Gavin Some misunderstandings appear to have arisen. As all EHRs are composed of compositions - it is only necessary to lock a composition for update - and that will be usurped anyway by the new version.
Demographics are completely separated out - this is a design feature that has been there for some time and relates to legislation in some jurisdictions (no identifying information in the clinical data store) and does aid security. Further, it makes merging of EHRs very straight forward and allows for different demographic identification at different sites - without leading to conflict. I think you will come to see the utility of this approach. Extracts are for moving information from one EHR store to another - not for accessing the EHR - this is done directly with the server - and the demographics can be handled as you wish behind the scenes. Archetypes are for discreet, complete reusable concepts - it is possible to archetype the different RM classes - but section archetypes will not include entry archetypes - rather reference them. The 'chaining' of archetypes into a composition is done at runtime using 'templates'. These have not been formalised as yet - but I include an experimental template in XML (we have a shared tool to do this with ADL soon) to give you the idea. The sort of XML this might generate for a BP of 120/80 measured with a wide cuff, an oral temperature of 36.5 C and pulse with rythm - for your information - is also included. There are 4 archetypes involved - one for the section - vital signs, one for BP, one for Pulse and one for Temperature. The template selects those aspects of these concepts that are required for recording vital signs, and how they will be organised. The fact that the BP is part of vital signs does not alter its meaning in any way. The XML schema for openEHR data is not yet finalised, but will be a single schema for all shared information. At Ocean we optimise this somewhat for internal presistence - but the in memory representation is always the same and based on the RM. Just to reinforce - these artefacts are not produced according to an agreed openEHR specification - and the standard form of templates will not be XML as in this example - though you can clearly do as you wish locally (templates do not alter semantics). I hope this is helpful. Cheers, Sam Christian Heller wrote: > Hi, > > >>Gavin Brelstaff wrote: >> >> >>>First it is not clear why Demographics should be separated out like >>>this from the entire record - it just introduces potential >>>inconsistency due to replication issues or worse mis-identification of >>>a patient. > > > I agree. > In my opinion, the whole EHR should be stored centrally somewhere. > Of course, it may be replicated regularly etc. > > >>>From an evidence-based perspective, it might be best to send and >>>receive a "sealed network packet" of as much as the patient record as >>>bandwidth permits: >>>That could mean the entire text data - leaving larger payloads such as >>>exam-data/imaging/traces etc to be requested on demand. > > [..] > > Good idea! May be not as much as bandwidth permits, but just that extract > of information which a special kind of Medical Practitioner (MP) needs. > > >>>But surely in an active clinical community the entire patient record >>>cannot be locked out of use while one participant is working on it. > > [..] > > What about optimistic locking? If several MPs get different parts > (extracts) of an EHR, then at checkin their data do not necessarily > have to conflict. > > >>>The flavor should be that of a Wiki while the >>>overall philosophy should be that of evidential audit/logging: who saw >>>what and what they did when they saw it - for medico-legal purposes. > > > I agree. > > >>>Here the entire patient record would be archetyped as >>>a single document in which Demographics was a self-contained subsection. >>>If you really needed to you could just replicate that already archetype >>>sub-section on a Demographics Server - but that should be a read-only >>>copy - the mastercopy being of course that in the full record. >>> >>>Something like a versioning XML server >>>(xmlDB,Xindice,OracleXML DB) might be the way to go. > > > I agree. > > On Thursday 03 March 2005 06:42, lakewood at copper.net wrote: > [..] > >>A 'Demographics Service component' is an interesting project but my >>hunch is that my >>HMO has not signed onto it. > > > I think this is just a question of physical distribution, not of the > logical "inside" architecture of a software system (or component). > In my opinion, every EHR system should be able to send extracts of an > EHR to another system, may it be demographic information or others. > > So, one could set up a physical box responsible for sending > demographics only, or images only etc. But the software running on > those boxes can be a general one, only that it once creates an EHR > extract with demographic-, and in the other case with imaging > information. > > >>There are 'levels' of records and within levels there may be varying >>needs for different >>Practitioners. What is 'necessary' and 'sufficient' for each >>Practitioner? We may be >>talking about multiple records, e.g., my Internal Medicine Practitioner >>wanted one set >>of information, the Surgeon wanted another. > > > This is a very good idea. I didn't think about it this way before. An > EHR software solution could come with several default EHR extract > models -- comparable to the "Data Transfer Object" (DTO) pattern of > Martin Fowler: one DTO model for administrative/demographic information, > another for an Internal Medicine Practitioner and so on. > > Of course, the software system needs to provide the necessary > "Translator" models as well. These are responsible for copying data > from the domain model to a DTO and vice versa. > > If the Medical Doctors in a certain region want their own special > EHR extract models, they can just create them (together with the > corresponding translator models) on their systems. As long as both > communication partners (software systems) know how to translate a > certain model, there shouldn't be a problem. > > And, of course, the data should preferrably be sent in XML format, may > it be the Clinical Document Architecture (CDA) or, even better, the > free Healthcare Xchange Protocol (HXP). > > Just some ideas, > Christian > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: Vital_signs_openEHR.xml Type: text/xml Size: 11532 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050304/770ff82a/attachment.xml> -------------- next part -------------- A non-text attachment was scrubbed... Name: Vital_signs.template Type: text/xml Size: 1071 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050304/770ff82a/attachment.template>
