Seven Decisions to Make Before You Brief a Healthcare Software Team

Say a healthcare organization sends a development partner a brief that is mostly a feature list. The partner’s first questions come from outside that list: where does the patient data go, which systems must it reach, and who signs the business associate agreement? A brief that answers those questions makes the quotes comparable, because each partner quotes against the same facts. These seven decisions come first. The checklist at the end turns decisions 1 to 6 into a brief and decision 7 into a call script.

1. Name the user and the job

Start with who uses the product and what job it does for them. A patient portal and a back-office claims tool are different products, even when they share data.

Write the job as one sentence. For example: “A nurse coordinator can see overdue follow-ups for her patients without opening three systems.” That may feel too small for a whole product, but the sentence is the test for the first release, and later decisions are checked against it.

Add one measure that tells you it worked, such as the share of overdue follow-ups closed within a week. Involve one or two real users now, because a short walkthrough of their workflow often reveals steps a requirements document misses.

2. Cut the first release down

A first release that does one workflow well teaches you more than a broad platform that stalls before launch. Pick the smallest release that a real user can use for a real task. Run it as a pilot at one location with one care team, such as a single clinic or department, before it goes to others. A second location brings its own staff, schedules, and systems, and those are better tested after the workflow works in one place. Features that do not serve the job sentence from decision 1 wait for a later release.

In telemedicine, video is the visible part, while scheduling, consent, documentation, and billing sit behind it. A first release can serve one visit type through a single consent and billing path. The other visit types and payment options go on the cut list. A breakdown of what goes into a telemedicine software build covers the patient app, doctor portal, and admin backend. It also covers the electronic health record (EHR) and pharmacy integrations behind the video call.

Write the cut list down with a reason for each item, because it becomes the roadmap for later releases. Make a first cut now and expect decisions 3 to 5 to move it, since patient data and system connections can force a second cut.

3. Map where patient data goes

Before choosing a technology, list the protected health information (PHI) the first release will collect. Note where it is stored, who can see it, and which outside services will touch it.

Hosting, messaging, analytics, and error monitoring can all end up receiving PHI if configured carelessly. Suppose your organization is a HIPAA covered entity (a provider, health plan, or clearinghouse) or a business associate of one. Then any vendor that creates, receives, maintains, or transmits PHI for you is also a business associate, and HIPAA requires a business associate agreement (BAA) with each of them. Your privacy or compliance officer can confirm your status.

A simple data-flow diagram shows which vendors need a BAA, and your development partner may be one of them, so put the diagram in the brief. If you sell directly to consumers, ask counsel whether HIPAA applies, since some consumer health apps fall outside it and other rules, such as FTC requirements, can apply instead. In that case the data-flow diagram and the test-data default below still hold, and whether the BAA and breach steps in decision 4 apply depends on counsel’s answer.

Decide early what test environments will contain. The safer default is synthetic or de-identified data (made-up records or real ones with identifiers removed), with a written exception process for the rare test that needs real records. Put that default and the exception process in the brief.

4. Build the safeguards in and set the breach clock

Much of what the HIPAA Security Rule asks of your software is decided in the design. Three technical safeguards are easier to build in than to retrofit: access control by role, audit logs of who viewed what, and encryption in transit and at rest, and your partner builds these controls.

The rule also requires a written incident response procedure and a documented risk analysis, and your organization owns both. The risk analysis is a review of where PHI sits and what could expose it, and the data-flow diagram from decision 3 is its starting point.

Under the HIPAA Breach Notification Rule, a covered entity must notify affected individuals without unreasonable delay. The outer limit is 60 calendar days after it discovers a breach of unsecured PHI, meaning PHI that is not encrypted or otherwise unreadable. A business associate must tell you before you can notify anyone, so set its notification window in the BAA. Ask for a specific number of days, and have counsel check your state’s rules, since some state breach laws are shorter than the federal limit.

5. List the systems you must connect to

Your product may need to read from or write to an EHR, a scheduling tool, a billing platform, or a lab system.

For the EHR, US rules give you a documented starting point. The Office of the National Coordinator for Health IT (ONC) runs a certification program for EHRs. If your EHR is certified under it, its developer must offer a standard API, a defined way for other software to request data. Ask your EHR vendor whether the product is certified and where its API documentation lives. Three standards sit behind that API. FHIR (Fast Healthcare Interoperability Resources) is the format the data travels in. SMART App Launch is how an outside app signs in and gets permission to read a patient’s data. USCDI (United States Core Data for Interoperability) is the baseline list of data types, such as allergies, medications, and lab results. The 2020 Cures Act Final Rule set this requirement, and the HTI-1 final rule updated it. Since January 1, 2026, the certification program requires SMART App Launch 2.0.0 and USCDI version 3.

That gives you a documented read path, but your app still has to register with the EHR vendor and clear its app review. Your organization has to approve the connection as well. Ask your EHR vendor now what registration requires and how long review takes. Your partner usually files the registration once chosen, so build that review time into the schedule. Many projects also need write-back, which sends data into the EHR, or data outside the baseline set. Ask for the standard layer and the system-specific layer to be estimated separately. The standard API covers EHR data only, so for each other system ask its vendor for API documentation and the typical approval time.

6. Choose how you will work with the partner

The same project can be run three ways, and two questions pick between them: can you name someone who sets product priorities weekly, and is the scope fixed? With team augmentation, engineers join your team and follow your process, so it needs both a product owner and an engineering process. A dedicated team is a full unit that works only on your product: you set the roadmap and priorities, and the partner runs hiring and day-to-day operations. It suits a team with a product owner but no developers and a product that will keep evolving. Outsourcing means the partner delivers a defined scope against acceptance criteria (the checks that decide whether the work is done). It suits an organization with a fixed scope and no technical staff.

Whichever model you pick, agree in writing who owns the code and who reviews it, and name who hosts, monitors, and supports the system after launch. Whoever hosts it receives PHI, so that party needs a BAA too (decision 3).

7. Decide what you will ask each partner

With the first six decisions on paper, you can judge a healthcare software development partner on specifics. Five questions to start with:

• Have they built products that handle PHI, and how do they keep it out of test environments?
• Do they bring their own BAA, what notification window does it set, and do their hosting and tooling vendors have BAAs with them?
• How do they handle EHR access and approval for each system, and what do they need from your EHR vendor by when?
• Which access control, audit logging, and encryption controls do they build by default, and what do they do during an incident?
• Does their plan keep to your first-release scope, and what risks do they flag?

Treat a vague answer to any of the first three as a warning sign. A partner with PHI experience should be able to show you a BAA template and a test-data policy.