The pilot went well. Genuinely well. Nurses at two medical-surgical units gave the care coordination tool strong satisfaction scores during the 90-day evaluation. The product team left the pilot review feeling confident. The health system signed the expansion contract.
Six months into full deployment, utilization had dropped to under 15% of the target nursing staff. Not because the tool stopped working. Not because the health system lost interest. Because when the tool went live across all units, nurses discovered that using it required switching away from their EHR screen, opening a separate browser tab, and re-entering context they had already entered in the EHR two minutes earlier.
In the pilot, nurses had been specifically recruited and given dedicated time during onboarding. In production, they were mid-shift, managing four to six patients, getting interrupted every eight minutes, and working on terminals that the IT department had locked to the EHR client by default. The separate tab was technically accessible. It was just never going to win against the cognitive and physical reality of that environment.
This is not a product failure story. It is a workflow design failure story. And it is one of the most common patterns I see when health-tech products move from controlled evaluation to real clinical deployment.
The Fundamental Misread
Most health-tech products are designed on laptops, in offices, by teams who have never spent a shift on a medical-surgical floor or inside an ED.
That is not a criticism. It is a structural reality that produces a predictable design assumption: that the user has a moment of relative calm, an available screen, and a reason to seek out the tool. In ambulatory settings, that assumption is occasionally accurate. In inpatient and ED settings, it is almost never true.
On a hospital floor, a nurse’s attention is allocated in fragments. They are not navigating to tools. They are responding to what appears in front of them. The EHR is already open because it has to be open. The workstation is often shared, sometimes on wheels, and typically locked to a specific application profile by the IT security team. The patient context, who this nurse is caring for, which encounter is active, what just happened in the last hour, already exists inside the EHR. Any product that asks the nurse to restate that context in a different interface has already failed the first design test.
The design question is not “is our product useful?” It is “does our product appear inside the workflow that already exists, with the context that already exists, without requiring the clinician to do anything extra to get there?”
If you cannot answer yes to that, you are building for the demo, not for production.
What EHR-Locked Terminals Actually Mean for Your Product
Most founders understand in the abstract that hospitals use EHRs. Fewer understand what that means at the infrastructure level when their product needs to run alongside one.
In inpatient and ED settings, workstations are typically configured by the health system’s IT team with a locked application profile. The EHR client, usually Epic, Oracle Health, or Meditech, is the primary and often only application that opens by default. Browser access may be restricted, filtered, or require a separate authentication step. Some terminals are shared across multiple clinicians, which means session state cannot be assumed. Some are on wheels and move between rooms, which means a clinician may pick up a device mid-task that has someone else’s session open.
This environment has direct consequences for product design.
A product that runs as a standalone web application, regardless of how well it is built, is not native to this environment. It requires the clinician to leave the EHR client, open a browser, authenticate, and re-establish patient context. Each of those steps is a dropout point. In a controlled pilot, motivated participants will complete those steps. In production, across an entire floor of nurses managing real patient loads, the majority will not.
The only integration pattern that reliably survives this environment is EHR-embedded. Specifically, a product that launches from within the EHR workflow, carries the patient and user context automatically, and does not require a separate login.
If you only remember one thing: if your product requires a second login, adoption drops. Not by a small margin. By enough to make your utilization numbers clinically irrelevant.
The Three Patterns That Actually Work
SMART on FHIR contextual launch. This is the most durable pattern for EHR-embedded products. A SMART on FHIR application launches from within the EHR, typically as an embedded panel or modal, and receives patient context, user identity, and encounter data as part of the launch sequence. The clinician does not re-authenticate. They do not re-enter the patient. The application opens with context already populated, within the EHR interface, without requiring the clinician to navigate anywhere.
The tradeoff is real: SMART on FHIR apps require the health system’s EHR team to configure and approve the launch, which adds implementation timeline and dependency on IT. Epic’s App Orchard and Oracle Health’s App Exchange are the formal channels for this. Approval timelines vary widely, from weeks to months, and the configuration work on the health system side is non-trivial. This is not a reason to avoid the pattern. It is a reason to plan for it from the start rather than discovering it at implementation.
CDS Hooks. For products that need to surface information or recommendations at a specific point in the clinical workflow, rather than as a standalone application, CDS Hooks is the right pattern. A CDS Hook fires at a defined EHR event, an order entry, a medication review, a patient discharge, and injects a card or alert into the EHR interface at that moment. The clinician sees the recommendation inside the workflow they are already in, without launching anything separately.
CDS Hooks is particularly well-suited for AI-generated recommendations that are contextually triggered. A sepsis risk alert at order entry. A care gap notification when a provider opens a patient chart. A drug interaction flag during medication reconciliation. The pattern ensures the output appears at the moment of relevance, not at a moment the clinician has to separately seek out.
The design constraint worth understanding: CDS Hook cards are deliberately limited in what they can display. They are not rich interfaces. If your product requires a complex interaction or detailed visualization, CDS Hooks gets you to the door but not all the way in. The right pattern is often a CDS Hook that surfaces a summary and launches a SMART app for the full interaction.
Native EHR build. For products that are deeply integrated into a specific EHR, Epic’s Cognitive Computing Platform or the equivalent in Oracle Health, a native build inside the EHR’s development environment is the most seamless option and the hardest to maintain across EHR versions. This path is typically relevant for health systems building internal tools, or for vendors with a deep enough relationship with a single EHR to justify the development investment. For most early-stage founders, SMART on FHIR is the more practical starting point.
Contextual Identity: The Detail Most Products Get Wrong
Even among teams that have correctly chosen EHR-embedded integration, contextual identity is where implementation frequently breaks down.
Contextual identity means your product knows, at the moment of launch, who the user is, what role they hold, which patient is active, and what encounter context is relevant. In a SMART on FHIR launch, this information is passed as part of the OAuth token exchange. The EHR tells your application the FHIR patient ID, the practitioner ID, the encounter ID, and the user’s role scope.
Most products receive this context correctly in development. Where it breaks in production is at the edges: shared workstations where session handoffs are incomplete, terminals where the EHR session has timed out and the launch sequence passes stale context, or environments where the health system’s FHIR server returns a different patient ID format than the one your application was tested against.
These are not hypothetical edge cases. They are the scenarios your implementation team will encounter at the third or fourth health system deployment when the EHR configuration is slightly different from what you tested against.
The practical implication is this: build explicit context validation into your application’s launch sequence. Before rendering anything to the user, verify that the patient ID, encounter ID, and user role are present, non-null, and in the expected format. If context is missing or malformed, surface a clear message rather than a broken interface. Clinicians who see a broken interface once tend not to relaunch the application. They work around it, and the workaround becomes permanent.
Red flag: If your SMART on FHIR app has no handling for missing or malformed launch context, it is not ready for multi-site production deployment.
Designing for Interrupted Attention
One more design reality that pilots consistently mask and production consistently exposes.
In an ED or inpatient floor, a clinician using your product will be interrupted. Not occasionally. Routinely. A nurse opens your care coordination panel, reads the first two lines, gets called to a patient room, comes back four minutes later, and the session has timed out. A hospitalist opens your recommendation card during rounds, gets asked a question by a resident, and closes the window without acting.
Products designed for uninterrupted attention fail in these environments. The design requirement is for the product to be useful in a 30-second interaction, resumable without re-navigation, and tolerant of abandoned sessions.
Practically, this means: the most important output should be visible above the fold, without scrolling, without tabs. Actions should be completable in a single click from the primary view. Session state should persist across interruptions without requiring the clinician to re-establish context. And the product should be designed around the assumption that the average interaction is incomplete, not complete.
Decision rule: If your product’s primary value requires more than 90 seconds of uninterrupted attention from an inpatient nurse or ED clinician, the workflow design needs to be reconsidered before the integration pattern is even relevant.
A Practical Pre-Integration Checklist
Before committing to an EHR integration approach at a new health system, validate these points:
- What EHR and version is the health system running? SMART on FHIR support varies significantly between Epic versions and is not universally enabled in Oracle Health or Meditech environments.
- Are SMART on FHIR apps enabled on their instance? Many health systems have not activated the App Orchard framework or have it restricted to specific departments.
- What is the IT approval process and estimated timeline for a new SMART app configuration?
- Are the target workstations shared or individual? If shared, how does session handoff work and how does it affect launch context?
- What is the browser policy on clinical terminals? If your SMART app relies on specific browser capabilities, verify they are available in the locked terminal environment.
- Who owns the CDS Hooks configuration if you are using that pattern, and what is the change management process for adding a new hook?
None of these questions are answerable from a vendor’s documentation. They require a conversation with the health system’s EHR team before implementation begins. The founders who skip this conversation are the ones who discover the answers six months into an implementation that is running three months late.
Closing
The nurses who stopped using that care coordination tool were not resistant to technology. They were rational. They had a finite amount of attention, a locked workstation, and a workflow that had been optimized over years to minimize unnecessary steps. A product that added steps lost.
Good clinical product design is not about building features that clinicians will appreciate in a calm moment. It is about building interactions that fit inside the most constrained moments, on the most restricted hardware, with the least available attention, in the middle of a shift that started six hours ago.
The EHR is not the enemy of your product. It is the surface your product has to live on. Design for that surface from the first wireframe, not from the first failed deployment.
