The simplest ehr is simply a series of text notes without any coding.
Just timestamped so old records can't be altered.
This is already better than paper records ( just have to learn to
touch type - but this is part of being a competent adult nowadays, let
alone being a competent professional ! )
When a user wants to do something with coding, then just put some mark
in the text that is recognisable and triggers some dropdown codes.
People with grey hair will remember the old Wordstar dot commands.
It is really elegant - dots normally go after a word - so if a dot
precedes a word, it means something special and can act as a trigger to
the software. Then some sort of dropdown will allow navigation to an
appropriate code, or a macro associated with a dot-word can pump out a
standard paragraph.
People who don't want to code will just keep making good clinical text
records. Which are still a great step forward in patient care.
( of course we still want text reports of investigations, and the text
of specialist reports to be coming in automatically)
Tim Churches wrote:
Richard Hosking wrote:
Tim Churches wrote:
I agree, but until there is an engine to play with, it is hard to tell
how many of the theoretical advantages of the openEHR approach will
carry over to the real world when used in real information systems. The
Australian trials of openEHR in Queensland relate to a shared community
EHR and thus only involve secondary data collection, not the initial
data capture or generation (as commonly occurs in GP information
systems), It will be interesting to see how openEHR translates to the
latter domain. I just wish they would bring out an open sourced engine
so that initial trials in GP settings could get underway.
I dont know whether any work has been done here - will GPs input data
into an archetype with very constrained fields and a complex tree
structure, or will they say bugger this and just go back to free text or
nothing at all?
Again, I think you have asked a very important question, Richard. I
agree that data entry screens, automatically generated from openEHR
archetypes and templates, containing lots of fields and pull-down lists
are not going to cut the mustard when you have a patient in front of you
and a dozen more in the waiting room. Hence my take that far more R&D
(not necessarily by openEHR) is needed into better data capture
interfaces, which can:
a) help make clinical narratives easier to enter, through keyboard
macros and mnemonics combined with "predictive texting" (like the T9
mode of text entry on your mobile phone), "smart" picklists using
Bayesian methods, better graphical interfaces - and I mean graphical,
not bunches of data entry fields on a screen - and even voice recognition;
b) convert (or help convert) that narrative text into computable form,
by identifying SNOMED CT concepts in the text AND capturing the
relationships between those concepts, or alternatively (and perhaps a
better approach), capturing the clinical narrative de novo as sets of
ConceptIDs and relationships between them, but hide that fact from the
clinician end user, who just sees human-readable narrative text;
c) storing those concepts and their complex relationships in an
efficient and future-proof fashion.
Now a) and b) above are out of scope for openEHR and similar
initiatives, but c) is not. However, it is unclear to me whether the
openEHR people have given the storage of decomposed narrative text much
thought. Perhaps the existing openEHR approach is adequate for this,
perhaps not. I suspect someone needs to suck it and see, but as I keep
saying ad nauseum, that's difficult given the current gap in the
available openEHR implementation tools.
It depends how widely openEHR is taken up and what form the social
infrastructure which faciltates the sharing and co-ordination of openEHR
Archetypes takes. A lot more work needs to be done (and not just by the
openEHR people) on the latter, elase it could end up as a big mess of
incompatible Archetypes.
Yeah, quoting Jon Udell quoting Rohit Khare (director of CommerceNet
Labs): "The ultimate integration challenge arises at layers 8 and 9 of
the OSI network stack: politics and economics."
Tim C
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
|
