Tutorial: Configuring Digital E-Prescriptions in a Clinic System: From Drug Master to SatuSehat Bridging

Prescriptions at clinics are often the weakest point in the digitalization chain. Registration is already online, medical records are already electronic, but prescription paper is still printed and then re-read by pharmacists — and that is where errors occur: signa 3x1 is read as 3x2, similar drug names (Glimepiride vs Glipizide), or stock turns out to be empty after the patient waits 20 minutes. At a clinic with 400 prescriptions per day, a misreading rate of just 1% means 4 patients potentially receive the wrong dose every day. Since Permenkes No. 24 Year 2022 on Electronic Medical Records came into effect, e-prescription is no longer an additional feature, but part of compliance. This article discusses its configuration concretely: data schema, validation rules, up to bridging to SatuSehat using FHIR R4 — an approach we commonly use when assisting SIM Klinik implementation in Yogyakarta and Magelang.

Mapping the e-Prescription Flow Before Touching Configuration

The most expensive mistakes in e-prescription projects are not in the code, but in master data. Before a single line of configuration is written, ensure the drug catalog has been normalized according to the Kemenkes Kamus Farmasi dan Alat Kesehatan (KFA): KFA code, generic name, active ingredient, dosage form, strength (mg or mg/mL), unit, and route of administration. At one clinic with 1,200 SKUs that we handled, 34% of entries turned out to be duplicates — Amoxicillin 500 mg was recorded in four different rows with different prices. Without this cleanup, drug usage reports will always be wrong and SatuSehat bridging will fail because the code is not recognized.

Second, define the prescription structure as an object, not free text. The header contains the prescription number, date, doctor along with SIP number, patient, and ICD-10 diagnosis. Each item contains obat_id, structured signa (frequency per day, time of taking, route, before/after meals), quantity, and iteration. Do not store signa as a string such as 3x1 after meals — split it into frekuensi=3, rute=oral, waktu=makan, aturan=sesudah. This structure is what will later be used for dose validation, automatic label printing, and conversion to FHIR dosageInstruction.

Third, define an explicit status machine: draft, signed, verified, dispensed, closed, with options cancelled and expired. Every transition writes an audit log (who, when, from which IP) and must not skip stages. Doctors' electronic signatures should use BSrE-certified TTE so that prescriptions have legal force. With this flow, the time from when the doctor presses save until the prescription appears on the pharmacist's screen can be reduced to under 5 seconds, from previously 4-6 minutes if still manual.

Technical Configuration: Table Schema and Dose Validation

For general implementation, a stable stack as of 2025 is PostgreSQL 16, Laravel 11 on PHP 8.3, and Redis 7.2 as cache. Create four core tables: drug_master, prescriptions, prescription_items, and signa_master. Lock the relation at prescription_items.obat_id (foreign key to drug_master.kfa_code), then add a composite index on (prescription_id, urutan) so that retrieving prescription details stays under 10 ms amid thousands of transactions per day.

Validation must be layered and run on the server, not only in the UI. At minimum there are four checks: active ingredient allergy against the patient's history, maximum daily dose, major drug interactions, and stock availability. For interactions, you can use the RxNorm API or the local ONC High-Priority (ONCHigh) database containing hundreds of critical interaction pairs. Stock reservation is done when the prescription has signed status, not at dispensing, to prevent overselling when two doctors prescribe the same drug in the same minute.

Example of dose and allergy validation implementation in Laravel:

// app/Services/ResepValidator.php — Laravel 11, PHP 8.3
public function validateItem(array $item, Patient $pasien): void
{
    $obat  = Obat::findOrFail($item['obat_id']);
    $total = $item['dosis_mg'] * $item['frekuensi'];
    if ($total > $obat->dosis_maks_harian) {
        throw ValidationException::withMessages([
            'dosis' => 'Dosis '.$total.' mg/hari melebihi batas '.$obat->dosis_maks_harian.' mg.',
        ]);
    }
    if ($pasien->alergi()->where('zat_aktif', $obat->zat_aktif)->exists()) {
        throw ValidationException::withMessages(['obat_id' => 'Pasien alergi zat aktif ini.']);
    }
}

Store the drug master in Redis with a 10-minute TTL and automatic invalidation whenever there is a price or stock change, so catalog queries do not burden the database. For a clinic with 20-40 doctors and 300-500 prescriptions per day, one PostgreSQL 16 instance with 4 vCPU and 8 GB RAM is sufficient — it is better to invest in monitoring and daily backups than in over-provisioning the server.

Bridging e-Prescriptions to SatuSehat and Pharmacy Queues

Bridging is not just sending JSON. Authentication uses OAuth 2.0 client_credentials to the sandbox endpoint api-satusehat-stg.dto.kemkes.go.id, with an access token valid for 3,600 seconds. Cache the token in Redis and refresh 60 seconds before expiration; do not request a new token on every request because it will hit the rate limit and slow down the entire flow.

Map prescriptions to FHIR R4 resources: MedicationRequest (intent=order, status=active, medicationReference to Medication with KFA code), Patient (NIK or mother's NIK for infants), and Encounter. Fill dosageInstruction with label text as well as a machine-readable timing structure. Use the prescription number as identifier so requests are idempotent — resending with the same identifier will not create duplicates on the SatuSehat server.

Network failure is inevitable. Implement the outbox pattern: every signed prescription goes into the outbox table, is sent by a queue worker (Laravel Horizon) with exponential retry backoff of 2, 4, 8, 16, 32 seconds up to 5 times, then moved to the dead letter queue and appears on the monitoring dashboard. A realistic target: 99.5% success rate with p95 latency under 1.5 seconds.

On the pharmacy side, a prescription that has been signed goes directly into the pharmacist's worklist via WebSocket (Laravel Reverb or Soketi). The pharmacist verifies, performs dispensing, the system reduces batch stock using the FEFO (First Expired First Out) method, then sends a status callback to SatuSehat. The average patient waiting time at the medicine counter dropped from 18 minutes to 7 minutes after this workflow ran stably for three months.

Best Practices

1. Clean the drug master data before go-live. Target at least 95% of SKUs mapped to KFA codes; mark the rest as non-KFA and handle them manually.
2. Validate on the server, not in the form. The UI may provide warnings, but the final decision remains in the service layer so it cannot be bypassed.
3. Design for idempotency from the start. Use the prescription number as a unique identifier for both bridging and internal queues.
4. Enable audit logs and TTE from day one. Retrofitting an audit trail after thousands of prescriptions have been processed is far more expensive.
5. Test with 1,000 historical prescriptions. Replay old data to measure validation accuracy, latency, and bridging failure rates before it is used for real patients.

FAQ

Is an e-prescription required to use a certified TTE?

For full compliance and legal validity, yes. A TTE from BSrE or a registered PSrE ensures the integrity and non-repudiation of the prescription. As an initial step, many clinics use an internal electronic signature with an audit log, then gradually migrate to a certified TTE.

What if the clinic's internet connection goes down during SatuSehat bridging?

No problem, as long as you use the outbox pattern. The prescription is still stored locally and printed, while the queue worker resends it when the connection is restored. The important thing is that the prescription status at the clinic must not depend on the external server's response.

How long does e-prescription implementation take for a clinic with five doctors?

With clean drug master data, core configuration and bridging are usually completed in 3-4 weeks: two weeks for development and data migration, one week for parallel testing, and one week for training and phased go-live per polyclinic.

Can old prescription data be migrated?

Yes, but paper prescriptions cannot be converted automatically. What is realistic is migrating medication history from the old system or Excel, then importing patient allergy history — this part is actually the most critical because it becomes the basis for safety validation.

A good e-prescription configuration always starts with data, not with the interface. Once the drug master data is tidy, layered validation is in place, and idempotent bridging is running, then advanced features such as automatic labels, BPJS claims, and prescription pattern analytics make operational sense. If you are preparing e-prescriptions for a clinic in Yogyakarta, DIY, or Magelang and need technical assistance, our team provides IT consulting services as well as development of SIM Klinik, SIMRS, ERP, POS, and website applications that are connected directly to SatuSehat and BPJS.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: Clinic Management System BPJS & SatuSehat Integration. Need a free consultation?