헬스케어 소프트웨어에는 대부분의 AI 도구들이 완전히 무시하고 있는 문제가 하나 있습니다. 바로 데이터가 건물 밖으로 나갈 수 없다는 점입니다.

"나가면 안 된다"가 아닙니다. "나갈 수 없다"입니다. 환자 기록을 제3자 API로 전송하는 병원은 편의성과 개인정보 보호 사이에서 절충안을 찾는 것이 아닙니다. 그것은 대부분의 관할 구역에서 법을 위반하는 것이며, 해당 시스템에 기록이 있는 모든 사람의 신뢰를 저버리는 행위입니다.

저는 실행 중인 기기 내에서 완전히 문서를 파싱하는 Windows 데스크톱 AI 어시스턴트인 NeonCore를 구축했습니다. 클라우드 업로드도 없고, 데이터 보관도 없습니다. 몇 달 전부터 의료 분야의 사람들로부터 동일한 질문을 받기 시작했습니다. "우리 환자 기록을 읽을 수 있나요?"

솔직한 답변은 "아니오"였습니다. 그래서 저는 그것을 직접 만들었습니다.

왜 더 간단한 것이 아닌 FHIR인가

FHIR R4는 대부분의 현대적인 병원 시스템이 이미 사용하고 있는 표준입니다. 기관에 인프라의 어떤 것도 변경해달라고 요청하지 않고 환자 데이터를 읽고 싶다면, FHIR는 이미 열려 있는 문입니다.

대안은 병원에 제 앱이 이해할 수 있는 특정 형식으로 데이터를 내보내 달라고 요청하는 것이었을 겁니다. 하지만 그것은 시작조차 할 수 없는 일입니다. 모든 내보내기(export) 단계는 민감한 데이터의 복사본이 있어서는 안 될 곳에 머물게 되는 것이며, 어떤 IT 부서도 이를 승인하지 않을 것입니다.

따라서 설계 제약 조건은 간단했습니다. 기관이 이미 운영 중인 자체 네트워크상의 FHIR 서버와 통신하되, 그 어떤 것도 다시 외부로 쓰지 않는 것입니다.

아키텍처

세 가지 요소로 구성됩니다:

1. 로컬 FHIR 클라이언트. NeonCore는 로컬 네트워크를 통해 기관의 FHIR R4 엔드포인트(endpoint)에 연결됩니다. 엔드포인트 주소는 제가 아닌 기관에 의해 설정됩니다. 저는 이를 절대 볼 수 없습니다.

2. 모델에 노출된 쿼리 도구. 리소스를 검색하기 위한 fhir_sorgula 함수와 ID로 특정 기록을 읽기 위한 fhir_kayit_oku 함수, 이렇게 두 가지 함수가 있습니다. 모델은 다른 도구를 호출하는 것과 동일한 방식으로 이 함수들을 호출합니다.

3. 온디바이스 추론 (On-device reasoning). 기록이 돌아오면 로컬에서 추론 과정을 거치고, 답변이 화면에 나타납니다. 사용자가 명시적으로 저장하지 않는 한 아무것도 디스크에 기록되지 않습니다. 클라우드 엔드포인트로 전송되는 것도 없습니다.

중요한 점은 그 목록에서 무엇이 빠져 있는가 하는 것입니다. 동기화 계층 (sync layer)이 없습니다. 쿼리 내용에 대한 원격 측정 (telemetry)도 없습니다. 세션 간의 환자 데이터 캐싱 (caching)도 없습니다.

예상보다 어려웠던 점

FHIR는 거대한 표준입니다. R4는 100개가 훨씬 넘는 리소스 유형 (resource types)을 정의합니다. 저는 그 모든 것을 구현하지 않았으며, 구현할 의도도 없습니다. Patient, Observation, Condition, MedicationRequest, DocumentReference가 임상의가 실제로 질문하는 내용의 압도적인 대다수를 차지합니다. 완전성보다는 범위의 규율 (scope discipline)이 더 중요했습니다.

인증 (Authentication) 방식이 매우 다양합니다. 어떤 기관은 SMART on FHIR를 사용하고, 어떤 곳은 일반적인 베어러 토큰 (bearer tokens)을 사용하며, 어떤 곳은 네트워크 경계 뒤에 위치하여 아무것도 사용하지 않기도 합니다. 저는 결국 특정 흐름을 가정하는 대신 설정 가능한 인증 계층 (auth layer)을 지원하게 되었습니다.

검색 파라미터 (Search parameters)는 실제 적용 시 일관성이 없습니다. 명세서 (spec)에는 한 가지로 적혀 있지만, 개별 서버 구현체들은 각자만의 방식으로 해석합니다. 방어적 파싱 (defensive parsing)은 선택이 아닌 필수였습니다.

구축하는 것보다 설명하는 것이 더 어렵습니다. 저는

이제 NeonCore에서 FHIR 지원이 활성화되었습니다. 다음 계획은 명세서(spec)가 제안하는 내용보다는 사람들이 실제로 요청하는 것에 기반하여 리소스 범위(resource coverage)를 확장하는 것과, 이전 버전의 FHIR를 사용하는 기관들을 위한 더 나은 처리 방식을 구축하는 것입니다.

만약 귀하가 헬스 IT (health IT) 분야에서 일하고 계시며 이 기능의 허점을 찾아내고 싶다면, 저는 진심으로 그 의견을 듣고 싶습니다. 제가 미처 생각하지 못한 실패 모드 (failure modes)들이 제가 이미 알고 있는 것들보다 저에게는 더 가치 있습니다.

https://neondijital.com/blog/fhir-r4-local-first-ai

NeonCore는 neondijital.com에 있습니다. 이즈미르(Izmir)에서 단독으로 구축하고 유지 관리하며, 자체 자금으로 운영됩니다.