Ian could be right ; an example is md and gnumed. md has a progress notes central ehr, but with "special"
parts of the notes in immunizations , antenatal care, pap smears , gp management plans / care plans, that
are specifically backended by tables with fields for those particular areas. Even the canadian OSCAR web based emr had specific tables for different counties within canada, for particular clinics, and had customizations for
use in brazil ; the openmed corba based open source demonstration ehr was specifically designed for bioterrorism
detection, although it uses a generic observation model from corbamed, it 's user interface was not usable for
gp office medicine ; gnumed's primary developer had a conceptual basis for his gp focused ehr system, some
european (?belgium) academic general practice work on how to organize encounters and health issues (aka as current medical problems), and has the ubiquitous well-known SOAP organization integrated into the
data clinical recording.
It is possible to make something like md notes import into gnumed , because md also
pays optional lip service to SOAP categorization within progress notes , through different entry labelling with
history, examination, diagnosis, management shortcuts.
Other more commercial oriented open source emr systems like openehr look like billing and appointment systems, with a simple extension "date , notes" tacked on for the clinical system.
One question might be, can model instances be made in something like openehr out of some of the less simplistic schemas such as md's, gnumeds, corbamed , so that then the guis are all indirectly backending the same openehr backend ? Ian might be asserting that this would be dubiously possible.
On Thu Feb 15 12:04 , "Andrew N. Shrosbree" <[EMAIL PROTECTED]> sent:
Ian,
Your suggestion that a GUI be closely wedded to the EHR makes me shiver. How about a design-pattern approach of having a decoupled program layer that interacts with the data?
This layer can be accessible by an (independent) GUI layer.
I agree with your need for a common set of fields. How about a library of abstract classes to match your data?
Andrew
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. 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.Ian _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
--
Andrew N. Shrosbree B.Sc, B.Ec
Technical Architect
ArgusConnect Pty Ltd
http://www.argusconnect.com.au Mob: +61 (0)415 645 291 Skype: andrewshroz
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
