ePA Export 플로우

DiGA(WELT Insomnia) 데이터를 ePA로 송출할 때의 전송·연결 경로를 다룬다. MIO Bundle 생성·매핑은 데이터 명세에서, export 선행 요소(eID/KVNR 등)는 필요 요소에서 다룬다.

이 문서의 범위

다룬다: dta-wide-api → RISE/Konnektor → ePA 의 망 연결 토폴로지, TIC(TI-Client)의 역할, RU 환경 설치 위치, 사내 네트워크 사전 점검 항목.
안 다룬다: SOAP 오퍼레이션 상세 스펙(WSDL/ITI-41), MIO 필드 매핑.

확정 전 (2026-06-08 기준)

RISE/fbeta 셋업 자료(Wireguard Config · PVS 인증서 · Arbeitsumgebung.txt)와 컨설팅 미팅은 일정만 요청한 상태로 미수령이다. 아래는 수령 자료의 정확한 IP/포트/엔드포인트로 확정 전의 작업 가설이며, 사내 네트워크 담당자에게 가능 여부를 사전 타진하기 위한 기준이다.

전체 전송 경로 (RU 기준)

두 가지를 분리해서 봐야 한다: 호출 관계(누가 누구를 부르나)와 망 경로(패킷이 어디를 지나가나).

호출 관계

wide-api의 SOAP 목적지는 RISE Konnektor다(Konnektor IP). TIC는 호출 대상이 아니다.

wide-api ──SOAP Protocol──▶ RISE Konnektor ──▶ ePA Aktensystem
                                          │
                                          └─(카드 읽기)─▶ 카드 단말기

망 경로

그 호출은 TIC가 상시 유지하는 Wireguard 터널을 타고 Konnektor에 닿는다. TIC는 SOAP를 받아 대신 전달하는 서버가 아니라 **터널 게이트웨이(라우팅 홉)**다.

[사무실 LAN]                              [RISE 클라우드]      [독일 의료망 TI]

wide-api / RU 개발 코드
   │  ① SOAP Protocol
   ▼
  TIC ══════[Wireguard 터널]═══════════▶ RISE Konnektor ──▶ ePA Aktensystem
   ▲  (터널 상시 유지, 아웃바운드)           │  (Konnektor as a Service,
   │                                        │   RISE 호스팅)
   │  ② 카드 읽기 (같은 터널을 거꾸로)        │
   └────────────────────────────────────────┘
   │
   │ SICCT/TCP (로컬 LAN)
   ▼
 카드 단말기(Cherry) + 테스트 SMC-B/eGK

Wireguard는 네트워크 레벨(L3) VPN이라, 터널이 서면 Konnektor IP가 우리 쪽에서 "닿는 주소"가 된다. wide-api는 TIC를 의식하지 않고 Konnektor IP로 직접 부르고, 그 패킷이 TIC 터널을 통해 흘러갈 뿐이다.
wide-api가 TIC와 다른 머신에서 돈다면, "Konnektor IP로 가는 트래픽은 TIC를 거쳐라"라는 라우팅이 필요하다. RU 최단 구성은 export 코드를 TIC 박스에서 함께 돌리거나 TIC를 Konnektor 대역의 게이트웨이로 두는 것.

핵심: 우리는 RISE Konnektor로 SOAP 호출만 하고, VAU 암호화·SMC-B 서명·XDS→Aktensystem 전달은 RISE Konnektor가 내부에서 처리한다. (Konnektor를 직접 운영하지 않고 "서비스로 빌려쓰는" 구조)

두 방향의 데이터 흐름

연결이 양방향이라는 점이 핵심이다. 누가 터널을 여는가와 요청이 어느 방향으로 흐르는가는 별개다.

① 문서 업로드:  dta-wide-api → TIC → (터널) → RISE Konnektor → ePA
② 카드 읽기:    RISE Konnektor → (같은 터널을 거꾸로) → TIC → 단말기(Cherry)

요청 시작은 우리(앱) — ① 문서 업로드가 출발점이다.
그 처리 도중 Konnektor가 카드(SMC-B 등)를 읽기 위해 우리 쪽으로 접근한다(②). 단, 이것은 새 인바운드 연결이 아니라 TIC가 미리 열어둔 터널을 거꾸로 타고 내려오는 트래픽이다.
방화벽은 "누가 연결을 시작했는가"만 본다 → 시작은 항상 TIC의 아웃바운드 Wireguard이므로, 사내망에 인바운드 포트를 열지 않아도 성립한다.
그래서 TIC는 상시 가동이어야 한다. 터널이 항상 서 있어야 요청이 왔을 때 Konnektor가 카드까지 닿는다.

ePA 쓰기에 필요한 카드

ePA 쓰기에서 주로 필요한 것은 기관 카드 SMC-B다. 환자 카드(eGK)는 인증(eID) 파트에서 처리되어, 쓰기 시점엔 KVNR만 있으면 된다(BfArM 합의). "카드 읽기 방향" 개념은 어느 카드든 동일하다.

구성 요소 역할

요소	위치	역할
dta-wide-api	GCP Cloud Run	MIO/FHIR 문서를 SOAP로 송출(요청 시작점)
TIC (TI-Client)	우리 측(RU=사무실)	Wireguard 터널을 아웃바운드로 상시 수립 + Konnektor↔단말기 중계
RISE Konnektor	RISE 클라우드	SMC-B 서명·VAU 채널·XDS 전달 추상화 (Konnektor as a Service)
카드 단말기(Cherry)	사무실 LAN	테스트 카드(SMC-B/eGK) 물리 리더. RU에서 카드 삽입/제거 테스트용

TIC 설치 위치 (RU)

근본 제약: Konnektor(클라우드)가 카드 단말기(물리)에 도달해야 하고, 앱이 Konnektor에 도달해야 한다. 단말기는 사무실에, 앱은 클라우드에 있어 둘이 떨어져 있다.

방식	TIC↔단말기	TIC↔Konnektor	판정
로컬 (사무실 LAN)	같은 망 → 추가 VPN 불필요	TIC가 아웃바운드 Wireguard 자동 수립 (RISE config) → 별도 공사 없음	권장 ✅
GCP	클라우드→사내 사설망 직접 불가 → site-to-site VPN 별도 구성 필요	같은 클라우드라 용이	RU 부적합 ❌

권장안: 단말기와 같은 사무실 LAN에 상시 켜둘 작은 박스 1대(미니 PC, 또는 이미 있는 NAS/서버 등 Docker 구동 가능 장비)에 TIC를 Docker 컨테이너로 가동한다. RISE는 TIC를 Docker 이미지 형태로 제공한다(Windows/Linux/Mac 지원).

왜 GCP가 RU에선 부적합인가

GCP 방식은 "과한" 게 아니라 추가 site-to-site VPN 공사를 얹어야 겨우 되는, 오히려 더 무거운 선택이다. 클라우드/서버급 사고는 PU(운영) 에서 제자리를 찾는다(아래 RU vs PU 참조).

설정 정보의 출처

Wireguard는 상호 인증이라 양쪽이 짝이 맞아야 터널이 선다. 정보는 두 갈래로 나뉜다.

정보	정하는 주체	비고
Wireguard 키 · VPN IP · 엔드포인트	RISE 발급	config 파일로 수령 → TIC에 그대로 적용
PVS 인증서 · Arbeitsumgebung ID(Mandant/ClientSystem/Workplace)	RISE 발급	SOAP 컨텍스트 헤더에 사용
카드 단말기(Cherry)의 사내 IP	우리가 설정	TIC가 단말기를 IP로 찾음 → 우리 숙제
TIC를 어느 머신에 띄울지	우리가 결정	RISE는 관심 없음(우리 LAN 내부)

RISE가 "터널 신원 한 벌(config)"을 발급해 보내면, 우리는 그것을 TIC에 넣고 + 사내망의 단말기 IP만 채운다. TIC가 그 config로 RISE에 붙으면 양쪽 짝이 맞아 터널이 성립한다.

사내 네트워크 사전 점검 항목

컨설팅 전, 사내 네트워크 담당자에게 가능 여부를 확인할 항목.

단말기 고정 IP — 현재 DHCP 자동 할당(매번 변경). TIC가 단말기를 IP로 찾으므로 고정 필요.
- 처리: 공유기/스위치에서 MAC 기반 DHCP 예약. (Cherry MAC 주소 확보 필요)
상시 가동 머신 — 단말기와 같은 LAN에 TIC용 상시 켜둘 작은 머신(미니 PC 또는 기존 NAS/서버) 설치 가능 여부.
아웃바운드 Wireguard(UDP) — 그 머신이 사무실에서 외부 RISE로 나가는 VPN을 방화벽이 막지 않는지.
단말기 TCP 포트 고정 — Konnektor가 단말기 호출 시 쓰는 포트(eHealth 카드단말기 표준, 보통 4742)는 변경 금지(단말기 설정에서 확인).
(차선책) 사무실 ↔ GCP site-to-site VPN — TIC를 GCP에 둬야 하는 시나리오 대비. 우선순위 낮음.

RU vs PU

	RU (테스트, Referenzumgebung)	PU (운영, Produktivumgebung)
TIC	우리가 사무실에 가동	가동 안 함
카드 단말기	우리 사무실(Cherry, 카드 직접 삽입/제거)	RISE 데이터센터에 신탁 호스팅
연결	TIC가 Wireguard로 RISE Konnektor에 접속	wide 서버 OS가 직접 Wireguard 터널

PU는 우리 쪽에 물리 단말기가 없으므로 locality 문제가 사라지고, wide 서버가 직접 Wireguard만 열면 된다.

미확정 / 후속

RISE 셋업 패키지(Wireguard Config · PVS 인증서 · Arbeitsumgebung.txt) 수령 — 수령 후 IP/포트/엔드포인트 확정.
RU config 1벌로 공유 TIC가 여러 클라이언트(개발자 코드) 를 받아줄 수 있는지(라이선스/세션 제약) RISE에 확인.
RISE Konnektor의 정확한 SOAP 서비스/WSDL·엔드포인트 — Arbeitsumgebung 패키지 또는 Konnektor 스펙(gemSpec_Kon)에서 확정.
export 트리거 시점·단계(데이터 수집 → MIO 생성 → 전송), local export vs ePA export 구분, 실패·재시도 처리 — 별도 정리 예정.

전체 전송 경로 (RU 기준)​

호출 관계​

망 경로​

두 방향의 데이터 흐름​

구성 요소 역할​

TIC 설치 위치 (RU)​

설정 정보의 출처​

사내 네트워크 사전 점검 항목​

RU vs PU​

미확정 / 후속​