전자처방전이 레세콘의 무엇을 바꾸는가 ── 소스 코드로 읽는 ORCA의 전자처방전 대응

2023년 1월에 운용이 시작된 전자처방전은 온라인 자격확인에 이은 의료 DX의 2탄으로 자주 이야기됩니다. 그렇다면 레세콘에게 전자처방전 대응이란 구체적으로 무엇을 하는 일일까요. 처방전이라는 장표를 전자화했다고만 말해서는 설계가 되지 않습니다.

1편에서 레세콘의 역할, 2편에서 니치레세 API, 3편에서 온라인 자격확인, 4편에서 레셉트 점검을 다뤘습니다. 5편인 이번에는 전자처방전을 레세콘 쪽에서 해부합니다.

• 전자처방전으로 처방 흐름이 어떻게 바뀌는지(제도의 핵심만)
• ORCA(니치레세) 대응의 전체 그림 ── 본체와 대응 프로그램의 책임 경계
• 처방전 ID·교환번호·리필을 관리하는 tbl_shoho_kanri의 설계
• 발행 형태 희망이 온라인 자격확인에서 도착한다는, 제도 사이의 연결

제도 쪽 서술은 후생노동성·ORCA 공식의 공개 자료에, 소스 코드에 관한 서술은 공식 공개된 니치레세 본체 5.2계 소스(2026년 7월 1일 공개 스냅샷)를 실제로 읽고 확인한 결과에 근거합니다(소스 입수 경로는 8장의 5)에 정리했습니다).

이 글의 읽는 법

대상 독자는 의료기관용 시스템(전자차트·처방 지원·접수·부문 시스템 등)을 만드는 벤더 엔지니어와, 원내에서 그 연동을 맡는 정보시스템 담당자입니다. 진료보수나 의료 업무의 사전 지식은 전제로 하지 않습니다. 관계형 데이터베이스와 API 연동의 일반적인 지식은 전제로 합니다.

이 글만으로 읽을 수 있는 범위: 전자처방전 제도의 골격(2장), ORCA의 책임 경계(4장), 처방 관리 테이블의 설계(5장), CSV 연동과 장표(6장), 벤더용 검증 환경(8장)은 시리즈를 읽지 않아도 그대로 읽을 수 있습니다.

전제로 하는 환경: 본문의 테이블 정의·소스에 관한 서술은 니치레세 5.2계(WebORCA 온프레미스 판, 2026년 7월 1일 공개 소스 스냅샷)에 근거합니다. 니치레세의 데이터베이스는 PostgreSQL이며, WebORCA 온프레미스 판 설치에서는 데이터베이스 사용자 orca·UTF-8 인코딩을 씁니다(PostgreSQL 버전은 OS를 따르며, 공식 절차가 있는 Ubuntu 22.04 LTS에서는 14계). 본문에 나오는 tbl_로 시작하는 이름은 이 PostgreSQL 위의 테이블입니다.

먼저 읽으면 이해가 빠른 회차: 본문에서 전제로 참조하는 회차는 다음 4편입니다. 처음부터 전부 읽을 필요는 없고, 참조가 나온 지점에서 돌아가며 읽으면 충분합니다.

호칭과 약어의 대응: 공식 자료와 본문에서 이름이 흔들리기 쉬운 것을 먼저 고정해 둡니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

목차

1. 먼저 결론 ── 처방전은 「건네는 것」에서 「가지러 가는 것」이 됩니다
2. 제도의 핵심만 ── 전자처방전 관리 서비스와 교환번호
3. 앞선 역사 ── 처방전은 2001년부터 QR 코드를 지고 있었습니다
4. ORCA 대응의 전체 그림 ── 본체와 대응 프로그램의 책임 경계
5. tbl_shoho_kanri를 읽기 ── 처방전 한 장이 갖는 전자적 속성
6. 데이터의 출구 ── 전자처방전 CSV와 장표
7. 온자와의 연결 ── 발행 형태는 자격확인에서 도착합니다
8. 벤더를 위해 ── 검증 환경을 어떻게 마련할 것인가
9. 연동 시스템을 만드는 쪽의 실무 포인트
10. 정리
11. 참고 자료

1. 먼저 결론 ── 처방전은 「건네는 것」에서 「가지러 가는 것」이 됩니다

종이 처방전은 의료기관이 인쇄하고, 환자가 약국까지 가져가는 「손으로 넘기는 데이터 연동」이었습니다. 전자처방전에서는 흐름이 뒤집힙니다.

flowchart LR
    subgraph clinic["의료기관"]
        DR["의사의 처방"]
        RC["레세콘/전자차트<br/>(ORCA에서는 처방 데이터를 관리)"]
        SIGN["전자처방전 대응 프로그램<br/>+ 별도의 전자서명 모듈<br/>(전자서명·송신)"]
        DR --> RC --> SIGN
    end
    SIGN -->|"처방전 데이터 등록"| EPS["전자처방전 관리 서비스<br/>(사회보험진료보수지급기금·국민건강보험중앙회)"]
    EPS -->|"교환번호(환자용)"| PT["환자<br/>(마이나보험증 또는 교환번호)"]
    PT --> PH["약국"]
    EPS -->|"처방전 데이터 취득"| PH
    PH -->|"조제 결과 등록"| EPS2["(관리 서비스로)<br/>중복 투약 등 점검의 기반이 됩니다"]

• 의료기관은 처방전 데이터를 전자처방전 관리 서비스(온라인 자격확인과 마찬가지로 사회보험진료보수지급기금·국민건강보험중앙회가 운영)에 등록합니다.
• 환자는 종이를 들고 다니는 대신, 마이나보험증으로 약국 접수하거나 교환번호(와 피보험자증 등 정보)를 전합니다.
• 약국은 관리 서비스에서 처방전 데이터를 가지러 가고, 조제 결과를 등록합니다.

레세콘 관점의 본질은 두 가지입니다. 첫째, 처방전이 원내에서 끝나는 장표가 아니라 외부 서비스에 등록되는 구조화 데이터가 되었다는 점. 둘째, 처방·조제 실적이 관리 서비스에 모이면서 의료기관·약국을 가로지르는 중복 투약 등의 점검이 가능해졌다는 점입니다. 4편에서 「다른 기관 데이터와의 대조는 원내에서는 원리적으로 할 수 없다」고 썼습니다. 전자처방전은 그 벽을 처방 영역에서(심사의 시점이 아니라 처방의 시점에) 넘기 위한 국가 인프라로 자리매김할 수 있습니다.

2. 제도의 핵심만 ── 전자처방전 관리 서비스와 교환번호

제도 쪽 요점만 정리합니다.

• 언제부터: 2023년 1월에 운용 시작. 온라인 자격확인의 네트워크와 기반을 전제로 한 구조이며, 대응 시설은 단계적으로 늘고 있습니다.
• 처방전을 특정하는 방법: 발행된 전자처방전에는 처방전 ID가 붙습니다. 환자가 마이나보험증으로 약국 접수하는 경우에는 카드 리더에서 대상 전자처방전을 골라 특정하고(여러 장이 있으면 고르는 단계가 있습니다), 마이나보험증을 쓰지 않는 경우에는 교환번호와 피보험자증 등 정보를 약국에 알려 특정합니다(교환번호만으로는 특정할 수 없습니다).
• 중복 투약 등 점검: 처방·조제 정보가 관리 서비스에 쌓이므로, 처방 시점에 직전의 처방·조제 데이터와 대조한 점검 결과를 의사·약사가 볼 수 있습니다.
• 리필 처방전: 2022년도 진료보수 개정에서 들어온, 일정 기간 안에 반복해서 쓸 수 있는 처방전. 전자처방전은 리필의 반복 이용 관리와도 잘 맞고, 뒤에서 보듯 ORCA의 테이블에도 리필 항목이 들어가 있습니다.

식별자는 병원과 약국 사이를 어떻게 오가는가

처방전 ID·교환번호·피보험자 정보라는 세 식별자가 누구의 손을 거치는지를, 발행부터 조제까지 시간 순으로 따라가면 전자처방전의 구조가 가장 잘 보입니다.

sequenceDiagram
    participant MED as 의료기관<br/>(ORCA+전처/서명 모듈)
    participant EPS as 전자처방전<br/>관리 서비스
    participant PT as 환자
    participant PH as 약국
    Note over MED: 처방 확정·전자서명
    MED->>EPS: 처방전 데이터 등록(피보험자 정보를 포함)
    EPS-->>MED: 처방전 ID+교환번호를 채번
    Note over MED: tbl_shoho_kanri에 기록<br/>부본 장표에 교환번호를 인쇄
    MED-->>PT: 부본(교환번호)을 건넵니다
    alt 마이나보험증으로 접수
        PT->>PH: 마이나보험증을 대고<br/>카드 리더에서 대상 처방전을 고름
        PH->>EPS: 피보험자 정보로 조회
    else 교환번호로 접수
        PT->>PH: 교환번호+피보험자증 등 정보를 전함
        PH->>EPS: 피보험자 번호 등+교환번호로 조회
    end
    EPS-->>PH: 처방전 데이터를 반환(내부에서는 처방전 ID로 관리)
    PH->>EPS: 조제 결과를 등록

이 그림에서 읽어야 할 것은 두 가지입니다.

첫째, 병원에서 약국으로 시스템 연동 데이터가 직접 넘어가지는 않는다는 점입니다. 처방전의 정본 데이터는 항상 관리 서비스를 거칩니다. 환자가 나르는 것은 「열쇠」(마이나보험증 또는 교환번호)입니다. 처방 내용(부본)의 종이를 받아 들고 다니는 경우도 있지만, 부본은 어디까지나 참고 정보이며, 약국이 조제에 쓰는 정본 데이터는 관리 서비스에서 가져옵니다. 병원·약국 사이의 포인트 투 포인트 연동을 만들 필요가 없는 대신, 양쪽 모두 관리 서비스와의 연동 품질이 전부가 됩니다.

둘째, 세 식별자는 역할이 분명하게 나뉜다는 점입니다.

ORCA 쪽에서 이 왕복의 흔적이 남는 곳이, 뒤에서 볼 처방 관리 테이블입니다. 발행 때 관리 서비스에서 돌아온 처방전 ID와 교환번호가 그대로 들어가고(PRESCRIPTIONID·ACCESSCODE), 부본 장표 인쇄나 취소·변경 때의 대조에 쓰입니다.

3. 앞선 역사 ── 처방전은 2001년부터 QR 코드를 지고 있었습니다

「처방전을 데이터로 만든다」 자체는 사실 새 이야기가 아닙니다. ORCA 소스에는 cobol/common/ORCSQRCSV.CBL 「처방전　QR 데이터 출력」이라는 프로그램이 있고, 작성 일자는 2001년 9월입니다. 종이 처방전에 QR 코드를 인쇄하고, 약국 쪽 시스템이 읽어 조제 시스템으로 넣는──그런 운용은 20년도 더 전부터 있었습니다.

즉 전자처방전이 가져온 변화는 「데이터화」가 아니라, 데이터가 놓이는 곳과 가져오는 경로의 표준화입니다. QR 코드는 종이에 찍힌 「그 한 장만의 데이터」였습니다. 전자처방전은 전국 공통의 관리 서비스에 등록되고, 처방전 ID로 누구든(권한 범위에서) 가져올 수 있습니다. 이 차이가 중복 투약 점검 같은 횡단 기능을 가능하게 했습니다. 소스 안에 옛것과 새것이 함께 있는 모습은, 이행기 레세콘다운 풍경입니다.

4. ORCA 대응의 전체 그림 ── 본체와 대응 프로그램의 책임 경계

ORCA의 전자처방전 대응은 공식 페이지(「일의표준레셉트소프트 전자처방전」)에 따르면 니치레세 본체+전자처방전 대응 프로그램(전자처방전 API) 구성입니다. 5.2계 공개 소스를 읽으면, 이 경계선이 구현에서도 확인됩니다.

재미있는 것은 마지막 행입니다. 전자처방전의 기술적 하이라이트인 전자서명 주변이, 니치레세 본체의 400만 줄에는 전혀 나오지 않습니다. 본체는 「처방 데이터의 정본으로 남는 일」에 머물고, 서명·통신처럼 변화가 빠른 영역은 다른 프로그램으로 떼어 낸다──3편에서 본 온자 연동(본체는 API와 테이블, 파일 주고받기는 onshi-tools)과 같은 경계 패턴입니다. 국가 인프라 쪽의 사양 변경을, 본체의 릴리스 주기에서 떼어 내는 설계로 읽을 수 있습니다.

그렇다면 떼어 낸 쪽에는 무엇이 있을까요. 공식 페이지에 실린 대응 프로그램군의 면면은 이렇습니다.

대응 OS는 컴포넌트마다 다릅니다. 전자처방전 모듈과 확장전처 헬퍼는 Windows 11(x64) 전용이고, 처방 입력 화면은 Windows·Mac·Ubuntu(Ubuntu 대응은 WebORCA 온프레미스 판만)입니다. 원내 단말 계획에서는, 발행 주변 모듈이 Windows를 전제로 한다는 점에 주의하십시오. 그리고 서명의 분담이 중요합니다. 공식 페이지에는 「전자처방전을 도입하려면, 별도의 전자서명 모듈이 필요하다」고 명시되어 있습니다. 검증이 끝난 전자서명 모듈(아이오데이터 기기, 미쓰비시전기 IT솔루션즈 제공)이, HPKI 카드(HPKI=보건의료복지 분야 공개키 기반. 의사 등의 국가 자격을 증명할 수 있는 전자증명서를 담은 IC 카드)에 의한 로컬 서명과 원격 서명(FIDO 인증·HPKI 카드 인증·마이넘버 카드 인증)을 맡습니다. 즉, 전자처방전에서 움직임이 가장 심한 「의사의 전자서명을 어떻게 성립시킬 것인가」라는 논점은, 니치레세 본체에서도 전처 모듈에서도 떨어져 나와 전용 서명 모듈 층에 흡수되어 있습니다──본체 소스에 HPKI가 나오지 않는 이유의 답이 여기입니다.

전자차트가 있는 경우, 발행의 주체는 어느 쪽인가

여기까지의 그림은 의료기관 안을 한 줄의 흐름으로 접었습니다. 실제 원내에는 전자차트와 레세콘이 함께 있는 구성이 많습니다. 그 경우, 처방이 약국(관리 서비스)에 닿기까지의 길은 크게 두 패턴으로 갈립니다.

그림으로 보면, 두 패턴의 차이는 「서명·등록의 상자가 어느 쪽에 있는가」로 모입니다.

flowchart TB
    subgraph A["패턴 A: ORCA를 발행 주체로 한다"]
        direction LR
        EMRA["전자차트<br/>(오더)"] -->|"니치레세 API"| ORCAA["ORCA<br/>tbl_shoho_kanri"]
        ORCAA --> MODA["전처 모듈<br/>+ 전자서명 모듈"]
        MODA -->|"등록"| EPSA["전자처방전<br/>관리 서비스"]
    end
    subgraph B["패턴 B: 전자차트를 발행 주체로 한다"]
        direction LR
        EMRB["전자차트<br/>(자체 전처 대응+서명)"] -->|"등록"| EPSB["전자처방전<br/>관리 서비스"]
        EMRB -->|"청구용으로 처방을 연동"| ORCAB["ORCA<br/>(레셉트 작성)"]
    end

패턴 A의 흔적은 소스에 분명히 남아 있습니다. 5장에서 볼 처방 관리 테이블의 발행원 구분(HAKKOKBN)에는 「API 중도 데이터 송신」이라는 값이 있고(COPY 구 CPSHOHO-KANRI.INC의 주석으로 확인), 전자차트에서 API로 들어온 처방도 ORCA 화면에서 입력한 처방과 같은 테이블에서 관리되는 구조입니다. 2편에서 본 「API는 화면 업무의 API 판」이라는 설계가, 전자처방전의 발행 경로에서도 살아 있는 셈입니다.

어느 패턴이든 약국으로 「보내는」 처리는 없습니다. 약국 쪽은 약국 레세콘·조제 시스템이 관리 서비스에서 처방전 데이터를 가져옵니다(약국 시스템 안의 연동에 대해서는, 후생노동성이 레세콘↔전자약력 사이의 연동 데이터 자료를 공개하고 있습니다). 의료기관 쪽 벤더가 설계에서 먼저 정해야 할 것은, 발행·서명·취소의 기점을 차트 쪽과 ORCA 쪽 어디에 둘 것인가, 그리고 그 결정에 맞춰 처방전 ID·교환번호가 청구 데이터와 대조되도록 tbl_shoho_kanri에 해당하는 관리를 어느 쪽이 가질 것인가, 하는 점입니다.

5. tbl_shoho_kanri를 읽기 ── 처방전 한 장이 갖는 전자적 속성

니치레세 본체 쪽의 중심은 처방 관리 테이블 tbl_shoho_kanri입니다. 정의(record/tbl_shoho_kanri.db)와 COPY 구의 일본어 주석에서 주요 항목을 뽑습니다.

tbl_shoho_kanri {
    TBL_UUID          varchar(36);  -- 식별 uuid
    RENNUM            number(1);    -- 연번(기본 키는 HOSPNUM+TBL_UUID+RENNUM)
    SRYYMD / PTID / SRYKA / HKNCOMBI  -- 진료일·환자·진료과·보험의 조합
    SHOHO_KEITAI      varchar(1);   -- 처방전 발행 구분(전자/종이)
    PRESCRIPTIONID    varchar(36);  -- 처방전 ID
    ACCESSCODE        varchar(16);  -- 교환번호
    REFILL_NUM        number(1);    -- 리필 횟수
    REFILL_ZAIKAISU   number(3);    -- 리필 처방 일수
    CANCEL_TIME / CANCEL_UNDO_TIME  -- 처방전 취소 일시와 취소 UNDO 일시
    CHANGE_TIME / CHANGE_UNDO_TIME  -- 변경 일시와 변경 UNDO 일시
};

이 테이블만으로도 전자처방전의 실무가 비칩니다.

• 처방전 ID(36자리분)와 교환번호(16자리분)의 영역을 쌍으로 가집니다. 2장에서 본 두 가지 수령 방법(마이나보험증/교환번호)에 대응하는 키가, 레코드의 속성으로 그대로 실려 있습니다(참고로 현행 운용의 교환번호는 6자리이며, 16자리는 컬럼의 용량입니다. 자릿수를 고정값으로 구현하지 않는 편이 안전할 것입니다).
• 취소와 변경에, 각각 UNDO의 일시가 있습니다. 전자처방전은 관리 서비스에 이미 등록된 데이터이므로, 원내에서 처방을 취소하면 등록도 취소해야 하고, 그 취소를 다시 취소하는(복원하는) 조작까지 일어날 수 있습니다. 종이 시대에는 「찢고 다시 쓰기」였던 운용이, 상태 전이의 관리로 바뀐 것입니다.
• 리필이 처음부터 속성입니다. 리필 횟수와 처방 일수가 처방 관리의 기본 항목에 들어 있어, 반복 이용을 전제로 한 라이프사이클 관리가 설계에 들어가 있습니다.

덧붙여 식별에 uuid를 쓰는 구조는, 3편의 온자 관련 테이블(tbl_onshi_kaku)과 공통의 관용입니다. 다만 기본 키는 uuid 혼자가 아니라 의료기관 번호+uuid+연번(RENNUM)의 복합 키이며, 같은 uuid에 여러 행이 매달리는 설계입니다. 연동 시스템 쪽에서 이 테이블에 해당하는 데이터를 다룰 때는, uuid만 행 키로 보면 여러 행이 뭉개지므로 주의하십시오.

6. 데이터의 출구 ── 전자처방전 CSV와 장표

5장의 테이블과 7장의 온자 연결까지 포함해, ORCA 안을 데이터가 어떻게 지나는지를 먼저 한 장으로 둡니다.

flowchart LR
    ONS["온라인 자격확인<br/>(접수 시)"] -.->|"발행 형태의 희망<br/>SHO_SHOHO_KEITAI"| TBL
    NYURYOKU["처방의 입력<br/>(화면 / 니치레세 API)"] --> TBL["tbl_shoho_kanri<br/>처방전 ID·교환번호·<br/>리필·취소/변경"]
    TBL -->|"CSV 출력<br/>(ORCSEPRECSV)"| MOD["전처 모듈<br/>(등록 요청의 조립·송신)"]
    SIGNM["전자서명 모듈<br/>(전자서명)"] -.->|"서명"| MOD
    MOD -->|"등록"| EPS["전자처방전<br/>관리 서비스"]
    EPS -.-> RET["처방전 ID·교환번호<br/>(tbl_shoho_kanri에 기록·<br/>부본 장표 ORCHC02계로)"]

처방 데이터가 대응 프로그램으로 넘어가는 출구가 ORCSEPRECSV.CBL(전자처방전 CSV 데이터 출력)입니다. 헤더의 수정 이력이, 그대로 제도 대응의 기록이 되어 있습니다.

• 2022년 10월 신규 작성 ── 2023년 1월 운용 시작에 앞서 구현
• 2023년 6월 용법 마스터 반영 대응 ── 전자처방전에서는 용법(복용 방법)도 코드화해 다루므로, 용법 마스터와의 정합이 필요해졌습니다
• 2024년 리필 횟수 대응(1월)·교부 번호 비고 기재 대응(3월)·선발 의약품 환자 희망 대응(8월)·한자 성명 40바이트화(12월) ── 장기 등재품의 선정 요양(환자 희망의 기록) 등, 제도 쪽 움직임이 그대로 항목 추가가 되어 있습니다
• 2025년 더미 코드 경고 대응(1월)·사용 기한 연월일 대응(4월)·부담자 번호/수급자 번호 자릿수 대응(7월) ── 운용 시작부터 2년 반이 지나도, 1년에 몇 차례씩 수정이 이어집니다

이 이력이 보여 주듯, 전자처방전의 CSV 연동은 「한 번 만들면 끝」이 아니라 지금도 바뀌고 있습니다. 장표 쪽에서는, 처방전 양식의 장표 프로그램(ORCHC02계·ORCHCM19계)에 전자처방전 대응 판이 나란히 있습니다. 전자처방전이 되어도 장표가 사라지지 않는 것은, 환자에게 건네는 부본(교환번호 안내를 포함)이나, 종이 운용과의 병행이 이어지기 때문입니다. 「전자화=장표 폐지」가 아니라, 장표는 남기면서 정본 데이터가 놓이는 곳이 바뀐다는 것이 이행기의 실태이며, 소스의 파일 구성이 그것을 정직하게 비춥니다.

7. 온자와의 연결 ── 발행 형태는 자격확인에서 도착합니다

전자처방전을 원내 흐름으로 보면, 첫 분기는 「이 환자는 전자와 종이 중 어느 쪽으로 처방전을 받을 것인가」입니다. 이 정보는 어디서 올까요──답은 온라인 자격확인입니다.

환자가 마이나보험증으로 접수할 때, 카드 리더에서 처방전 수령 방법(전자/종이)을 고를 수 있습니다. 그 선택은 자격확인 결과와 함께 레세콘으로 도착합니다. 3편에서 읽은 온자의 자격확인 결과 테이블 tbl_onshi_kaku에는 처방전 발행 형태 항목(SHO_SHOHO_KEITAI)이 있고, 정의 주석에 따르면 2022년 7월의 추가입니다. 온자의 XML 정의에도 PrescriptionIssueSelect(처방전 발행 형태)라는 항목이 있습니다. 전자처방전 운용 시작(2023년 1월)의 반년 전에, 먼저 온자 쪽 받는 곳이 넓혀져 있었습니다──제도가 쌓이는 순서까지, 소스의 날짜에서 읽을 수 있는 셈입니다.

그리고 접수에서 정해진 발행 형태는, 처방 장면에서 tbl_shoho_kanri.SHOHO_KEITAI로 처방전 한 장마다 확정됩니다. 온자(접수)→처방(진료)→관리 서비스(발행)이라는 제도 사이 데이터 전달이, 테이블 설계 수준에서 이어져 있습니다. 온라인 자격확인을 「자격을 입구로 정보가 흐르는 간선」이라고 부른 3편의 읽기가, 전자처방전에서도 뒷받침됩니다.

8. 벤더를 위해 ── 검증 환경을 어떻게 마련할 것인가

전자처방전 연동 개발에서 먼저 막히는 것은 코드가 아니라 「사양서와 테스트 환경의 입수 경로가 흩어져 있다」는 점입니다. 공식 정보를 입구별로 정리합니다.

1) 사양서 입수 ── 「의료기관 등 ONS」

시스템 벤더용 1차 사양은, 지급기금이 제공하는 벤더용 정보 사이트 「의료기관 등 ONS」에 모여 있습니다(온라인 자격확인 등 시스템 외부 인터페이스 사양서와 전자처방전 관리 서비스 기록 조건 사양도 여기입니다). 의료기관이 쓰는 종합 포털과는 다른 사이트이며, 벤더로서의 이용 등록이 전제입니다. 아울러 후생노동성의 「전자처방전(시스템 벤더용)」 페이지에 시스템 벤더용 기술 해설서(집필 시점 2.04판)와 약국 시스템용 연동 자료가 공개되어 있습니다. 참고로 JAHIS(일반사단법인 보건의료복지정보시스템공업회. 의료정보시스템 벤더가 모인 업계 단체이며, 각종 표준 규격과 구현 가이드를 만듭니다)의 「전자처방전 구현 가이드」(Ver.1.2, 2021년)는 현행 전자처방전 관리 서비스보다 앞선 검토 자료이며, 현행 사양의 1차 자료는 어디까지나 ONS의 사양서·기술 해설서 쪽입니다. 검색에서 먼저 나오기 쉬우니 주의하십시오.

2) 테스트용 증명서·카드 입수

전자처방전 발행에는 의사·치과의사의 전자서명(HPKI)이 필수이므로, 테스트에도 증명서가 필요합니다. 입수 창구는 용도로 갈립니다.

• HPKI 테스트 카드(서명용·인증용): 창구는 직종으로 갈립니다. 의사용은 일본의사회 전자인증센터(JMACA. 일본의사회가 운영하는 HPKI 인증국이며, 의사자격증=HPKI 카드를 발행합니다)의 「벤더 여러분께」 페이지에서 신청서를 우편으로 보내 받습니다. 치과의사용·약사용은 각각의 인증국(MEDIS=일반재단법인 의료정보시스템개발센터, 일본약제사회 인증국)의 안내를 따릅니다.
• HPKI 세컨드 전자증명서(카드리스 서명)의 검증 환경 이용·테스트용 마이넘버 카드: MEDIS의 전용 창구에 메일로 신청합니다.
• 주의점으로, 실운용용 HPKI 카드는 평시에도 신청부터 발행까지 2〜3개월이 걸립니다. 게다가 집필 시점의 JMACA 안내에서는, IC 카드 부족으로 물리 카드(의사자격증) 발행이 일시 정지되고, HPKI 세컨드 전자증명서(카드리스)를 먼저 발행하는 운용이 안내되어 있습니다. 카드를 전제로 계획을 세우기 전에, 최신 발행 상황과 카드리스 서명으로의 대체 가능 여부부터 확인하는 편이 안전합니다.

3) 접속 검증과 릴리스 전 점검

관리 서비스와의 접속 검증은 ONS 경유 안내를 따라 진행하게 됩니다. 개발자로서 먼저 읽어 두고 싶은 것은, 후생노동성이 공개한 「전자처방전 대응판 소프트웨어 릴리스에 관한 셀프 체크리스트(테스트 완료 확인)」(집필 시점 4.2판)입니다. 벤더는 이 체크리스트의 테스트 완료를 확인하고 릴리스하는 구조이며, 뒤집으면 「무엇을 테스트해야 하는가」의 공식 목록이 처음부터 있다는 뜻입니다. 테스트 계획은 여기서부터 역산하는 것이 지름길입니다. 또한 서명 처리를 직접 구현하지 않는 선택지로 전자처방전 서명 공통 모듈이 있고, 도입 지원 서비스 제공 사업자 목록도 후생노동성 페이지에 실려 있습니다.

4) ORCA 쪽의 검증 환경

니치레세+대응 프로그램 구성으로 검증한다면, WebORCA 온프레미스 판을 검증용 서버에 세우고, 공식 전처 모듈&확장전처 헬퍼 설치 매뉴얼을 따라 셋업합니다. 6장에서 본 대로 전자처방전은 용법 마스터와 맞물리므로, 마스터 갱신까지 끝내 두지 않으면 출력 데이터의 검증이 되지 않습니다. 나아가 표준 용법 코드에는 사용 기한이 있습니다. 집필 시점의 공식 페이지에서는, 2026년 8월 1일부터 일부 표준 용법 코드가 전자처방전에서 사용 불가가 되고, 기한이 지난 코드의 매핑이 남아 있으면 니치레세는 더미 코드를 출력한다는 안내가 있습니다. 마스터를 최신으로 맞추는 것만 아니라, 자사 시스템이 쓰는 용법 코드의 재매핑 확인까지 검증 항목에 넣으십시오(지금 테스트가 통과해도, 기한일을 경계로 더미 코드 출력으로 바뀔 수 있습니다). 3편에서 소개한 온자의 검증용 패턴 파일과 마찬가지로, 스스로 테스트 데이터를 만들기 전에 공식 검증 수단을 확인하는 것이 철칙입니다.

5) 소스를 직접 읽기

이 글의 구현에 관한 서술은, 모두 공개 소스의 실물을 확인해 적은 것입니다. 같은 일은 누구든 할 수 있습니다. 경로는 이렇습니다.

• 입수: ORCA Project의 기술 정보 페이지에서 소스가 공개되어 있습니다. 매월 1일에, 전월 1일 시점의 소스가 tar 볼(zip)로 공개되는 형태이며, 5.2계 본체는 https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip입니다(디렉터리 목록 표시는 되지 않으므로, 기술 정보 페이지의 링크에서 받으십시오). 지방 공비(jma-receipt-kk)와 장표(jma-receipt-forms)는 별 아카이브입니다.
• 어디를 볼 것인가: 테이블 정의는 record/ 아래(예: record/tbl_shoho_kanri.db), 항목의 일본어 주석은 COBOL의 COPY 구(cobol/copy/CPSHOHO-KANRI.INC), 처리 본체는 cobol/common/ 아래(예: ORCSEPRECSV.CBL)입니다. 테이블 전체를 잡고 싶을 때는, 같은 기술 정보 페이지의 「일의표준레셉트소프트 데이터베이스 테이블 정의서」를 색인으로 쓸 수 있습니다.
• 읽어 가는 방법: 일본어 주석으로 검색하면 소스의 문자 코드에 좌우되므로, 우선 영숫자 식별자로 따라가는 편이 확실합니다.

# 처방 관리 테이블의 정의와, 항목명+일본어 주석을 가진 COPY 구
less record/tbl_shoho_kanri.db
less cobol/copy/CPSHOHO-KANRI.INC

# 처방전 ID를 다루는 프로그램을 가려낸다
grep -rl "PRESCRIPTIONID" cobol/ | head

# COBOL 프로그램의 머리 주석에는 수정 이력이 들어 있다(제도 대응의 기록이 된다)
head -60 cobol/common/ORCSEPRECSV.CBL

• 변경을 쫓기: 월별 아카이브를 저장해 두고, 전월 분과 diff -r을 하면, 공식 공지보다 빨리 변경을 알아챌 수 있습니다(9장의 5).

9. 연동 시스템을 만드는 쪽의 실무 포인트

전자차트·처방 지원·접수 시스템 등에서 전자처방전 주변에 관여할 때의 요점입니다.

1. 책임 경계를 먼저 긋습니다. 처방 데이터의 관리는 니치레세 본체, 서명·관리 서비스 통신은 전자처방전 대응 프로그램, 이라는 경계가 ORCA의 표준 구성입니다. 자작 연동 시스템이 어느 쪽과 대화해야 하는지를, 기능마다 나눈 뒤에 설계하십시오. 서명 주변을 직접 구현하겠다는 판단은, HPKI 카드 운용까지 짊어진다는 뜻입니다.
2. 처방전 ID와 교환번호를 엔티티로 다룹니다. 「처방전=인쇄물」 데이터 모델 그대로면, 취소/변경/UNDO, 리필 같은 상태 관리가 나중에 붙습니다. tbl_shoho_kanri의 항목 구성은, 전자처방전 시대의 처방 엔티티 설계 참고서로 뛰어납니다(다만 갖고 있는 것은 리필의 횟수·일수이며, 사용한 횟수·남은 횟수의 상태는 실려 있지 않습니다. 남은 횟수는 조제 쪽 라이프사이클에 속하는 데이터로, 따로 다룬다는 전제로 설계하십시오).
3. 발행 형태는 접수 기점으로 흘러 옵니다──다만 마이나 접수에 한합니다. 전자/종이의 희망이 온자의 자격확인 결과에 들어가는 것은, 마이나보험증으로 접수한 경우입니다. 자격확인서 등 마이나보험증을 쓰지 않는 환자에서는, 창구나 진찰실에서 스태프·의사가 의향을 확인하는 운용이 되므로, SHO_SHOHO_KEITAI만 믿으면 의향을 확인하지 못한 채로 처방에 닿는 경로가 남습니다. 접수 시점의 정보를 진료·처방까지 끌고 가는 동선과, 카드 리더에서 온 값이 없을 때의 확인 흐름을, 둘 다 설계에 넣으십시오.
4. 「종이」 안에도 두 종류가 있다는 것을 전제로 합니다. 전 환자·전 약국이 전자로 맞춰질 때까지는 종이 처방전이 남습니다. 다만 전자처방전을 이미 넣은 시설에서는, 종이 처방전이라도 처방·조제 정보를 관리 서비스에 등록하는 운용(교환번호가 붙은 종이 처방전)이 있고, 중복 투약 등 점검의 대상이 됩니다. 「전자/종이」의 이분이 아니라, 「전자/관리 서비스 등록이 있는 종이/종래 QR 코드 운용의 종이」라는 세 가지 선택을 전제로 한 분기 설계가 현실적입니다.
5. 제도의 확장을 따라가는 구조를 갖춥니다. 용법 마스터 대응, 리필 대응과, 전자처방전 주변 소스는 해마다 갱신됩니다. 시리즈에서 반복해 권하듯, 월별 공개 소스의 record/·cobol/ diff 감시가, 여기에서도 공식 공지보다 빠른 변경 감지가 됩니다.

10. 정리

• 전자처방전은, 처방전을 「환자가 들고 다니는 종이」에서 「관리 서비스에 등록되고, 처방전 ID/교환번호로 가져오는 구조화 데이터」로 바꾸는 구조입니다. 처방·조제 정보가 모이면서, 의료기관·약국을 가로지르는 중복 투약 등 점검이 가능해졌습니다.
• ORCA의 대응은 니치레세 본체(데이터 관리·CSV 출력·장표)+대응 프로그램군(전자처방전 모듈·확장전처 헬퍼 등)+별도로 필요한 전자서명 모듈(검증이 끝난 벤더 제공품) 구성입니다. 본체 소스에 전자서명이 나오지 않는 것이, 이 책임 경계의 증거가 됩니다.
• 본체 쪽의 중심은 tbl_shoho_kanri이며, 처방전 ID·교환번호·리필 횟수/일수·취소/변경과 그 UNDO 일시를 처방전 단위로 관리합니다. 처방전 QR 코드 출력(2001년〜)과의 공존이 소스에 남아, 「데이터화」에서 「놓는 곳의 표준화」로라는 변화의 본질을 비춥니다.
• 전자/종이의 발행 형태는, 마이나 접수에서는 온라인 자격확인 결과로서 접수 시에 도착합니다(온자 쪽 받는 곳은 소스상 2022년 7월에 먼저 추가). 자격확인서 등의 환자에서는 창구·진찰실에서의 의향 확인이 따로 필요합니다. 온자→전자처방전이라는 제도의 쌓임이, 테이블과 XML 정의 수준에서 연결되어 있습니다.

시리즈 다음은, ORCA의 데이터베이스 스키마 전체를 읽는 「DB편」 또는 월별 소스 diff 감시의 실운용을 예정하고 있습니다.

11. 참고 자료

• 전자처방전 - 후생노동성
• 일의표준레셉트소프트 전자처방전 - ORCA Project(전자처방전 대응 프로그램·대상 장표)
• 일의표준레셉트소프트의 전자처방전 대응에 대하여 - ORCA Project
• 전자처방전(시스템 벤더용) - 후생노동성(기술 해설서·기록 조건 사양·릴리스 전 셀프 체크리스트)
• 벤더 여러분께(HPKI 테스트 카드) - 일본의사회 전자인증센터
• 처방전 인쇄 API - ORCA Project
• 기술 정보 - ORCA Project(소스 코드의 월별 공개·데이터베이스 테이블 정의서)
• 2대 운용 설정(니치레세 5.2 이후) - ORCA Project(WebORCA 온프레미스 판의 데이터베이스가 PostgreSQL이라는 점)
• HPKI 보건의료복지 분야 공개키 기반 전자인증국 안내 - MEDIS
• 니치레세 본체 5.2계 소스 코드(2026년 7월 공개 스냅샷) record/tbl_shoho_kanri.db / cobol/copy/CPSHOHO-KANRI.INC / cobol/common/ORCSEPRECSV.CBL / cobol/common/ORCSQRCSV.CBL / record/tbl_onshi_kaku.db 외 ── 본문 중 구현에 관한 서술은 모두 이 스냅샷에 근거합니다

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

전자처방전은 종이 처방전과 무엇이 다른가요?

종이 처방전을 환자가 약국까지 가져가는 대신, 처방전 데이터를 전자처방전 관리 서비스(사회보험진료보수지급기금·국민건강보험중앙회가 운영)에 등록하고 약국이 온라인으로 가져옵니다. 환자는 마이나보험증으로 접수한 뒤 카드 리더에서 대상 처방전을 고르거나, 교환번호와 피보험자증 등 정보를 약국에 알려 처방전을 특정합니다(처방전 ID는 시스템 내부 식별자이며, 환자가 다루는 번호가 아닙니다). 관리 서비스 쪽에 처방·조제 정보가 모이므로, 의료기관·약국을 가로지르는 중복 투약 등의 점검이 가능해진 점이 가장 큰 변화입니다.

ORCA(니치레세)는 전자처방전에 어떻게 대응하나요?

역할이 둘로 나뉩니다. 니치레세 본체는 처방전 ID·교환번호·리필 횟수·취소/변경 이력을 관리하는 테이블(tbl_shoho_kanri)과, 처방 내용을 CSV로 출력하는 구조, 전자처방전용 처방전 양식 장표를 갖습니다. 한편 전자서명(HPKI 카드에 의한 로컬 서명이나 원격 서명)과 전자처방전 관리 서비스와의 통신은, 전자처방전 모듈·확장전처 헬퍼 등 대응 프로그램군과, 별도로 필요한 전자서명 모듈(검증이 끝난 벤더 제공품이 있습니다)의 일입니다. 공개된 니치레세 본체 소스에 전자서명 처리가 보이지 않는다는 점에서도, 이 책임 경계를 읽을 수 있습니다.

교환번호란 무엇인가요?

환자가 마이나보험증 없이 약국에서 전자처방전을 받을 때 쓰는 번호입니다. 약국은 이 번호와 피보험자증 정보로 처방전을 특정해 관리 서비스에서 가져옵니다. 현행 운용의 교환번호는 6자리이며, ORCA(니치레세) 소스에서는 처방 관리 테이블에 ACCESSCODE(최대 16자리 영역)로 저장되고, 처방전 ID와 세트로 관리됩니다.

온라인 자격확인과 전자처방전은 어떤 관계인가요?

입구가 이어져 있습니다. 환자가 마이나보험증으로 접수할 때, 카드 리더에서 처방전을 전자로 받을지 종이로 받을지 희망을 고를 수 있고, 그 정보(처방전 발행 형태)가 온라인 자격확인 결과와 함께 레세콘으로 흘러 들어옵니다. ORCA 소스에서도 자격확인 결과 테이블에 처방전 발행 형태 항목이 2022년 7월에 추가되어 있어, 온자와 전자처방전이 같은 기반 위에 쌓여 있음을 알 수 있습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.