Ensuring Clinical Safety - HL7 Implementation

The one thing that is missed quite often during deployment and rollout of HL7 (read HL7V2.x) is the “clinical safety” factor. It is not often considered if introducing the messaging is any way compromising the information quality of patient’s data or if it’s introducing any major business changes to the existing clinical workflow in the organisation. Organisations need to stress to the system providers as well as to the system integrators that they ought to consider clinical safety as a major factor in all stages of the rollout including development, deployment and testing.

There are ways to ensure that the introduction of HL7 does not compromise clinical safety. This post discusses a approach for this

Conformance Accreditor: The organisation needs to employ a system integrator or act itself as one (in case it has a internal tech team) to define conformance standards

Conformance Guidelines: The defining of conformance standards need to be based on the following principles

1. Define the message set that is required to be used within the organisation and publish it. The definitive message needs to be based on the requirements to automate and provide seamless data access, subject to access controls.

2. Avoiding optionality and being more specific when defining the messages

3. Identify the use cases and build story boards using every day scenarios of the organisation. Involve the organisations clinical and administrative team in this.

4. Publication of defined code set to be used in the messages

5. Define mapping guidelines to enable system providers to identify the correct data attributes

6. Provide sufficient guidance on message interactions for the messages that need to be sent and received by the systems for different events.

7. Define the expected systems behaviour while processing the message.

The publication of proper definition of code sets and values, message specifications and mapping guidelines ensures that data is not manipulated in a clinically unsafe fashion or mapped to the wrong code compromising patient safety.

(See this for a better understanding of conformance : http://secure.cihi.ca/cihiweb/en/downloads/hl7can_conformance.pdf)

Conformance Tools: Provide simple test harness tools adhering to the proposed conformance standards, for the system providers to check the correctness of their implementation- e.g. message structures, data types, expected code values. Provide ability to view data in the message in a GUI so that they do not have to traverse the message. These tools are expected to be provided by the system integrator

Conformance Testing: The clinical safety testing process involves exhaustive end to end testing to see if the data sent by the sending systems has not hindered the work flow in the receiving system. The testing to defined work flows in system where the data is received and used ensures that safety of the patients is not compromised

Defining Transition: The changes that are brought about by implementing HL7 in an organisation needs to be formally documented. The capabilities and workflows in the organisation that are impacted by the implementation needs to be compared and ensure that the users are aware of the changes through training.

Standards - Case and Types

The purpose of the post is to reinforce the need for standards and help classify standards

Case for Standards

The idea that Healthcare continuum (using information systems) extends not just across the departments in a healthcare enterprise, but across healthcare enterprises in different care settings (necessitating information exchange) has accelerated the adoption of standards. The other fact that the best of breed systems for different departments are now the preferred option to a single monolithic system for a single enterprise (requiring information and data exchange within the organisation to function as single entity) has again brought the notion of standards to the forefront. Even for organisations which have single enterprise wide system, healthcare standards are relevant as they need to standardise the entry and capture of healthcare data.

In summary standards are needed for representing and exchanging information to

• Not compromise the safety of patients by preventing exchange of incorrect, insufficient and not understandable information , e.g. allergies , adverse reactions
• Provide access to data for patients from different providers in uniform fashion
• Allow aggregation of data for performance measurements and monitoring
• Provide access in disparate systems for a longitudinal view of the patients medical history
• Lower IT support costs by reducing need for data cleansing and data quality

Types of Standards

In general the implementation of standards fall in the following areas of categories

Voluntary Standards: These standards are usually developed in voluntary consensus by industry bodies or market groups associated with the industry. As these standards are developed by industry or someone associated with industry the standards are usually well regarded. The voluntary nature of standards will allow the implementers of standards to innovate on the base standards.

However the voluntary natures of standards ensure no enforcement mechanism, ambiguous interpretation and absence of mechanism for conflict resolution.

E.g. HL7V2.x standards developed by HL7 Inc which is a voluntary organisation

Regulatory Standards: These standards are usually legally binding contracts, laws or authority enforced regulations. Everyone must adhere to these standards and non-compliance is recognisable. There usually will be regulatory who ensure the compliance and assess the compliance.

However the regulatory standards encourage no innovation and sometimes do not cover all possible situations. Any conflicts on interpretation lead to long legal wrangles and the need for compliance assessment and inspection leads to large regulatory inspection teams

E.g. Usage of READ standards in UK NHS primary health care

Implementation and Conceptual Standards: Implementation standards are those have are dominant and wide usage and reinforce existing patterns. Conceptual standards are those which are developed to bring in new ways of thinking and working in the industry

E.g. Usage of XML, SOAP-WS

Product Standards: There are some standards which prescribe and recommend products or services. This can lead to better design of existing products and services or future products and services. This lead to a consistent and uniform feel to users of different products across the industry.

E.g. standards recommending common CUI (Clinical user interface)

Process Standards: A process is usually defined as a series of activities and logic that form a repeatable pattern. Process standards are those that focus on bringing efficiencies to the industry by developing repeatable processes.

E.g. Standard pathways for treating patients based on NICE guidelines

PS: Thanks to a friend who kept asking me for my next blog post and helping me revive my interest