Yep, my use
case is a little hazy - maybe it might be better to start talking about
data collection for some project or allowing extensions to software by
clinicians for special purposes without having to go back to the vendor.
It will be a while before there are a lot of openEHR systems out there,
though it is possible to imagine hybrid systems starting to emerge with
a openEHR repository between the older system and the outside world
rather than rebuild from scratch. This is a likely way forward for
vendors to implement these things rather than rebuilding from scratch.
Tim Churches wrote:
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
__________ NOD32 2062 (20070215) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
|
