왜 80%의 헬스케어 AI 파일럿이 파일럿 단계에서 사라지는가: 데이터 아키텍처 문제

Source: Dev.to

Overview

헬스케어 데이터는 엉망입니다. EHR, 실험실, 약국, 보험사, 그리고 다양한 공급업체들이 “거의‑FHIR, 일종‑HL7, 무작위 CSV, 그리고 미스터리 XML”이라는 약간씩 다른 방언을 사용하고 있습니다. 게다가 중복 데이터, 누락된 필드, 그리고 누군가의 머릿속에만 존재하는 비즈니스 규칙이 있습니다.

그 위에 강력한 LLM을 얹어도 마법이 일어나지는 않습니다. 불안정한 동작, 안전하지 않은 권고, 그리고 “멋진 내부 데모” 단계에서 벗어나지 못하는 프로젝트가 됩니다.

AI‑준비된 헬스케어 데이터 아키텍처를 6단계로 구축하는 전체 가이드 읽기

Why most healthcare AI projects stall

• 데이터가 파편화되고, 일관성이 없으며, 명시적인 규칙 대신 부서별 암묵지에 의해 관리됩니다.

Core layers of a modern healthcare platform

1. FHIR 운영 레이어 – 거의 실시간 임상 워크플로.
2. Warehouse / lakehouse – 비식별 데이터에 대한 분석 및 ML.
3. MDM / hMDM – 신원 해결 및 골든 레코드.
4. API + 접근 제어 – 앱과 AI가 데이터를 다루는 방식.

Six steps to make the stack AI‑ready

1. FHIR‑first 영속성을 정규 모델로 사용합니다.
2. 세분화된 권한 부여를 추가해 일반 앱 RBAC보다 엄격하게 합니다.
3. LLM용 도구 / 함수 호출을 노출하고 원시 API 접근은 제한합니다.
4. **Retrieval‑Augmented Generation (RAG)**을 도입해 답변이 환자 데이터에 기반하도록 합니다.
5. ETL을 통해 웨어하우스로 이동시켜 환자 간 분석 및 ML을 수행합니다.
6. 프라이버시 및 컴플라이언스 제어를 내장합니다 (토큰화, 동의, 로깅, 영구 삭제 LLM).

Common failure pattern

1. 팀이 모델부터 시작합니다 (“우리 EHR에 GPT를 통합하자!”).
2. 샌드박스 데이터셋으로 빠른 프로토타입이 작동합니다.
3. 실제 데이터와 실권한에 닿자마자 모든 것이 무너집니다.

거의 20년 동안 규제 산업용 소프트웨어를 구축해 온 경험에 비추어 보면, 이 패턴은 AI 문제라기보다 아키텍처 문제에 가깝습니다.

Typical blockers

• 누락되거나 일관성 없는 필드 → 잘못 분류된 위험, 오류가 있는 트리아지, “왜 답변이 이렇게 틀렸지?”
• 중복된 환자·제공자 → 깨진 히스토리, 안전하지 않은 권고.
• 시스템 간 상충되는 비즈니스 규칙 → 어떤 소스를 호출하느냐에 따라 AI 동작이 달라짐.
• 동일 개념에 대한 서로 다른 소스 포맷 → 취약한 ETL, 예상치 못한 오류.

전자상거래 앱에서는 무해할 작은 데이터 결함이 임상 지침에서는 큰 문제로 이어질 수 있습니다. 그래서 우리는 모델보다 데이터 기반을 먼저 잡습니다.

Detailed view of the four layers

FHIR‑first operational data layer

• 거의 실시간 임상 데이터.
• Patient, Observation, MedicationRequest, Encounter, Condition 같은 리소스가 공통 의미 체계를 공유합니다.
• 시스템이 일회성 스키마 대신 알려진 구조에 연결될 수 있습니다.

Warehouse / lakehouse analytics layer

• Snowflake, BigQuery, Databricks 등.
• ETL된, 표준화된 데이터가 인구 건강 대시보드, 장기 환자 여정, 비식별 데이터 기반 예측 모델, 비용·품질 분석 등에 활용됩니다.

MDM / hMDM (Master Data Management)

• 환자, 제공자, 보험사, 플랜 간 신원을 조정합니다.
• “골든 레코드”를 생성해 위 레이어들이 불안정한 신원 레이어 위에 구축되지 않도록 합니다.

API + access control layer

• REST / GraphQL / FHIR API를 예측 가능한 방식으로 노출합니다.
• 권한 로직, 사용 목적 검증, 마스킹/레드액션, 감사, 필드‑레벨 접근 제어를 중앙에서 관리합니다.
• AI 시스템도 이 레이어를 통해 진입해야 합니다.

Why FHIR matters for AI

• 스키마 혼란 제거 – 모든 임상 엔터티가 정의된 리소스 구조를 사용합니다.
• 일회성 매핑 감소 – 많은 공급업체가 이미 FHIR를 제공하거나 안정적인 파이프라인으로 변환할 수 있습니다.
• 상호운용성 기본값 – 병원, 실험실, 약국, 보험사가 모두 같은 구조에 연결됩니다.
• 예측 가능한 출력 – get_patient_observations() 같은 함수는 항상 Observation 리소스 리스트를 반환합니다.
• 유연성 유지 – 새로운 모듈이나 AI 도구가 데이터 모델을 재구성하지 않고도 연결될 수 있습니다.

Other healthcare standards (for context)

우리는 일반적으로 FHIR가 이러한 표준과 병행해서 사용되는 것을 보며, 대체하지는 않습니다. FHIR는 현대적인 API‑구동, 환자 중심 워크플로를 담당하고, 다른 표준은 보관, 연구, 규제 용도를 담당합니다.

Example: FHIR‑first patient engagement platform

• Server: HAPI FHIR 서버가 읽기/쓰기 작업을 관리합니다.
• Integration: 외부 EHR 및 약국 시스템이 FHIR API를 통해 동기화됩니다.
• Permissions: 리소스 수준에서 강제 적용 (RBAC + 관계 기반 규칙 + FHIR 보안 메커니즘).

Impact

• 핵심 임상 데이터에 대한 맞춤 스키마가 없어 매핑 작업이 크게 감소합니다.
• 여러 앱(환자, 제공자, 관리자)이 동일한 데이터 레이어를 재사용할 수 있습니다.
• 접근 제어가 FHIR 리소스와 자연스럽게 정렬됩니다.
• AI 기능을 추가했을 때, 데이터 모델이 이미 LLM에 친숙했습니다.

Permission model for AI assistants

AI 어시스턴트에게 임상 데이터 접근 권한을 부여하는 것은 일반 CRUD 앱을 만드는 것과 매우 다릅니다. 다음을 고려한 권한 모델이 필요합니다:

• 사용자‑별 접근 – 환자는 자신의 기록만 볼 수 있고, 의사는 자신이 담당하는 환자만 볼 수 있습니다.
• 사용 목적 – 치료, 연구, 청구 등 구분.
• 맥락 기반 규칙 – 시간 제한 접근, “비상 상황” 긴급 우회.
• 전체 감사 로그 – 누가 어떤 필드를 언제 왜 접근했는지 기록.

Example flow

1. 환자: “내 마지막 혈액 검사 결과가 뭐야?”
2. AI가 사용자를 식별하고 인증합니다.
3. 권한 레이어가 평가합니다: 이 사용자가 환자인가? 자신에 대한 Observation 리소스를 볼 권한이 있는가?
4. 허가된 FHIR 리소스만 조회됩니다.
5. AI가 해당 관찰 결과를 자연어로 요약합니다.

Tools for fine‑grained access control

• Permit.io, Permify – 개발자 친화적인 API.
• OPA / ABAC – 매우 구체적인 정책 로직을 위한 맞춤 솔루션.

핵심 포인트: 모든 AI 질의는 이 레이어를 통과해야 합니다. 모델이 직접 데이터스토어를 “자유롭게 탐색”하지 않도록 합니다.

Safe AI interaction via function calling

최신 LLM(OpenAI, Claude 등)은 함수 호출을 지원합니다. 모델이 SQL을 생성하거나 임의의 URL을 호출하도록 하는 대신, 작은 툴킷 형태의 함수들을 노출합니다.

Available back‑ends

• FHIR 서버 (운영 데이터)
• Warehouse / lakehouse (분석)
• MDM (신원)
• APIs (접근)

Example function toolbox

def get_patient_observations(patient_id: str, category: str) -> List[Observation]:
    ...

def get_patient_conditions(patient_id: str) -> List[Condition]:
    ...

def get_patient_medications(patient_id: str) -> List[MedicationRequest]:
    ...

def search_encounters(patient_id: str, date_range: Tuple[date, date]) -> List[Encounter]:
    ...

Runtime flow

1. 사용자가 질문을 합니다.
2. LLM이 툴킷에서 적절한 도구를 선택합니다.
3. 도구가 권한 레이어를 사용해 검증하고, 필요에 따라 FHIR/MDM/warehouse를 조회해 구조화된 데이터를 반환합니다.
4. LLM이 그 구조화된 결과를 기반으로 자연어 답변을 생성합니다.

모델은 직접 FHIR 스토어나 웨어하우스에 접근하지 않으며, 항상 여러분이 제어하는 얇고 검증된 레이어를 거칩니다. 여기서 입력 검증, 로깅, 컴플라이언스를 강제합니다.