전자처방전은 레세콘의 무엇을 바꾸는가 ── 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편입니다. 처음부터 전부 읽을 필요는 없으며, 참조가 나올 때마다 되돌아가서 읽는 방식으로 충분합니다.

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

목차

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/>중복투약 등 체크의 기반으로"]

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

레세콘 관점에서의 본질은 2가지입니다. 첫째, 처방전이 원내에서 완결되는 서식이 아니라 외부 서비스에 등록되는 구조화 데이터가 되었다는 것. 둘째, 처방・조제 실적이 관리서비스에 모임으로써 의료기관・약국을 넘나드는 중복투약 등의 체크가 가능해졌다는 것입니다. 4편에서 ‘타 기관 데이터와의 대조는 원내에서는 원리적으로 불가능하다’라고 썼지만, 전자처방전은 그 벽을 처방 영역에서(심사 시점이 아니라 처방 시점에) 넘기 위한 국가 인프라라고 자리매김할 수 있습니다.

2. 제도의 최단 이해 ── 전자처방전 관리서비스와 교환번호

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

• 언제부터: 2023년 1월에 운용 개시. 온라인자격확인의 네트워크와 기반을 전제로 한 구조로, 대응 시설은 단계적으로 확대되고 있습니다.
• 처방전 특정 방법: 발행된 전자처방전에는 처방전ID가 부여됩니다. 환자가 마이나보험증으로 약국 접수를 하는 경우에는 카드리더 위에서 해당 전자처방전을 선택하여 특정하고(여러 건이 있을 경우 선택 단계가 있습니다), 마이나보험증을 사용하지 않는 경우에는 교환번호와 피보험자증 등의 정보를 약국에 전달하여 특정합니다(교환번호만으로는 특정할 수 없습니다).
• 중복투약 등 체크: 처방・조제 정보가 관리서비스에 축적되기 때문에, 처방 시점에 최근 처방・조제 데이터와 대조한 체크 결과를 의사・약사가 참조할 수 있습니다.
• 리필처방전: 2022년도 진료보수 개정에서 도입된, 일정 기간 내에 반복해서 사용할 수 있는 처방전. 전자처방전은 리필의 반복 이용 관리와도 궁합이 좋으며, 뒤에서 설명하듯 ORCA의 테이블에도 리필 항목이 포함되어 있습니다.

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

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

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: 조제결과를 등록

이 그림에서 읽어내야 할 점은 2가지입니다.

첫째, 병원에서 약국으로 시스템 연동 데이터가 직접 건네지는 일은 없다는 것입니다. 처방전의 정규 데이터는 항상 관리서비스를 경유합니다. 환자가 운반하는 것은 ‘열쇠’(마이나보험증 또는 교환번호)이며, 처방 내용(부본)의 종이를 받아 들고 다니는 경우도 있지만, 부본은 어디까지나 참고 정보일 뿐 약국이 조제에 사용하는 정규 데이터는 관리서비스에서 취득합니다. 병원・약국 간에 포인트투포인트 연동을 만들 필요가 없는 대신, 양쪽 모두 관리서비스와의 연동 품질이 전부가 됩니다.

둘째, 3가지 식별자는 역할이 명확하게 나뉘어 있다는 것입니다.

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가 등장하지 않는 이유의 답 맞추기가 바로 이것입니다.

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

지금까지의 그림은 의료기관 내부를 하나의 흐름으로 접어서 표현했지만, 실제 원내에는 전자차트와 레세콘이 병존하는 구성이 많습니다. 그 경우 처방이 약국(관리서비스)에 도달하기까지의 경로는 크게 2가지 패턴으로 나뉩니다.

그림으로 나타내면, 두 패턴의 차이는 ‘서명・등록 상자가 어느 쪽에 있는가’로 요약됩니다.

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년 반이 지나서도 연간 수차례 페이스로 개수가 계속됨

이 이력이 보여주듯, 전자처방전의 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(医療機関等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. ‘종이’ 안에도 2종류가 있다는 것을 전제로 한다. 전 환자・전 약국이 전자로 통일될 때까지는 종이 처방전이 남지만, 전자처방전을 도입한 시설에서는 종이 처방전이라도 처방・조제 정보를 관리서비스에 등록하는 운용(교환번호 부착 종이 처방전)이 있으며, 중복투약 등 체크의 대상이 됩니다. ‘전자/종이’라는 이분법이 아니라 ‘전자/관리서비스 등록이 있는 종이/기존 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.