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 -- Gavin Brelstaff - BioMedical Area, CRS4 in Sardinia Loc. Pixina Manna Edificio 1, C.P. n.25, 09010 Pula (CA) Italy. Email: gjb at crs4.it Phone:+39.070.9250.312 Fax:+39.070.9250.216 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
