What Does the Electronic Prescription Change in a Receipt Computer? — Reading ORCA's Electronic Prescription Support in the Source Code

The electronic prescription, which went live in January 2023, is often described as the second wave of medical DX after online eligibility verification. But what does supporting electronic prescriptions concretely mean for a receipt computer? “Digitising the prescription form” is not a statement you can design from.

Part 1 covered the role of the receipt computer, Part 2 the Nichi-Rece API, Part 3 online eligibility verification, and Part 4 receipt checking. In this fifth part we dissect the electronic prescription from the receipt computer’s side.

• How electronic prescriptions change the prescribing flow (the shortest understanding of the regulatory side)
• The overall shape of ORCA’s (Nichi-Rece’s) support — the division of responsibility between the core and the supporting programs
• The design of tbl_shoho_kanri, which manages prescription IDs, exchange numbers and refills
• The connection between systems whereby the patient’s preferred issue format arrives from online eligibility verification

Statements about the regulatory side are based on public material from the Ministry of Health, Labour and Welfare (MHLW) and the official ORCA site; statements about the source code are based on actually reading the officially published Nichi-Rece core 5.2-series source (the snapshot published on 1 July 2026).

Table of Contents

1. The conclusion first — the prescription goes from something you hand over to something you fetch
2. The shortest understanding of the regulations — the Electronic Prescription Management Service and the exchange number
3. Prehistory — prescriptions have been carrying QR codes since 2001
4. The overall shape of ORCA’s support — the division of responsibility between the core and the supporting programs
5. Reading tbl_shoho_kanri — the electronic attributes of a single prescription
6. The data’s exit — the electronic prescription CSV and the report forms
7. The connection to online eligibility verification — the issue format arrives from eligibility checking
8. For vendors — how to set up a verification environment
9. Practical points for those building integrations
10. Summary
11. References

1. The conclusion first — the prescription goes from something you hand over to something you fetch

A paper prescription was “hand-carried data integration”: the healthcare provider printed it and the patient carried it to the pharmacy. With electronic prescriptions the flow reverses.

flowchart LR
    subgraph clinic["Healthcare provider"]
        DR["Doctor's prescription"]
        RC["Receipt computer / EMR<br/>(in ORCA, manages the prescription data)"]
        SIGN["Electronic prescription support program<br/>+ separate electronic signature module<br/>(signing and transmission)"]
        DR --> RC --> SIGN
    end
    SIGN -->|"Register prescription data"| EPS["Electronic Prescription<br/>Management Service<br/>(Payment Fund / National NHI Federation)"]
    EPS -->|"Exchange number (for the patient)"| PT["Patient<br/>(My Number card or exchange number)"]
    PT --> PH["Pharmacy"]
    EPS -->|"Retrieve prescription data"| PH
    PH -->|"Register dispensing result"| EPS2["(back to the management service)<br/>the basis for duplicate-prescribing checks"]

• The healthcare provider registers the prescription data with the Electronic Prescription Management Service (operated, like online eligibility verification, by the Payment Fund and the National Federation of National Health Insurance Associations).
• Instead of carrying paper, the patient is either received at the pharmacy with their My Number health insurance card or gives the exchange number (together with insurance card details).
• The pharmacy fetches the prescription data from the management service and registers the dispensing result.

From the receipt computer’s point of view there are two essential changes. First, a prescription is no longer a report form completed inside the clinic but structured data registered with an external service. Second, because prescribing and dispensing records accumulate in the management service, checks such as duplicate prescribing become possible across healthcare providers and pharmacies. In Part 4 we wrote that matching against another organisation’s data is impossible in principle inside a provider; the electronic prescription can be seen as national infrastructure for crossing that wall in the prescribing domain (at prescribing time rather than at assessment time).

2. The shortest understanding of the regulations — the Electronic Prescription Management Service and the exchange number

Just the key points of the regulatory side.

• Since when: operation began in January 2023. It is a mechanism built on the network and foundation of online eligibility verification, and the number of participating facilities has been expanding in stages.
• How a prescription is identified: each issued electronic prescription is assigned a prescription ID. If the patient is received at the pharmacy using a My Number health insurance card, the prescription is identified by selecting it on the card reader (there is a selection step where more than one exists); if they do not use a My Number card, it is identified by giving the pharmacy the exchange number together with insurance card details (the exchange number alone is not sufficient).
• Duplicate prescribing checks: because prescribing and dispensing information accumulates in the management service, doctors and pharmacists can consult the results of checks against recent prescribing and dispensing data at the time of prescribing.
• Refill prescriptions: introduced in the FY2022 fee schedule revision, these are prescriptions that can be used repeatedly within a given period. Electronic prescriptions suit the management of repeated refill use well, and as we will see, refill fields are built into ORCA’s tables too.

How the identifiers travel between hospital and pharmacy

The structure of the electronic prescription is clearest if you follow, in chronological order from issue to dispensing, whose hands the three identifiers — prescription ID, exchange number and insurance details — pass through.

sequenceDiagram
    participant MED as Healthcare provider<br/>(ORCA + e-prescription/signature module)
    participant EPS as Electronic Prescription<br/>Management Service
    participant PT as Patient
    participant PH as Pharmacy
    Note over MED: Prescription confirmed, electronically signed
    MED->>EPS: Register prescription data (including insurance details)
    EPS-->>MED: Issue prescription ID + exchange number
    Note over MED: Recorded in tbl_shoho_kanri<br/>exchange number printed on the patient copy
    MED-->>PT: Hand over the copy (with exchange number)
    alt Received with a My Number health insurance card
        PT->>PH: Present the My Number card and<br/>select the prescription on the card reader
        PH->>EPS: Query using the insurance details
    else Received with an exchange number
        PT->>PH: Give the exchange number + insurance card details
        PH->>EPS: Query using the insured person's number etc. + exchange number
    end
    EPS-->>PH: Return the prescription data (managed internally by prescription ID)
    PH->>EPS: Register the dispensing result

There are two things to take from this diagram.

First, no system integration data passes directly from the hospital to the pharmacy. The authoritative prescription data always goes via the management service. What the patient carries is a “key” (a My Number health insurance card or an exchange number); they may also carry a paper copy of the prescription content, but that copy is reference information only — the authoritative data the pharmacy dispenses from is retrieved from the management service. You are spared having to build point-to-point integration between hospital and pharmacy, but in exchange, for both parties the quality of the integration with the management service is everything.

Second, the three identifiers have clearly distinct roles.

The traces of this round trip on the ORCA side appear in the prescription management table discussed below. The prescription ID and exchange number returned by the management service at issue time are stored as they are (PRESCRIPTIONID and ACCESSCODE) and used for printing the patient copy and for matching on cancellation or amendment.

3. Prehistory — prescriptions have been carrying QR codes since 2001

“Turning prescriptions into data” is in fact not a new story. ORCA’s source contains a program cobol/common/ORCSQRCSV.CBL, “Prescription QR Data Output”, with a creation date of September 2001. Printing a QR code on a paper prescription for the pharmacy’s system to read and import into its dispensing system has existed for more than twenty years.

So the change the electronic prescription brought was not “digitisation” but standardisation of where the data lives and how it is retrieved. A QR code was “the data for that one sheet” printed on paper; an electronic prescription is registered with a nationally shared management service and can be retrieved by anyone (within their permissions) using the prescription ID. That difference is what made cross-cutting features such as duplicate prescribing checks possible. Old and new mechanisms coexisting in the same source tree is a very characteristic view of a receipt computer mid-transition.

4. The overall shape of ORCA’s support — the division of responsibility between the core and the supporting programs

According to the official page (“Nichi-Rece Electronic Prescriptions”), ORCA’s electronic prescription support consists of the Nichi-Rece core plus the electronic prescription support programs (the electronic prescription API). Reading the published 5.2-series source, that dividing line can be confirmed from the implementation too.

The last row is the interesting one. The electronic signature machinery — the technical highlight of electronic prescriptions — does not appear at all in the four million lines of the Nichi-Rece core. The core sticks to being the authoritative record of the prescription data, while the fast-moving areas of signing and communication are carved out into separate programs — the same division pattern as the online eligibility integration we saw in Part 3 (core provides APIs and tables, file exchange goes through onshi-tools). It can be read as a design that decouples specification changes on the national infrastructure side from the core’s release cycle.

So what lives on the carved-out side? The line-up of supporting programs on the official page looks like this.

The supported operating systems differ by component: the electronic prescription module and the extended e-prescription helper are Windows 11 (x64) only, while the prescription entry screen runs on Windows, Mac and Ubuntu (Ubuntu support only in the WebORCA on-premises edition). When planning clinic workstations, be aware that the modules around issuing assume Windows. The division of signing responsibility matters too: the official page states explicitly that “in order to introduce electronic prescriptions, a separate electronic signature module is required”. The verified electronic signature modules (supplied by I-O Data Device and Mitsubishi Electric IT Solutions) handle local signing with an HPKI card and remote signing (FIDO authentication, HPKI card authentication and My Number card authentication). In other words, the most volatile question in electronic prescribing — how to make the doctor’s electronic signature happen — has been carved out of both the Nichi-Rece core and the e-prescription module and absorbed into a dedicated signing layer. That is the answer to why HPKI never appears in the core source.

Where an electronic medical record is present, which side issues the prescription?

The diagrams so far folded everything inside the healthcare provider into a single flow, but in real clinics an electronic medical record (EMR) and a receipt computer often coexist. In that case the route by which a prescription reaches the pharmacy (the management service) broadly splits into two patterns.

Drawn as a diagram, the difference between the two patterns comes down to which side the “signing and registration” box sits on.

flowchart TB
    subgraph A["Pattern A: ORCA as the issuer"]
        direction LR
        EMRA["EMR<br/>(order entry)"] -->|"Nichi-Rece API"| ORCAA["ORCA<br/>tbl_shoho_kanri"]
        ORCAA --> MODA["E-prescription module<br/>+ electronic signature module"]
        MODA -->|"Register"| EPSA["Electronic Prescription<br/>Management Service"]
    end
    subgraph B["Pattern B: EMR as the issuer"]
        direction LR
        EMRB["EMR<br/>(own e-prescription support + signing)"] -->|"Register"| EPSB["Electronic Prescription<br/>Management Service"]
        EMRB -->|"Pass prescription for claiming"| ORCAB["ORCA<br/>(receipt creation)"]
    end

The traces of pattern A are clearly present in the source. The issue source classification (HAKKOKBN) in the prescription management table we look at in section 5 has a value meaning “API interim data submission” (confirmable from the comments in the COPY member CPSHOHO-KANRI.INC), so prescriptions pushed in from an EMR via the API are managed in the same table as prescriptions entered on ORCA’s screens. The design we saw in Part 2 — “the API is the API version of the screen functions” — is alive in the electronic prescription issuing route too.

In neither pattern is there any processing that “sends” anything to the pharmacy. The pharmacy side — the pharmacy’s own receipt computer and dispensing system — retrieves the prescription data from the management service (for integration inside the pharmacy’s systems, MHLW publishes material on the integration data between receipt computer and electronic dispensing record). The first thing a vendor on the provider side has to decide is whether the starting point for issuing, signing and cancelling sits on the EMR side or the ORCA side, and then, in line with that decision, which side holds the equivalent of tbl_shoho_kanri so that prescription IDs and exchange numbers can be reconciled against the claim data.

5. Reading tbl_shoho_kanri — the electronic attributes of a single prescription

At the centre of the Nichi-Rece core side is the prescription management table tbl_shoho_kanri. From the definition (record/tbl_shoho_kanri.db) and the Japanese comments in the COPY member, the main fields are:

tbl_shoho_kanri {
    TBL_UUID          varchar(36);  -- identification uuid
    RENNUM            number(1);    -- sequence number (primary key is HOSPNUM+TBL_UUID+RENNUM)
    SRYYMD / PTID / SRYKA / HKNCOMBI  -- treatment date, patient, department, insurance combination
    SHOHO_KEITAI      varchar(1);   -- prescription issue classification (electronic/paper)
    PRESCRIPTIONID    varchar(36);  -- prescription ID
    ACCESSCODE        varchar(16);  -- exchange number
    REFILL_NUM        number(1);    -- refill count
    REFILL_ZAIKAISU   number(3);    -- refill prescription days
    CANCEL_TIME / CANCEL_UNDO_TIME  -- prescription cancellation timestamp and cancellation-undo timestamp
    CHANGE_TIME / CHANGE_UNDO_TIME  -- amendment timestamp and amendment-undo timestamp
};

This one table alone lets you see through to the practicalities of electronic prescribing.

• It holds fields for the prescription ID (36 digits) and the exchange number (16 digits) as a pair. The keys corresponding to the two collection routes we saw in section 2 (My Number card / exchange number) sit right there as attributes of the record. (Note that the exchange number under current operation is six digits; the 16 is the column capacity. It would be safer not to implement the digit count as a fixed value.)
• Both cancellation and amendment have their own UNDO timestamps. Because an electronic prescription is data already registered with the management service, cancelling a prescription in the clinic requires cancelling the registration too — and cancelling that cancellation (restoring it) can happen as well. What used to be “tear it up and rewrite it” in the paper era has become state transition management.
• Refills are an attribute from the outset. The refill count and prescription days are among the basic fields of prescription management, so lifecycle management premised on repeated use is woven into the design.

Using a uuid for identification is an idiom shared with the online eligibility tables from Part 3 (tbl_onshi_kaku). The primary key, though, is not the uuid alone but a composite key of healthcare provider number + uuid + sequence number (RENNUM), a design in which multiple rows can hang off the same uuid. When your integration system handles data equivalent to this table, be careful: treat the uuid alone as the row key and you will collapse multiple rows into one.

6. The data’s exit — the electronic prescription CSV and the report forms

Before going further, here is a single picture of how data moves inside ORCA, taking in both the table from section 5 and the online eligibility connection from section 7.

flowchart LR
    ONS["Online eligibility verification<br/>(at reception)"] -.->|"Preferred issue format<br/>SHO_SHOHO_KEITAI"| TBL
    NYURYOKU["Prescription entry<br/>(screen / Nichi-Rece API)"] --> TBL["tbl_shoho_kanri<br/>prescription ID, exchange number,<br/>refills, cancellation/amendment"]
    TBL -->|"CSV export<br/>(ORCSEPRECSV)"| MOD["E-prescription module<br/>(assembles and sends the registration request)"]
    SIGNM["Electronic signature module<br/>(electronic signing)"] -.->|"Signature"| MOD
    MOD -->|"Register"| EPS["Electronic Prescription<br/>Management Service"]
    EPS -.-> RET["Prescription ID and exchange number<br/>(recorded in tbl_shoho_kanri and<br/>passed to the ORCHC02 copy reports)"]

The exit through which prescription data passes to the supporting programs is ORCSEPRECSV.CBL (Electronic Prescription CSV Data Output). The revision history in its header is itself a record of keeping up with regulatory change.

• October 2022, newly created — implemented ahead of the January 2023 go-live
• June 2023, support for reflecting the dosage-instruction master — because electronic prescriptions handle dosage instructions (how the drug is taken) in coded form too, consistency with the dosage-instruction master became necessary
• 2024: refill count support (January), delivery number remarks support (March), patient-requested originator drug support (August), 40-byte kanji names (December) — moves on the regulatory side, such as selected-treatment copayments for long-listed branded drugs (recording the patient’s request), translate straight into new fields
• 2025: dummy code warning support (January), expiry date support (April), payer number / recipient number digit-count support (July) — even two and a half years after go-live, modifications continue at a rate of several a year

As this history shows, the electronic prescription CSV integration is not “build it once and you’re done” but something still changing. On the report side, versions supporting electronic prescriptions sit alongside the prescription-form report programs (the ORCHC02 and ORCHCM19 families). Reports do not disappear when prescriptions go electronic, because the patient copy handed over (including notification of the exchange number) and continued coexistence with paper operation both persist. “Digitisation = the end of paper forms” is not the reality of the transition period; the forms remain while the location of the authoritative data changes — and the file layout of the source reflects that honestly.

7. The connection to online eligibility verification — the issue format arrives from eligibility checking

Looked at as a clinic workflow, the first branch in electronic prescribing is “will this patient receive the prescription electronically or on paper?”. Where does that information come from? The answer is online eligibility verification.

When a patient is received using a My Number health insurance card, they can select on the card reader how they wish to receive the prescription (electronic or paper). That selection reaches the receipt computer together with the eligibility verification result. The eligibility verification result table tbl_onshi_kaku that we read in Part 3 has a prescription issue format field (SHO_SHOHO_KEITAI), and per the definition comment it was added in July 2022. The online eligibility XML definitions also contain an item PrescriptionIssueSelect (prescription issue format). Half a year before electronic prescriptions went live (January 2023), the receiving end on the online eligibility side had already been extended — you can read the order in which the regulations were stacked from the dates in the source.

The issue format determined at reception is then fixed per prescription at prescribing time as tbl_shoho_kanri.SHOHO_KEITAI. The handover of data between systems — online eligibility (reception) → prescribing (consultation) → management service (issue) — is connected at the level of the table design. The view we took in Part 3, calling online eligibility verification “the trunk line along which information flows from the eligibility entrance”, is borne out by electronic prescriptions too.

8. For vendors — how to set up a verification environment

The first thing you trip over in electronic prescription integration work is not the code but the fact that the routes for obtaining specifications and test environments are scattered. Here is the official information organised by entry point.

1) Obtaining the specifications — “Medical Institution ONS”

The primary specifications for system vendors are consolidated on “Medical Institution ONS” (Iryō Kikan tō ONS), the vendor information site provided by the Payment Fund (the External Interface Specification for the Online Eligibility Verification System and the Electronic Prescription Management Service Record Condition Specification are both there). It is a separate site from the general portal that healthcare providers use, and registration as a vendor is a prerequisite. Alongside it, MHLW’s “Electronic Prescriptions (for system vendors)” page publishes a technical explanatory document for system vendors (version 2.04 at the time of writing) and integration material for pharmacy systems. Note that JAHIS’s “Electronic Prescription Implementation Guide” (Ver.1.2, 2021) is a study document predating the current Electronic Prescription Management Service; the primary sources for the current specification are the ONS specifications and the technical explanatory document. It tends to come up first in search results, so be careful.

2) Obtaining test certificates and cards

Because issuing an electronic prescription requires an electronic signature (HPKI) from a doctor or dentist, you need certificates for testing too. The application routes differ by purpose.

• HPKI test cards (for signing and for authentication): the point of contact differs by profession. For doctors, you obtain one by posting an application form from the “For Vendors” page of the Japan Medical Association’s certification authority (JMACA). For dentists and pharmacists, follow the guidance of the respective certification authorities (MEDIS and the Japan Pharmaceutical Association CA).
• Use of the verification environment for HPKI second electronic certificates (cardless signing) and test My Number cards: apply by email to the dedicated contact point at MEDIS (the Medical Information System Development Center).
• One caution: even in normal times, a production HPKI card takes two to three months from application to issue. Moreover, at the time of writing, JMACA’s guidance states that issuance of physical cards (medical qualification certificates) has been temporarily suspended because of an IC card shortage, and that HPKI second electronic certificates (cardless) are being issued ahead of them. Before drawing up a plan premised on cards, it is safer to check the latest issuance situation and whether cardless signing is a viable substitute.

3) Connection verification and pre-release checks

Connection verification against the management service proceeds per the guidance issued via ONS, but the thing a developer should read first is MHLW’s published “Self-Check List for Releasing Electronic-Prescription-Capable Software (Test Completion Confirmation)” (version 4.2 at the time of writing). The arrangement is that vendors confirm test completion against this checklist before release — which, turned around, means an official list of “what you should test” exists from the outset. Working backwards from it is the quickest way to build a test plan. There is also an Electronic Prescription Common Signing Module as an option if you would rather not implement the signing yourself, and MHLW’s pages carry a list of providers offering introduction support services.

4) The ORCA-side verification environment

If you are verifying a Nichi-Rece plus supporting programs configuration, stand up the WebORCA on-premises edition on a verification server and set it up following the official E-Prescription Module & Extended E-Prescription Helper Installation Manual. As we saw in section 6, electronic prescriptions interlock with the dosage-instruction master, so unless you have completed the master updates you are not really verifying the output data. Furthermore, standard dosage instruction codes have expiry dates. The official page at the time of writing announces that from 1 August 2026 some standard dosage instruction codes will no longer be usable in electronic prescriptions, and that if mappings to expired codes remain, Nichi-Rece will output dummy codes. So do not just bring the masters up to date — include re-checking the mapping of the dosage instruction codes your own system uses among your verification items (tests that pass today can turn into dummy code output the moment the expiry date arrives). Just like the online eligibility verification pattern files introduced in Part 3, the iron rule is check what official verification means exist before inventing your own test data.

9. Practical points for those building integrations

The key points when an EMR, prescribing support or reception system becomes involved with electronic prescriptions.

1. Draw the division of responsibility first. ORCA’s standard configuration divides things as: prescription data management in the Nichi-Rece core, signing and management service communication in the electronic prescription support programs. Work out, function by function, which side your own integration should talk to before you design it. Deciding to implement the signing yourself means taking on the operation of HPKI cards as well.
2. Treat the prescription ID and exchange number as entities. Stay with a “prescription = printed document” data model and state management for cancellation, amendment, UNDO and refills all becomes an afterthought. The field structure of tbl_shoho_kanri is an excellent textbook for designing the prescription entity in the electronic prescription era. (Note, though, that what it holds is the refill count and days — the state of how many uses have been consumed and how many remain is not there. Design on the assumption that the remaining count is data belonging to the dispensing side’s lifecycle and must be handled separately.)
3. The issue format flows down from reception — but only for My Number reception. The patient’s electronic/paper preference is included in the online eligibility verification result only when they are received with a My Number health insurance card. For patients not using one — those with an eligibility confirmation certificate, for instance — the intention has to be confirmed by staff or the doctor at the front desk or in the consulting room, so relying on SHO_SHOHO_KEITAI alone leaves a route by which a prescription is reached without the preference having been confirmed. Include both the path that carries the reception-time information through to consultation and prescribing, and a confirmation flow for when there is no value from the card reader.
4. Assume there are two kinds of “paper”. Paper prescriptions will remain until every patient and every pharmacy has moved to electronic, but at facilities that have introduced electronic prescriptions there is a practice of registering prescribing and dispensing information with the management service even for paper prescriptions (a paper prescription with an exchange number), which then falls within the scope of duplicate prescribing checks. Rather than a binary electronic/paper split, it is realistic to design your branching around three cases: electronic, paper registered with the management service, and paper under the traditional QR code arrangement.
5. Have a mechanism for tracking regulatory extensions. Dosage-instruction master support, refill support — the source around electronic prescriptions is updated every year. As this series keeps recommending, diff monitoring of record/ and cobol/ in the monthly published source detects changes faster than official announcements here too.

10. Summary

• The electronic prescription turns a prescription from “paper the patient carries” into “structured data registered with a management service and retrieved by prescription ID / exchange number”. Aggregating prescribing and dispensing information has made duplicate prescribing checks possible across healthcare providers and pharmacies.
• ORCA’s support consists of the Nichi-Rece core (data management, CSV export, reports) + the supporting program family (the electronic prescription module, extended e-prescription helper and so on) + a separately required electronic signature module (verified vendor-supplied products). The absence of electronic signing from the core source is the evidence for that division of responsibility.
• At the centre of the core side is tbl_shoho_kanri, which manages the prescription ID, exchange number, refill count and days, and cancellation/amendment with their UNDO timestamps per prescription. The coexistence of prescription QR code output (from 2001) in the same source reflects the true nature of the change: from “digitisation” to “standardising where the data lives”.
• The electronic/paper issue format arrives at reception time as part of the online eligibility verification result — for My Number reception (the receiving end on the online eligibility side was added ahead of time, in July 2022 per the source). For patients with an eligibility confirmation certificate and the like, the preference must be confirmed separately at the front desk or in the consulting room. The way the regulations stack — online eligibility, then electronic prescriptions — is connected at the level of tables and XML definitions.

The next instalment in this series is planned to be either a “database edition” reading ORCA’s entire database schema, or the practicalities of running monthly source diff monitoring.

11. References

• Electronic Prescriptions — Ministry of Health, Labour and Welfare
• Nichi-Rece Electronic Prescriptions — ORCA Project (electronic prescription support programs and target reports)
• About Nichi-Rece’s electronic prescription support — ORCA Project
• Electronic Prescriptions (for system vendors) — Ministry of Health, Labour and Welfare (technical explanatory document, record condition specification, pre-release self-check list)
• For Vendors (HPKI test cards) — Japan Medical Association Certification Authority
• Prescription Printing API — ORCA Project
• Nichi-Rece core 5.2-series source code (snapshot published July 2026): record/tbl_shoho_kanri.db / cobol/copy/CPSHOHO-KANRI.INC / cobol/common/ORCSEPRECSV.CBL / cobol/common/ORCSQRCSV.CBL / record/tbl_onshi_kaku.db and others — every statement about the implementation in this article is based on that snapshot

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

How does an electronic prescription differ from a paper one?

Instead of the patient carrying a paper prescription to the pharmacy, the prescription data is registered with the Electronic Prescription Management Service (operated by the Payment Fund and the National Federation of National Health Insurance Associations), and the pharmacy retrieves it online. The patient is received using their My Number health insurance card and selects the relevant prescription on the card reader, or identifies it by giving the pharmacy the exchange number together with their insurance card details (the prescription ID is an internal system identifier, not a number the patient handles). The biggest change is that, because prescribing and dispensing information accumulates in the management service, checks such as duplicate prescribing can be performed across healthcare providers and pharmacies.

How does ORCA (Nichi-Rece) support electronic prescriptions?

The role is split in two. The Nichi-Rece core holds a table (tbl_shoho_kanri) managing prescription IDs, exchange numbers, refill counts and cancellation/amendment history, a mechanism for exporting prescription content as CSV, and prescription-form report programs that support electronic prescriptions. Electronic signing (local signing with an HPKI card, or remote signing) and communication with the Electronic Prescription Management Service, on the other hand, are the job of the supporting program family — the electronic prescription module, the extended e-prescription helper and so on — plus the separately required electronic signature module (verified vendor-supplied products exist). The fact that no electronic signature processing appears in the published Nichi-Rece core source is itself evidence of that division of responsibility.

What is an exchange number?

It is the number a patient uses to collect an electronic prescription at a pharmacy without using a My Number health insurance card. The pharmacy identifies the prescription from this number together with the insurance card details and retrieves it from the management service. Under current operation the exchange number is six digits; in the ORCA (Nichi-Rece) source it is stored in the prescription management table as ACCESSCODE (a field of up to 16 digits) and managed together with the prescription ID.

How do online eligibility verification and electronic prescriptions relate to each other?

They are connected at the entrance. When a patient is received using a My Number health insurance card, they can indicate on the card reader whether they wish to receive the prescription electronically or on paper, and that information (the prescription issue format) flows to the receipt computer together with the eligibility verification result. In the ORCA source too, a prescription issue format field was added to the eligibility verification result table in July 2022, which shows that online eligibility verification and electronic prescriptions are stacked on the same foundation.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.