Abhinav Shashank

Healthcare has lately been dotted with data-driven innovation. Companies with huge data warehouses like Google, Facebook, Amazon have made use of next-generation technologies to deliver connectivity, ease of access, and user experience. Then, why not healthcare? The future of Big Data is promising- the analytics market in healthcare is projected to grow from $7 billion in 2016 to $24 billion in the next five years and tapping Big Data could offer several more possibilities.

Bringing Big data to healthcare

In 2011, the entire healthcare industry managed to generate 150 billion gigabytes, or 150 Exabytes, of data- comprising of patient information, disease registries, regulatory data, etc. Managing these tremendous amounts of data with conventional hardware and software became challenging over time and healthcare began leveraging Big Data:

      –     Helps to track and manage population health more efficiently

• Will significantly improve, transform and reduce the cost patient care
• Enhance the ability to deliver preventive care

To deal with big data, healthcare needs technology like Hadoop, Spark, and Scala. But, very few health systems have invested in IT systems/solutions to optimize data processing, without which health care will struggle to exploit the opportunities and benefits that big data offers.

Currently, the existing standards used for integrating data are relatively slow and need an upgradation. The reason for this varies- from siloed data, to getting patient consent and furthermore, vendors charging a hefty fee for data solutions. Healthcare is far from its aim of achieving real-time data integration.

Aiding Big data

What’s needed is to explore the better options that are out there in healthcare.

Technologies like Hadoop and Spark along with Scala will give health data the much-needed boost it needs in terms of storage, the speed of transfer and scalability. Currently, the organizations using these technologies include Yahoo, Facebook, eBay, Amazon, Federal Reserve Bank, etc. It makes no sense that the healthcare industry should lag behind sectors like retail and banking in the use of big data and work on reducing costs, improving the quality of care and delivering superior outcomes.

Addressing the elephant- Hadoop

This Linux-based, open source framework of tools was made to support the running of applications on Big Data. It addresses the challenges with big data stepwise- velocity, volume, and variety. This means that data flows in with speed, in large amounts and is of varied formats. A batch processing set of tool, Hadoop breaks higher tasks into smaller pieces and sends the final result back to the application. Hadoop assists researchers and data scientists in using data to engage clinicians in providing high-quality care with the following core softwares that work with Hadoop:

• Hive- an SQL-like query language suited for Hadoop
• Pig- a high-level query, used for MapReduce
• HBase- a column-like data store that runs on the Hadoop framework
• Spark- a general-purpose analytical and computing framework

It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. Hadoop breaks the data and the computation associated with it into smaller pieces to enable dealing with big data. Hadoop has two useful components- MapReduce, that allows the transfer of programs to different machines where data is stored and Hadoop Distributed File System or HDFS, that controls the storage and access of data.

Hadoop deals efficiently with disparate and skewed data. It’s well prepared for unstructured data. To scale it up, all that’s needed is to increase the number of clusters that too without needing different sets of codes for each. All the data is well distributed amongst clusters- thus making the creation of space in healthcare less challenging.

Spark in healthcare

Another execution framework is Spark wherein data processing takes place simultaneously and in bulk. It is quick, easy to use and has sophisticated analytics, with APIs in Java, Scala, Python, R, and SQL. Since Spark does all the computation and process in memory by using RAM, it is 10 times faster than Hadoop.

Spark can run on a laptop, standalone systems, cloud or with Hadoop. It can access diverse data sources including HDFS, Apache Cassandra, Apache HBase, and S3. It also performs ad hoc data analysis interactively and is actively used by Internet powerhouses such as Netflix, Yahoo, and Tencent where Spark is deployed at a massive scale and runs with over a thousand of nodes.

Apart from Java, Spark also supports Python and Scala. Since Spark stores data in memory, the time-consuming work that MapReduce undergoes by reading programs in disk back and forth is absent in Spark. Another plus point is that the coding required is much less; just one line of code in Spark as compared to hundreds in Hadoop or other frameworks- delivering fast processing.

Scala- Scaling up processing

A programming language written in Java, Scala is also the language that Spark is written in. Short for scalable language, it runs on the Java Virtual Machine.

Programming libraries for Spark can be done through Scala which is better designed to work with Spark than Python or Java. Scala requires highly reduced the number of lines of code.

However, Spark does not replace Hadoop. Although Spark can be used as a standalone, both Hadoop and Spark work great together. When MapReduce does all that recording onto the disk, it allows for the possibility of restarting after failure. MapReduce makes Spark faster, more scalable and reliable. Especially for systems which are already running on Java, it’s easier to switch to Scala and improve the flexibility and the scalability of the system.

The road ahead

About two decades ago, the cost to capture data and to store it was too high. Even as early as 5 years ago, the cost of creating and managing a relational database was around $100,000 per TB, not counting the cost of support and maintenance. The introduction of Hadoop has been a great leap in our ability to store and process large volumes of data. Physicians and providers have started to worry less about storage and processing and are working towards delivering superior, value-based outcomes. Maybe in the near future, we can see healthcare industry deliver personalized patient care at controlled costs.

For years we have known and experienced the negative impacts of delayed and inaccurate information transfer. The reasons could be many- lack of continuity, fragmented systems, different data standards- owing to which the news of a patient’s medical encounter may take some time to reach the provider, if it ever does. Stepping up, the international standards development organization, Health Level 7 (HL7) came up with ADT – Admit, Discharge and Transfer feeds to establish patient data notification services.

ADT messages are lately becoming the cornerstone in care management as the go-to source of data, holding a wealth of valuable information that can affect point-of-care decisions. Seemingly simple, ADT messages are invaluable tools in helping providers better coordinate care and solving the issue of national interoperability.

What type of data do ADT feeds capture?

ADT feeds capture important elements pertaining to a patient’s demographic and clinical information, right from their name and address to their medical record number. The messages usually communicate:

• A patient’s demographics- name, insurance, address, medical record number, etc.
• If a patient’s ‘status’- admitted, discharged, or transferred- has been updated.

Some of the most important segments in an ADT message are PID (patient identification) segment, PV1 (patient visit) segment and an additional IN1 (insurance) segment. There are 51 different types of ADT messages, reflecting different events like admit, discharge, transfer, registration, etc. and can be augmented with additional data to streamline and manage process within a health system and helping providers be prepared and deliver effective care.

For example, the insurance information present in the ADT messages can let providers gain valuable information like referrals, details of billing, where to send medication orders, validating prescriptions.

Making ADT feeds instrumental in care management

In the age of technological evolution, providers and patients alike have begun relying on electronic mediums of communication, making ADT feeds a focal point in improving clinical outcomes. ADT feeds hold valuable information that can integrate departments, provide accessibility of information and store large volumes of data in a secured, organized manner. Apart from the above, ADT feeds can be used for:

• Enhanced care management: As ADT messages contain structured information about a patient’s health, they allow care teams to monitor patients’ health and connect with them proactively.
• Real-time notification services: Leveraging ADT messages at the point of care, combined with machine learning can help providers and health coaches be notified about care encounters like hospitalizations, ED visits and follow up with discharge instructions.
• Analysis of care quality: ADT messages can be extracted out of their databases for various time periods and attributes and can be processed through scripting logic and analyzed to generate consolidated reports about different parameters like inpatient encounters, 72-hour ED visit, 30-day readmissions etc.

Existing ADT exchange infrastructures

ADT messages tend to be high-volume, and there has to be a special focus on avoiding duplicate message routing, miscommunication of information and on managing inter-facility variations. Here are some existing models:

• Point to point model: the point-to-point model, or P2P model, is the most simplified and basic approach with the underlying architecture relying on two systems establishing VPN connectivity between themselves to send and receive ADT messages. The biggest advantage of the model is its technical simplicity with rapid implementation.
• Hub model: The hub model introduces a lightweight engine to improve the processing and routing of ADT messages and addresses the scalability issues with the P2P model. It follows a simple ‘if-else’ routing; for example, ‘If the state code of incoming message doesn’t equal my local state code, send the message back to the routing hub.’
• MPI query model: The MPI (Master Patient Index) query model has a targeted method of routing ADT messages based on patient identity. Instead of using geographic routing, MPI query model first evaluates if a patient exists within another HIN infrastructure and if yes, the message is routed further.
• SHIEC patient-centered data home: The Strategic Health Information Exchange Collaborative rolled out this approach that combines the technicalities of all these models to facilitate inter-HIE data exchange. Similar to P2P and hub models, ADT messages are pushed to the destination system, and a unique patient identifier is associated with the subject patient record and included in the ADT messages.

The road ahead

From health systems to accountable care organization to integrated delivery networks, we see today that providers can gain a holistic perspective on their patients with valuable and actionable real-time information i.e. with ADT messages. More than admit, discharge and transfer notifications and accurate data exchange, ADT feeds have the potential to have all the members of a health system working in cohesion. True, there is a certain fatigue and skepticism associated with ADT as is the case with any other new data sharing initiative, but if ADTs are implemented at full-scale, we can have reduced readmissions, better outcomes for high-risk populations, improved patient experience of care, and perhaps a viable solution to achieve 100% interoperability.

Today we would like to have all our health information at our fingertips. Just like the access to emails, calendar, maps, etc., it would be awesome if we also had a similar arrangement to view our cholesterol levels, insulin, and other vitals on the fly.

With the boon of digitization in healthcare, care delivery became faster and easier, but interoperability got lost somewhere in this revolution of healthcare. Without it, our ‘modernized and digitized’ systems weren’t as capable as we had hoped them to be in terms of delivering the efficiency needed in health care.

Standards were developed to make for a smoother transition and to make sure interoperability isn’t lagging behind and eventually forgotten. Though slow, the progress is taking place to connect healthcare seamlessly.

HL7 FHIR, one of the most talked-about developments in healthcare, came up on the front lines with the success of RESTful based APIs. It was nothing less than a flexible idea- traditional health data exchange, but from scratch and with a modern approach. As it turns out, several ideas served as the foundation for FHIR: 

HL7 V2: the bedrock

Health Level Seven (HL7) International came up with certain interoperability standards for the smooth flow of healthcare data. Its main idea was to exchange data in a batched or grouped manner. A well-established standard created by clinical interface specialists, HL7 V2, has following features:

• An 80-20 approach, where 80% of the interface framework is fixed, and the rest 20% would reflect custom business, clinical, and administrative needs.
• Defined encoding rules, groupings, and default ASCII character set for data exchange.
• Batch processing and exchange of message files.
• Support for local variations in data exchange by allowing optional/additional message fields.
• Compatible with lower layer protocols to avoid replication of features, application protocols, and other existing health care protocols.

Why we needed something better than HL7 V2?

The lack of precision and complexity that V2 endorsed became a roadblock in time. As it became a legacy standard, its utilization for modern devices and apps trying to leverage patient data began diminishing.

Another problem was that the entire data has to be transmitted and it wasn’t possible to send data across selectively. Moreover, adding new elements into the standard became time-consuming as the entire architecture had to be recreated from bottom up.

HL7 V3: the successor

Next standard was the HL7 V3 that defined applications. This means there were fewer options to define something new within the standard. V3 addressed the challenges of V2 in these ways:

• A consistent data model with defined applications and message syntax was defined.
• Application roles were very well defined
• Message optionality was limited
• Less cost was incurred in building and maintaining mid-to-long term interfaces

What did HL7 V3 lack?

The newer had no compatibility with the older format i.e. HL7 V2 and thus, retraining and retooling became a necessity for any organization adopting it. For clinical interface specialist, the standard was heavy on the pocket to change for to customize it, as it had to be restarted and had long adoption cycle.

The unpopularity of both the standards was due in part because one was too flexible while the other too rigid and a new ‘digital divide’ was created.

The foundation and the surface of FHIR

FHIR which stands for Fast Healthcare Interoperability Resources is the brand new standard to have come out of HL7. It came about as a result of a special HL7 test called “The Fresh Look” task force. It was needed to make up for the limitations of V2 and V3. With the best features borrowed from both as also from CDA (clinical document architecture), FHIR boasts the following key features:

• It is way faster to design and implement than the previous standards.
• It is customizable, has speed and document exchange.
• It supports four interoperability paradigms – REST, Documents, Messages, and Services. FHIR resources are formatted in commonly used XML or JSON formats.
• Besides structured data, resources in FHIR contain human readable text.

As opposed to the segments in HL7V2, the resources in FHIR can be independently queried or updated and are sometimes linked together. Each can stand alone and be exchanged independent of other resources. They are easy to extend and to adapt. Therefore, resources are simple and follow a modular approach, and that’s why FHIR stands out as a more refined version of interoperability standards.

How will these changes affect healthcare?

Physicians will be able to access health data on their mobile phones through numerous API (Application Programming Interface) functions that FHIR supports. This ease of access to complete and accurate patient data will, in due course help in many ways.

As providers and health coaches work together on improving the health of the population, it becomes extremely crucial for them to be able to access accurate data from sources other than EMRs. FHIR acts as a bridge to the gaps in tools by providing care management teams with the capability to connect with the patient data seamlessly through open APIs and view patient records on the fly.

FHIR: Making digital health care easier

Consider a patient referred to some other location by his Primary care Physician. In this scenario, his immunization, lab, and vitals data will be sent to the state and stored in one of the FHIR repositories. The advantage of FHIR here is that it provides clinician and patient the flexibility to access patient data on their favorite FHIR-enabled app, instead of logging into a state-provided portal.

This process not only provides ease of access but also allows the integration of accurate patient data on one app where one can view it without visiting the EMR every time.

The future of FHIR

We now have the next generation of technology being introduced in healthcare, and we need revolutionary solutions to make these technologies create an impact on granular levels. Today, our focus should be on developing FHIR-based APIs to help healthcare organizations enable seamless information sharing on an expanded network of electronic health records and other health information technology based on the Internet and different architectures.

Interoperability has the capability to redefine the basic premise of health IT. Without it, we will stay stuck where we are and make healthcare more complex, or we can achieve true interoperability and advance coordinated care delivery.