SNOMED, complex hospitals and knowledge engineering

This post is following on from my post yesterday and the subsequent meeting with the team in my hospital cluster looking at SNOMED deployment into our hospitals. We have a complex (but not unusual) information system environment with a “best of breed system” approach.

There were a number of short-term challenges and opportunities identified, some of which I’d put under a software engineering (SE) and some under a knowledge engineering (KE) umbrella:

1. deploying and integrating user interfaces that allow capture of high quality coded information into our existing systems [SE]
2. formulating (or better still selecting from an available standard) a coherent information model that allows free text to coexist with coded data in an ongoing manner and allow some of the free text to be gradually encoded using a mixture of automated and human interventions [SE]
3. parsing of free text to extract codes automatically where this is possible simply (and often it is possible simply) using off-the-shelf algorithms and lexical indexes [KE]
4. automated generation of SNOMED codes from structured data fields in existing system [KE] using structured rules expressed potentially quite a few different ways:
• within the source system programming language (urg),
• sql (apparently quite a few of our system live in SQL server)
• GELLO (or something like GELLO)
• using whatever interface macro language is close
5. dealing with the need for coding system management [KE] at a local level to allow ongoing management of:
• subsets for specific purposes
• mappings between codes from different systems
• other semantic relations
• version control and tracking
• “off-the-shelf” and locally derived free text indexing
• publication of “export formats” to drop into our third party systems.

We talked yesterday about the some fancy off the shelf products for doing the coding system management, but, to be honest, I reckon – to start with at least – the best thing would be to simply start off in the old familiar desk-top relational database. We don’t even know what the business rules are yet, yet alone if some off the shelf system will support them.

I’ve deliberately flagged what I’d call the KE (knowledge engineering) aspects of all of this because they raise some special issues. They all involve manipulation of complex information expressing expert clinical knowledge. This means that all the KE activities need to support:

• initial expert involvement in knowledge expression or capture
• ongoing peer-review,
• interdisciplinary negotiation

The nature of modern clinical care is that the modern doctor only holds a small fraction of medical knowledge in their head. That means that in order for a hospital knowledge engineering system to be robust it must allow the involvement of not just a selected handful of specialists who are “informatics friendly” but the process must be transparent to a large gaggle of doctors from a diverse set of backgrounds with diverse aptitudes.

To complicate matters further these experts are expensive, impatient and busy. So the knowledge engineering process needs to present them with filtered content highlighting what is new and highlighting what is relevant to their domain. The system then needs to capture their expert involvement to allow ongoing system verification and maintenance.

Don’t panic, we can do this. But not if we set off thinking it will be easy.