Clinical Software Certification – What’s Practical, Necessary and What Makes Sense?

In the last few months there has been some correspondence in the Medical Journal of Australia and elsewhere on the topic of the safety of clinical software and the possible need for certification of such software.

In this commentary I want to consider this suggestion from a range of perspectives including practicality, barriers to implementation, likely impact on quality of care and so on. I would also like to point out that from my perspective, while I believe it is vital, certification of clinical software is likely to prove clinically challenging, technically complex as well as commercially contentious.

Before going any further it is important to say that I recognise the inherent difficulty and complexity of the topic and need to take a perspective that ignores the system user – recognising the unreality of pretending areas such as user skill, attention, competence and experience are not important in the overall outcome. What I seek to achieve here is to try and identify the different components of an approach that may address the issues around having the practitioner be confident that the system they are using is providing the best possible aid and support for their care delivery.

What attributes are needed for the purchaser and user to be sure this to be so?

I would suggest the following are important.

1. Data Model

The target system needs to have a sufficiently rich data model to support both the usual data capture required in a clinical EHR system as well as the detailed – and hopefully structured information required for automated decision support. This means that at the very least crucial laboratory results (e.g Haemoglobin, Creatinine etc) will be captured in atomic form.

Clearly there is also the need to address coding / terminology in appropriate areas (e.g. diagnoses, medications etc) to ensure useful values are held and are computable to support clinical decision making.

2. Functionality

The functionality of the EHR system that is required for quality care delivery has been the subject of much work over the years and is quite well understood. The requirements contained in the General Practice Computing Report in Australia and the HL7 and CCHIT specifications for the US provide quite reasonable guidance in this area.

Clearly the full scope of these requirements including clinical decision support and clinical pathway management and tracking are required.

3. Knowledge Database(s)

While vital, here we arrive at a major difficulty. This is at least one area where the quality, scope and depth of what is required is likely to prove less than straight-forward to define.

4. Interoperability

As attractive as ‘vendor lock in’ may or may not be to commercial software providers it is anathema to software customers and users. For this reason all information stored in the EHR should be exportable in a standard – and preferably standardised form to any certified competing product.

5. A Commercial Future

With use over time the value of the information held in a clinical system becomes progressively larger. The purchaser / selector of a system, which will be expected to be operational for ten years or longer, needs to be confident of the commercial viability of the software provider in terms of maintenance, updates, recurrent costs and so on.

6. Messaging and Communications Capability

Systems these days do not live in a vacuum and they need to be able to securely transmit and receive both clinical and administrative information in a seamless and standardised fashion.

7. Usability

It is important any systems should be engineered to be both easy to use and also to be designed using the principles applied to aircraft-cockpit design where the important information cannot be overlooked easily or without warning.

It should be noted that while the emphasis in this article has been on ambulatory systems all the forgoing is just as relevant to the hospital and other larger provider sectors.

The next issue is how is assurance obtained that these attributes are indeed present and are of the quality etc required.

Given the current political situation it seems to me that what is required is a CCHIT (Certification Commission for Healthcare Information Technology in the USA) like organisation, funded by, but at arms length from, Government that can work with users and all the other stakeholders to develop the requirements and criteria in each of these areas and then offer incremental and reasonably in-expensive paths to certification.

The CCHIT approach of developing roadmaps of requirements and capabilities to be delivered over a known time-frame I see as remarkably sensible and pragmatic and well worth adoption.

Clearly the Australian CCHIT would need to work collaboratively with both system developers, academia, clinicians and standards bodies to develop and then assess systems against the agreed criteria. This said it would also be important to have very professional leadership of the commission in place to ensure there is no easy route for less than high quality systems to be certified. A half baked process would be far worse than no process at all.

My guess this would be of the order of a five year project to get where we need to be with initial certifications possible in two to three years.

To not go down this path will leave individual purchasers and vendors possibly, indeed almost inevitably, liable for possible errors of omission or commission. The Government must really act to provide appropriate coverage for all those in the E-Health sector.

The other step I believe is required is that there be financial incentives for the clinical users to both install and then use the advanced systems as we know from the study reported yesterday that it is only the actual use of capable quality systems that makes a real quality and safety difference.

The business case for the Commonwealth to do this in the Ambulatory Sector I am sure would be totally compelling!

David.