AIDC: Future of Electronic Health Records

Key Blocker in usage of EHR's

Clinicians are always under pressure, in any given visit be it as a part of an outpatient clinic visit or a bed side round. They are expected to make eye contact, listen empathetically, process nonverbal cues, keep lab tests, allergies, and medication lists in mind, and formulate differential diagnoses. The same clinician is also required to document clinical notes granularly enough to support clinical coding and enter data in a structured way to comply with data quality and regulatory requirements.

With widespread usage of EHR's it has become common to see clinicians and other allied professionals staying after hours to do just data entry into EHR's to comply with mandated data entry. This is reducing physicians and other providers into data entry clerks and is detracting them from being productive to provide quality care. This ended up making data entry as the largest potential obstacle to the effective use of EHR within clinical settings. Physicians at Yale and the University of California recently argued that EHRs are becoming detrimental to the care of patients as physicians spend twice as much time in front of a computer compared to face time with a patient.

However there are other multiple studies which proved that real time entry of patient data will make the current data available to clinicians and help them target the right patients to provide care. But real time entry of data adds additional burden to the clinicians taking their valuable and critical time away from providing care to patients and often leading to missing and erroneous data impacting patient outcomes and creating administrative overheads.

Current Status

Currently there are some tools and work arounds within clinical settings to lessen the burden of data entry.

Intuitive User Interface: Clinicians have been complaining about quality of the interface they were forced to use since the inception of EHR's. The user interfaces were often found to be not intuitive and required countless keystrokes and they found it difficult to align their work process with what was needed to be entered into the EHR.  Even today the best of the EHR's in the market have sloppy user interfaces, but vendors are making effort to create user interfaces by designing based on human behaviour principles and by working, observing and consulting with end users.  The intuitive user interfaces need to be accompanied by proper education, training and support to aid in easier use of EHR by users.  

EHRs with intuitive user interfaces aggregate information pertinent to the problem at hand and are designed using data visualization techniques for optimal display. But intuitive user interfaces has its own limitations in terms of space on screen, expectations of varied users and affordability and human senses.

Digital Dictation: To reduce clinician’s workload related to data entry in EHR’s lot of organisations use digital dictation tools with voice-to-text capability to speed up data entry. EHR providers are increasingly incorporating and integrating voice-recognition software into their products to allow clinicians to directly narrate into the system. There is an overhead of narrated notes need to be reviewed for accuracy and then approved, but clinicians are found approving their entries without reviewing them. This increases the risk of inaccurate data and mistakes. The art of converting narrative into structured data and incorporating semantic workflow to support the narrative is quite complex.

Natural Language Processing: Natural language processing (NLP) is increasingly considered as a viable technical solution for improving clinical outcomes and simplifying data entry. NLP deciphers doctors’ notes and other unstructured information generated during patient visit into structured, standardized formats. However NLP suffers from the similar issues as digital dictation and text is often ungrammatical, consists of “bullet point” telegraphic phrases with no semantic context.

What the future holds?

Internet of Things (IoT) is a concept that basically connects any device with an on and off switch to the Internet. IoT’s offer Automatic identification and data capture (AIDC) technologies, AIDC refers to the process of automatically identifying and collecting information about patients and logging this information in an application such as EHR.  AIDC refers to a range of different types of data capture devices such as barcodes, biometrics, RFID (Radio Frequency Identification), magnetic stripes, smart cards, OCR (Optical Character Recognition) and sensors.

What AIDC can do for EHR's is briefly discussed below.

Digitising Written Notes: Many clinicians are still more comfortable working with paper and asking them to enter data electronically can lead to resistance against an EHR implementation. Automated document and data capture technology can be leveraged to enable doctors to continue to utilize paper encounter forms with a new EHR system. AIDC allows setting up bar codes (2-D or 3-D) automatically and assign them to patient’s record by scanning and digitizing their back files and integrating them with the EHR system to have a single view of an entire patient history. OCR/ICR technology is typically incorporated in document and data capture software applications that also have features like image processing for improving the quality of scanned documents; forms recognition, to identify the type of form being scanned; and forms processing, which enables the software to identify and capture specific pieces of data.

Improving Efficiency: One of the most important aspects of AIDC is to improve efficiency of an organisation by assisting in equipment tracking, inventory management and patient tracking. This is done using solutions involving RFID and mobile scanners which will help organisation track assets, providing real-time information about assets (drugs and consumables) ensuring hospitals have what they need, where they need it, when they need it.

One of the good examples of improving efficiency using AIDC technologies apart from the usual inventory management and equipment tracking  is  bed management where bed occupancy sensors provides an early warning by alerting that the user has left their bed and not returned within a pre-set time period, indicating a possible fall. These sensors can also be programmed to switch on lights, helping as digital signage devices.

Managing Patient Care: To provide better patient care, clinicians need access to medical equipment and access clinical data which is increasingly being collected using mobile devices and other wearable technologies. Mobile devices and wearable sensors are a part of IoT solutions and they allow clinicians to gain access to the information in real-time to improve patient experiences and outcomes. The wearables and other wireless devices and sensors allow monitoring patient temperature, Parkinson’s disease, post-surgery awakening, etc. These applications require asset tagging and patient tracking. The proliferation of IoT devices allow data being automatically collected and fed into EHR systems with vendors of IoT devices proving  interfaces to integrate them with EHR's thereby helping organizations gather more data and deliver better care.

How widespread is usage of AIDC?

Automatic identification & data capture (AIDC) technology in healthcare has greatly promoted the error-free data collection and improved patient safety. It is helping reduce medication errors and related healthcare expenditure. Growing focus on patient safety, technological revolution, and rising government legislations on the use of barcode & RFID technology are further expected to boost the growth of the global healthcare automatic identification & data capture (AIDC) market.

Automatic Identification & Data capture (AIDC) market within healthcare industry is mainly segmented into clinical and non-clinical applications. The non-clinical application segment holds the largest share, owing to the higher adoption of barcode & RFID technology in the non-clinical applications such as supply chain management and medical staff & asset tracking, though the clinical application segment is also growing fast. Global Healthcare Automatic Identification & Data Capture (AIDC) Market is expected to reach USD 3,122.7 million by 2022 supported by a CAGR of 15.4% during the forecast period of 2017 to 2022.

Use Cases within NHS

The Wythenshawe Hospital used a traditional paper-based process to manually enter patient information into patient records. This process is known to be less reliable than automated entry and can cause major health concerns for patients as a result of the opportunity for human error. For the medical facility, error that leads to the injury or even death of a patient opens the door for major legal complications. The Wythenshawe Hospital staff also found the process to be time-consuming, as doctors and nurses had to take time away from patients to enter data, recall patient records or refill prescriptions manually.

Wythenshawe Hospital decided to implement a system based on bar codes and bar code scanning devices to support staff in scanning codes on patient records. By automating this activity, the staff is able to automatically retrieve a patient’s Electronic Medical Record (EMR).

Ref: http://www.datalogic.com/eng/media-center/success-stories/automatic-data-entry-replaces-paper-based-patient-record-system-for-better-patient-care-csd-792.html

Six trusts which include Salisbury NHS Foundation Trust, Plymouth Hospital NHS Trust and Leeds Teaching Hospital have been selected as a part of Scan4Safety project which used barcoding to better identify and match patients, products and locations.  Across the six demonstrator sites, early signs of benefits are extremely encouraging, with over £700,000 of savings already being identified:

-          Stock reduction/one off stock holiday – £233,000

-          Reduction in wastage/obsolescence – £462,000

-          Non-clinical pay efficiencies – £46,000

Based on these initial findings, it is estimated that for a typical NHS Hospital trust, the benefits could be:

-          Time release to patient care – equivalent to 16 band 5 nurses per trusts, that’s 2,400 band 5 nurses across the NHS.

-          A reduction of inventory averaging £1.5 million per trust, £216 million across the NHS.

-          Ongoing operational efficiencies of £2.4 million per trust annually, that’s £365 million across the NHS.

Ref: https://www.scan4safety.nhs.uk/benefits/

What are the challenges with AIDC?

·         AIDC devices and technologies interfaces with EHR are not ‘plug-and-play’. The devices will need some kind of interface to be installed that will translate the measurement data from the device into a format that the EHR database can understand and use

·         AIDC devices provide high volume of data which is required to be captured and processed at high speed

·         Unlike manual data capture the data coming from AIDC devices need to be categorised into wanted and unwanted data categories

Standards for AIDC

·         ISO/IEC standards such 16022 Data Matrix and 18004 QR Code

·         ISO/IEC 29161 Unique Identification for IoT

·         ISO 17367 Supply chain applications of RFID – Product tagging

·         ISO/IEC WD 30101 Sensor Network and its Interfaces for Smart Grid System

·         GS1 Global Specifications, www.gs1.com

·         HIBC Health Industry Bar Code, www.hibc.de

·

Are “Personal Health Records” value for money?

What exactly is a Personal Health Record?

There is a big trend towards providing access to health and care records for Citizens and patients within the NHS, both locally and nationally. Majority of the STP’s have within their Local Digital Roadmaps mentioned that they would like to provide some sort of patient access to their records. Their best of intentions for such a move is to let the patients and citizens benefit from it.

There is a very subtle difference between Personal Health Record and Patient Portals. A lot of organizations here and across the pond use the term interchangeably, especially if the Personal Health Record is provided by an organization based on the data they hold for the patient.

The definition’s for Person Health Record as stated by
Royal College of Physicians is “...a digital tool that helps people to maintain their health and manage their care. It may do this by enabling them to capture their own health and care data, to communicate with health and care services, and/or to have access to their care record.’  and by

HealthIT.gov is “A personal health record (PHR) is an electronic application used by patients to maintain and manage their health information in a private, secure, and confidential environment.”

What are the Challenges with these Patient Portals, err…?I mean Personal Health Records?

I would concentrate on the challenges as the vendors do a very good job of selling them with the advantages anyway by touting them as a way to spur better patient engagement and set the stage for improved outcomes.

Privileged Users: Personal Health Record’s often aren't used at all by the very people who may need them most. The characteristics of the neediest are from ethnic and minority communities or those with lower median household incomes or from the older generation who may be not that Tech Savvy or can’t afford the digital tools to access the records.

Lack of Studies: There are some and if not many studies done to understand if patient portals (using it interchangeably for personal health records) if they actual provide any visible benefit. The few studies I have seen notably https://www.ncbi.nlm.nih.gov/pubmed/25733435 and http://bmjopen.bmj.com/content/4/9/e006021 suggest that there is no definitive evidence of improvements in health outcomes. I have not come across a clear benefits qualitative study of PHR (that's one for the swear jar), maybe because PHR simply does not provide qualitative benefits.

Misuse: There is a real risk that patients might misuse a patient portal for emergency situations and use the portal to request emergency care and the requests may not be taken seriously. There is also a danger that patients may contact clinicians through the portal and inappropriately send repeated messages, overwhelming clinic staff. Further, there is a worry that certain types of patients may expect immediate responses to their repeated electronic requests/communications.

Security and Information Governance: Security and Information Governance concerns around the access to patient’s portals are the biggest inhibitors to adoption of patient portals. Even if the vendors have provided the best security features around the portal platform, citizens and patient would be accessing it using unsecure devices at home leaving a way for unwanted sources find a way to get into the portal. Another aspect of Personal Health Records is it would allow citizens and patient to enter their own data through the portal and there is a risk they may put inaccurate data into the record, and the health organisations will be liable for mistakes carried out based on incorrect data. Also the whole process of confirming the identity of patient before allowing them to access the patient portal is a huge overhead for clinical organisations. 

Incentive: Patient Portals do not properly incentivize the patient either intellectually (providing enough data to prove useful) or financially. (Both in time and/or value)  Patients who are generally healthy have real lives and aren’t interested in fixating on accessing their data daily or letting their friends know of their “health status” through a post or photo.

Financial Viability:  Organisations who provide portals will find it is financially not viable to create a platform if not many patients and citizens use it. For example, Mayo Clinic found out that only 5% of all the patients who registered with their patient portal actually use it.

False Power: There was evidence that patients who access to health records regularly feel that they are in control of their health and would ignore warnings about their real health.

Interpretation: Patient Portals present the information from their tethered EHR's which contain clinical jargon. The patients would not fully understand the information present in the portal, triggering more phone calls and questions. Lab results could be particularly troublesome because clinically insignificant abnormal results are common and it may cause unwarranted worries to patients.

Interoperability: Patient’s expect portals to provide a way of exporting their data to their personal site/repository that they can then control (e.g., Google Health, HealthVault or other PHR) leading to extra communication channels into patient portals causing more worries. There are no standards defined to provide automated export or defined data set for such a capability.

Multiple Portals: Right now there is a multitude of personal health records within NHS, provided by primary care providers , acute/tertiary provider portals, IDCR portals, STP led portals and even national portals. This is causing huge confusion to patients about the number of avenues of clinical data access for them.

No Universal Definition: There are no clear and consistent policies in place today within NHS as to what a healthcare organization is obligated to provide a patient access to through these portals.

So what is the Minimum Viable Product for Patient Portals?

• Concentrate on providing transactional services such as online appointment scheduling, filling in repeat Prescriptions and communicating with clinicians for pre-booked remote consultations rather than using it provide access to their detailed data.
• Greater attention is needed to understand why vulnerable populations do not access it and provide incentives for them to access it. Concrete policies need to be in place to overcome racial, ethnic, and literacy barriers to portal use
• Present clinical data in a simple fashion and avoid clinical jargon, provide patient portals through primary care providers and encourage them to use Patient Online and have access to summary care record which should be enough for patients and citizens.
• Have a single point of access to all the patient portals with Federated access so that citizens and patient don’t need to  remember lots of passwords

Relevance of PEPPOL in post-brexit world

NHS eProcurement strategy published in April 2014 sought to  establish the global GS1 coding and PEPPOL messaging standards throughout the healthcare sector and its supporting supply chains.

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/344574/NHS_eProcurement_Strategy.pdf

What is GS1 ?

GS1 is the international not-for-profit organisation behind the only global system for bar coding, and for standardised identification of products, assets, services, places and organizations.

To start off NHS wants to implement GS1 for for person identification (using bar coded wristbands) product coding (using manufacturers barcodes on products), location coding (by allowing trusts to define their locations as per agreed format)and data synchronisation. This linking of patient, product and location initially will create improvements for traceability in Patient's pathway. They can identify where they’ve been, who treated them, what products were used, which products were implanted, which equipment they used, the drugs they took, where they were located

In future it is planned to use GS1 barcodes for  events medical records and equipment as well for end to end traceability using standard well defined coding mechanism.

https://www.gs1uk.org/our-industries/healthcare

What is PEPPOL ?

PEPPOL stands for Pan-European Public Procurement Online and was designed to solve interoperability issues for electronic procurement

To start off NHS want to implement PEPPOL for eOrdering, eInvoicing, electronic Credit Notes and Advance Shipping Notifications. PEPPOL implementation would modify the traditional way of each trust needing an individual EDI connection to each of their suppliers, large and small. But PEPPOL through a nationally established infrastrucure will allow a trust to have one single eProcurement link to the outside world, via which they can trade with current future suppliers, large and small, in the UK as well as internationally. A supplier also needs only one connection to PEPPOL, in order to reach not only all NHS customers, but also all other PEPPOL-connected trading partners at home and abroad.

http://www.peppol.eu/

Where are we now ?


DH has provided central funding in order to develop GS1 standards within 6 acute trusts which are to act as demonstrator sites for the remainder of the NHS. The demonstrator sites have 2 years starting January 2016 to roll out the GS1 and PEPPOL standards.


http://www.nationalhealthexecutive.com/News/six-gs1-and-peppol-demonstrator-sites-chosen

Relevance of PEPPOL in Post-Brexit world

PEPPOL has no dependency on being in EU or not. PEPPOL standardizes the way suppliers and organisational buyers interact with each other. PEPPOL through locally provided infrastructure will enable e-trading driving down costs and suppliers, who trade across Europe.The average costs associated with processing a single order through to invoice at NHS trusts range from £5 to £7. Business cases produced by demonstrator sites are expected to demonstrate that that cost can be reduced to around £1.

The country which uses PEPPOL most widely is Norway which is not even in EU. The Norwegian public sector has chosen to communicate through the PEPPOL network and in 2015, approximately 21 million electronic invoices were exchanged via PEPPOL Norway bringing decent savings and improved traceability of public expenses.

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

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.)

ICP's and EHR

An ICP determines locally agreed, multidisciplinary practice based on guidelines and evidence where available, for a specific patient/client group. It forms all or part of the clinical record, documents the care given and facilitates the evaluation of outcomes for continuous quality improvement".

National Pathway Association (1998)

ICP’s have their origin in providing coordinated care to patients by different specialist teams within a healthcare organisation. Each team records their interventions on a patient for a specific health condition in the organisation’s Electronic Patient Record (EPR) system and other teams intervene accordingly based on the notes provided. This paved the way to define electronic ICP’s (e-ICP) in EPR systems.

The advent of Electronic Health Records (EHR) brought the possibility of extending ICP’s across multiple healthcare organisations from different care settings. EHR's facilitate flow of information across different care setting boundaries even to agencies outside healthcare (e.g. social care) who are involved in the care of a patient.

Benefits of Electronic Care Pathways over EHR's:

• Allows care pathways to be built around patients and not institutions by providing real time recording and allowing different organisations involved in the patient care to have the same view
• e-ICP’s provide quick access to information(instead of browsing though bundles of paper for which each organisation has different format and different recording styles) and provide multiple views – high level summary view from different organisations as well as detailed view of each organisation in a chronological fashion
• e-ICP’s allow faster remodelling and review of business processes to suite each patient

However the difficulties in deploying e-ICPS’ through EHR is not a technological one but cultural and business one involving the need for agreeing common data formats and sharing the data owned by an organisation across different care settings and agencies.

EMR from Prespective of Pharma

Pharma companies have started working with clinical service providers and started using EMR's from two prespectives

• Data and Study Setup


• Secondary Users Service

Data and Study Setup

Data and Study setup can be incorporated in a EMR to exploit the following features

• Implement screening parameters into core EMR to identify prospective patients for pharma trials at point of care
• Setup data capture from trials as part of clinical care and clinical documentation workflow
• Populate data in care report forms automatically from EMR
• Embed care record forms as tabs in core EMR so data is collected and stored against patient record
• Implement clinical rules and alerts for compliance and range checks for data and structured documentation checks

Secondary Users Service

It can be used for the following

• Easier data extraction from EMR for proper reporting on adverse events
• Unified reporting of current and historical data
• Findings can be published as standard clinical documentation
• Monitor outcomes based on ICP’s and evidence based decision support

Example Implementations

Pfizer – Drug Safety -Supporting Physician Reporting of Adverse Reactions and Public Health Threats

NOVARTIS – Clinical Trial: Lab and Image Data - Innovating Clinical Data Capture for Labs and Images using EMR lab ordering and results reporting using HL7

Eli Lilly – Patient Visit Workflow – Streamlining the patient workflow using standard Inpatient and Outpatient workflows

genzyme – Disease Registry – Profiling diseases geographically and using other statistical profiling such as gender , age etc

SAIC – Biosurveillance -Standardizing and Facilitating Data Collection for Enhanced Biosurveillance

Ramblings about Electronic Patient Record

This post is a set of ramblings which may sound a bit incoherent but needed to be grouped together to give an overview about some of the things that needed to considered about Electronic Patient record/Electronic Medical record.

Mandatory Pre-Requisite

In my view a mandatory pre-requisite for meeting the many objectives of Electronic Patient Record (EPR) is the ability of that application to support semantic interoperability of clinical information. What I mean by that is the Entry, storage and communication of clinical information by the application in ways that allow it to be consistently reused, retrieved and processed by it and its ability to communicate that information to different software applications. However maintaining Semantic Operability is not so easy due to various issues

• Technical issues
– Different information models
– Different clinical terminologies
– Different interfaces between information models and terminologies
• Practical issues
– Different perspectives on similar information
– Different motivations for data entry
– Different methods of data entry
– Different expectations about the use of information

Barriers

From my practical experience, implementation/deployment of EPR is not very easy; there are lots of barriers in implementing EPR. I jotted down a few of the barriers which needed to bottomed down in the business plan before deciding to implement EPR.

• Financial and Capital costs associated with the EPR applications

• Adoption of the systems mainly by clinicians and to some extent by auxiliary clinicians. Most organizations underestimate the training required for their staff to adopt the new system but also fail to convince them.

• Defining technology and information standards and adhering to them. I know in some cases it becomes expensive to adhere to them but if you start compromising then there will be no end to it.

•In some cases if the organization already has a legacy system the transition phase adds work to an already overburdened IT staff.

•Of course the now famous Information Governance issues covering security, privacy and consent to access the electronic records.

• In some cases the failure to define clear and tangible benefits also becomes a barrier

Standards

EMR’s and almost any other information-oriented system in a clinical environment cannot be used without well-defined standards for representing and communicating information. Data need to be exchanged between multiple, heterogeneous systems and might be used by very different applications .The following points highlight the need for standards

• Unavailable standardized communication results in health hazards, e.g. drug hypersensitivity
• Patients are starting to demand that ”their” data should be available online
• Improve efficiency by enabling professional cooperation in new ways
• Quality management requires aggregated data
• Standards allow integration of modular systems from different suppliers
• Many standards issues require professionals and authorities not just industry
• Standards can lower costs of ICT support by expanding the market

Failure Reasons

The failure of certain organisations in implementing Electronic Patient Record in my view is the failure to understand basic standardisation approaches in healthcare organisations. There are two standardisation approaches in theory

• External standardisation
– Strategic planning tool
– Market reassurance
– Consensus approach
• Internal standardisation
– Strategic enhancement of the use of internal resources
– Change management is essential
– Class discussion: regulatory and laissez-faire approaches to internal standardisation

Implementing EPR at a single organisation of multiple organisations read hospitals is essentially setting an internal standard for information processes related to patient information
– Regulatory approach: set the standard way for all possible situations involving production of patient information
– Laissez-faire approach: describe all accepted standard procedures and allow hospital staff to choose which standards to use or invent their own procedures, if necessary

Just wished they had known which approach to use.

The Transit Electronic Health Record

Electronic Health Record is normally seen as repository of aggregate clinical and demographic information fed by point of source systems from different care settings. But the infrastructures associated with the EHR are being used to perform other ancillary functions such as facilitating the data exchange between the different point of the source systems. A classic example is the exchange of patient data between two systems through a project called GP2GP as a part of the UK CFH-Connecting for Health initiative.

The objective of GP2GP record transfer mechanism is to support the exchange of a GP’s (General Practitioner who is the patient primary care service provider in the context of UK) patient record electronically to a new practice when a patient registers with a new GP. In England an estimated 10% of patients change their practice each year and if the average list size of a practice is 1500 then there will be average of 150 transfers each year per practice. Most practices handle this transfer using the standard Lloyd George envelope or Medical Record envelope method for the transfer of the patient’s past care paper record.

The most common process of transfer of the electronic component of the patient record using Lloyd George envelope method is to produce a printout of the content of the medical record and to put it in the Lloyd George MRE at de-registration. Factually few doctors study such printouts and fewer practices re-enter any salient information and this information is unavailable to assist future care. Thus, an effective method which is aimed at the increased use of electronic records by GPs to improve the care of the patients is reducing the data quality of the patient record when passed to other GPs.

Currently England under CFH with history of pilot implementation of GP2GP using HL7 V3.0 by HIRI (Health Informatics Research International Ltd) consortium in 2003 is now trying to provide this transfer electronically using the national infrastructure and methodology developed under the National Programme for IT-CFH. The GP2GP messages, designed form part of the CFH Message Implementation Manual to support an automated request, acknowledgement and send of the electronic component of the record to assist in the continuation quality electronic records when a patient moves practice.

The objectives and benefits of GP2GP as per CFH website (http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp) are twofold – benefits the patients and benefits to the practice administration. The benefits of using GP2GP to the patients as perceived under GP2GP are

Ø The patient health record being available to the new GP a lot sooner (e.g. within 24 hours)

Ø The new GP will have knowledge of the patient’s:
o Current medication
o Drug interactions
o Current problems
o Key past medical history
o An improvement in patient safety

Ø Increase patient confidence that they will get good continuing care

Ø Prevent patients being asked information that they have previously reported

The benefits to the practice administrative support teams as perceived under GP2GP are

Ø Reduction in administrative time at the previous GP practice to find and forward on patient records to the new GP practice

Ø Reduction in administrative and clinical time at the new GP practice to review and summarize or re-key the patient record received from the previous GP practice

Ø Reduction in the time taken for the practice to receive the patient record

Ø Reduction in administrative time to chase up patient records from Health Authorities

Exchange Mechanism under CFH GP2GP

The GP2GP process under CFH starts with the registration of a new patient with a GP practice. The GP2GP explicit flows are triggered by the NHAIS Registration links acceptance message flow and the update of the GP registration on a national MPI database called PDS (Personal Demographic Services) which is a part of the national EHR called Spine.

The GP2GP process covers the electronic transfer of the patient record between primary care systems through the MHS (Message Handling Service) of the Spine supplied by the NHS Care Record (NCRS) National Application Service Provider (NASP). There is no interaction with the on-going paper process of transferring Lloyd George envelopes.

The Expected basic functionality provided as part of GP2GP by CFH is as follows

Ø Construct and process EHR Request & Acknowledgement messages
Ø Construct and transfer EHR Extract and integrate into receiving system

Figure below the GP Exchange under CFH GP2GP when a patient shifts from Practice A to Practice B. The exchange is based on intermediary ebXML exchange where the infrastructure of the national EHR called Spine is used as the intermediary MHS.

A1- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A2- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A3- As part of the local registration process, the PDS is queried for the patient’s up to date details e.g. demographics, NHS number and current registration details

A4-The Spine Integration infrastructure will route the query to PDS which will populate a response message with the available patient details. If no record of the patient exists on PDS then a new entry will be created and appropriate PDS update messages sent

A5- The patient demographics and NHS number content of the PDS query response is integrated in the local system.

A6- The GP system will interrogate a national directory called SDS to find out if the practice system with which the patient was previously registered is compliant for GP2GP record transfer messages. The SDS keeps a list of all compliant systems.

A7-If the SDS response is negative e.g. the practice system is unable to send/receive GP2GP record transfer messages then the GP system will alert the user to the fact that no electronic transfer of the existing patient record is available

A8- A positive SDS response will trigger a record transfer request to be sent to Spine to route it to the GP practice system.

A9 - The Spine will route it to the GP practice system with which the patient was previously registered

A10- GP system will receive the request and alert appropriate users to the request.

A11- The EHR Request will be considered by the requested GP Practice

A12- The GP system will send an acknowledgement of receipt of the request to the spine which acts as intermediary to be sent to the requesting GP system.

A13- The Spine will forward the acknowledgement of receipt of the request to the requesting GP system.

A14- The GP system will receive the acknowledgement.

A15- The GP system will alert appropriate users to the receipt of the acknowledgement.

A16- If the request can be fulfilled the GP system will send the patient’s Primary care record as an EHR extract message to the Spine

A17- The Spine will forward the EHR extract to the requesting system by acting as intermediary.

A18- The GP system will receive an EHR extract

A19- The GP system will notify appropriate users to the receipt of EHR extract

A20- The EHR extract will be considered by the requested GP Practice

A21- The EHR extract will be integrated with the appropriate patients record

PS: Iam not sure why they are called EHR messages though but again everyone have their own definitions

EHR and Open Source Software

One of the major obstacles in deploying Electronic Health Records (EHR) apart from the usual political and technical reasons is the huge outrageous economic costs associated with the product suites involved in the deployment of EHR. So one option to reduce the costs might be looking at using Open Source software (OSS) to improve the financial viability of the implementations. Gartner has predicted that

· By 2010, 90 percent of Global 2000 organizations will have formal open-source acquisition and management strategies.
· By 2008, OSS solutions will directly compete with closed-source products in all software infrastructure markets.
· By 2010, open source will be included in mission-critical software portfolios within 75 percent of Global 2000 enterprises.
· By 2010, Global 2000 IT organizations will consider open-source products in 80 percent of their infrastructure-focused software investments and 25 percent of business software investments

In this post I will look at the main features of Electronic Health Records and the commercial software available for implementing these features and the open source alternatives for them. At a high level the features of Electronic Health Records are

Patient / Person Registries

One of the important feature required for the successful implementation of a EHR is the establishment of a patient/person registry and the identifies associated with them. This will allow the correct identification of patient’s identification and subsequent association of care records with them. The issues associated with the establishment of such a registry are

• Management of local identifiers and national identifiers
• Migration of data; resolution of duplicates and confusions
• Synchronization mechanism between local and national records

The commercial software for the establishment of registry are
• SUN SeeBeyond eView
• QuadraMed EMPI Solutions
• Initiate Identity Hub™ software
• The MPI software associated with Product Vendors such as IDX, Cerner, Eclipsys, McKesson,

The alternative OSS for the registry are
• Record Locator Service (RLS) – openhre
• Part of Medsphere OpenVista
• Eclipse OHF - Patient Identifier Cross-Referencing (PIX)
• High Available Open Source Database Solution using MySQL for Enterprise Registry Application with advance features.

Exchange of HealthCare data –Application Interoperability

One of the major features of EHR is the ability to feed a central health repository healthcare data associated with key events and at the same time exchange the data with different clinical systems. The issues associated with exchange of clinical data are

• Level and Granularity of clinical data
• Quality of data and existing data
• Choosing the right standards
• Legacy Systems Compliance

The commercial software available for the exchange of clinical data are
• Sun SeeBeyond e*Gate
• Oracle HTB
• ORION Rhapsody
• Microsoft BizTalk
• IBM Websphere

The alternative OSS available for exchange of clinical data are
• Mirth
• Eclipse OHF Bridge
• JBOSS, Hibernate, Web Services,
• Enterprise Service Bus, Messaging

Appointment Bookings

Though Appointment bookings are not itself a part of the EHR the ability to provide options to referrals and allow appointments to be made between different care settings by clinicians and even by patients themselves is emerging as the part of different nation’s healthcare IT infrastructure. The issues associated with appointment bookings are

• Problems with departmental system slots
• Definition of Resources
• Category of appointments –Inpatient/Outpatient

The commercial software available for providing appointment bookings are

• Cerner Enterprise Wide Scheduling
• USA RMS
• Isoft Revive
• Scheduling.com
• Epic Cadence Scheduling

The alternative OSS available for appointment bookings are
• O3-MARIS
• OpenVistA Scheduling

Healthcare Portal

Healthcare Portals are a crucial component in the infrastructure of EHR not only from the perspective of content management of the data that can be made available to clinicians available in the repositories associated with EHR but also access to services like appointment booking which is a part of the EHR. The issues associated with Healthcare portals are

• Security controls for data visible to citizens over Internet
• Clinically safe to use with relevant data made visible

The commercial software available for building of Healthcare Portals are
• McKesson Physician Portal
• ORION Concerto™ Medical Applications Portal

The alternative OSS available for Healthcare Portals are
• iPath - Open Source Telemedicine Platform
• Liferay Portal Enterprise and Professional
• Akaza OpenClinica
• Integrated Portal and Enterprise Content Management system (Alfresco/OpenCMS/
Mambo/cocoon)

Information Governance – Access Control

Another crucial aspect in the management of portals is the management of access and the provision of role based access. The issues associated with access control are

• Definition of RBAC Activities
• Smart Card access for operators and normal for citizens
• Agreed definition of roles

The commercial software available for providing access based control are

• SUN LDAP
• Microsoft Active Directory

The alternative OSS available for access based control are
• Centralized Authentication & Authorization using Open LDAP

Reporting

One of the main outputs of EHR is the ability to generate reports and provide the ability to allow clinical and administrative governance. The issues associated with reporting are

• Lack of transparency of system schemas to reporters
• Lack of LDMs for operational / departmental systems, data warehouses
• Lack of data pedigrees for reported data elements
• Lack of comprehensive data dictionaries for systems

The commercial software available for providing reporting are
• Informatica
• Business Objects

The alternative OSS available for reporting are
• Jasper Suite

The Verbose HL7V3- Part 1

In Mid-2006 Gartner in a note on HL7V3 stated that HL7V3.0 messages are quite verbose and applications require considerable effect to understand and process the message. Gartner suggested that HL7V3 messages need a critical midcourse correction and suggested to HL7 Inc to act vigorously to make HL7V3 messages easier to use and more compact.

In the next couple of posts I would look into the reasons and complications behind the verbose nature of HL7V3 and conclude by presenting the solutions on offer to overcome the problems associated with this verbose nature of HL7V3. This post will also help you to some extent to understand how to browse through an R-MIM.

Why are HL7V3 Messages Verbose?

HL7V3 messages are XML messages which are model driven and model driven XML are usually verbose in nature compared to custom written bespoke XML messages designed to convey the same information.

Why do we need Model driven messages?

Currently in the healthcare industry point-to-point messaging is common and non-standardised data exchange is the norm leading to data quality issues, confusions and processing errors sometimes with grave consequences affecting patient care. So it’s absolutely necessary to have a common understanding of the data that is being exchanged to eliminate the misinterpretations. To facilitate this, a level of semantic interoperability is required.

Semantic interoperability can be achieved using a common information exchange reference model so that data is shared and defined unambiguously. XML schema models are derived from this reference model and used to generate run time schemas which cannot be modified directly unless the model itself is modified. As different applications build XML messages sourced from the reference model they end up having the same content and construct facilitating meaningful data exchange. HL7 Inc produced a global semantic model for healthcare called Reference Information Model (RIM) which is the basis for HL7V3 messages [Refer to the HL7V3 Primer post dated January 2008 at

http://healthcareinformatics3000feet.blogspot.com/2008/01/hl7v30-primer.html].

So what’s the issue?



Well, let’s take a sample example and see what exactly the issue is. The following is an extract from XML instance to represent author of a clinical document based on the discharge summary CDA schema taken from CFH-MIM6.3 available on HL7-UK Website

Now let’s look in detail at the representation of the author. The R-MIM representation of the first part is shown below

The author representation starts with the author as participant. It contains the following attributes

1. “typecode” with a fixed value of “AUT” – Indicating this class is that of author

2. “functioncode" to indicate the function of document author from a pre-defined vocabulary. In this case it has a fixed value of “OA” indicating originating author.

3. “contextControlCode” - Specifies how the author contributes to the context of the discharge report and whether it may be propagated to descendent acts whose association allows such propagation.

4. “contentId” - An identifier for a template which constrains the classes and attributes which follow. This is more of a structural navigational aid and not an indicator of semantic meaning. In this case it is the AssignedAuthorSDS template.

5. “time” - The time at which the author authored the clinical document.

The XML representation of the above is shown below

The AuthorChoice leads to template for the author who is in a directory called SDS-Spine Directory of Services. The R-MIM representation of author in SDS is shown below

The AssignedAuthorSDS identifies a person playing the role of author. The role information includes the user identifier and role profile information of the author along with the job role.The AssignedAuthorSDS contains the following attributes.

1.“classCode” - A fixed value of “Assigned” indicating that this role is assigned

2.“id” – it has a cardinality of [1..2] with two identifiers one to identify the user id and one to identify the role profile of the person to whom the role is assigned

3.“code” - A code from a vocabulary which defines the person’s job role and with displayname associated with code

4.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedAuthor template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to person entity which is playing the role of the author. The attributes within the person entity are given below

1. “classCode” - A fixed value of “PSN” indicating that this entity is a person

2. “determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of person
Name – Name of the person

3. “templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedPerson template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to the represented organisation to which the author belongs to. The attributes within the organisation entity are given below.

1. “classCode” - A fixed value of “ORG” indicating that this entity is a organisation

2.“determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of an organisation

3.“id” – A unique identifier which identifies the organisation nationally

4.“name” – name of the organisation

5.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the representedOrganisation template.

The XML representation of the above is shown below

Still not clear on what’s the issue here?

Well a simple XML representation of the author as described above would have probably looked something like this

Hmm…

But is it that not the price you pay for using a model to provide semantic interoperability?

Yes it is but the verbose nature of the HL7V3 problems are creating huge problems as mentioned above regarding the effect to understand and process the message correctly apart from hogging the network bandwidth and destroying one of the unique the advantage of XML messages- “Readability” which is critical for developers and testers.

So what can we do?

There is a huge debate going on if we can take an alternative path to provide semantic interoperability with simpler XML messages. We will discuss those options in our next post.

Acknowledgements and Copyrights

1. HL7-UK / CFH - MIM 6.3 - Copyrights for R-MIM

2. Acknowledgements - Is it Possible to be Simple Without being Stupid?

Exploring the Semantics of Model-driven XML - Ann Wrightson

Healthcare ESB Approach

This post defines an approach which can be used for development of Enterprise Service Bus to enable communication using both HL7V2.x and HL7V3.0. The approach is based on Service-Oriented Architecture (SOA) to better align the solution with the business. Enterprise Service Bus (ESB) has emerged as the best proven, fastest and simplest way to implement SOA and offers dramatic productivity and ROI improvements over traditional integration technologies. Figure below a schematic representation of proposed ESB involving applications communicating using both HL7V2.x and HL7V3.0.

ESB Model


SOA simplifies the complexity in integration by the provision of a common infrastructure for service communication, mediation, transformation, and integration. ESB serves as the backbone for an SOA implementation. The ESB will provide the following services

Transport Services: The transport services need to support multiple communication protocols to support both local and national communication. The relevant communication protocols for the current scenario that will be supported are TCP-IP/MLLP, HTTP(S) and JMS.

Message Type: The solution need to support multiple messaging models such as synchronous, asynchronous, publish, subscribe and store and forward. The message types supported with these messaging models are JMS with headers, XML, SOAP and ebXML.

Validation Services: The messages come in different formats varying from string delimited for HL7 v2.x, XML for V3.0 and proprietary formats for existing systems. The validation components will vary from using standard XSD’s to custom XSD’s.

Transformation Services: The transformation service is required to transform currently one version of HL7v2.X to other versions of HL7V2.x and some custom format. The functionality supported by transformation service is
Ø Transforms messages based on the target service
Ø Transforms messages based on XQuery or XSLT
Ø Supports transformations on both XML and string delimited messages

Routing Services: The routing services need toallow routing of messages to existing systems and national applications based on the message content or message headers. The routing services will be based on XQuery-based policies or callouts to external Web services. The routing policies apply to both point-to-point and one-to-many routing scenarios.

Service Management: The service management services need to help handle logging, monitoring and error handling variety of message errors. The logging and monitoring will support logging messages for both systems operations and business auditing purposes, search capabilities, and others. Both business services and ESB services are monitored, as are response times, message counts, and error counts. The error handling components allows configuring of systems to format and send error messages, and return messages for consumers of services who expect a synchronous response.

Common Wrapper: The differences in transport mechanisms used by HL7V2.x and HL7V3.0 will hinder the ESB. The development of a common wrapper with elements of MLLP wrapper and SOAP/ebXML wrapper is crucial for successful deployment of this model.

Null Flavors in HL7V3

The concept of null in HL7v3 is very different from HL7V2.x (See my old post on Null values in HL7V2.x. http://healthcareinformatics3000feet.blogspot.com/2007/11/null-values-in-hl7v2x.html). This is essentially to do with lack of support for optionality in HL7V3 – Reference Information Model which itself rose from the issues associated with optionality in HL7V2.x – see else where in this blog for strengths and weaknesses of HL7V2.x and HL7V3.0.

At a high level we can say that in HL7V3 the multiple exceptional values, i.e. values other than recommended or allowed by message specifications are grouped under the banner of NullFlavor. nullFlavor is a property of every data type through ‘extension.’ This property is valued and communicated as part of a message when information is missing. The flavor provides the reason why the information is missing. This can be best illustrated by the following example

The Character String with Code (SC) data type contains a character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.

If the name of the software(e.g. RamboRavage) is known


< softwareName> RamboRavage < /softwareName >

To indicate the name of software (RamboRavage)and code of the software(RaRv)

< softwareName code="1" codeSystem=" 2.22.222.2.222222.2.2.2.2.2222" displayName=" RamboRavage" >RaRv</softwareName>

To indicate that the software name is unknown

<softwareName nullFlavor=" UNK" />

It need to be remembered that a nullFlavor is not permitted simultaneously with a value. The various types of null flavour as per the latest HL7V3 ballot pack are given below

1.NI -no information- This is the most general and default exceptional value. There is no information which can be inferred from this exceptional value.

2.MSK- masked – This particular item has a known proper value, but it cannot be released in a given context due to security, privacy or other reasons.

3. OTH- other -There is a value, but it is not an element in the value domain of a variable
NINF negative infinity of numbers
PINF positive infinity of numbers

4.UNK- unknown - proper value is applicable, but not known.

• ASKU - asked but unknown – information was sought from the source but not known (e.g., patient was asked but didn't know)
  
• NAV temporarily not available - Information is not available at this time but it is expected that it will be available later.
  
• NASK not asked - The Information was not requested from the patient
  
• QS Sufficient quantity – The actual quantity is not known but sufficient enough to achieve a specific goal. For example the advice can be add sufficient quantity of water to 10 mg of medicine
  
• TRC trace – The content is tool small to measure but a nonzero value

5. NA not applicable – There is no proper value for this data item for this patient; for example the date of last menstrual period is not applicable for a male.

The practical use of null can be gauged from different scenarios. For example a unconscious patient brought to the hospital have to be registered and most Patient Administration systems need at least one address. If the patient address is not known the patient address element <addr> can be set to UNK and sent to other down stream systems or repositories. If Sensitive/VIP patients need to be sent to other systems and if they do not have the same levels of security and control as the sending system have the sending system can send a null flavor of MSK indicating that they do not wish to expose the patients address.

But the usage of nullflavor has come under for huge criticism from different quarters notably from Barry Smith(Ref:http://hl7-watch.blogspot.com) where it was pointed out that the different nullflavors might lead to the need for different reasoning services and might become an overhead for message processing by applications. The other criticism of nullflavor is that the need for mandatory values for attributes would force systems to be modified to restrict users who normally ignore non-mandatory fields on screen to fill them with nullflavors. They need to be manually filled in with the real reason for that null value and proper nullflavor need to be entered on the screen. Some of the nullflavors like NAV (temporarily unavailable) are not very user intuitive terms for them to be selected. The values of +infinity and –infinity are mathematical conceptual numbers and does not indicate non-availability of data in any manner.

Organization such as CEN have rejected HL7V3 data types apart from Australia opposing the current draft ISO health data types standard (ISO 20190) based on HL7 v3 data types and one of the reasons it has been rejected or opposed is the huge confusion over usage of nullflavors(see the debate on nullflavors on openEHR website).