How to take an App to a Health System (and Integrate with their EHR)

Scrubbing In

This guide provides a high-level overview of the processes involved in taking your App to a Health System and integrating with their EHR. This guide does not cover selling to Health Systems, it assumes you already have clinical buy-in for your app and some level of agreement from key decision-makers. The first part covers the steps leading up to the Health System executing the contract and allocating resources to your project, while the second half focuses on everything that follows.

While I've been through this process more than a few times, it's not my sole focus, and I recognize there are plenty of experts who do this every day, all day. If you're one of them, I'd love to hear your feedback and will gladly include any contributions below, along with a link.

It's also worth noting that most Health Systems I've worked with are understaffed and stretched on the IT front, often facing a significant backlog of integrations that might run for months. So, no matter how many lives or dollars your app could save, or how many superstar clinicians are championing it, expect some pushback along the way and don't take it personally.

To that end, a seemingly minor, pending security task can sometimes delay an entire project. For you as the vendor, this is just another customer; for the Health System CIO, their entire career depends on ensuring there is no security breach when they hand over the keys to the castle (eg UnitedHealth failures from 2024).

Pre-op

Timeframe?

For reasons discussed below, this is akin to asking how long is a piece of string. In fact, even the average timeframe isn't particularly helpful. For example, I have one client who just got back to me after nearly two years, during which their project was placed on hold at UCSF. That said, the median timeframe would be a few months.

Security Questionnaire

Every Health System has some form of vendor security questionnaire and you want to try to get a hold of that as early as possible. Even if they use a cloud-based compliance system with web forms, ask if they have a spreadsheet copy or screenshots they can share in advance so you can start ensuring you have everything checked-off.

Most Health Systems I've encountered require the gold standard SOC 2 Type II (or the equivalent ISO 27001). If a vendor has not yet completed the attestation or only holds a Type I (point-in-time) while working toward Type II (which requires a minimum three-month surveillance), some Health Systems may be willing to move forward with the assumption that it will be completed before go-live. Others, however, will not even consider the vendor until the attestation is finalized. There are exceptions - the most minimal security requirements I’ve seen from a Health System included only a HIPAA Security & Privacy Statement, a Continuity and Disaster Recovery Plan, an Incident Response Plan, and a Staff Security Training Checklist.

The questionnaire may also include requests beyond the scope of SOC 2, such as results from a recent Security Penetration Test. In many cases, these additional tasks can be performed and remediated without blocking project progress.

What about HITECH and HITRUST?

HITECH is federal law that outlines rules and controls to strengthen HIPAA but it does not require external auditing like SOC 2 or HITRUST. In short, if you have SOC 2 attestation, HIPAA security policies, breach notification procedures and BAAs then you are likely HITECH compliant. HITRUST on the other hand is the crown jewel of healthcare compliance, it is a true certification that typically takes an additional 6 months on top of SOC 2. I have not yet encountered any Health Systems that have a hard requirement for vendors to be HITRUST certified.

Implementation Guide

The Implementation Guide is the Most Valuable Player of deliverables - it reflects on you as the vendor, sets the tone for the engagement and propels the entire project - this is not something you want to leave to a junior or ChatGPT.

First and foremost, a well-crafted Implementation Guide should strike the right balance: clear and concise enough for a non-technical reader to quickly grasp what your app does and how it integrates with their organization, while still providing the necessary technical details for an EHR specialist to architect the integration without having to follow up with endless questions. It should prioritize nice diagrams over dense text, and be structured so that high-level information is presented upfront, with more detailed technical specifics referenced towards the end.

Additionally, the guide should focus equally on the Ops and Organizational processes involved in the implementation. This includes identifying key stakeholders, providing a template project plan and schedule, offering an agenda for the kick-off call, and outlining the steps for clinical UAT and cutover to production.

The Implementation Guide should be delivered to the Health System as early as possible (because it should be something you're proud of and demonstrates you have your act together) but often it is not requested or read until after the Security Questionnaire is underway.

If you need help designing an EHR integration or writing your Implementation Guide get in touch.

Data Governance and Architecture Reviews

These reviews typically involve calls with a wide range of Health System participants, including stakeholders and staff from relevant departments. A good Implementation Guide ought to provide all the necessary information, but you should also be prepared to address any ad-hoc questions that may require more detailed answers. Common topics discussed include Data Security, Ownership, Access Control, Lifecycle Management, Auditing, Incident Response, On-Prem vs Cloud, Authentication, High Availability, Change Management, Auditing and Testing.

The primary objectives of these reviews are twofold: first, to ensure everything is in order on the vendor side, and second, to allow the Health System to estimate the effort required, assess resources, and establish a timeline for implementation, all of which feeds-in to the Capital Committee review.

Capital Committee Review

A client I worked with once compared this process to a farmer pulling a cart through a market, with each seller piling on their goods along the way. Similarly, as the review call moves through each group involved or impacted, the respective costs are announced and recorded. These may include unexpected expenses, for example the Nurse Informatics Group needing to adjust protocols or update training materials indirectly affected by the app.

The findings from the Data Governance and Architecture Reviews will inform cost estimates, just as budget considerations from the Capital Committee Review may influence decisions in those reviews (eg. On-Prem vs. Cloud). Expect weeks of back-and-forth discussions and follow-up calls as these factors evolve.

Who pays?

The answer varies depending on several factors, but in my experience, about half the time, the Health System covers its internal costs, while the other half, the vendor either shares or fully covers them. I've also seen cases where funding came from external sources, such as an NIH grant or an SBIR award.

However, it's important to note that covering or sharing these costs does not necessarily move the project to the front of the queue. Health System integrations are rarely as simple as hiring an EHR analyst to focus on a single project, even when working through the EHR account manager. For example, in one case with a Health System using Cerner, we had to navigate a little-known custom development department within Oracle. That process alone involved months of calls, emails, and quotes just to schedule the development of a relatively minor integration.

Contract Redlining, Execution and Resource Allocation

Tasks on the Business Track typically run in parallel to the Tech & Ops Track, with contracts evolving as decisions are made. Then, at long last—when the stars align and you feel like you’ve aged a lifetime since the process began—you receive the long-awaited email: the contract has been executed, and you can finally see the sun (or moon) again.

Now that the Health System can allocate a PM and staff can track and bill their time to the project, you'll often notice a seismic shift in responsiveness. The project begins to gather momentum—what would normally take hundreds of emails can now be accomplished in a single phone call by an internal PM."

On The Table

Timeframe?

Redox, that do this every day all day, average 10-14 weeks from kickoff to go-live. However, I've seen a simple integration completed in just four weeks. Ultimately it all depends on the Health System's resource availability.

Thoughts on Redox?

I've worked with Redox on a couple of projects and have nothing but good things to say about them. They're highly regarded and well-trusted in the industry, and partnering with them can lend credibility to your own efforts. That said, they are expensive, I tend to agree that they're not a complete integration strategy, and they don't get involved in anything prior to contract execution (ie everything covered above), which for first-timers is probably the heaviest lift.

Kickoff Call

It's important to get everyone together, but no one enjoys long, drawn-out calls, especially busy people, and even more so, busy technical people. A clear, structured agenda is essential, but instead of yet another document buried in yet another email thread with a million CCs, it should already be in your Implementation Guide.

For many on the call, this may be their first time seeing the Implementation Guide and in the spirit of how Bezos famously structures Amazon meetings, carving out time to walk them through is a key function of the call itself.

Weekly Update Calls

Be sure to schedule these in the Kickoff Call - they help keep the project on track by ensuring tasks are progressing, identifying bottlenecks early, and keeping stakeholders accountable. They provide a forum for resolving challenges while ensuring alignment across business, clinical, and IT teams. Regular check-ins also improve decision-making, mitigate risks, and maintain project momentum by keeping everyone engaged and informed.

Training

It's important to get this moving alongside the technical implementation. Training Health System staff on a new application isn’t as simple as sending a calendar invite and calling it a day. With packed clinical schedules, rotating shifts, and diverse learning needs, careful planning is essential to ensure everyone gets the right training without disrupting patient care.

Building

Getting the EHR and authentication interfaces up and running is usually the easy part—wrangling the right people, finding time on their packed calendars, and getting configuration details and approvals is where things get tricky. It can feel like a scavenger hunt, except instead of treasure, you're chasing down magic numbers and signoffs. The real secret weapon? Excellent documentation. Not just good, but great documentation wins the hearts of the tech team, cuts down on endless email chains, and helps move things along without unnecessary detours.

End-to-end Testing

End-to-end testing is where all the pieces come together, the moment when months of meetings, emails, and "just one more review" cycles turn into something real. It’s the first time you get a tangible result to point to, a milestone that proves all the effort is paying off. On one side, you’ve got the clinical team ready to put the app through its paces; on the other, the tech team crossing their fingers that everything works as expected. It’s a critical, albeit sometimes chaotic, convergence of front-end and back-end, where all the planning meets reality, and hopefully, reality cooperates.

User Acceptance Testing (UAT)

This is where the rubber meets the road - real users finally get their hands on the app and put it through its paces. It’s the moment of truth where we find out if everything actually works in the real world or if there are quirks that only a clinician clicking at 100mph can uncover. Catching issues now, before go-live, saves a world of pain later, so while it might feel like just another checkbox, a smooth UAT can mean the difference between a launch day celebration and a last-minute scramble.

Go Live

Swapping the training wheels of the test environment for the real thing, this phase requires careful coordination to ensure a seamless shift, with a focus on addressing any last-minute issues that may arise. Expect a mix of high-fives and last-minute troubleshooting, but once that first real patient encounter flows through successfully, it’s officially live, and you've crossed the finish line.

Support

As with any new system, there may be some bumps along the way, whether on the tech or user side. But that’s where your support team comes in, ready to swoop in, keep things running smoothly, and ensure the Health System can handle any curveballs that come their way.

Closing Up

I hope you've found this guide useful and it's important to note that each Health System marches to the beat of its own drum, so flexibility and adaptability are key, but excellent documentation and consistent communication will be your best friends.

Key Takeaways

• Start Early: Gather compliance documentation (e.g., SOC 2) upfront to avoid delays.
• Focus on Communication: Regular, clear updates with stakeholders are essential to keep things on track.
• Expect Delays: Resource constraints in Health Systems can push back timelines, so plan for flexibility.
• Invest in Documentation: High-quality Implementation Guides and clear processes reduce back-and-forth and speed up decision-making.
• Manage Expectations: Be patient and proactive, as internal Health System teams often have competing priorities.