Resources for Healthcare Founders by Stage

Which resources should a healthcare founder use first?

The first resources a healthcare founder should use are the ones published by the bodies that set the rules: HHS Office for Civil Rights for HIPAA, the FDA Digital Health Center of Excellence for device questions, ASTP/ONC for certified health IT, CMS for payment, and HL7 for data standards. Summaries help with orientation, not decisions.

The test for a primary source is simple. It is written by the regulator, the standards body or the vendor that owns the system, and it carries a date or version. If a page has neither, find the document it is summarizing and read that instead.

Keep a short source log from the first week. For each decision that rests on a rule or a standard, note the document, its version or date, and the section relied on. That log becomes the backbone of investor diligence answers and of the first customer security review.

Where do privacy and security answers come from?

Privacy and security answers come first from HHS OCR, which administers HIPAA, and from the FTC for health apps that sit outside HIPAA. Start by working out which regime applies, because that decides almost everything else about how the product handles data.

• HHS OCR HIPAA for Professionals: the official home of the Privacy, Security and Breach Notification Rules, with guidance on business associates, cloud computing, health apps and the right of access.
• FTC Mobile Health Apps Interactive Tool: a question-based tool on ftc.gov that suggests which federal laws may apply to an app, including HIPAA, the FTC Act, the Health Breach Notification Rule and COPPA.
• Security Risk Assessment Tool: a free tool from ASTP/ONC and OCR that walks a small organization through a HIPAA risk assessment.
• NIST SP 800-66 Rev. 2: a NIST guide that maps HIPAA Security Rule standards to practical cybersecurity activities.

The FTC tool is a good first step for a consumer app because it asks plain questions about who the users are and where the data goes. It states that it is not legal advice, so treat its output as a list of questions for counsel rather than a conclusion.

ASTP/ONC states that the Security Risk Assessment Tool was developed with the HHS Office for Civil Rights for small and medium providers. A startup that is a business associate can still use it to structure its own risk analysis, even though some questions assume a clinic setting.

NIST published SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide, in February 2024. It is a practical document for turning the technology-neutral Security Rule into an engineering backlog, because it lists activities and related NIST controls for each standard.

Does the product need FDA input?

The product needs FDA input if any software function may meet the definition of a medical device, and the FDA Digital Health Center of Excellence is where to start finding out. Answer this question before building clinical features, because device status changes the development process, not just the paperwork.

The Digital Health Policy Navigator on fda.gov walks a developer through a series of questions about a software function and points to the policies that may apply. FDA says its results are not a formal device determination, so record the answers and the reasoning, and revisit them each time the feature set changes.

For clinical decision support, read the FDA guidance itself. FDA issued its final Clinical Decision Support Software guidance on 6 January 2026 and re-issued it on 29 January 2026. It explains which decision support functions fall outside the device definition and which do not, including the exclusion for software that analyzes medical images or physiological signals.

When the answer is still unclear, FDA's Q-Submission program is the formal route for asking the agency questions before a marketing submission. A founder who goes that route needs a clear description of the intended use and the software functions, which is useful discipline on its own.

Where do interoperability rules and standards live?

Interoperability rules live with ASTP/ONC on healthit.gov, and the data standards they reference live with HL7 on hl7.org. A founder selling into hospitals needs both, because customers will ask what the EHR exposes and how the product uses it.

• HL7 FHIR specification: the base standard, published by version, with every resource, data type and RESTful operation defined.
• US Core: the HL7 implementation guide that sets US profiles and must-support elements, and the profile set ASTP/ONC certification references for the (g)(10) API.
• SMART App Launch: the HL7 guide that defines how an app launches from an EHR or a patient portal and gets an OAuth access token.
• Certified Health IT Product List (CHPL): the ASTP/ONC list of certified products, useful for checking what a customer's EHR version is certified to do.
• Inferno: an ASTP/ONC-hosted FHIR testing tool with test kits such as the (g)(10) Standardized API kit and the US Core kit.

Read the version you are building against, not the latest one. Each HL7 guide publishes a version history, and a customer's EHR may support an older US Core release than the one on the home page. Write the target versions into the product's technical documentation.

CHPL listings are a quick way to check claims during sales. If a customer says their EHR supports a given API, the certified product listing shows which criteria it was certified against, which tells you where to look in the vendor's documentation.

Which sandboxes let you test before a pilot?

EHR vendors and standards projects run sandboxes that let a team test against example data before any customer is involved. Testing there first means the pilot is spent on site-specific issues, not on basic connection bugs.

• Epic on FHIR (fhir.epic.com): Epic's free developer site, with API documentation, client registration and a testing sandbox with example data.
• open.epic: Epic's public site for interface specifications and its developer programs.
• Oracle Health (Cerner) developer documentation: the vendor's published FHIR API documentation for its Millennium platform.
• SMART App Launcher: a public launcher from the SMART Health IT project that simulates an EHR or portal launch for testing SMART apps.
• Synthea: an open-source synthetic patient generator that produces realistic test records, including FHIR output, with no real patient data.

Use synthetic data everywhere outside production. Demo environments, pitch decks and test fixtures that contain real patient data create HIPAA questions and diligence problems that a generated data set avoids entirely.

Sandboxes are not the same as production. A sandbox may enable APIs or scopes that a given customer has not turned on, and example data rarely shows the coding quirks of a real site. Plan time in each pilot for a site-specific discovery step.

How do founders check whether a service is billable?

Founders check billability in CMS's own documents: the Physician Fee Schedule final rule for each year, the Medicare Learning Network (MLN) booklets that explain specific services, and the coverage and payment look-up tools on cms.gov. Payer contracts and state Medicaid rules then add their own conditions.

Read the final rule, not the proposed one, when building billing logic. Proposed rules can change before they take effect, and a product that encodes a proposal as current law will need rework. Track each code the product relies on, the rule year it comes from, and the date to check it again.

MLN booklets are written for providers and billing staff, which makes them easier to read than the rule text. They still cite the rule, so a founder can trace any line in a booklet back to the regulation before encoding it.

A resource map by stage

Most founders do not need every resource at once. This map lists what to open at each stage and the output each stage should leave behind.

• 1. Idea: run the FTC interactive tool and the FDA Policy Navigator on the planned features, and record which regimes may apply and the questions for counsel.
• 2. Prototype: build on synthetic data from Synthea, test SMART launch flows on a public launcher, and write down the FHIR and US Core versions you target.
• 3. First customer: read HHS OCR business associate guidance, run a risk analysis with the SRA Tool or NIST SP 800-66 Rev. 2, and check the customer's EHR listing in CHPL.
• 4. Pilot: register in the EHR vendor's developer program, test in its sandbox, run Inferno test kits where they apply, and plan site discovery.
• 5. Revenue model: trace every billing assumption to the current CMS final rule or MLN booklet and set a review date for each code.
• 6. Clinical features: reread the FDA CDS guidance for each new decision support function and update the device assessment.

Two failure points recur across stages. The first is relying on an old summary after the underlying rule has changed. The second is treating a sandbox result as proof that a production site will behave the same way. A dated source log and a discovery step in every pilot address both.

How Agnotic can help

Founders spend early months translating regulations and standards into product decisions, and a mistake there is expensive to undo. Agnotic Technologies builds software for digital health startups and works from the same primary sources: risk analyses mapped to the Security Rule, FHIR and SMART integrations tested in vendor sandboxes, and billing logic traced to current CMS rules.

Agnotic does not give legal or regulatory advice. It builds the product, documents the engineering decisions against their sources, and works alongside the founder's counsel and regulatory advisers.

Sources

• NIST SP 800-66 Rev. 2: Implementing the HIPAA Security Rule (February 2024)
• ASTP/ONC: Security Risk Assessment Tool
• FDA: Clinical Decision Support Software guidance
• FTC: Mobile Health Apps Interactive Tool