EMR Software Development Guide

The ONC Health IT Certification Program is voluntary, but clinicians participating in CMS programs such as Promoting Interoperability and the MIPS Promoting Interoperability category need certified EHR technology. Certified developers also take on continuing duties under the program's Conditions and Maintenance of Certification, including information blocking, API, and real-world testing obligations. The ONC certification program sets the regulatory context, but it doesn't answer the first product question.

Before writing code, an EMR team must decide whether certification is needed at all, and whether to build a full EMR, buy one, or extend an existing system. Those choices shape scope, ownership, clinical risk, and operational work more than the underlying programming language. This EMR software development guide covers that decision, core modules, specialty workflows, ONC certification, HIPAA and FDA boundaries, FHIR APIs, clinical usability, AI governance, and post-launch maintenance.

Deciding whether to build, buy or extend

Most organizations that say they need EMR software development don't need to build a full system. For many clinics and specialty practices, extending an established EMR with specialty workflows, integrations, and carefully governed AI features delivers more value with less regulatory and operational exposure.

A full build makes sense when the specialty workflow is poorly served by existing products, or when the EMR itself is the product being sold. In that case, certification status, clinical content, usability, and maintenance obligations matter more than the choice between Java, .NET, or another stack.

Start with the certification question

The ONC program defines certification criteria and testing requirements for health IT products. A product can exist without ONC certification, but a provider's participation in applicable CMS programs can create a practical need for certified EHR technology. The decision belongs to the product owner and participating organization, with compliance counsel confirming the applicable program requirements.

Certification involves more than implementing a FHIR endpoint. A developer selects applicable criteria under 45 CFR Part 170, Subpart E, works with an ONC-Authorized Testing Lab and ONC-Authorized Certification Body, and maintains the product's listing on the Certified Health IT Product List when applicable. The developer also needs evidence that each certified capability works in the product configuration being distributed.

ONC's Conditions and Maintenance of Certification include eight conditions in the current ONC framework: information blocking, assurances, communications, application programming interfaces, real-world testing, attestations, business practices, and annual submission of mandatory disclosures. The Conditions and Maintenance of Certification requirements should be treated as an operating model, not a launch checklist.

Compare the ownership trade-offs

EMR strategy comparison	Best fit	Typical effort	Regulatory burden	Time to value	What the organization owns afterward
Buy	Standard clinical workflows and limited differentiation	Configuration, contracting, integration, and training	Primarily customer governance and vendor oversight	Usually faster than a full build, but depends on configuration and interfaces	Contracts, configuration decisions, workflow governance, and operational readiness
Extend	A clinic has a workable core EMR but poor specialty workflows	Specialty modules, SMART on FHIR apps, templates, integrations, and testing	Shared. The core vendor owns its certified product, while the customer owns its use, configuration, and connected software	Often the shortest path when the required extension points exist	Specialty workflows, app behavior, data governance, integration operations, and support
Build	The EMR is the product, or existing systems cannot support the specialty	Clinical platform, modules, interfaces, testing, certification work, support, and governance	Broadest. The developer owns product compliance work and the customer owns deployment and clinical operation	Usually slower than extending or buying because the product surface is larger	Product roadmap, certification evidence, security controls, clinical content, support, and regulatory maintenance

The table isn't a substitute for due diligence. A purchased system can still create heavy integration and workflow work, while an extension can become a second undocumented EMR if teams don't define data ownership and clinical authority.

Hypothetical dermatology decision

Hypothetical: A dermatology group operating ten clinics finds that its general EMR handles photo documentation, lesion tracking, and procedure templates poorly. It has three realistic paths.

A full specialty EMR would provide maximum control over the dermatology workflow. The group would also own the broadest clinical surface, including certification analysis, patient access, medication and allergy handling, orders, results, audit controls, support, and ongoing updates. This option fits only if the specialty workflow is central enough to justify taking on those responsibilities.

Extending the current EMR with a SMART on FHIR application and specialty templates may preserve the existing patient, medication, scheduling, billing, and certification foundation. The new app could display lesion-specific fields, manage photo workflows, and return structured documentation to the core record where supported. The group would need to validate SMART launch context, scopes, data completeness, clinician workflow, and failure handling.

Switching to a specialty EMR could improve the clinical fit without requiring the group to become an EMR vendor. The trade-off is migration and integration work, disruption to established routines, new vendor dependency, and careful confirmation that the replacement supports the group's CMS participation requirements.

Decision factor	Full specialty build	SMART on FHIR extension	Specialty EMR purchase
Certification need	The group must determine whether the product itself needs certification and which criteria apply	The core system's certification remains relevant, while the extension needs its own compliance and security review	The group must verify the vendor's certification status and applicable product capabilities
Integration effort	Broad integration surface across clinical and administrative functions	Concentrated around APIs, launch context, specialty data, and write-back behavior	Depends on interfaces, export capability, and replacement scope
Clinician workflow	Highest control, highest design responsibility	Preserves familiar core workflows while adding specialty capability	May improve specialty fit but requires adaptation
Data ownership	The group owns product and governance decisions	Shared operational responsibility across core vendor, app owner, and group	Defined by contract, export terms, and operational governance
Time to value	Usually the longest path	Often the most direct path if extension points work	Potentially faster than building, but replacement work can be substantial

For this hypothetical group, extending the current EMR is the default recommendation, not because extensions are automatically easy, but because it limits the product surface. The group should choose a full build only after proving that the existing EMR cannot support the required clinical workflow and that the business is prepared to own a regulated software product.

Core modules and specialty clinical workflows

A usable EMR starts with a coherent clinical record, not a feature list. Each module must preserve context across the patient chart, encounter, order, result, prescription, appointment, and billing handoff.

Core module	What it requires to build well
Patient chart and documentation	Encounter context, structured and narrative notes, attachments, author attribution, amendment handling, and templates that match real visits
Problems, medications, and allergies	Terminology mapping, reconciliation workflows, source and date tracking, status changes, and clear visibility of uncertainty
Orders and results	Order status, routing, result matching, abnormal-result review, acknowledgments, and escalation for unreviewed results
E-prescribing	Medication selection, allergy and interaction checks, refill workflows, pharmacy routing, and controlled-substance controls
Scheduling	Provider availability, location, appointment types, cancellations, reminders, and links between appointment and encounter
Billing and practice management integration	Charge capture, coding context, claim handoff, eligibility or payer interfaces where required, and reconciliation between clinical and financial records
Patient portal and patient API	Portal access, messaging, document and result presentation, consent, authorization, and the ONC standardized API requirement where certification applies

E-prescribing needs special treatment. Electronic prescriptions for controlled substances, or EPCS, are subject to DEA requirements in 21 CFR Part 1311. The product must also connect to the applicable prescription network and support the identity, signing, authentication, and audit processes required by the chosen workflow. A prescription form that merely looks complete in the UI isn't enough.

Specialty content carries the clinical value

The differentiator is often the content layer. Dermatology needs lesion characteristics, body-site mapping, image attachment and comparison, procedure templates, pathology context, and follow-up logic. Cardiology, ophthalmology, oncology, and behavioral health each require different structured observations, documentation patterns, and safety checks.

Use standards where they preserve meaning:

• SNOMED CT supports clinical findings and problems.
• LOINC supports laboratory and other observations.
• RxNorm supports normalized medication concepts.
• ICD-10-CM supports diagnosis coding in the US.
• CPT supports procedure and service coding.

These terminologies should appear in the data model, search behavior, pick lists, validation rules, reporting, and exchange mappings. Storing a free-text label beside a code creates ambiguity when clinicians revise the display name or when another system expects a different representation.

Clinical content also needs ownership. A medical director or designated clinical governance group should approve templates, order sets, required fields, alert logic, and terminology updates. Engineering implements and tests those decisions. The practice remains responsible for how staff use the configured system.

Teams building healthcare products can also learn from work on AI development beyond engineering, particularly when product, clinical, and operational stakeholders need to participate in software decisions. For healthtech organizations combining clinical workflows with automation, Ekipa's healthcare engineering work provides a relevant reference point.

Lab, imaging, and pharmacy connectivity belongs in the scope from the beginning. HL7 v2 messages remain common for orders and results, while e-prescribing networks handle pharmacy transactions. The implementation details vary by partner and use case, so the EHR integration API reference should sit beside the clinical requirements, not after them.

Navigating certification, HIPAA and FDA status

Certification, HIPAA, and FDA status answer different questions. ONC certification concerns specified health IT capabilities and program requirements. HIPAA concerns safeguards for electronic protected health information when the organization is covered by the rule. FDA status depends on the software's intended use and functions.

Separate the ONC work from the HIPAA work

ONC certification may include criteria for patient access, application programming interfaces, safety-enhanced design, clinical data, and other functions. The standardized API criterion, 170.315(g)(10), creates requirements around patient and population services that certified products must meet when the criterion applies.

Information blocking is a separate ongoing obligation under 45 CFR Part 171. Product teams should involve legal and compliance staff when designing access, export, contract, and support policies. Engineering evidence can include API behavior, access logs, test results, documented error handling, and records of product changes, but evidence alone doesn't decide whether conduct falls within an exception.

HIPAA's technical safeguards in 45 CFR 164.312 cover access controls, audit controls, and transmission security. The engineering team implements mechanisms such as unique user mappings, authorization checks, activity records, and protected data transmission. The covered entity or business associate defines the compliance program, risk decisions, policies, and operational review.

Question	Primary owner	Evidence that supports the control
Does the product meet applicable ONC criteria?	Certified developer, with testing lab and certification body involvement	Test results, certification records, product listing, and maintained documentation
Is access to ePHI limited to authorized users?	Customer governance and engineering implementation	Role and policy tests, identity mappings, access reviews, and denied-access tests
Can the organization examine system activity?	Customer compliance and engineering	Protected audit records showing access and relevant actions
Is transmitted ePHI protected?	Engineering and infrastructure owners	Configuration evidence, transport tests, and deployment review
Does a feature fall within FDA device oversight?	Product owner, regulatory counsel, and clinical safety leadership	Intended-use analysis, risk assessment, requirements, and regulatory determination

FDA status depends on function and intended use

FDA guidance on software policies explains that software intended to serve as an electronic patient record is excluded from the device definition under the relevant statutory framework. That exclusion doesn't automatically cover every feature placed inside an EMR.

Some clinical decision support functions may remain within FDA oversight, particularly where the software analyzes clinical information and produces recommendations or outputs that affect diagnosis or treatment. AI-based diagnostic functions require the same intended-use analysis. Teams should document what the feature does, who uses it, what decision it supports, and how the user can independently review the basis of the output. For work at this boundary, Ekipa's SaMD engineering page is relevant, while regulatory compliance ownership should remain with the product organization and its regulatory specialists.

Engineering FHIR APIs and clinical usability

FHIR makes exchange more structured, but it doesn't make an EMR clinically useful by itself. The engineering target is a successful clinical task, such as finding a current allergy, reviewing an external result, or giving a patient access to the right record without exposing another patient's data.

The ONC standardized API criterion points teams toward standards-based patient and population access. SMART App Launch adds OAuth 2.0 scopes that map permissions to FHIR resources and interactions. For example, user/Encounter.rs permits an authorized application to read and search Encounter resources available to the user, while system/Encounter.rs applies to a configured system-wide dataset. Teams should request the minimum necessary scope and test what the authorization server returns.

Treat authorization and launch context as clinical controls

SMART on FHIR version 2 supports granular scopes such as patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory. The server must enforce the filter at query and response level. A client-side filter is insufficient because unauthorized data has already crossed the trust boundary.

EHR launch and standalone launch also differ. An embedded application receives a launch parameter associated with the current EHR session, while a standalone application may request a patient context through a scope such as launch/patient. Tests should cover stale launch parameters, missing context, a user changing patients, and mismatched patient or encounter identifiers. Treating launch as a generic login parameter can create cross-patient exposure even when OAuth and FHIR endpoints function correctly.

The integration test should ask a clinical question rather than only checking HTTP success:

1. Can the application identify the correct patient and encounter?
2. Does the token grant only the intended resource and interaction?
3. Does the server reject or omit unauthorized data?
4. Can the clinician understand provenance, date, author, and status?
5. What does the user see when the external system is unavailable?

Material on best practices for document processing APIs can help teams think about validation, failure handling, and document workflows, but clinical usability still needs testing with the actual EMR users.

Measure usability as a safety requirement

Bring clinicians into discovery before templates and screen flows harden. Start with high-risk workflows such as medication ordering, result review, allergy reconciliation, and clinical handoffs. Define task-level measures for completion time, clicks, and errors, then test the actual configuration rather than relying on certification or average satisfaction.

A multicenter study of EHR products found up to a nine-fold difference in task completion time and an eight-fold difference in clicks, with task error rates ranging from 0% to 50%, depending on the workflow (JAMIA study). The same evidence links usability to medication safety, including approximately one-third of health IT-related medication safety events in three hospital systems and 3,243 of 9,000 reviewed medication-safety events across three pediatric facilities.

A release gate should block unresolved high-severity errors. After launch, combine usability telemetry, incident reports, medication-error reviews, and clinician interviews. Excessive alerts, incomplete external data, and templates that force irrelevant fields create workarounds that a clean API test will never reveal.

Integrating AI with governance and safety controls

AI belongs in narrow clinical tasks where the workflow already has a clear reviewer and a clear point of accountability. In EMR products, that usually means documentation support, coding suggestions, chart summarization, and information retrieval, not autonomous clinical action. Ambient documentation can draft a note for clinician review. Coding support can surface likely codes for confirmation. Summarization can condense a long chart for an authorized user without changing the underlying record.

The failure mode is familiar. Teams spend months tuning prompts and model output, then leave governance for later. A 2025 healthcare survey found that 56% of respondents were concerned about privacy and security in generative AI, 55% were concerned about biased outputs from inadequate training data, only 18% said their organization had published authorized-use policies, and only 20% required formal AI training (Wolters Kluwer Future-Ready Healthcare 2025). If you are extending an existing EMR rather than building from scratch, this is usually the right place to use the platform's existing controls instead of inventing a parallel access model.

Put controls in the product

Start with the same permissions model that governs the rest of the EMR. Retrieval should respect user, patient, encounter, and resource-level authorization before any prompt is assembled. The model should only receive the minimum data needed for the task. The application also needs a traceable record of source documents, generated output, clinician edits, and final acceptance, because that is what supports audit, incident review, and legal defensibility.

A practical control set includes:

Control	Product implementation	Operational owner
Data minimization	Send only the fields required for the task and remove unnecessary identifiers where possible	Engineering and privacy
Permission-aware retrieval	Apply user, patient, encounter, and resource authorization before retrieval	Engineering and customer security
Human review	Require clinician review and attestation before AI-generated content enters the legal record	Clinical leadership
Monitoring	Track prompts, model versions, rejected suggestions, overrides, and unsafe outputs	Product, engineering, and clinical safety
Downtime behavior	Provide a manual or non-AI workflow when the model or external service is unavailable	Operations and clinical leadership
Vendor risk	Define data use, retention, subprocessors, incident duties, and change notification in contracts	Procurement, legal, and security

Release posture should stay conservative. Healthcare organizations are already dealing with frequent cyberattacks and care disruption, and teams also report that protecting confidential data used in AI systems is difficult. In practice, that means staged rollout, stricter logging, vendor review before production traffic, and a fallback workflow that still works when the model or external service is down.

Teams adding AI to clinical workflows can use Ekipa's AI delivery framework as one reference point for connecting delivery work with governance. The harder part is internal. Define intended use, set escalation rules, document who can override what, and investigate adverse events as product safety issues, not just model-quality defects.

Post-launch obligations and engineering FAQs

Post-launch work is where EMR strategy gets real. If you chose to extend a certified core instead of building a full system, this is usually the point where that decision starts paying off. A team still has to maintain evidence, monitor standards changes, control release scope, and support customer configurations that can affect certified behavior. But it is very different from owning every certification artifact, every regulated workflow, and every regression risk across a full EMR stack.

ONC's real-world testing requirements should be reviewed against the current program position. As of 2025, ONC announced enforcement discretion for some real-world testing requirements, so teams should check current obligations with the applicable ONC-Authorized Certification Body and the ONC real-world testing guidance. In practice, I treat any standards update, API revision, template change, or interface rewrite as a potential certification-impacting event until proven otherwise. That means regression testing, updated documentation, and a clear record of what changed and why.

Interoperability also has to be measured in production, not assumed from conformance testing. In 2023, 70% of US hospitals reported engaging at least sometimes in finding, sending, receiving, and integrating information, but only 43% met the stricter definition of routine interoperability (ONC interoperability analysis). That gap matters. A successful API response does not mean a clinician can find outside data quickly, trust what they are seeing, and use it during care.

This is also where build versus buy keeps showing up after launch. Buying or extending does not remove engineering responsibility. It changes the shape of it. The hard part shifts from inventing every module to controlling integrations, upgrades, tenant-specific configuration, data mapping, and support boundaries with the certified vendor.

Conclusion

EMR software development goes better when leadership defines the clinical scope and regulatory boundary before choosing architecture. For many organizations, extending a certified base with specialty workflows and targeted integrations is the lower-risk path. Building a full EMR can make sense, but only when the product strategy justifies long-term ownership of certification work, clinical content, usability evidence, interoperability operations, AI governance, and customer support.

Is ONC certification mandatory for every EMR?

No. The ONC Health IT Certification Program is voluntary, but clinicians participating in applicable CMS programs may need certified EHR technology. Confirm the program requirements first, then check whether the product's intended use and deployment model fall within the certification criteria that apply.

What does real-world testing require?

Real-world testing requires certified developers to demonstrate that applicable certified capabilities work in real-world settings. ONC announced enforcement discretion for some requirements in 2025, so teams should confirm current obligations with the ONC-Authorized Certification Body and the latest ONC guidance referenced above.

How granular should SMART on FHIR scopes be?

Scopes should request the minimum necessary access and can identify the subject, FHIR resource, interaction, and search parameters. SMART App Launch version 2 supports patient-specific scopes such as laboratory-only Observation access, and the server has to enforce that access control rather than leaving filtering to the client.

Does FHIR guarantee interoperability?

No. FHIR defines a standard exchange model, but usable interoperability still depends on identity matching, terminology mapping, consent handling, provenance, partner connectivity, reconciliation, and presentation in the workflow. Routine interoperability means clinicians can find and use outside information at the point of care.

Does an electronic patient record function make the whole product exempt from FDA oversight?

No. FDA guidance excludes software intended to serve as an electronic patient record from the device definition, but other functions may still be regulated. Clinical decision support and AI-based diagnostic features still need intended-use and regulatory analysis.

Other countries apply their own health data, certification, privacy, prescribing, and medical device rules. A US design should not be treated as a global compliance design without jurisdiction-specific review.

Ekipa AI helps healthtech teams define and build clinical software, extend existing EMR systems, implement HL7 and FHIR integrations, and add governed AI workflows such as documentation and summarization. If you're deciding whether to build, buy, or extend an EMR, discuss the clinical scope and regulatory boundary with Ekipa AI.