Hugh Leslie wrote: > Hi Tim > > As someone who has dabbled in ehr interface design myself, I agree with you > that > its very unlikely that any automatically generated user interface (from a db > schema or openEHR archetypes) will be satisfactory for clinicians to use day > to > day. > > Where it could be useful is in displaying and entering data for clinical > information that hasn't been seen by a system before. Imagine a GP system > that > receives data in openEHR format from some specialist system that it was > never > designed to understand or display in a gui. It would be possible to display > a > gui that even allowed editing of the data with each element in its correct > type > etc. An archetyped blood pressure within the body of that report would be > able > to be viewed with all the other bps in the system from whatever source even > though the gp system had never been designed to view that information.
OK, I agree that that more constrained aim is more achievable - indeed, products like Adobe Acrobat (the full version, not the free Reader), Microsoft SharePoint and the like already allow that - the data and the means to view and edit it (with constraints, checks, look-ups etc) are able to be sent together and automatically called by or integrated into the receiving system. Of course, these are proprietary systems and thus have limited scope, and the constraints they offer may be less sophisticated than those in openEHR (although the latest version of MS SharePoint is pretty comprehensive), but the idea is the same - and it is a powerful idea. However in your use case I can't quite see why the GP would want to, or should be able to, edit data values in a report sent from a specialist. If you mean that a specialist could send the GP a new type of medical record, say a specialised symptoms record for inflammatory bowel disease, and then the GP could update it in the meantime within the context of the GP's own information system, until the next review by the specialist, and then send the updated record back to to specialist, then yes, that's useful. Perhaps that's what you meant? Which GP information vendors are likely to sign up to incorporate this openEHR technology, I wonder? Would certainly overcome the problem of vendor lock-in. But I suspect that a whole new generation of systems is needed to support this, and maybe a whole new generation of system vendors/developers too. Tim C > Tim Churches wrote: >> Ian Haywood wrote: >> >>> On Thursday 15 February 2007 08:12, Elizabeth Dodd wrote: >>> >>>> On Wednesday 14 February 2007 23:41, john hilton wrote: >>>> >>>>> How would you like a surgerywhere in each GP's office the doctor uses his >>>>> fave EHR frontend prog, from a shared db? >>>>> >>>> That's what I was thinking of when Horst made his suggestion. I'd love it. >>>> I would never be blamed because of my choice of program (although I haven't >>>> had any for more than a year) >>>> >>> One of the things I've learnt from trying to write an EHR is that the GUI >>> and >>> the backend are inevitably wedded fairly closely in term of behaviour. You >>> can move things around, change fonts, colour etc. very easily, but to >>> implement a particular workflow on the GUI, you need a matching database >>> structure. >>> >> >> Yes, exactly right. It is not so hard to generate generic interfaces >> from a back-end schema, but it is all the bells-and-whistles, the little >> conveniences and shortcuts that turn an application from clunkily >> painful into usable. >> >> >>> This is also why a 'common set of fields' to make EHR data portable is very >>> hard, unless you make it very simple, and then the imported data won't be >>> as 'rich' as the EHRs own data. For example, you won't be able to do >>> automatic repeats scripts from the old data, as it's just a free >>> string "Amoxil 500mg tabs" which the new EHR can't make sense of. You can >>> read it though, so it's still useful. >>> >>> This is not absolute, I think it is possible to have the two interfaces >>> demonstrated by Richard and Horst talk to the same backend, (and an >>> MD-style >>> one as 'lowest comon denominator') however it would need very careful >>> thought, and there would be limits, certain areas were all the clients >>> would >>> have the same or similar behaviour. >>> >> >> The OpenEHR guys are trying to develop shared, interoperable data >> storage/retrieval as well as automatically generated template driven >> front-ends for those back-ends. We've yet to see the back-end bits fully >> working, although they are said to, but I am very dubious about their >> ability to generate rich, user-friendly front-ends, automatically (or >> semi-automatically). at some stage, things need to be customised to suit >> the particular database schema and workflow in use. >> >> Tim C >> >> _______________________________________________ >> Gpcg_talk mailing list >> [email protected] >> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >> >> __________ NOD32 2061 (20070214) Information __________ >> >> This message was checked by NOD32 antivirus system. >> http://www.eset.com >> >> >> >> _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
