Hi All, Demographics (characteristics of a population) is one element of a larger more complex problem which may be labeled 'Patient Categories and Classifications', or simply 'Patient Boxes'. Conceptualizing the postal annex analogy, the interesting part comes when the available information is processed and placed into a designated box.
All those Patients living at some time within 25 miles of a known toxic waste dump (important because the Cancer Death Rate spikes in this area) can be placed in an appropriately labeled box. All those former military personnel who served in the first gulf war go in another box. All those who received surgical care at a hospital identified with MRSA into another box, or a box just for that hospital. How about people who were employed in areas that later were identified as being life-shortening. Pick a job site or a residential location (data supplied upon request). Or perhaps current agriculture workers exposed to chemicals. BTW: Try obtaining a complete medical record for a Patient from their branch of the military. A 'Demographics Service component' is an interesting project but my hunch is that my HMO has not signed onto it. A 'record' transmitted to a local or remote Practitioner should comply with a set of 'necessary' and 'sufficient' tests so that the recipient does not have to dig though unrelated and inappropriate data, and the Patient is permitted to open the Kimono far enough to obtain needed services. The 'all-or-nothing' approach works where all data is relevant and where little data is available. An 80 year old Patient may have suffient data to derail the practitioner and deflect focus from currently needed treatment. 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. Regards! -Thomas Clark Gavin Brelstaff wrote: > Yin Su Lim wrote: > >> This discussion document is produced by UCL (CHIME) to highlight >> issues that have arisen when designing a Demographics Service >> component. This service component will need to conform to the >> openEHR demographics package and be able to support the requirements >> of live demonstrator sites in north London. Any feedback and >> comments are welcome. > > > This is a _tantalising_ question - that I've ruminated on for some time. > > 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. > > 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. > The receiving medic would then be able to make any decisions on the > basis of the best available evidence at that particular time - using > the traditional document metaphor. Of course the onus is on > client-side to > make all evidential aspect of that document visible during any decision > making [no mean task]. > > But surely in an active clinical community the entire patient record > cannot be locked out of use while one participant is working on it. > Traditional database/directory locking works against rather than for the > collaborative process IMHO. Sure participants need to be aware of each > others concurrent activity on the same record but they must be given > both (1) the means to communicate with each other to decide if either > should go first (2) some convenient means to resolve conflicts that > would otherwise arise in the patient record due to their individual > asynchronous submissions. This is _not_ rollback but is instead a > kind of roll-forward and again the emphasis would be on a smart client > (able to coherently explain conflicts and choices to resolve them > at the point of resubmission) - rather than smart server. > 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. > > 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. > > > Just my 2 penceworth > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
