간단히 말해: 병원에서는 수십 개의 시스템을 운영하며, 이러한 시스템들을 하나의 환자에 대해 일관되게 작동하도록 만드는 것이 통합 작업입니다. HIS(병원 정보 시스템) 또는 EHR이 환자의 신원, 입원 기록 및 임상 기록을 관리하며 중심에 있습니다. 주변에는 검사실(LIS), 영상의학과(RIS 및 PACS), 약제과, 수술실, 응급실, 청구, 의료기기(모니터, 수액 펌프) 등이 있으며, 점점 더 환자 앱, 웨어러블 기기 및 원격 진료 시스템이 추가되고 있습니다. 중간에 있는 인터페이스 엔진은 메시지를 수신, 변환 및 라우팅하여 각 시스템이 다른 모든 시스템과 개별적으로 연결되는 대신 한 번만 연결되도록 합니다. 주로 이벤트(입원, 처방, 결과)의 경우 MLLP를 통한 HL7 v2 메시지, 이미지의 경우 DICOM, 문서의 경우 CDA 또는 PDF, 그리고 새로운 시스템, 환자 대면 또는 외부 시스템의 경우 REST를 통한 FHIR이 사용됩니다.
시스템 및 교환 내용
병원 통합 환경은 환자 정보, 진료 기록, 임상 기록을 보유한 HIS 또는 EHR과 함께 검사실 시스템, 영상의학과(RIS 및 PACS), 약제과, 기기, 환자 앱, 원격 진료 및 지역 시스템으로 구성됩니다. 이들은 ADT, 주문 및 ORU 결과와 같은 HL7 v2 메시지, DICOM 이미지, CDA 문서 및 FHIR 리소스를 교환합니다.
| 시스템 | 소유 | 전송 | 수신 |
|---|---|---|---|
| HIS / EHR | 환자 신원, 진료 기록, 처방, 임상 기록 | ADT (입원, 전원), ORM/OML 처방, SIU 일정 | ORU 결과, MDM 문서, DFT 청구 |
| LIS (검사실) | 검체, 분석, 결과, 정상 범위 | ORU^R01 결과, ORR 처방 응답 | ORM/OML 처방, ADT (인구 통계 정보) |
| RIS / PACS | 영상 처방, 작업 목록, 보고서, 이미지 | ORU 보고서, DICOM (뷰어용), SIU | ORM/OMI 처방, ADT; DICOM MWL (장비용) |
| 약제과 | 약품 목록, 조제, 재고 | RDS 조제, RAS 투여 | OMP/RDE 약품 처방, ADT |
| 의료기기 및 모니터 | 활력 징후, 파형, 경고 | ORU^R01 관찰 결과 (IHE PCD), 독점 형식 | ADT (환자 컨텍스트) |
| 환자 포털 / 앱 | 환자 입력 데이터, 접근 | FHIR 관찰 결과, 설문지, 메시지 | FHIR (결과, 예약, 문서 읽기) |
| 원격 진료 | 영상 통화, 원격 모니터링 | FHIR Encounter, Observation, DocumentReference | 예약, 환자 컨텍스트, SMART 실행 |
| 지역 및 국가 시스템 | 공유 기록, 등록부, 전자 처방 | CDA 문서 (XDS), FHIR, 국가 메시지 | 조회, 알림 |
인터페이스 엔진
인터페이스 엔진은 병원의 메시징 허브 역할을 합니다. 각 시스템에서 HL7 v2, FHIR, 파일 및 데이터베이스 트래픽을 수신하고, 이를 필요로 하는 다른 모든 시스템으로 변환 및 라우팅하며, 큐, 재시도, 모니터링 및 감사를 관리합니다. 인터페이스 엔진이 없으면 N개의 시스템은 최대 N×(N−1)/2개의 수제 인터페이스가 필요하지만, 엔진이 있으면 각 시스템은 한 번만 연결하면 됩니다.
엔진(Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare 및 IRIS for Health, Infor Cloverleaf, Qvera QIE 등)은 리스너(MLLP, HTTP, 파일, 데이터베이스), 변환(필드 매핑, 코드 수정, v2를 FHIR로 변환), 라우팅(ADT를 8개의 필터로 8개 시스템에 전송), 큐 및 재시도, 모니터링 및 감사 기능을 제공합니다. 또한 시스템 간에 환자 정보가 일치하지 않을 때 환자 정보를 조정하고, 레거시 데이터베이스 위에 FHIR 프록시를 구축하는 곳이기도 합니다. 인터페이스 엔진 설명을 참조하세요.
가장 중요한 흐름
가장 중요한 병원 통합 흐름은 HIS에서 발생하는 ADT(입원, 퇴원, 전원 및 인구 통계 업데이트), EHR과 검사실 또는 영상의학과 간의 주문 및 결과, 약품 주문 및 조제, 퇴원 서신과 같은 문서, 모니터에서 오는 기기 데이터, 그리고 FHIR을 통한 환자 결과, 예약 및 가정 측정값 교환입니다.
- ADT: 모든 입원, 퇴원, 전원, 등록 및 인구 통계 업데이트(A01, A03, A02, A04, A08, A40 병합)는 HIS에서 다른 모든 시스템으로 전파됩니다. ADT가 늦거나 잘못되면 모든 하위 시스템은 잘못된 환자 또는 진료 기록에 데이터를 저장합니다. HL7 v2 메시지 설명 참조.
- 처방 및 결과: ORM/OML 발신, ORU 수신, 플레이서 및 필러 번호로 연결; 결과에 LOINC 및 UCUM 포함. HL7 v2 처방 메시지 및 검사실 시스템과 EHR 통합 참조.
- 영상: RIS로의 처방, 스캐너로의 DICOM 작업 목록, PACS로의 이미지, ORU로의 보고서 반환, DICOMweb을 통한 뷰어. PACS 대 RIS 대 VNA 참조.
- 약품: 약제과로의 처방, 조제 및 투여 반환, 안전을 위한 폐쇄 루프(침상 바코드) 목표.
- 문서: 퇴원 서신, 수술 기록 및 스캔된 문서가 MDM 메시지, CDA 또는 PDF로 문서 저장소에 저장되고 지역 등록부에 게시됩니다.
- 의료기기: IHE PCD 프로파일 또는 공급업체 게이트웨이를 통해 기록으로 활력 징후를 보내는 모니터, 경고 관리는 별도의 분야입니다.
- 환자 대면: FHIR을 통해 포털 및 앱으로 결과, 예약 및 문서 전송; 설문지, 가정 측정 및 웨어러블 데이터 수신, 출처를 환자 보고로 표시. FHIR을 이용한 원격 환자 모니터링 참조.
효과적인 패턴
효과적인 병원 통합 패턴은 다음과 같습니다. 환자 정보에 대한 마스터 시스템 하나를 두고 모든 다른 시스템이 ADT를 구독하도록 합니다. 엔진에서 LOINC, SNOMED CT 및 ATC 코드를 한 번만 매핑합니다. 모든 메시지에 대한 승인, 큐 및 재시도를 설정합니다. 결과 및 문서는 멱등성을 갖도록 합니다. 환자 앱 및 외부 파트너를 위한 FHIR 계층을 구축합니다. 그리고 실제 적용 전에 가상 환자를 이용한 테스트 환경을 마련합니다.
- 신원 정보의 단일 마스터. HIS(또는 마스터 환자 색인)가 식별자를 소유하며, 다른 모든 시스템은 ADT를 구독하고 환자를 새로 생성하지 않습니다.
- 경계에서의 코드 매핑. 엔진에서 로컬 코드를 LOINC, SNOMED CT, ATC로 한 번 매핑하고 로컬 코드를 함께 유지합니다.
- 승인, 큐잉, 재시도. 모든 v2 메시지는 ACK를 받습니다. 엔진은 데이터를 저장하고 다시 시도하며, 시스템 재부팅으로 인해 결과가 손실되지 않습니다.
- 멱등성. 결과 및 문서는 식별자를 포함하며, 재시도는 중복이 아닌 업데이트를 수행합니다.
- 새로운 모든 것에 대한 FHIR 계층. 환자 앱, 원격 진료, 연구 추출 및 외부 파트너는 HIS에 직접 연결하는 대신 FHIR 인터페이스 또는 내부 흐름에서 공급되는 전용 FHIR 서버와 FHIR로 통신합니다.
- 가상 환자를 이용한 테스트 환경 및 프로덕션에 적용하기 전의 적합성 단계(IHE Connectathon 프로파일, 국가 테스트 스위트).
흔히 발생하는 오류
거의 모든 병원 통합에서 발생하는 실패 모드는 등록 오류로 인한 중복 환자, 병합 후 잘못된 진료 기록에 결과가 기록되는 경우, 매핑되지 않은 로컬 코드, 타임스탬프의 시간대 및 일광 절약 시간 오류, 텍스트 단위, 모니터링 없이 조용히 중단되는 인터페이스, 파서를 손상시키는 공급업체 Z-세그먼트, 그리고 영원히 폐기되지 않는 임시 CSV 피드입니다.
등록 오타로 인한 환자 중복; 병합 후 잘못된 진료 기록에 저장된 결과; 매핑되지 않은 로컬 테스트 코드; 메시지 타임스탬프의 시간대 및 일광 절약 시간; 자유 텍스트 단위; 조용히 중단되고 아무도 모니터링하지 않은 인터페이스; 파서를 손상시키는 공급업체별 Z-세그먼트; 그리고 10년 후에도 여전히 실행 중인 "임시" CSV 피드.
FHIR이 변화를 가져오는 부분
FHIR은 핵심보다는 병원 통합의 가장자리에서 변화를 가져오고 있습니다. 건물 내부에서는 분석기, 스캐너 및 레거시 모듈이 HL7 v2 및 DICOM을 사용하기 때문에 그대로 유지됩니다. FHIR은 환자 접근, SMART on FHIR 앱, CDS Hooks 의사 결정 지원, 구독, EHDS 및 TEFCA 하의 지역 및 국가 교환, 연구 추출을 담당합니다.
내부적으로 HL7 v2와 DICOM은 모든 분석기, 스캐너 및 레거시 모듈이 이를 사용하기 때문에 수년간 유지될 것입니다. FHIR은 가장자리에서 승리합니다: 환자 접근, EHR 내에서 실행되는 앱(SMART on FHIR), 의사 결정 지원(CDS Hooks), 이벤트 기반 통합을 위한 구독, EHDS 및 TEFCA 하의 지역 및 국가 교환, 연구 추출. 많은 병원에서 이제 건물 외부의 모든 통합을 위한 통합 계층으로 엔진에서 공급되는 FHIR 서버를 운영하고 있습니다. 의료 상호 운용성 표준: 지도 참조.
Anpheros에서
Anpheros Platform은 병원 통합의 FHIR 가장자리에 위치합니다. 병원이나 클리닉이 환자의 동의 하에 쓰고 읽을 수 있는 FHIR R4 레코드이며, 실험실 커넥터(HL7 v2 ORU, CSV 또는 JSON)를 통해 병원 자체 통합에서 공급받고, 웹훅 및 출처별 출처 정보를 제공합니다. HIS나 엔진을 대체하지는 않습니다.
Anpheros Platform은 이러한 가장자리에 위치합니다. 병원이나 클리닉이 환자의 동의 하에 쓰고 읽을 수 있는 FHIR R4 레코드이며, 병원의 자체 통합( 검사실 커넥터는 HL7 v2 ORU, CSV 또는 JSON을 사용)에서 공급되며, 변경 알림을 위한 웹훅과 출처별 출처 정보가 제공됩니다. HIS나 엔진을 대체하는 것이 아니라, 환자가 건물 밖으로 가지고 나갈 수 있는 기록을 제공합니다.
관련 페이지
- 인터페이스 엔진 설명
- 검사실 시스템과 EHR 통합 방법
- HL7 v2 메시지 설명: ADT 및 ORU
- PACS 대 RIS 대 VNA
- FHIR을 이용한 원격 환자 모니터링
- 의료 상호 운용성 표준: 지도
- FHIR을 이용한 클리닉 시스템 통합 (개발자 사이트)
출처
- HL7 Version 2 제품군
- IHE IT Infrastructure 기술 프레임워크
- IHE Devices 도메인 (Patient Care Device 프로파일)
- HL7 FHIR R4: 메시징 및 워크플로
- HL7 v2-to-FHIR 구현 가이드
자주 묻는 질문
새로운 병원은 모든 것을 FHIR로 통합해야 하나요?
모든 것을 통합할 필요는 없습니다. 분석기, 스캐너 및 대부분의 부서 시스템은 HL7 v2와 DICOM을 사용하며, 이는 곧 바뀌지 않을 것입니다. 환자 대면, 외부 및 새로운 통합에는 FHIR을 사용하고, 엔진을 사용하여 연결하세요.
HIS와 EHR의 차이점은 무엇인가요?
국가별로 사용법이 다릅니다. HIS는 종종 행정 및 임상 병원 시스템을 함께 의미하며, EHR은 임상 기록을 강조합니다. 통합 관점에서 둘 다 신원, 진료 기록 및 기록을 소유하는 시스템입니다.
중간 규모 병원에는 인터페이스가 몇 개나 있나요?
일반적으로 엔진을 통해 전달되는 메시지 흐름은 방향과 수신 시스템을 각각 계산하여 50개에서 수백 개에 이릅니다. 엔진의 모니터 화면은 통합 팀이 주로 사용하는 곳입니다.
병원에서 통합은 누가 담당하나요?
병원의 IT 통합 팀이 일반적으로 엔진 공급업체의 지원을 받으며, 각 부서 공급업체가 해당 부분을 담당합니다. 국가 프로그램과 IHE 프로파일은 프로젝트 작업을 줄여주지만 완전히 제거하지는 않습니다.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →