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
