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 | § | Yes | No | Nice-to-have | Not sure |
| --- | --- | --- | --- | --- | --- | --- |
| 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](/content/docs/integration/scriptsure/index.html)** — full API surface with custom FHIR operations and bots, plus an authenticated iframe. 
- **[DoseSpot](/content/docs/integration/dosespot/index.html)** — embedded iFrame prescribing.