Dear Matt, Helping out here may be like giving away trade secrets. However in the interests of the open EHR, try this.
The problem is similar to one I had with an Ophthalmology data base. This created a 'general screen' on first patient contact with an appropriate 'SOAP' structure, then would allow the clinician to graduate to a more specialized protocol such as 'glaucoma' or 'cataract' as the client's condition became understood and a care plan made. There would be copy forward of fields for new 'general' encounters or for successive iterations of encounters structured by the more specialized screens. But if you went the other way and created a general screen from a specialized screen (to follow some other bit of pathology that turned up), and wanted to share data harvested in field common to both (e.g. IOP or 'intra- ocular pressure', which is a simple numerical value), you had to reverse copy, with as many lines of programming as there were separate forms that might share fields. It was much simpler to make the field entities into 'classes' just like archetypes, so that the forms which shared fields always 'looked at' the latest instantiation from the latest encounter. The 'carry forward' was achieved because the 'object' looked at was always the latest one harvested/instantiated (for that class/archetype). So whatever form you pulled down, all the 'fields' in it that were shared with any other forms (or new ones you might make), looked at the same corpus of harvested 'objects', and would always show the most recent one (and thus the most current value, in the case of IOP, or pneumonia status, as in the example quoted). Its a kind of 'versioning', since in this model, all forms would end up as attested documents for storage and communication (as CDAs), and later ones are also attested. So you don't usually look at the pre- op assessment document you originally created, but an updated version of it, although the earlier one is there to remind you of your errors when required to. Mike Mair ----- Original Message ----- From: "Matt Evans" <[email protected]> To: <openehr-technical at openehr.org> Sent: Saturday, March 06, 2004 5:55 AM Subject: Basic EHR functionality Dear all, I would be grateful for some advice on an issue that has been troubling me for some time. I am a clinician currently on secondment full time to an EHR project. I do not wish to name the software house we are using but they are a major EHR developer with an interest in the UK. The application on which we are currently basing our documentation strategy seems to have a flaw. The following is a made up example but I hope it illustrates a point. The application allows the creation of documents with standard windows form controls (e.g. drop down lists, multiselects, radio buttons etc). When I open a document it pulls though the appropriate value to each field from a previous form. Let's say I have a free text field that says 'Reasons patient unfit for surgery' and I have entered "pneumonia" as the value. I save the document and can view the information from the document viewer. A month later I review the patient and they no longer have pneumonia. I open the pre-op assessment document (which pulls through pneumonia to the relevant field) and delete it. The form is therefore either saving a zero length string or null value. The amended document is saved and the correct information can be viewed in the document viewer. Now, the patient phones up with some additional information which I wish to add to the assessment. I open it up to add that info. On a different page of the document however the 'reasons not fit' box pulls through not the last value (null or "") but the last non-null or "" value i.e. pneumonia. When the document is signed the author has unwittingly signed the fact that the patient is unfit for surgery as that is the value in that field now. The system automatically runs a theatres scheduling query and that patient is permanently rejected as being unfit for surgery. This is one of a number of significant problems with the system that in my opinion make it at best inconvenient or in some cases unsafe to use. All control types are affected and the solution we have been offered thus far is that you don't pull any values through. Therefore you have to retype all the information every time! The other worrying thing is the number of hours spent by Trust staff and IT staff on designing and building all the documentation is phenomenal and has resulted in very little. The UK government has spent an estimated ?2.3 billion on systems for the NHS for the first 3 years of a 10 year contract. This causes me concern given the above issue may be the tip of the iceberg. I am something of an amateur dabbling in the world of IT so would appreciate some informed opinion... Thank you. Matt - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
