간단히 말해, 인터페이스 엔진(통합 엔진)은 의료 메시징을 위해 구축된 미들웨어입니다. 이 엔진은 여러 프로토콜(HL7 v2용 MLLP, FHIR 및 SOAP용 HTTP, 파일, 데이터베이스, 큐)을 수신하고, 메시지를 변환(필드 매핑, 코드 변환, HL7 v2에서 FHIR로의 형식 변환 등)하며, 필터를 사용하여 하나 이상의 대상지로 라우팅합니다. 또한 큐, 재시도, 로그 및 대시보드를 유지하여 메시지가 손실되지 않고 모든 실패가 가시화되도록 합니다. 병원에서는 각 시스템이 다른 모든 시스템과 직접 연결되는 대신 엔진에 한 번만 연결되도록 하기 위해 이를 사용합니다. 잘 알려진 제품으로는 Mirth Connect(NextGen Connect, 역사적으로 오픈 소스), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion 등이 있으며, 그 외에도 많은 제품이 있습니다. 클라우드 제공업체는 관리형 서비스를 제공합니다.
구성 요소
인터페이스 엔진의 구성 요소는 채널(소스에서 대상까지의 흐름), MLLP 및 HTTP와 같은 소스 커넥터 또는 리스너, 메시지가 계속 진행될지 여부를 결정하는 필터, 필드 및 코드를 매핑하는 트랜스포머, 대상 커넥터, 재시도 기능이 있는 큐, 알림 기능이 있는 모니터링, 채널 변경 및 메시지 기록에 대한 감사 추적입니다.
어떤 용어를 사용하든 모든 엔진은 동일한 구성 요소를 가집니다.
- 채널(인터페이스): 소스에서 하나 이상의 대상으로 가는 하나의 흐름으로, 자체 설정 및 통계가 있습니다.
- 소스 커넥터/리스너: MLLP(HL7 v2용 프레이밍이 있는 TCP), HTTP(S) 엔드포인트, SFTP 및 파일 폴링, 데이터베이스 쿼리, JMS 또는 기타 큐, 일부 제품의 DICOM.
- 필터: 메시지가 계속 진행될지 여부를 결정하는 규칙(이 환자 클래스에 대한 ADT^A01만 해당).
- 변환기: 메시지를 변경하는 스크립트 또는 매핑: 필드 이름 변경, 조회 테이블을 통해 로컬 코드를 LOINC로 매핑, OBX 세그먼트에서 FHIR Observation 빌드, 레거시 시스템이 예상하는 Z-세그먼트 추가.
- 대상 커넥터: 결과가 가는 곳으로, 자체 프로토콜 및 오류 처리가 있습니다.
- 큐 및 재시도: 메시지는 승인될 때까지 유지됩니다. 실패 시 백오프 방식으로 재시도됩니다. 잘못된 메시지는 사람을 위해 오류 큐로 이동합니다.
- 모니터링 및 경고: 채널별 카운터, 지연 시간, 오류율, 채널이 조용해질 때 경고(의료 통합에서 가장 유용한 경고).
- 감사: 누가 어떤 채널을 변경했는지, 문제 해결을 위한 메시지 기록, 보존 및 액세스 제어(환자 데이터이므로).
일반적인 작업
의료 인터페이스 엔진의 일반적인 작업은 HIS에서 부서로의 ADT 팬아웃, 여러 수신기로의 검사 결과 라우팅, 로컬 코드를 LOINC, ATC 및 UCUM으로 변환, HL7 v2, FHIR, CDA 및 CSV 형식 연결, 레거시 데이터베이스에 대한 FHIR 페이드를 노출, 장치 피드 정규화, 내부 MLLP를 외부 HTTPS로 조정하는 것입니다.
- ADT 팬아웃: HIS에서 입원 정보를 수신하고, 부서별로 필터링 및 변환하여 검사실, 영상의학과, 약국, 병상 관리 및 환자 포털로 전달합니다.
- 결과 라우팅: LIS에서 EHR, 처방한 GP 시스템, 지역 기록, 환자의 FHIR 기록으로 ORU를 전달하며, 각기 다른 하위 집합과 형식을 사용합니다.
- 코드 변환: 로컬 테스트 코드를 LOINC로, 로컬 약물 코드를 ATC로, 자유 텍스트 단위를 UCUM으로 변환하며, 유지 관리되는 조회 테이블을 통해(lab codes to LOINC 매핑).
- 형식 브리징: HL7 v2를 FHIR로, FHIR를 HL7 v2로, CDA를 FHIR로, 오래된 시스템의 CSV를 어떤 형식으로든 변환합니다.
- FHIR 파사드: 엔진이 FHIR 엔드포인트를 노출하고 레거시 데이터베이스를 쿼리하거나 v2 쿼리를 보내 응답하여, 실제로는 존재하지 않는 곳에 앱이 FHIR 서버를 볼 수 있도록 합니다.
- 장치 통합: 독점 모니터 피드를 IHE PCD 관찰로 정규화합니다.
- 프로토콜 적응: 건물 내에서는 MLLP, 외부에서는 OAuth를 사용한 HTTPS를 사용합니다.
선택하기
인터페이스 엔진 선택은 메시지 볼륨과 지연 및 중단이 얼마나 중요한지, 즉시 지원되는 프로토콜 및 표준(HL7 v2, FHIR R4, DICOM, 국가별 형식), 개발자 경험, 클러스터링 및 장애 조치와 같은 운영, 라이선스 조건(일부 제품의 경우 2025년에 변경됨), 채널을 유지 관리하는 데 사용할 수 있는 기술 등 6가지 기준에 따라 달라집니다.
- 볼륨 및 중요도: 하루 메시지 수, 허용 가능한 지연 시간, 2분간의 중단이 중요한지 여부(ADT 및 결과의 경우 중요합니다).
- 기본 제공 프로토콜 및 표준: HL7 v2 버전 및 파서, 유효성 검사가 포함된 FHIR R4 지원, DICOM, 미국에서는 X12, 국가별 형식.
- 개발자 경험: 스크립팅 언어(Mirth의 JavaScript, 다른 제품의 독점 언어), 채널 정의의 버전 관리, 테스트 도구, 여러 환경으로의 배포.
- 운영: 클러스터링, 장애 조치, 모니터링 통합, 업그레이드 경로, 지원 모델.
- 라이선싱: 오픈 소스 또는 커뮤니티 에디션, 채널 또는 코어당 구독, 관리형 클라우드 오퍼링; 일부 역사적으로 오픈 소스 제품의 라이선싱은 2025년에 변경되었으므로 현재 약관을 확인하십시오.
- 사용 가능한 기술: 엔진은 채널을 유지 관리하는 사람만큼만 좋습니다.
안전하게 실행하기
인터페이스 엔진을 안전하게 실행하려면 채널 정의를 버전 관리 시스템의 코드로 취급하고, 프로덕션 전에 합성 메시지로 테스트하고, 명명된 소유자로 코드 조회 테이블을 관리하고, 채널이 침묵할 때 알림을 보내고, 환자 데이터이므로 메시지 기록을 제한 및 삭제하고, 모든 채널의 목적을 문서화하고, 엔진이 기록 시스템이 되지 않도록 해야 합니다.
채널 정의를 코드로 취급하십시오: 버전 관리, 검토, 테스트 및 스테이징 환경으로의 배포(합성 메시지 사용). 조회 테이블(코드 맵)은 소유자와 함께 거버넌스 하에 유지하십시오. 오류뿐만 아니라 침묵에 대한 경고를 설정하십시오. 메시지 기록에 대한 액세스를 제한하십시오(환자 데이터이므로 보호 및 삭제해야 함). 각 채널의 목적과 소유자를 문서화하십시오. 문서화되지 않은 채널은 작성자가 떠날 때 부서가 중단되는 채널입니다. 그리고 엔진이 기록 시스템이 되도록 결코 허용하지 마십시오. 데이터의 이동 및 변환을 담당하며, 데이터를 소유하지는 않습니다.
필요하지 않은 경우
녹색 시스템의 모든 파트너가 FHIR를 사용하는 경우 인터페이스 엔진이 필요하지 않습니다. 이 경우 구독 및 API 게이트웨이가 있는 FHIR 서버가 라우팅 및 인증을 처리하거나, 단일 HL7 v2 인터페이스가 HAPI HL7v2 또는 hl7apy와 같은 라이브러리로 처리될 수 있는 경우에도 마찬가지입니다. 엔진은 여러 시스템 및 형식에서 그 가치를 증명합니다.
파트너가 모두 FHIR를 사용하는 그린필드 시스템은 구독 및 API 게이트웨이를 사용하여 인증, 속도 제한 및 라우팅을 처리하고 일반 서비스에서 변환을 수행하는 FHIR 서버를 사용할 수 있습니다. 단일 HL7 v2 인터페이스는 애플리케이션 내의 작은 라이브러리(Java의 HAPI HL7v2, Python의 hl7apy 또는 python-hl7)로 처리할 수 있습니다. 엔진은 여러 시스템, 여러 형식 및 비개발자가 모니터링할 수 있는 운영 콘솔이 필요할 때 그 가치를 발휘합니다.
Anpheros에서
Anpheros Platform은 엔진의 FHIR 측에 있습니다. 병원은 공유하려는 흐름(결과, 문서, 진료 기록)을 엔진 또는 lab connector를 통해 Anpheros로 라우팅하고, FHIR API 및 웹훅을 통해 다시 읽어옵니다. 개발자 사이트에는 커넥터가 적용하는 HL7 v2 to FHIR 매핑이 나와 있습니다.
관련 페이지
- 병원 시스템 통합 설명
- 검사실 시스템을 EHR과 통합하는 방법
- HL7 v2 메시지 설명: ADT 및 ORU
- 로컬 검사 코드를 LOINC로 매핑하는 방법
- FHIR 구독 설명
- HL7 v2에서 FHIR로의 매핑(개발자 사이트)
출처
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2 라이브러리
- HL7 v2-to-FHIR 구현 가이드
자주 묻는 질문
인터페이스 엔진은 ESB 또는 iPaaS와 같은 것인가요?
같은 계열이지만 특화되어 있습니다. 인터페이스 엔진은 HL7 v2, DICOM, CDA 및 FHIR 지원, MLLP, 의료 관련 모니터링 및 팀이 사용하는 어휘 통합 기능을 기본적으로 제공합니다. 일반 ESB 및 iPaaS 제품은 더 많은 구축을 통해 이 작업을 수행할 수 있습니다.
엔진이 HL7 v2를 FHIR로 자동 변환할 수 있나요?
여러 엔진에는 HL7 v2-to-FHIR 가이드 기반의 매핑이 포함되어 있으며 일반적인 세그먼트를 처리합니다. 로컬 규칙, Z-세그먼트 및 코드 매핑은 항상 프로젝트 작업이 필요합니다.
엔진이 환자 데이터를 저장하나요?
전송 중인 메시지를 유지하고 문제 해결을 위한 메시지 기록을 유지합니다. 이는 환자 데이터이므로 보호 및 삭제해야 합니다. 장기 저장소 또는 기록 시스템으로 사용해서는 안 됩니다.
오픈 소스 또는 상용?
대형 병원에서 모두 사용 중입니다. 결정은 일반적으로 지원, 기술, 클러스터링 요구 사항 및 현재 라이선스 조건에 따라 달라집니다. 일부 제품의 경우 라이선스가 변경되었으므로 계약 전에 확인하십시오.
샌드박스에서 무료로 사용해 보세요
5분 만에 첫 FHIR 호출. 환자의 동의가 내장된 HL7 FHIR R4 API: 샌드박스에서 먼저 사용해보고, 자체 앱 또는 병원 시스템을 연결하세요.
무료 · 합성 환자 30명 · 카드 불필요
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →