This is a highly
strategic decision for us to make. Our challenge is that much of our existing data is not "good"... where "good" is measured along the axes of patient safety, and interoperability, and computer-processability, etc. If we
relax our requirements for PS coding, then we may find we've preserved all the
not-good aspects of our present situation... and we run the risk of foregoing all the benefits that are motivating our projects in the first place.
Taking on the job of doing wholesale data cleaning (a "big bang" approach) would delay our time-to-benefit by years... and that assumes we could keep up the interest and energy for long enough to ever get benefits at all, which is unlikely IMHO. A "bootstrapping" approach, however, could be a potential way to associate little spoonfulls of bother with little spoonfulls of durable benefit. If every time a clinician wanted to share a PS, the relevant free text fields needed to be coded, then that effort would:
- create a coded PS for that one patient (immediate benefit accruing to both the originating clinician and the PS recipient)
- add to a local library of TEXT->CODE (or LOCAL_CODE->ENTERPRISE_CODE) content maps in the clinician's EMR (future benefit to be realized by the originating clinician in the next PS-generation process).
I appreciate these are implementation issues and not data engineering issues... but choosing an "implementation metaphor" (like bootstrapping, for example),
now, could usefully focus us on data model issues that do, or don't, preserve our value propositions.
My $0.02...
Derek