EHR builds rarely fail in the code. They fail because a decision nobody made in month one turns up in month nine: the record has to be certified after all, a second care setting joins the scope, or the data model cannot represent the thing the clinicians care about most.
This guide lists the decisions to settle before the first sprint, in the order they constrain each other. It assumes you have already decided to build. Each section names the decision, the options and what goes wrong when it is left open, and the guide ends with a readiness checklist your team can sign off.
What are EHR build prerequisites?
Starting an EHR build?
Agnotic helps clients settle scope, certification, data model and safety decisions, then builds the EHR against them.
EHR build prerequisites are the decisions a team settles before writing code: which care settings and users the record serves, whether it will be ONC certified, how the data model and terminologies work, which parts are bought, who owns clinical safety, and how security and hosting are set up. Each one shapes the architecture.
None of these needs a perfect answer. Each needs a written answer, an owner, and a date on which it will be reviewed. An open decision is still a decision; it just gets made by whoever writes the code that week.
Which care settings and users is the record for?
Settle the care settings, specialties and user roles first, because they decide the shape of the chart. An outpatient record, an inpatient record and a home-based record differ in encounters, orders and documentation from the first screen.
- Settings: Ambulatory, inpatient, emergency, home or virtual. Each adds its own encounter types, scheduling and orders.
- Specialties: List the ones in scope for the first release and the ones expected later, so the model leaves room for their data.
- Roles: Physicians, nurses, care coordinators, front desk, billers, patients and caregivers. Each role needs its own permissions and views.
- Sites and tenants: One organization or many. Multi-tenancy is far cheaper to design in than to add later.
- Out of scope: Write down what the first release will not do, such as inpatient medication administration, so it does not creep back in.
Have the clinical lead approve this list, not the engineering lead. The people who will document in the record are the ones who know which setting or role was quietly left out, and they should see the list before design begins.
Will the EHR be certified, and to which criteria?
Decide on ONC certification before design, because certified criteria add features that are expensive to retrofit. If your users take part in CMS programs that require certified EHR technology, certification is not optional.
Electronic health information (EHI) export is a good example. ONC's companion guide for 45 CFR 170.315(b)(10) requires a certified product to let a user create an export of all of a single patient's EHI at any time, without developer assistance, in an electronic and computable format, with a publicly accessible link to the export format. It also requires an export for the whole patient population.
That one criterion touches the data model, the file storage, the permissions system and the documentation. A team that learns about it after launch has to trace every place data is stored. A team that knows from the start keeps a catalog of stored data as it builds.
- No certification: Fine for products outside CMS payment programs, but still plan export, audit and API features, because buyers and regulators ask for them.
- Selected criteria: Certify the modules your customers need, such as the standardized API or quality measures, and pair with other certified products for the rest.
- Full Base EHR: Needed when your customers must meet the Base EHR Definition with your product alone.
How will the data model and terminologies work?
Choose the storage approach and the code systems before the first table is created. Changing either after real patient data exists means a migration inside your own product.
- FHIR-native store: Data is kept as FHIR resources, which makes the API simple and complex reporting harder.
- Relational core with a FHIR layer: Data lives in your own schema and is mapped to FHIR at the API, which gives reporting flexibility and adds mapping work.
- Terminologies: Pick SNOMED CT for problems and findings, LOINC for labs and observations, RxNorm for medications and ICD-10-CM for billing diagnoses, and decide where the mappings between them live.
- Patient identity: Decide how duplicate patients are detected and merged, and what an identifier from another system means in yours.
- Versioning and audit: Decide whether every change to clinical data is kept as a version, which most clinical records need for amendments and legal holds.
Write a short data dictionary for the first release: each concept, its code system, its required fields and its owner. It becomes the reference for the API, the reports and the export.
Which parts will you buy instead of build?
Buy the parts that are commodity, heavily regulated or networked, and build the parts that carry your care model. Make the list before design so the architecture plans the seams.
- E-prescribing: Connecting to a prescription network and handling controlled substances usually means a certified partner.
- Claims and eligibility: A clearinghouse handles X12 837, 835, 270 and 271 transactions with payers.
- Lab and imaging connectivity: HL7 v2 interfaces through an interface engine, or a lab network partner.
- Identity and sign-in: An identity provider with multi-factor authentication, instead of a home-grown login.
- Drug and clinical content: Drug interaction databases and clinical content come from licensed sources.
Who owns clinical safety and regulatory calls?
Name a clinical safety owner and a regulatory owner before design, and give them the authority to stop a release. Decisions about alerts, defaults and calculations are clinical, even when an engineer writes them.
Decision support is where this matters most. FDA's Clinical Decision Support Software guidance describes four criteria a software function must meet to be excluded from the device definition under section 520(o)(1)(E) of the FD&C Act. The fourth is that it enables a health care professional to independently review the basis for its recommendations, so the professional does not rely primarily on them for a decision about an individual patient.
That criterion is a design requirement. If the EHR will show risk scores or treatment suggestions, the screens must show the inputs and the logic behind them, and the regulatory owner must decide early whether any function falls outside the exclusion.
What security and hosting decisions come first?
The first security decision is the risk analysis. Under 45 CFR 164.308(a)(1)(ii)(A), a required specification of the HIPAA Security Rule, a covered entity or business associate must conduct an accurate and thorough assessment of risks to the confidentiality, integrity and availability of the electronic protected health information it holds. HHS describes it as the first step in choosing safeguards.
- Hosting: Choose the cloud provider and region, and sign its business associate agreement before any real data arrives.
- Environments: Development, test, staging and production, with synthetic patients everywhere except production.
- Access model: Role-based access with break-the-glass rules for emergencies, and an audit trail of every chart opened.
- Encryption and keys: Decide who manages keys and how backups are encrypted and restored.
A readiness checklist before sprint one
Sign off each item with a name and a date. If an item cannot be signed, the build is not ready to start, and the gap belongs at the top of the plan.
- 1. Scope: Settings, specialties, roles and the out-of-scope list are written and approved by the clinical lead.
- 2. Certification: The certification decision and target criteria are recorded, with the payment programs they serve.
- 3. Data: Storage approach, code systems, identity rules and the first data dictionary are agreed.
- 4. Buy list: Partners for prescribing, claims, labs and identity are chosen or shortlisted.
- 5. Safety: A clinical safety owner and a regulatory owner are named and have release authority.
- 6. Security: The initial risk analysis is done, and hosting and its agreement are in place.
- 7. Migration: Source systems for existing records are known, with a sample extract in hand.
- 8. Users: A group of clinicians has agreed to test each release in a real workflow.
How do unsettled prerequisites show up later?
Unsettled prerequisites show up as rework, usually after real users or real data arrive. Each symptom below traces back to one of the decisions above.
- Late certification: A customer's compliance team asks for the CMS EHR Certification ID, and audit, export and API features are rebuilt under deadline.
- Scope drift: A second specialty is promised to a customer, and the note and order models turn out to assume the first one everywhere.
- Code system gaps: Problems were stored as free text, so quality measures and registry submissions need a manual coding project.
- Duplicate patients: No merge rules were agreed, and records from an imported system create two charts for the same person.
- Unowned alerts: An engineer adds a default dose or an alert threshold, and no clinician reviewed it before release.
- Migration surprises: The legacy extract arrives in the final month with formats nobody planned to load.
Migration deserves its own early test. Ask for a sample extract from every source system during discovery, load it into a scratch copy of the planned model, and list what does not fit. The list usually changes the data dictionary, and finding that out before the build is far cheaper than after it.
How Agnotic can help
Agnotic Technologies runs a short discovery with your clinical, regulatory and technical leads to settle these decisions in writing, then builds the EHR against them. Certification criteria, the data dictionary and the risk analysis shape the architecture from the start instead of arriving as change requests.
For teams that have already started, Agnotic reviews the open decisions in a build in progress and turns each one into a plan, starting with the ones that are most expensive to change later.
Settle the decisions before the code
Plan your EHR build with our engineers, or read more EHR articles in the integration hub.
Related reading on Agnotic
See how an EHR build runs once these decisions are made, whether building your own pays off, how the data and security layers fit, and how the EHR will integrate with other systems.
