"You seem to do a lot of work with various diagnosis classification methodologies. I wonder whether you have done any research on the quality of the underlying data?"
I'm always very, very careful about using the word "research" because in my world, this requires mathematical precision in the acquisition of knowledge.
However, my experience tells me, that the design of the information flow is much more important than the choice of classification system. You need to design the information flow well, first, and then pick suitable classification systems. We have run into several limits of the SKS system (ICD10+extensions), for instance, an easy way to register various levels of CIPN in order to differentiate the patients in statistics. Also, it usually takes more than a month to get a new code introduced in the SKS system, so we often introduce new codes into our system that do not have an SKS mapping yet, and then map to SKS later when they catch up.
The data quality is best, when you know the registration context, and when the registration context supports mechanisms that ensure that everything gets registered, and mechanisms that ensure that nothing gets registrered against the operationalized registration criteria. We do both, of course, in combination with various technicalities that motivate the user to do their best, and various mechanisms to ensure feedback on bad data quality.
Other IT systems here are not focusing in the same way on data quality - most of them are basically similar to Epic/Cerner/Siemens etc., i.e. traditional horizontal EHR systems. The data quality in those systems is ensured by management, not by IT, and data quality typically deteriorates for each integration bridge that the data needs to cross. However, from what I hear from the clinicians in other departments about the use of ICD-10 in SKS, is that it is not detailed enough, and the lack of details affects data quality in a bad direction. |
