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
