E-Prescribe Decision Guide | Medplum

E-prescribing in Medplum runs through an integration with an e-prescribing vendor connected to the SureScripts network. This space is less about the FHIR data model than a sequence of integration and enrollment decisions: how much prescribing UI you build, whether you send controlled substances, and how prescribers get enrolled and verified. This guide moves from those high-level decisions down to feature detail.

Section 1: Use Case & Participants

1.1 What are you prescribing?

Non-controlled medications only
Controlled substances too (Schedule II–V)
Not sure / depends on specialty

1.2 How much of the prescribing experience do you want to build?

Hosted iframe — embed the vendor's prescribing UI. Minimal build; drug search, dosing, pharmacy, and send all happen inside the vendor's screens.
Integrated (API-driven) — build your own prescribing UI on Medplum's FHIR operations and bots; only the final, regulation-required review-and-send step stays a hosted widget.
Not sure

1.3 New build or replacing an existing e-Rx system?

New — no e-prescribing today
Replacing another EHR or e-Rx vendor
Adding alongside an existing clinical system

1.4 Who is involved in prescribing?

Prescribers (sign and send)
Prescribing agents / proxies (stage but can't send)
Administrators (enroll prescribers, manage practices, configure favorites)

Section 2: Feature Scoping

#	Feature	§
1	Integration model (hosted iframe vs. integrated/API)	3.1
2	Prescriber enrollment & identity proofing	3.2
3	Provider & practice identity data (NPI, DEA, roles)	3.3
4	Non-prescriber staff access (pharmacy / history ops)	3.3
5	Controlled substances / EPCS	3.4
6	Formulary/benefit checks & prior authorization	3.5
7	Refills, reorders & discontinuation	3.6
8	Clinic favorites / order sets	3.7
9	Pediatric prescribing	3.7
10	Medication history retrieval (with consent)	3.8
11	Multi-location / multi-practice prescribing	3.9
12	Multi-tenant / platform deployment (multiple downstream clients)	3.10
13	Migration from an existing e-Rx system (Change of Vendor)	3.11

Section 3: Feature Deep Dives

Foundations

3.1 Integration Model

How much of the prescribing UI you build — the decision that shapes almost every section below.

Questions:

Do prescribers need to write prescriptions in context (from inside your chart), or is a standalone screen fine?
How much engineering do you want to invest in the prescribing UI, now and ongoing?
Do you need to control the look and steps of the flow, or is a vendor-standard flow acceptable?

Situation	Approach
Standalone screen fine; minimal build	Hosted iframe — the vendor's prescribing UI, embedded. Fastest to live; UX is fixed and not customizable.
Must prescribe from within your own chart	Integrated (API-driven) — build the pre-approval flow on FHIR operations and bots; the prescriber stays in your UI until the final send.
Own the branding and steps	Integrated — you control everything up to the vendor-hosted review-and-send widget (stylable; transmitted content is not).
Either model	The final review-and-send step is always vendor-hosted and compliance-controlled — neither model replaces the moment of transmission with your own code.

3.2 Prescriber Enrollment & Identity Proofing

Every prescriber must be enrolled before transmitting. Decide who drives enrollment and how much your platform automates.

Questions:

Who initiates enrollment — an ops admin, or the prescriber on first login?
Do prescribers send controlled substances (which adds identity proofing and 2FA)?
How will you see which prescribers are stuck mid-enrollment?

Situation	Approach
Ops admin drives it, stage by stage	Admin-driven enrollment bot — invoked per practitioner; the admin controls when each stage advances. Requires a project admin with vendor admin access.
Prescriber self-enrolls on first use	Self-service enrollment bot — auto-advances through registration as the prescriber opens the iframe. Requires an admin-level vendor user id as a project secret and an active prescriber role record.
Non-controlled only	Enrollment completes at basic registration — the prescriber can prescribe non-controlled meds immediately; no identity proofing or 2FA.
Track enrollment state	The bots return a status that progresses registration → identity proofing → 2FA; surface it to admins so stuck prescribers are visible.

3.3 Provider & Practice Identity Data

Accurate provider identity data prevents the most common enrollment failures.

Questions:

Do you have complete, validated Practitioner records (name, DOB, address, work phone/fax, email, NPI)?
Do controlled-substance prescribers have a valid DEA number with issuing state?

Situation	Approach
Standard prescriber	`Practitioner` with full name, birth date, complete address, work phone and fax, email, and a valid 10-digit NPI. Missing or malformed fields are the top cause of enrollment errors.
Controlled-substance prescriber	Additionally a DEA number with the issuing state present (2-letter abbreviation) — required to trigger EPCS enrollment.

Controlled Substances

3.4 EPCS (Electronic Prescriptions for Controlled Substances)

Supported, but a regulated, multi-step enrollment on top of basic registration. Treat it as its own workstream.

Questions:

Which prescribers will send controlled substances, and does each have a valid, active DEA registration (with state)?
Are prescribers ready to complete identity proofing and set up two-factor auth?

Situation	Approach
Enable EPCS for a prescriber	Three stages on top of registration: (1) registration with DEA present → (2) identity proofing (Experian-based) → (3) two-factor auth activation. All three required before transmitting controlled substances.
Missing or inactive DEA	Blocks identity proofing; the DEA number and issuing state must be on the `Practitioner`.

Prescribing Workflow

3.5 Formulary/Benefit Checks & Prior Authorization

Whether prescribers see coverage and cost at the point of prescribing, and how prior auth is handled.

Questions:

Do prescribers need formulary status, patient cost, and covered alternatives while prescribing?

Situation	Approach
Show coverage & cost	The vendor pulls active benefit info from pharmacy-benefit data via patient demographics and surfaces formulary status, cost, and alternatives.

3.6 Refills, Reorders & Discontinuation

How prescribers handle prescriptions after the first send.

Questions:

Do prescribers respond to pharmacy-initiated refill requests?

Situation	Approach
Refills	Pharmacy-initiated requests for more of an existing prescription; prescribers approve or deny.
Reorders	Prescriber-initiated new prescription for a previously prescribed medication.

3.7 Favorites, Order Sets & Pediatric Prescribing

Questions:

Does the practice repeatedly prescribe a common set of medications worth curating?

Situation	Approach
Common medication set	Configure clinic favorites / order sets — curated, reusable entries.

3.8 Medication History

Whether prescribers can see a patient's external medication history, and the consent required to retrieve it.

Questions:

Do prescribers need a patient's medication history from outside your system?

Situation	Approach
Need external history	Retrieved from the SureScripts network (pharmacy fill history and/or active prescriptions).

Practice Structure

3.9 Multi-Location / Multi-Practice Prescribing

Questions:

Do prescribers prescribe on behalf of more than one practice?

Situation	Approach
Multiple practices/locations	Model each practice as an `Organization` (linked to a parent business-unit `Organization` via `partOf`).

Situational

3.11 Migration from an Existing e-Rx System (Change of Vendor)

Questions:

Are prescribers currently sending through another system on SureScripts?

Situation	Approach
Already on SureScripts	Coordinate a Change of Vendor so the new system is recognized; without it, new prescriptions may work while refills and edits fail.

Related Integrations

The e-prescribing vendors Medplum integrates with first-party:

ScriptSure — full API surface with custom FHIR operations and bots, plus an authenticated iframe.
DoseSpot — embedded iFrame prescribing.