Prescriptions

An electronic prescription is a compliant medication order issued by a doctor and later redeemable at a pharmacy. It's a first-class entity: it has its own identifier, its own lifecycle, and — depending on the country — its own regulatory constraints (patient consent, national repository certification).

Electronic prescriptions belong to Osigu's ePrescription (EHR) product, which is separate from ARC but shares the same OAuth tokens, provider identity, medical and provider-product catalogues, and dispensing endpoints. Endpoints in this section are under /ehr/..., not /arc/....

The prescription and the dispensation are two sides of the same coin: the doctor issues the prescription in the ePrescription product; a pharmacy redeems it via the same /dispensing/v1/dispensations endpoints used for pre-authorizations. See Dispensing.

Three versions, three purposes

The ePrescription product exposes three prescription-creation endpoints that coexist. Which one you use depends on your integration's contract:

Endpoint	When to use
POST /ehr/v1/prescriptions	v1. Baseline. Most integrations.
POST /ehr/v1.1/prescriptions	v1.1. Adds mandatory patient-data-consent validation. Required in some markets.
POST /ehr/v2/prescriptions	v2. Certified against the Spanish national e-prescription repository. Required for Spain.

The shape of the request is very similar across the three, but the required fields grow with each version. Newer versions accept a superset of older data.

Anatomy of a prescription

A prescription bundles:

• Patient — either an existing patient in Osigu's ePrescription directory (referenced by patient_id) or a new patient created inline (see createPatient if you want to create ahead of time).
• Prescribing doctor — derived from the OAuth token plus the doctor identifier passed in the body. The medical-board registration is validated at issuance.
• Diagnosis(es) — ICD-10 code(s) drawn from the diagnoses catalogue.
• Medications — a list of items with product code, quantity, posology, and duration. Product codes come from the medications catalogue and must match a PROVIDER_PRODUCT in the doctor's inventory.

Issuance flow

Once issued, the prescription can be:

• Retrieved by prescription_id: getPrescription.
• Listed for a beneficiary: listPrescriptions.
• Resent to the patient (email / link): resendPrescription.
• Dispensed at a pharmacy via startDispensation with the prescription code.

Version differences in practice

Even though there are three endpoints, most fields are shared. What changes:

• v1.1 requires patient_data_consent = true in the body. Some sponsors mandate this for GDPR-adjacent regimes.
• v2 requires everything v1.1 has, plus a national_repository_id and a signed-hash structure the Spanish repository validates. If you're integrating outside Spain, ignore v2.

Server-side, the entities produced by the three endpoints all look the same — the version is a legal contract, not a data-shape difference.

Catalogues

Prescriptions draw from four Osigu-managed catalogues, each with its own endpoint:

Catalogue	Endpoint
Diagnoses (ICD-10)	listDiagnoses
Medications	listMedications
Provider products (the subset the doctor's provider has registered)	listProviderProducts
Patients (the doctor's patient directory)	listPatients

Related concepts

• Dispensing — the pharmacy-side flow that redeems prescription codes.
• Provider Products — the catalogue of items you can prescribe.
• Beneficiary Lookup — how to find who the prescription is for.
• API versioning — how the three prescription endpoints coexist.