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

Acknowledgements in HL7V2.x

HL7V2.x messaging standard indicates that Acknowledgements (ACK’s) are messages sent by a receiving system to the sending system in response to a transaction from the sending application. In a setup where HL7 is implemented the sending system will assume that the message sent by it is not received till it receives an ACK from the receiver. So in summary Acknowledgements are used to confirm the receipt of the message. Acknowledgements are implemented at two levels transport level and application level. In this post we will have a look at both the options.

Transport Level Acknowledgements: Sending systems open a connection to send messages to the receiving messages, mostly through the interface engine which act as broker for communications between different systems in a healthcare setup. If a message is acknowledged on the same connection which is used to send a message they are termed as transport level acknowledgements.

The connections can be transient or persistent in nature. Transient connections are those where the connections are closed after an acknowledgement is received. Each time a message is sent a new connection is made. Persistent connections are those where the connections are kept open and messages are sent over the same connection in a sequence, in sense sending a next message over the same connection after an acknowledgement is received for the previous sent message. Persistent connections are generally configurable where the connections can be closed after a certain period of inactivity. There are different factors which determine the choice of connection. The factors include message throughput, latency, sequencing, fail over, high availability and general infrastructure of the organisation.

Transport Level Acknowledgements also indicate that the ownership of the message is passed to the receiving system after it has received a acknowledgment. The transport level acknowledgement also informs the transport and reception error.

If a message is received and accepted by the receiver then it sends a ACK and performs one of the following

•Validates and persists the message successfully, generating the functional response message with a value of AA (Application Accept) in MSA-1-acknowledgment code field.

Or

•Send an error response, providing error information in functional segments to be included in the response message with a value of AE (Application Error) in MSA-1-acknowledgment code field.

Or

•Fail to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.). For most such problems it is likely that the receiving system will be able to accept the same message at a later time. The sending system must decide on an application-specific basis whether the message should be automatically sent again. The response message contains a value of AR (Application Reject) in MSA-1-acknowledgment code.

Application Level Acknowledgement: A sending system may require an application level acknowledgment from the receiving system if confirmation of successful processing is required. This can take the form of an HL7v2 ACK message (e.g. to indicate a successful processing of order it received) or a business response.

Generally the transport acknowledgment only confirms the receipt of messages but does not convey any confirmation of processing of the message. The need for these interfaces needs to be decided by the business processes. They are transmitted in the same way as any other message

In HL7 terminology the above two types of ACK's are termed as follows

•Original Mode Acknowledgement - a "Receive" ACK and majority of the ACKs used in HL7 communications; indicates that a message has been received but not necessarily processed yet

•Enhanced Mode Acknowledgement - an "Application" ACK that is a resultant status return rather than a communication response (i.e. query results, order response, etc.)