The deployment of electronic health records (EHRs) and the emergence of robust, API-based integration have combined to create he opportunity for innovation through the integration of third-party digital health applications. This powerful, new paradigm of integration has inherent challenges and lacks a clear framework for maximizing benefit while minimizing risk. Having a set of guiding principles to help identify potential defects and mitigate risk is a good start.
We have identified six key principles that help identify specific areas of focus when developing digital health applications that will integrate with an EHR. We have also expanded on these ideas in a detailed white paper that includes a set of screening questions that can be used by IT professionals.
Principle #1 – Integration APIs can be generically risk-stratified based on function and use.
APIs that provide EHR integration points can be grouped into risk categories based on their function and use. These categories can be used as a high-level screening tool when assessing new applications or functions.
Risk Category | API Action | Examples |
Low Risk | Reading data from the EHR |
|
Medium Risk | Writing data to the EHR |
|
High Risk | Writing clinical actions to the EHR |
|
Table 1. API Risk Categories
It can be safe to build applications in any of the risk categories. The key is to understand the rationale and assess if the benefit makes it worthwhile. The higher the risk, the more imperative it is to ensure solutions are both worth it and up to the challenge.
Principle #2 – Respect native EHR clinical decision support (CDS).
With rare exceptions, designers should not bypass or in any way inhibit the expected performance of native EHR CDS which is typically a combination of EHR vendor, enterprise and local customizations. All writing of clinical data into the EHR should be carefully reviewed to assess if there is an impact on CDS functionality.
In rare cases where the decision is made to bypass native CDS, the impact must be carefully documented and validated with the health system hosting the EHR. Special attention needs to be given to both the affected current CDS logic and potential future rules that could be ignored by the application.
Principle #3 – Always write data to the “right” database location.
EHRs and the analytics and reporting that are built upon them make certain assumptions about where data is located within the underlying database. All too often, applications writing to the EHR will put important information in the wrong “place,” which may work fine for their use case but can have dangerous downstream impacts.
Like CDS, analytics and reporting are typically a combination of an EHR vendor, enterprise and local design and customizations. Also, analytics can drive CDS and other real-time activities that could be adversely affected if data is written carelessly. If data is written to the “wrong” location, CDS (and clinical users) can be fooled, leading to unforeseen and undesirable results.
Principle #4 – Comprehensive non-production testing is a critical element of safe operations.
The potential for harm in clinical IT is significant. Harm reduction should be based on a “swiss cheese” model that identifies and mitigates risk at multiple levels. Testing should be standardized and use adequate data sets in a robust non-production environment. Workflows should also be validated with appropriate end-users.
Minimalistic test data is unlikely to be rigorous enough to proactively identify issues. Test scenarios should be as realistic as possible. Involving actual end-users (and not just their representatives!) is critical to identifying real-life workflows and issues.
Principle #5 – Mission critical applications should be robust and reliable.
Healthcare applications (both clinical and non-clinical) that are mission critical require high reliability. Careful planning, monitoring and rehearsal of downtime procedures are the hallmark of highly reliable systems. These should be part of any plan to deliver and support critical systems. Given the high volume of transactions, specific attention should be given to handling “silent” failures (e.g., a transaction is dropped without an obvious impact). Proactive performance monitoring is also essential.
Principle #6 – Know and follow data privacy and HIPAA best practices.
EHR source data often contains personal health information (PHI). Application designers should know and follow appropriate best practices to protect PHI and ensure compliance with HIPAA. Appropriate audit trails should be maintained, business associate agreements (BAA) should be in place and organizations should conduct regular, meaningful HIPAA compliance exercises.
Conclusion
Health IT is on the cusp of an “app revolution.” You need look no further than the smartphone in your pocket to see where we are headed: a symphony of applications that work together seamlessly and effectively to provide better healthcare. But the revolution also carries risks. Careful attention to the design principles outlined above combined with a methodical approach to screening and addressing issues can go a long way towards ensuring the revolution will be both safe and effective.
A comprehensive white paper that includes more detail and a set of screening questions for professional developers is available here.
Dr. Dave Levin has been a physician executive and entrepreneur for more than 30 years. He is a former Chief Medical Information Officer for the Cleveland Clinic and serves in a variety of leadership and advisory roles for health IT companies, health systems and investors. You can follow him @DaveLevinMD or email [email protected].
Dr. Maulin Shah is a physician and engineer and has been an innovator in health IT for 20 years. He is Chief Informatics Engineer at Providence St. Joseph Health where he leads the design and usability of clinical workflow innovations. You can follow him @maulinpshah or email [email protected]
