Many health-tech startups plan their product around a simple promise: the app will connect to the electronic health record, and the data will flow. The promise is realistic, but the path to it is mostly made of steps that have little to do with writing code. Registrations, reviews, sandboxes and per-organization onboarding all take calendar time, and none of them can be rushed by the startup. A founder who sees them early can plan a runway and roadmap around them. One who sees them late finds that engineering was never the bottleneck.

This article lists what to plan for, in the order the work tends to arrive, and treats timelines as phases with gates instead of numbers.

Phase one: decide what the product really needs

Integration work starts with a scoping decision. List the data the product reads, the data it writes back and the users who will trigger each action. Reading a patient’s medication list is a different undertaking from creating an appointment or writing a note, and write access normally brings more scrutiny and more testing.

Then decide which EHR platforms matter. Large vendors differ in how they expose data, in which capabilities they support and in how they onboard outside developers. A startup that treats “major EHRs” as one target tends to underestimate the work. Pick the first platform based on where the first customers are, and treat each later platform as a separate project that reuses what it can.

Check the standards baseline early. In the United States, health IT certified under the ONC program has to offer a standardized API, and the HealthIT.gov test method for the certified API criterion specifies FHIR Release 4.0.1, the SMART App Launch implementation guide, US Core and bulk data access. The same criterion requires developers to publish complete API documentation through a public link, including the technical requirements an app must meet to register with the authorization server. In practice, this means a startup can read the rules of engagement before it signs anything.

Phase two: work in the sandbox

Most platforms offer a sandbox or test environment populated with synthetic patients. It is the right place to build the first version of the integration, because mistakes there cost nothing and no real patient data is involved.

Treat sandbox success with caution, though. A sandbox is cleaner than production. It has well-formed records, predictable permissions and no legacy quirks. An app that works there has shown that the happy path functions. It has not shown that the app copes with missing fields, local code sets or unusual data from a particular health system.

Use this phase to settle the engineering foundations: authorization, data mapping, error handling and a test suite that can be re-run against each platform. The SMART App Launch specification is the core reference for authorization, since it defines how apps are authorized, how they discover server capabilities and how scopes limit access.

Phase three: registration and review

To reach real systems, an app generally has to be registered with the platform. Registration typically involves describing the app, declaring the data scopes it will request, supplying redirect addresses and, for apps that authenticate with keys, providing public keys. Some platforms run a review before an app becomes available to customers, and some maintain a directory or marketplace where approved apps are listed.

The processes vary from vendor to vendor, and the startup does not control their pace. Three practical habits help.

Request narrow scopes from the first submission. A review that sees a request for far more data than the described features need is likely to ask questions, and each round of questions adds waiting time.

Keep documentation ready: a data-flow description, a security overview and a clear statement of what the app does with the data. These artifacts will be requested more than once, by vendors and later by health systems.

Plan the first submission as a learning exercise. Feedback from the first review is information about the platform’s expectations that no public document fully captures.

Phase four: onboarding at each health system

Passing a platform’s review rarely ends the process. Health systems are separate organizations, and each decides whether and how to activate an app inside its own environment. That usually means a security assessment, agreements about data handling, configuration of the app inside the local EHR instance and testing with the organization’s own data.

For a startup, this phase determines the revenue timeline more than any other, and it is the one least within its control. Plan for it by identifying a contact who owns integrations at the first customer early, not after contract signature, and by treating each new customer as a repeatable onboarding procedure with a checklist.

Phase five: operations

An integration that has gone live needs an owner. APIs get new versions, scopes change, tokens expire and server behavior shifts. Someone has to watch error rates, handle failed requests and respond when a health system changes its configuration.

Budget for this from the start. A startup that treats go-live as the finish line will find its first support burden arriving in the same month as its first reference customer.

A planning checklist in prose

Before committing to an integration roadmap, a founder should be able to answer a short set of questions. Which data does the product need, and in which direction? Which platform comes first, and why? Where is the vendor’s published documentation, and what does it require? What is the first sandbox milestone, and what evidence will show the integration is ready for review? Who handles security questionnaires? Who owns the integration after launch?

Teams that would rather bring in outside engineers for the technical layer can find the EHR and EMR integration engineering offered by JetRuby at https://jetruby.com/healthcare-app-development-company/ and should keep clinical and regulatory questions with the startup’s own clinical and compliance advisers, since the offer does not extend to them.

The common thread is sequencing. Engineering effort is the part a startup controls. Registration, review and health-system onboarding are the parts it must wait for, so they belong at the start of the plan, where they can still shape the roadmap.