Guest post by Gavin Robertson, CTO and senior vice president, WhamTech.
Gavin Robertson
As technology continues to permeate healthcare in different ways, it is becoming increasingly important for providers to have access to the data generated and retained by these technologies. With insurance providers, hospitals and clinics using a variety of electronic health records (EHRs), patient portals and databases, it can be difficult for all providers to have access to all relevant and most recently updated patient information. Differences among EHR vendors and systems make data access, sharing and interoperability nearly impossible.
Interoperability is a hot topic in healthcare today. Healthcare providers want to move beyond conventional Healthcare Information Exchanges (HIEs) that generally exist as single application to single application (P2P) data formats. The HL7 standard data model has helped a lot, but (i) it is too complex and extensive for full adoption, (ii) it is, typically, a specific relational or hierarchical implementation, requiring additional transformation, and (iii) there are a number of implementation variations.
Regardless of the improvements associated with the HL7 standard data model, the challenges facing interoperability remain; in that (a) multiple vendors have multiple ways to represent common data, (b) data may be required from more than one application and associated data sources, (c) poor data quality, (d) there may be no unifying view of data from one or more data sources, e.g., single patient view, and (e) there is no ability to write back to/update data sources.
HL7-based FHIR (Fast Health Interoperability Resources) APIs is a recent attempt to standardize access to data sources, but most vendor systems are nowhere close, as it is a different way of representing data from most vendor data schemas; i.e., object vs relational data representation. Also, some FHIR APIs need access to multiple tables in a single data source or in multiple data sources.
To implement FHIR APIs, one approach is to convert between the data source schemas (relational, hierarchical or flat) and the FHIR object model on-the-fly, but it does not address other shortcomings (poor data quality, no federation and lack of master data management (MDM)/single patient view). Another approach, which improves on just converting formats, is to copy and transform data into FHIR-friendly data stores and enable data services on top. However, this introduces additional problems, including latency, security, privacy, no interactivity; e.g., no write back/update to operational systems, additional storage and systems, and time and cost to implement.
Regardless of the approach, FHIR APIs open up interoperability and raise capabilities to new levels. New workflows can be developed and run using simple power end-user applications, such as BPM, reporting, BI and analytics tools. Examples include new smartphone app-driven BPM workflows running against FHIR API services, include write back/updates, on multiple legacy data sources in multiple organizations. Another example being hybrid cloud installations where multiple data sources are both on premise and in the cloud.
CIOs in healthcare face the constant challenge of doing more with less. Most are being asked to dramatically cut costs while continually tackling an ambitious list of responsibilities, including maintaining their organizations’ ability to demonstrate meaningful use, making the transition to ICD-10, sharing information through healthcare information exchanges (HIEs) and maintaining stringent patient privacy and HIPAA compliance programs.
Three key and often overlooked elements can help to address these tasks: document scanning, clinical language understanding and integration standards. Mastery of this electronic health record (EHR) trifecta can significantly simplify the healthcare CIO’s challenge.
Document scanning
Electronic health record adoption levels are steadily increasing, but ongoing interoperability issues result in high volumes of paper-based communications between providers. In fact, a survey conducted by the Bipartisan Policy Center in Washington, D.C., found that 71 percent of physicians identified lack of EHR interoperability and exchange infrastructure as major barriers to HIE.
HIE expansion about supply and demand? Well, if you read this blog regularly, you’ll know that I spend a good bit of time perusing HealthIT.gov. Though it’s not flashy and overwhelming, the site is informative and actually provides a great deal of information, which says a lot since it’s a government property.
What HeatlhIT.gov does well is provide a nice primer of information about a variety of subjects from meaningful use, electronic health records and health information exchanges.
In addition, the site puts everything in plain and simple language for all the world to understand.
For example, take a look at the reasons why health information exchanges are important to the healthcare landscape:
The ability to exchange health information electronically is the foundation of efforts to improve healthcare quality and safety. HIE can provide:
The connecting point for an organized, standardized process of data exchange across statewide, regional and local initiatives
The means to reduce duplication of services (resulting in lower healthcare costs)
The means to reduce operational costs by automating many administrative tasks
Governance and management of the data exchange process
And for good measure, here are a few examples of how health information exchanges are benefiting the healthcare landscape. Some of these concepts are a bit obvious and overstated here, but still this provides a nice starting point in support for the soon to be possible movement.
Benefits of health information exchanges:
Provide a vehicle for improving quality and safety of patient care
Provides a basic level of interoperability among EHRs maintained by individual physicians and organizations
Stimulates consumer education and patients’ involvement in their own healthcare
Helps public health officials meet their commitment to the community
Creates a potential loop for feedback between health-related research and actual practice
Facilitates efficient deployment of emerging technology and healthcare services
Provides the backbone of technical infrastructure for leverage by national and state-level initiatives
I’m not alone in the belief that I feel HIEs’ most important role is one of creating interoperable opportunities to connect physicians and their patients to a web of other care givers and health community members.
It seems that the closer we get to HIEs and their overall acceptance in healthcare, doesn’t it seem like we take two steps back?
What are some of the hurdles keeping HIEs from reaching their full potential? Glad you asked.
Cost has to be the clear front runner. As I’ve previously stated, the questions remain – who’s going to pay for them? The government clearly wants a healthy HIE community because it is believed that they will lead to greater adoption of EHRs while vendors want part of the action so they can charge physicians to transfer data through the networks. Vendors can’t figure out a financial model for them and until they can get someone to pay for them, there may be little movement here.
Another hurdle of HIEs is that for those that exist, the data often exists in silos. Problem with siloed data is that the data doesn’t go anywhere. Sounds a lot like an EHR, but an EHR may be more user friendly and robust. Just saying.
Finally, lack of standards impede their advancement. More development for standards is required for the variety of HIEs to be able to communicate. Profiles, like the need for structured data in EHRs, will help advance the cause and promote their development.
Ultimately, HIE expansion will most likely come down to basic business 101: supply and demand. When the population demands it, we’ll see the supply increase and in so doing, we’ll see cost containment, industry wide standards and completely interoperable systems that will completely open up the health IT market place.
