Designing Safe and Effective Digital Health Applications

The deployment of electronic health records (EHRs) and the emergence of robust, API-based integration have combined to create the 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 priniciples 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.

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.

Health care 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 health care. 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.