본문으로 건너뛰기
피드

심평원, DUR부터 의료영상 심사까지 클라우드로 갈아엎는다

backend 약 4분
vote
0
댓글
북마크

심평원이 정보시스템 클라우드 전환과 함께 병·의원 업무에 직접 닿는 DUR, 의료영상 AI 심사, 요양급여내역 조회 시스템을 고도화한다. 핵심은 설치형 프로그램 중심이던 연계를 웹과 API 기반으로 넓히고, 진료·청구 과정에서 실시간 확인과 자동 판독을 강화하는 쪽이다.

  • 1

    DUR 시스템을 클라우드 기반으로 개편해 접속 집중과 처리량 증가에 따른 장애 위험을 낮추려 함

  • 2

    설치형 프로그램 중심 정보 제공을 웹 기반 API와 JSON 송수신 방식으로 확대

  • 3

    척추질환 AI 의료영상 심사판독 시스템의 제외 영상 분류와 좌표 탐지 방식을 고도화

  • 4

    물리치료, CT, 트라마돌주, 신경차단술 등 환자별 요양급여내역 조회 범위를 확대

  • 심평원이 정보시스템을 클라우드로 옮기면서, 병·의원과 약국이 매일 쓰는 업무 시스템까지 같이 손보는 중임

    • 단순히 서버 위치만 바꾸는 게 아니라 DUR, 의료영상 심사판독, 요양급여내역 확인 같은 현장 업무가 대상임
    • 요양기관 입장에서는 진료, 처방, 청구 과정에서 심평원 시스템과 붙는 방식이 바뀔 가능성이 큼
  • 제일 큰 변화는 의약품안전사용서비스(DUR) 전면 개편임

    • 기존 노후 인프라를 클라우드로 전환해서 접속 집중이나 처리량 증가 때 생기는 장애 위험을 줄이겠다는 방향임
    • 지금까지 설치형(C/S) 프로그램 중심으로 제공하던 정보를 웹(WEB) 환경으로 확대함
    • 웹 기반 API 점검 서비스를 만들고, 데이터 송수신은 JSON 형식으로 도입할 계획임

중요

> 병원과 약국은 별도 프로그램 설치 없이 웹 브라우저에서 표준화된 팝업창으로 DUR 점검 결과를 바로 확인하는 쪽으로 바뀔 수 있음.

  • 척추질환 AI 의료영상 심사판독 시스템도 고도화됨

    • 기존에는 전문가 판독 프로세스와 AI 판독값의 모호성 때문에 심사 활용에 한계가 있었다고 함
    • 굴곡·신전 영상처럼 심사에서 제외해야 할 영상을 선별하는 분류 모델을 개선함
    • 척추체 탐지 방식도 간소화해서 판독에 필요한 필수 좌표만 빠르고 정확하게 짚도록 바꾸는 게 목표임
  • 환자별 요양급여내역 확인 시스템도 범위가 넓어짐

    • 기존 한방 추나요법, 첩약 중심에서 물리치료, 컴퓨터단층촬영(CT), 트라마돌주 투여, 신경차단술까지 확대됨
    • 병원은 진료 당일이나 연간 기준으로 해당 환자가 다른 요양기관에서 받은 진료 횟수를 합산 조회할 수 있음
    • 중복 진료를 줄이고 환자 안전을 높이겠다는 명분인데, 실제로는 실시간 연계 API 품질이 관건일 듯함

기술 맥락

  • 이번 전환의 핵심은 클라우드 자체보다 “요양기관과 심평원 사이의 연결 방식”이에요. 설치형 프로그램 중심이면 배포와 업데이트가 느려지고, 기관마다 환경 차이가 커지거든요.

  • 웹 기반 API와 JSON 송수신을 도입하면 병원·약국 시스템이 심평원 기능을 더 표준적인 방식으로 붙일 수 있어요. 특히 DUR처럼 진료 흐름 중간에 바로 응답이 필요한 서비스는 장애 대응과 처리량 관리가 중요해요.

  • 의료영상 AI 쪽은 판독 정확도만의 문제가 아니에요. 심사에 안 맞는 영상을 먼저 걸러내고, 필요한 좌표만 안정적으로 뽑아야 실제 심사 업무에 넣을 수 있거든요.

  • 요양급여내역 조회 확대는 환자 단위 데이터를 여러 기관 기준으로 묶어 보는 흐름이에요. 그래서 병원 업무 시스템 입장에서는 단순 조회 화면보다 연계 API, 응답 속도, 데이터 정합성이 더 중요해져요.

공공 의료 시스템의 클라우드 전환은 단순 인프라 교체보다 연계 방식 변화가 더 큼. 병원 EMR, 약국 시스템, 청구 업무가 웹 API 중심으로 움직이면 현장 개발사와 병원 IT팀의 작업 방식도 같이 바뀔 수밖에 없음.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.