Before the prolific rise of EHR systems, patient health data was managed through telephone calls and fax machines. The only ‘electronic’ component associated with patient health information was rooted in these devices to exchange data that would ultimately be printed onto paper. For medical procedures such as surgeries, care providers would call up local hospitals, schedule elective procedures, and conduct a screening for the patient, before entering the operation theatre. The patient profile comprised tests, medical history, and physical examination details and existed as a file that needed to be carried around.
The introduction of EHR systems eased the access, transfer and use of patient records into Electronic Patient Health Information (ePHI). However, despite HIT developers’ noble efforts to make life easy for care providers, the disconnected data silos resulting from the use of disparate EHR systems in a care facility made the endeavor counterproductive.
The complete clinical picture of the patient (history and prognosis) remains unclear even today, despite the ubiquitous adoption of EHR systems by healthcare facilities.
Understanding the Need for Interoperability
Value-Based Care (VBC) is the holy grail of the new frontier of healthcare, and the Department of Health and Human Services (HHS) is gunning for it. Financial reimbursements for care providers continue to be conjoined with improvements in care outcomes and reduced re-hospitalization rates. With the CMS and ONC tightening the clamps on reimbursement laws, healthcare delivery organizations would require a complete picture of the patient healthcare information. In short, the healthcare industry is in dire need of HIT systems that facilitate the seamless exchange of health information from one EHR system to the other
It’s an API Based World
Application Programming Interfaces (APIs) can provide clinicians, and patients access to ePHI through convenient means such as third-party health apps. Among the many benefits of APIs for exchanging electronic patient health data, their ability to augment clinical decision support and the exchange of ePHI between disparate care provider teams, stand out.
APIs can be imagined as a bridge or a conduit that allows care providers and patients to access an ePHI repository securely. Think of it as a foundation of an ecosystem comprising healthcare applications designed to access, exchange and introduce changes to patient health records. While, in theory, APIs appear to be the silver bullet for the long-standing interoperability challenges of the healthcare industry, the ground reality suggests that HIT developers have their work cut out for them.
The Road Ahead for HIT Vendors
The healthcare technological ecosystem is primed to transform into a mix of applications, processes and data, working in harmony to assist physicians to pursue better care outcomes. While care providers are placed at one end of the spectrum, patients are placed at the other, and the intention is to empowering them to take up an active role in their care process. However, HIT developers must
tackle challenges with using API as the Seraph sword to pave the way for the seamless interoperability of healthcare systems. The following are the prominent ones surrounding API development:
Lack of Data Standards: Disparate HIT systems contain health data in varying data standards. Getting these systems to ‘talk to each’ other calls for the deployment of common data standards.
Data Transformation Timelines: Currently, all of the Extract/Transform/Load (ETL) mechanisms require a change from the ground up to facilitate interoperability. HIT vendors must explore avenues to reduce the total time involved in this transformation.
API Testing: The use of different EHR systems across care facilities, and the complexity of the data channels and the varying healthcare data standards they adopt, makes testing an important task. In addition, since many care facilities possess multiple HIT environments, testing solutions will inevitably become a tough challenge.
Backward Compatability: Future healthcare solutions must be capable of supporting legacy data with version improvements. In addition, new advancements in API development must consider backward compatibility of systems a care facility already uses to reduce the cost burden involved in adopting technological improvements.
Consent Management: There needs to be a mechanism for capturing consent from patients and members. This needs to allow for different levels of granularity Document, field, an instance of a record ( medication or visit, for instance).
HIT developers could speed up development time and reduce development costs by associating with organizations specializing in healthcare IT services. Such business partners pursue singular goals, enabling mainstream HIT vendors to focus on core functions such as product development. The interoperability journey is long and arduous, and technology partners specializing in healthcare interoperability solutions might give them the boost they need in the industry’s transformation into a ‘patient-centric world