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
