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; Tim, I noticed you and several others are using SNOMED as an abbreviation for a "clinical coding system". Sure it's a very good system, but it's also rather expensive. It's important to differentiate the use-cases for coding clinical data. At individual patient and GP level they're pretty limited: some basic decision-support around drug-disease warnings, possibly linking to guidelines. It seems (please correct me if I'm wrong) this can be done perfectly well, or rather, well-enough, with simple keywords (i.e. using English as your coding system) It doesn't seem fair to make GPs buy SNOMED when they aren't the main beneficaries.
There's no reason why the data collectors can't be the ones writing cheques to the US pathologists and develop a mapping to the keywords already in the database. We should, at the very least, keep an EHR coding-system-agnostic, so GPs can buy SNOMED, DOCLE or whatever (or have it bought for them) if, and only if, they need it. Of course the government should buy a nationwide licence, but, like OpenEHR kernels. it's unwise to rely on that happening. Ian _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
