스마트 의료용 베드의 통합 관리를 위한 인터페이스 시스템 설계 및 구현

2.1 스마트 의료용 베드

의료용 베드란 환자 및 의료기기가 필요한 사람들을 위해 설계된 베드를 의미한다. 병원에 의료용 베드가 도입된 정확한 시기를 찾기는 어려우나, 과거에는 들것이 의료용 베드의 역할을 대처하던 시기부터 베드를 전동으로 제어할 수 있는 의료용 전동 베드까지 현재 기술의 발전과 함께 기존의 의료용 베드의 문제점을 개선해가며 발전되기 시작하였다. 발전이 진행되고 있는 상황에서 최근 일반적으로 스마트베드라고 불리는 스마트 의료용 베드가 등장하였다[5].

스마트베드는 기존의 의료용 베드에서 개발되었던 욕창 방지, 높이 조절과 같은 다양한 기능에 디지털 혁신이 적용된 것을 의미한다. 이러한 스마트베드는 베드에서 탈부착이 가능한 생체 센서를 통해 데이터를 축적한 빅데이터를 통해 환자의 건강 상태를 예측할 수 있으며, 생체 신호를 실시간으로 간병인, 의료 관계자, 보호자에게 전송하여 환자의 건강 상태를 확인할 수 있다.

또한 원격으로 베드의 조명 및 매트리스의 각도까지 수정하는 것이 가능하다[6]. 하지만 데이터 전송과정에서 민감한 환자 정보의 유출과 같은 보안 문제, 환자의 편성 및 사용성 문제, 제조사들 마다 서로 다른 프로토콜 및 인터페이스로 인한 표준화 문제가 존재한다. 각각의 문제를 해결하기 위해 다양한 연구가 진행 중이다[7,8]. 하지만 스마트베드 자체의 시스템 구조에 초점을 맞출 뿐, 의료정보 시스템과의 통합에 대한 포괄적인 시스템의 구조 연구는 아직 미비하다.

2.2 HL7 FHIR

의료정보는 진료정보와 의료기관, 제약회사 및 유관기관 등 다양한 경로에서 수집한 정보를 분석/정제한 데이터를 뜻한다. 이러한 의료정보는 빅데이터, 인공지능 기술과 접목하여 의료 데이터를 분석하여 환자 및 의료 관계자에게 좋은 방향의 서비스를 제공하기 위해 필수적이다[9]. 이러한 의료정보는 HIS에 EMR의 형태로 기록된다. EMR은 의료기록을 기존 종이에 기록하던 것을 컴퓨터를 이용해 전자적 형태로 기록 한 것을 뜻한다.

국제적으로 ISO(International Standard Organization), CEN(European Committee for Standardization), IEEE, HL7과 같은 다양한 기구에서 의료 데이터의 표준을 개발하고 있으며 대표적인 것이 HL7이다. V2 Message를 시작으로 V3(Version 3) RIM(Reference Information Model), CDA(Clinical Document Architecture), FHIR(Fast Healthcare Interoperability Resource)가 존재한다. V2 Message는 1990년대 초반에 개발된 표준으로 폭넓은 상호운용성을 보장하는 정보전달을 하기에는 부족하였다. V3 RIM은 SOA(Service Oriented Architecture)에 기반해 폭넓은 상호운용성을 보장하나, 의료 전문지식이 없는 개발자가 이해하기에는 너무 어려워 시장에서 성공적이지 못했다. 반면 CDA는 이러한 문제를 해결하기 위해 가이드를 배포하여 시장에 성공적으로 안착하였고 마지막 버전인 FHIR가 한국, 미국 등의 국가에서 의료정보 표준으로 지정되었다[10].

FHIR가 표준으로 지정된 이유는 다음과 같다. 모듈식 구조를 가지고 있는 리소스라는 단위를 사용하고, 보안과 개인정보 보호를 고려하여 설계되었으며, 오픈소스이다. 또한 HTTP통신에 근간을 두고 있는 RESTful 서비스를 지향하고 있으며, JSON 또는 XML과 같은 일반적인 형식으로 표현이 가능하다. 이전 버전들과 호환이 된다는 점도 존재한다. 현재 국내에서는 HL7 FHIR를 한국의 특성에 맞추어 한국보건의료정보원과 HL7 Korea함께 KR Core라는 한국형 상호운용성 기술 표준을 개발하였다.

3.1 통합 인터페이스 시스템 개요

본 논문에서 제안하는 통합 인터페이스 시스템은 스마트 의료용 베드의 통합 관리를 위한 것으로 IoT, 인공지능, 전자 제어 등의 기술이 결합된 스마트베드의 모니터링, 조작, 데이터 수집 및 분석, 통신 등을 효율적으로 관리하기 위해 통합관리 서버와 스마트베드를 연결하는 게이트웨이를 중심으로 설계되었다. 본 논문을 통해 해결하고자 하는 문제는 다음과 같다

시스템의 복잡성, 네트워크의 부하, 서로 다른 데이터 규격 문제 해결

병원 정보 시스템과의 표준 기반 연동(HL7, HL7 FHIR)

환자, 보호자, 의료 관계자에게 안전한 원격 접근 및 제어 기능 제공

서로 다른 제조사의 스마트베드 연결을 위한 공통 메시지 규격 설계

이러한 요구 사항 해결을 위한 제안 시스템의 기본 개념은 그림 1과 같다. 시스템은 크게 통합 인터페이스 서버, 스마트베드 게이트웨이, HIS 인터페이스 모듈, Service로 구성된다.

Fig. 1.

SmartBed integrated management system architecture

HIS 인터페이스 모듈은 어댑터 패턴 구조의 인터페이스로 설계하여, 각각의 다른 데이터 규격을 가진 HIS에서 서버에서 전송한 HL7/FHIR Resource를 수용할 수 있도록 하였다.

스마트베드와 게이트웨이의 연동은 RestAPI를 방식을 통해 스마트베드에서 생성한 여러 데이터와 서버에서의 요청을 수신받을 수 있도록 하였다. 서비스는 환자, 보호자, 의료관계자들이 시스템의 현 상황을 파악하고, 시스템의 기능에 접근 할 수 있도록 대시보드와 어플리케이션을 제공한다.

3.2 통합 인터페이스 서버

서버는 서비스 이용자의 자격에 따라 접근 권한을 통제할 수 있어야 하며, 요구사항에 대한 기능을 수행할 수 있어야 한다. 그림 2는 통합관리 시스템의 서버의 구성도를 나타낸 그림이다. 서버는 크게 두가지 영역으로 구분할 수 있다. 첫째로 HIS와의 연동을 위한 HL7/FHIR Resource로 변환 및 FHIR 검증하는 영역, 둘째로 스마트베드 및 게이트웨이 의 일반적인 정보와 생체 정보를 포함한 환자의 정보를 처리하는 영역으로 구분할 수 있다. HL7/FHIR 컨버터 모듈에서 Resource에 포함되는 값인 value, time, patientName과 같은 값들은 서버와 연결된 데이터베이스로부터 정보를 가져온다. 이후 생성한 리소스를 HL7/FHIR Validator를 통해 검증을 거치게되며, 검증에 통과한 리소스들은 정상적으로 HIS로 전송되게 된다.

Fig. 2.

Server architecture structure

그림 3은 서비스에서 서버로 기능을 수행하기 위한 프로세스를 보여준다. 대시보드, 애플리케이션에서 스마트베드 제어, 데이터 요청이 들어온다. 이러한 기능적인 요청은 서버의 API Module을 통해 수신받게 되고, 요청이 들어온 스마트베드가 실제 존재하는지, 서비스 사용자가 권한이 존재하는지 검증 과정을 진행한다. 검증이 완료되면, 해당 모듈에 따라 정상적으로 기능을 수행하게 된다.

Fig. 3.

Sequence diagram

각각의 모듈은 모두 스마트베드를 중심으로 움직이며, 기능을 수행하기 위해 데이터베이스에 접근하거나, API Module을 거쳐 게이트웨이를 통해 스마트베드에 접근하게 된다.

3.3 HIS 인터페이스 모듈

HIS 인터페이스 모듈은 병원 환경에 따라 확장 가능해야 하므로 규격화 하기 어려운 부분이 많다. 본 논문에서는 이를 수용하기 위해 GoF(Gangs of Four) 디자인 패턴중 어댑터 패턴 구조를 적용한다. 기본 인터페이스 규격은 ICommonHIS인터페이스로 정의하고 스마트베드의 Device Data와 환자의 Vital Data를 병원마다 다른 HIS시스템과 연동할 수 있도록 어댑터를 제공하는 방식이다. 그림 4는 HIS 인터페이스 모듈과 이와 관련있는 모듈에 대한 구조를 보여준다. 병원 환경마다 다양한 데이터 규격을 고려하여 효율적인 정보 교환이 가능하도록, 통합관리시스템에서 제공하는 인터페이스를 구현하여 각 병원 환경 규격에 맞추어 연결하여 기기 정보와 생체 정보를 제공할 수 있도록 하였다.

Fig. 4.

HIS iInterface architecture

HIS에서 통합관리시스템으로 데이터는 요청하는 과정은 그림 5의 시퀀스 다이어그램과 같다. HIS는 필요한 데이터를 요청하면 HIS에서 상속받아 구현한 인터페이스 Adapter에서 HIS의 데이터 규격을 HL7/FHIR Resource로 변환한다. 이러한 데이터는 서버로 전송되어 HL7/FHIR Resource로 요청 데이터를 반환한다. 이후 위의 과정과 같이 어댑터에서 HIS 규격으로 변환 후 요청이 완료된다.

Fig. 5.

HIS sequence diagram

3.4 게이트웨이 모듈 및 API 설계

게이트웨이 모듈은 병원내 스마트 베드를 묶어서 관리해 주는 역할을 수행한다. 보통 입원실 단위로 설치될 수 있으며 게이트웨이 자체는 별도 하드웨어로 제작되거나 동일 공간을 사용하는 스마트베드 한대에 플러그인 되는 형태가 될 수 있다. 게이트 웨이 구조를 통해 서로 다른 제조사의 스마트베드를 통합 인터페이스 서버와 연결할 수 있게 된다. 물론 게이트웨이 모듈은 연결된 베드와 통신하기 위한 SmartBed Converter 모듈을 탑재해야 하며 스마트 베드 제조사 규격에 맞게 구현해야 한다. 그림 6은 게이트웨이의 모듈 구조를 보여준다. 서버로부터의 요청은 게이트웨이의 API 모듈을 통해 통신하며, 유효성 검사 과정에서 요청이 수신된 스마트베드와 현재 게이트웨이 간의 연결 상태 및 요청된 값의 유효성을 확인한다. 그런 다음, 게이트웨이에 내장된 데이터베이스에서 해당 스마트베드의 ID를 검색하여, 스마트베드의 제조사 정보를 확인한다. 이후 스마트베드 제조사의 메시지 형식에 따라 메시지를 변환한다. 마지막으로, 변환된 메시지는 스마트베드로 전송되어 통신이 이루어진다.

Fig. 6.

Gateway module architecture

게이트웨이 모듈에서 스마트 베드와 연결하기 위한 세부 기능은 확장 가능하지만 통합 인터페이스 서버와의 통신을 위해 최소한 표 1의 데이터가 제공된다고 가정한다.

Table 1.

Required message data

3.5 스마트 의료용 베드 통합 인터페이스 시스템 구현

설계에 따라 통합 게이트웨이 서버와 HIS 인터페이스 모듈을 구현한다. 두 모듈은 같은 프로젝트 모듈로 통합 구현하며 게이트웨이 모듈은 별도 하드웨어상에서 동작해야 하기 때문에 분리해서 구현한다.

시스템을 사용하기 위한 UI는 웹 기반으로 환자관리, 게이트웨이관리, 스마트베드 관리 등의 기능을 제공하는 통합 대시보드와 연결된 스마트 베드 마다 현재 상태정보와 생체정보 등을 확인할 수 있는 모니터링 대시보드로 구성된다.

시스템 구현은 자바 JDK 17, 스프링부트 3.2, MySQL 8 데이터베이스를 사용해 구현 했으며 구현 UI 결과물은 그림 7과 같다. 통합관리 시스템의 대시보드 화면으로 연결된 게이트웨이와 스마트베드 현황 및 API 호출 로그를 보여준다. 게이트웨이, 스마트베드, 환자, 사용자 등의 관리 메뉴를 포함하고 있으며 스마트베드를 선택하면 그림 8과 같이 스마트베드를 사용하고 있는 환자의 정보와 생체 정보, 부가 서비스, 컨트롤 대시보드가 나타난다.

Fig. 7.

Integrated management system dashboards

Fig. 8.

SmartBed dashboards

4.1 실험 개요

3장에서 설계 및 구현된 스마트 의료용 베드의 통합 인터페이스 시스템의 검증을 위해 기능 적합성 및 성능 테스트를 다음과 같이 실험을 진행하였다.

실제 완성된 스마트베드 제품의 API 규격과 연동하기 위한 시뮬레이터 구현

의료기관과 데이터 연동을 검증하기 위한 HL7 Message 생성 및 검증

1,000 병상 규모의 병원 내 운영을 위한 성능 테스트

실험에 사용된 스마트베드 제품은 (주) 에이아이젬의 Y-300 시제품 이며 그림 9의 우측 상단과 같다. 스마트베드 시뮬레이터는 실제 환자의 생체 신호와 상황을 Y-300에서 제공하는 데이터를 그대로 모방하도록 설계되었다. 이 시뮬레이터는 환자의 심박수, 체중, 호흡수 등의 생체 신호를 정확하게 시뮬레이션하며, 침대 각도 조절, 조명 변화와 같은 기계적 기능을 표현하였다. 이러한 시뮬레이터는 실험 환경을 표준화하고 재현성을 확보할 수 있으며, 일반적인 시나리오에 더해 실제 환경에서 얻기 힘든 예외적인 특정 시나리오와 데이터를 생성하여 실험을 진행하였다.

Fig. 9.

Test environment

SmartBed Interface System은 3장에서 설계 및 구현한 인터페이스 시스템이며 그림 9에는 실험을 위해 추가된 인터페이스 어댑터 부분만 표현되어 있다. SmartBed Simulator는 1,000대의 스마트베드와 연동을 시뮬레이션 하기 위한 실험 모듈이며 HL7 FHIR Converter는 실험에 사용된 데이터를 의료정보 교환 표준 메시지 규격으로 변환하기 위한 모듈이다. 이를 통해 생성된 HL7 Message는 hl7.org에서 제공하는 공식 Validator를 통해 적합성을 검증하게 된다.

실험을 위해 Interface System, Simulator서버를 분리해 운영 했으며 각각의 동작 환경은 표 2 와 같다.

Table 2.

Test server specification

4.2 기능 적합성 실험

기능 적합성 실험은 설계된 SmartBed Interface System이 실제 스마트베드와 데이터 교환 및 제어 수행이 적합하게 이루어지는지에 대해 진행하였다. 시뮬레이터를 통해 1,000개의 스마트베드를 생성하고 대시보드를 통해 스마트베드 현황과 실시간 데이터 교환, 스마트베드 컨트롤을 진행하였다.

대시보드를 통한 정보 교환과 제어는 4개의 API를 호출하도록 되어있다. 표 3은 이를 나타내며, 수행한 단위 테스트 결과 API가 정상적으로 작동함을 검증하였으며, 일부분 긴 JSON 데이터는 생략하였다.

Table 3.

API unit tests

의료기관과의 데이터 교류 적합성 검증은 다음과 같이 진행 되었다. 스마트베드에서 생성된 생체 정보를 의료정보 시스템과 연동하기 위해 변화된 메시지를 HL7 FHIR Validator를 통해 검증을 수행하였으며 그림 10은 이를 나타낸다.

Fig. 10.

Resource validation

검증은 Fatals, Errors, Warnings, Information 단계가 존재하는데, 순서대로 치명적인 오류, 일반 오류, 경고사항, 추가 정보사항을 나타낸다. 스마트베드가 제공하는 생체 데이터가 적합함을 확인할 수 있었다.

4.3 성능 실험

병원 환경에서 스마트베드가 주로 들어가는 공간은 입원실임을 고려하여, 상급종합병원 기준인 500병상의 두배 규모인 1,000병상이 존재한다고 가정하고, 테스트를 진행하였다. 시나리오는 다음과 같다.

총 1,000베드가 100% 운용중이라는 것을 가정

환자의 생체정보는 심박수, 호흡수, 체중 데이터가 랜덤하게 분당 10회 발생

베드 컨트롤은 상부/중앙/하부에 대해 랜덤하게 분당 10회 발생

생성된 환자의 생체정보는 HL7/FHIR Resource로 분당 10회 변환

동시 접속 처리 성능 평가는 스마트베드를 50개에서 1000개까지 증가 시키면서 응답시간 측정

실험은 대표적인 성능 테스트 도구인 Apache Jmeter를 이용해 정의한 시나리오에 따라 진행했으며, 응답 오류 여부와 실험이 진행되는 동안의 응답시간을 측정해 평가하였다. 총 60분동안 진행되었고 Interface Server로의 inbound요청과 outbound요청은 각각 모두 976,076건씩 발생했다. 그림 11는 Thread의 수에 따른 TPS와 Response Time에 대한 그래프이고, 표 4는 신뢰성 테스트에 대한 결과이다.

Fig. 11.

Jmeter experimental process display

Table 4.

Reliability test result

그림 11과 표 4에서 볼 수 있듯 1,000대에 도달한 이후 에도 급격한 성능 감소나 에러가 발생하지 않은 것으로 보아, 최대 규모의 병원에서 극한의 데이터 트랜잭션이 발생하는 상황에서도 정상적인 스마트베드의 운용이 가능함을 알 수 있다.