# 임상 데이터 추상화를 사람의 판단은 남기고 자동화한 Carta Healthcare Lighthouse
개요
Carta Healthcare는 병원이 임상 레지스트리에 제출할 데이터를 만들기 위해 수행하는 임상 데이터 추상화(clinical data abstraction)를 줄이기 위해 Lighthouse와 Voyager 기반 AI-assisted abstraction을 운영합니다.[1][3] 공개 자료에 따르면 이 시스템은 Claude를 사용해 EHR의 정형 데이터와 비정형 임상 노트를 읽고, 레지스트리 질문마다 제안 답안과 근거 인용을 제시하며, 최종 검증은 임상 abstractor가 수행합니다.[1][2] Anthropic 고객 사례는 처리 시간이 최대 66% 줄었고, abstraction 비용이 50% 이상 절감됐으며, IRR(검토자 간 일치도) 98-99%를 달성했다고 설명합니다.[1] 이 글은 공개된 성과를 그대로 일반화하지 않고, FHIR 인입, context construction, PHI 보호, human-in-the-loop 검증이라는 운영 조건을 함께 봅니다.
1. 사례의 핵심: 값을 찾는 작업에서 근거를 검증하는 작업으로
임상 데이터 추상화는 환자 의무기록을 읽고 레지스트리 질문에 맞는 값을 찾아 제출 가능한 형태로 정리하는 작업입니다. 예를 들어 “시술 전 가장 최근 glucose 값은 무엇인가”, “퇴원 시 aspirin이 처방됐는가”, “30일 내 감염이 있었는가” 같은 질문은 단순 키워드 검색으로 끝나지 않습니다. 시술 시작 시각, 투약 맥락, conflicting note, structured field와 free text의 차이를 함께 판단해야 합니다.[2]
Carta Healthcare의 공개 자료가 강조하는 변화는 역할의 재배치입니다. AI가 값을 최종 확정하는 것이 아니라, 가능한 답안과 supporting evidence를 먼저 제시합니다. 임상 abstractor는 처음부터 차트를 뒤지는 “manual data hunter”가 아니라, AI가 제시한 답과 근거가 임상적으로 맞는지 검증하는 “high-value validator”에 가까워집니다.[1]
공개 자료에서 확인되는 핵심은 다음과 같습니다.
| 공개 사실 | 의미 | | --- | --- | | Claude powers Lighthouse platform for clinical registry abstraction.[1] | LLM은 레지스트리 질문에 대한 답과 근거를 만드는 엔진입니다. | | Phase 1에서 Claude Haiku 3.5와 Sonnet 4가 근거를 추출하고, Phase 2에서 Claude Sonnet이 근거를 합성합니다.[1] | 모델 하나로 모든 작업을 처리하기보다 추출과 합성을 분리합니다. | | Lighthouse는 supporting evidence와 rationale을 abstractor에게 보여줍니다.[2] | 검증 가능한 근거가 UI의 중심입니다. | | Carta는 Voyager를 FHIR, clinical guardrails, secure infrastructure, native EHR integration을 결합한 AI platform으로 설명합니다.[3] | Lighthouse 단일 기능보다 인입·오케스트레이션·보안 경계가 중요합니다. |
2. 사용된 AI 기술과 context engineering
이 사례에서 가장 중요한 기술적 교훈은 “프롬프트를 잘 씁니다”보다 “문제별로 올바른 context를 구성합니다”에 가깝습니다. Anthropic 기술 블로그는 pre-procedure glucose나 weight처럼 시점 경계가 중요한 항목에서 환자별 procedure start time을 runtime context에 넣어야 한다고 설명합니다.[2]
| 기술 요소 | 공개 근거 | 운영 설계상의 해석 | | --- | --- | --- | | FHIR 기반 EHR 인입 | Carta는 native, standards-based FHIR connectivity와 read-only EHR access를 설명합니다.[3] HL7 FHIR는 의료 정보를 전자적으로 교환하기 위한 표준입니다.[4] | Patient, Encounter, Observation, DocumentReference, Procedure, Medication 같은 리소스를 registry 질문에 맞게 조합합니다. | | Runtime context construction | Carta 팀은 가장 어려운 문제가 context construction이었다고 설명합니다.[2] | 질문마다 필요한 문서, 시간 범위, 우선순위, 제외 기준을 runtime에 구성합니다. | | Two-phase extraction | Anthropic 고객 사례는 Haiku 3.5/Sonnet 4 evidence extraction과 Sonnet synthesis를 설명합니다.[1] | 긴 차트에서 근거 후보를 넓게 모은 뒤, 답안 생성과 ranking은 별도 단계로 둡니다. | | Citation and rationale | Lighthouse는 각 data point에 supporting evidence와 rationale을 보여줍니다.[2] | Abstractor가 “믿는” 것이 아니라 “검증”할 수 있어야 합니다. | | Prompt feedback loop | 임상 전문가의 설명이 prompt 개선으로 직접 반영되고, 같은 날 production에서 테스트될 수 있다고 설명됩니다.[2] | Registry별 edge case와 correction을 prompt/eval asset으로 관리합니다. | | PHI-safe deployment | Claude on Amazon Bedrock, customer data not used for model training, dedicated AWS account, encryption, BAA/SOC 2가 공개 자료에 언급됩니다.[1][3] | 모델 선택보다 PHI 경계, 데이터 분리, 감사 가능성이 먼저입니다. |
이 문서에서는 Lighthouse와 Voyager를 이렇게 구분해 읽습니다. Lighthouse는 registry question에 대한 AI-assisted abstraction 경험을 가리키는 제품/기능명으로 쓰이고, Voyager는 FHIR 인입과 오케스트레이션까지 포함하는 Carta의 AI data platform 설명에 가깝습니다.[3] 실제 고객 구현에서는 두 명칭이 함께 등장할 수 있으므로, 기능과 데이터 경계를 분리해 보는 편이 안전합니다.
3. 공개 사례에서 확인되는 업무 흐름
공개 자료를 기준으로 임상 데이터 추상화 흐름은 다음처럼 정리할 수 있습니다.
| 단계 | 입력과 처리 | 통제 지점 | | --- | --- | --- | | EHR 인입 | 병원 EHR에서 FHIR 리소스와 임상 노트를 읽습니다.[3][4] | Read-only scope, 최소 권한, 환자/케이스 식별자 매핑을 확인합니다. | | Registry 질문 해석 | NSQIP 같은 레지스트리 질문을 patient-specific context로 바꿉니다.[1][2] | 질문별 time boundary, 포함/제외 기준, terminology rule을 유지합니다. | | 근거 후보 추출 | Claude가 구조화 데이터와 비정형 note에서 evidence 후보를 찾습니다.[1] | 근거가 없는 답은 제안하지 않거나 low-confidence로 둡니다. | | 답안 합성과 ranking | Phase 2가 근거를 종합해 suggested answer와 rationale을 만듭니다.[1] | conflicting evidence와 missing data를 표시합니다. | | Abstractor 검증 | 임상 전문가가 Lighthouse UI에서 근거와 답안을 검토합니다.[1][2] | 승인, 수정, 거절, override reason을 기록합니다. | | 품질 측정과 제출 | IRR, correction, export status를 확인한 뒤 registry 제출 workflow로 넘깁니다.[1] | 검증 전 값은 제출하지 않습니다. |
한 large health system 사례에서 공개된 수치는 구체적입니다. 연 22,000건 이상의 surgical cases, 14개 병원 기준으로 routine case는 30분에서 15-22분으로, complex case는 5-6시간에서 90분으로 줄었고, annual time savings는 3,667-6,050시간으로 제시됐습니다.[1] 다만 이 수치는 특정 공개 사례의 결과입니다. 모든 병원, 모든 registry, 모든 chart quality에 같은 절감률이 적용된다고 쓰면 안 됩니다.
4. 구현 가능한 시스템 아키텍처
아래 아키텍처는 Carta의 내부 구성 전체를 복제한 것이 아닙니다. 공개 자료에서 확인되는 FHIR, dedicated AWS account, Claude on Bedrock, evidence/citation, abstractor validation, registry export를 바탕으로 유사한 PHI-safe 환경에서 검토할 수 있는 AWS 레퍼런스 구성입니다.[1][3]
| 논리 단계 | AWS 서비스 예시 | 역할 | | --- | --- | --- | | FHIR ingestion | API Gateway, Lambda, S3 | EHR에서 FHIR resource와 document reference를 read-only로 인입합니다. | | PHI boundary | Dedicated AWS account, KMS, IAM, CloudTrail | 고객별 데이터 분리, 암호화, 접근 감사 로그를 제공합니다.[3][5] | | Context construction | Step Functions, ECS Fargate | Registry 질문별 time boundary, 문서 범위, structured field를 조립합니다.[2] | | Evidence extraction | Amazon Bedrock, Claude | Phase 1에서 관련 근거를 추출합니다.[1] | | Synthesis and citation | Amazon Bedrock, DynamoDB | Phase 2에서 suggested answer, rationale, citation을 저장합니다.[1] | | Evidence retrieval | OpenSearch, S3 | 임상 note와 근거 span을 검색하고 원문을 확인합니다. | | Human validation | CloudFront, S3, ALB, ECS Fargate, Cognito | Abstractor가 근거를 보고 승인·수정·거절합니다. | | Registry export | Lambda, batch export job | 검증된 값만 registry format으로 내보냅니다. |
이 구조에서 AI output은 항상 proposed 상태입니다. Abstractor가 승인한 값만 validated 또는 export_ready 상태가 됩니다. 의료 데이터에서는 이 상태 구분이 품질뿐 아니라 책임 경계입니다.
5. 프로덕션 설계에서 보완할 점
PHI 경계와 보안 통제를 먼저 확정합니다
HHS의 HIPAA Security Rule 요약은 ePHI 보호를 위해 administrative, physical, technical safeguards가 필요하다고 설명합니다.[5] Carta의 공개 자료도 dedicated AWS account, AES-256 encryption at rest, TLS 1.2+ in transit, HIPAA BAA, SOC 2, customer data not used to train external models를 강조합니다.[3] 따라서 healthcare AI에서는 “어떤 모델이 더 똑똑한가”보다 “PHI가 어디에 저장되고, 누가 접근하고, 어떤 로그가 남는가”를 먼저 확정해야 합니다.
Context construction을 제품 기능으로 관리합니다
Registry 질문은 단순 extraction field가 아닙니다. “시술 전”이라는 단어 하나만 있어도 patient-specific procedure time, document timestamp, lab timestamp, clinical admissibility가 함께 필요합니다.[2] 따라서 context construction은 prompt 내부 문장이 아니라 별도 runtime component, test suite, failure taxonomy로 관리하는 편이 좋습니다.
Abstractor correction을 eval로 되돌립니다
IRR이 높더라도 case mix가 바뀌면 품질이 흔들릴 수 있습니다. Abstractor가 수정한 답, 거절한 근거, conflicting note, missing document는 registry별 eval item으로 쌓아야 합니다. NIST AI RMF 관점에서도 AI 시스템의 신뢰성은 설계, 평가, 운영에서 지속적으로 관리해야 합니다.[7]
Prompt injection과 excessive agency를 막습니다
임상 note에는 모델 지시처럼 보이는 텍스트가 포함될 수 있고, 외부 문서나 환자 제공 자료가 섞일 수도 있습니다. OWASP LLM Top 10은 prompt injection, sensitive information disclosure, excessive agency를 주요 위험으로 제시합니다.[8] 따라서 Lighthouse류 시스템은 note content를 instruction으로 취급하지 않도록 분리하고, registry export나 EHR write-back 같은 action은 모델이 직접 수행하지 못하게 해야 합니다. Carta의 공개 FAQ도 Voyager가 EHR에 write back하지 않는 read-only 접근이라고 설명합니다.[3]
6. 구축 및 운영 비용
Carta Healthcare의 내부 운영비와 고객별 Bedrock 사용량은 공개되지 않았습니다. 비용은 최소한 다음 가정을 나눠 산정해야 합니다.
- 가정: 2,000 cases/month, case당 80,000 input tokens와 1,500 output tokens, evidence extraction과 synthesis를 합친 단순 상한 산정.
- 모델 비용: 2026년 7월 7일 접근 기준 Anthropic 가격표에서 Claude Sonnet 4 계열의 $3/MTok input, $15/MTok output 단가를 단순 적용하면 모델 비용 상한은 약 $525/month입니다.[6]
- 절감 변수: 실제 구조는 Haiku 계열로 넓은 evidence extraction을 처리하고 Sonnet을 synthesis에 쓰는 two-phase routing이므로, model mix와 cache hit가 비용을 크게 바꿀 수 있습니다.[1][6]
- 제외: Bedrock regional premium, FHIR connector, EHR vendor integration, OpenSearch, storage, logging, KMS, monitoring, abstractor 인건비, clinical QA, security review, BAA/SOC evidence, registry export 운영비는 제외했습니다.
- 총비용의 중심: 의료 환경에서는 모델 token보다 integration, 보안 심사, abstractor review, registry별 QA, 고객별 배포·운영 비용이 더 클 가능성이 높습니다.
이 비용 문단은 구매 견적이 아니라 planning guardrail입니다. 파일럿에서는 case당 token, rejected answer 비율, abstractor correction rate, IRR 변화, missing-note 비율, export 실패율을 함께 기록해야 합니다. 그래야 속도 절감이 데이터 품질 손상으로 바뀌지 않는지 판단할 수 있습니다.
7. 비즈니스 이익과 KPI
Anthropic 고객 사례가 제시하는 직접 이익은 abstraction time reduction, cost savings, IRR 유지, abstractor 역할 전환입니다.[1] 그러나 healthcare 운영에서는 자동화율 하나만 KPI로 잡으면 위험합니다.
| KPI 묶음 | 예시 지표 | 해석 | | --- | --- | --- | | 속도 | Time per case, queue age, routine/complex case 분리 | 단순 case와 복잡 case의 병목을 따로 봅니다. | | 품질 | IRR, abstractor correction rate, unsupported answer rate | AI 제안이 registry 제출 품질을 유지하는지 봅니다. | | 근거성 | Citation coverage, source-note availability, conflict flag rate | 답안이 원문 evidence로 검증 가능한지 봅니다. | | 운영 | FHIR ingestion failure, missing document rate, export failure | 모델 밖의 병목을 분리합니다. | | 보안 | Access log coverage, PHI boundary exceptions, retention compliance | PHI 처리 경계가 실제로 지켜지는지 봅니다.[5] |
이 사례의 강점은 abstractor를 없애는 데 있지 않습니다. 오히려 고숙련 임상 인력이 값을 찾는 반복 작업보다 근거 검증, edge case 판단, registry quality improvement에 시간을 쓰게 하는 데 있습니다.
8. 규제 산업·B2B 기업에 주는 시사점
이 패턴은 의료에만 국한되지 않습니다. “긴 문서에서 규정된 항목을 찾아 근거와 함께 제출해야 하는 업무”라면 비슷한 구조를 적용할 수 있습니다.
- 제조 품질 기록에서 불량 원인, corrective action, 검사 결과를 추출합니다.
- 의료기기·제약 문서에서 임상시험, 안전성, 규제 제출 항목을 정리합니다.
- 보험 심사에서 의무기록 근거와 청구 항목의 일치 여부를 검증합니다.
- 안전·환경 보고서에서 규제 보고 항목과 원문 evidence를 연결합니다.
- 감사 대상 인증 문서에서 control evidence와 reviewer approval을 관리합니다.
공통 조건은 세 가지입니다. 첫째, 항목 정의가 명확해야 합니다. 둘째, 원문 근거가 없으면 값도 확정하지 않아야 합니다. 셋째, 전문가 검증 전에는 downstream 제출이나 시스템 반영을 막아야 합니다. 의료 사례에서 배울 점은 “AI가 판단을 대신합니다”가 아니라 “AI가 검증 가능한 판단 후보를 만들어 전문가의 시간을 아낍니다”입니다.
9. 도입 체크리스트
| 점검 항목 | 완료 기준 | | --- | --- | | 항목 정의 | Registry question, 허용 값, 제외 기준, ambiguity 상태가 문서화돼 있습니다. | | FHIR 범위 | Patient, Encounter, Observation, DocumentReference 등 필요한 리소스와 read-only scope가 정의돼 있습니다.[3][4] | | Context construction | Time boundary, document priority, missing-note 처리, conflicting evidence rule이 테스트됩니다.[2] | | 근거 인용 | 모든 suggested answer에 source note, timestamp, citation, rationale이 붙습니다. | | Human validation | Abstractor 승인 전에는 registry export가 실행되지 않습니다. | | PHI 보호 | Administrative, physical, technical safeguards와 BAA/SOC 증적이 준비돼 있습니다.[5] | | Write-back 제한 | EHR write-back은 금지하거나 별도 승인 workflow로 분리합니다.[3] | | 평가 | IRR, correction rate, unsupported answer, temporal reasoning failure를 지속 측정합니다. | | 보안 방어 | Prompt injection, sensitive information disclosure, excessive agency 방어가 설계돼 있습니다.[8] | | 비용 | Token, Bedrock/API, search, storage, integration, abstractor QA, 보안 심사 비용을 분리합니다.[6] |
결론
Carta Healthcare Lighthouse 사례의 핵심은 임상 판단을 AI로 대체한 것이 아니라, 임상 추상화 작업을 근거 중심의 human-in-the-loop 운영으로 바꾼 점입니다. 공개 자료에서 확인되는 구성은 FHIR 기반 인입, runtime context construction, two-phase Claude pipeline, supporting evidence와 rationale, abstractor validation, PHI-safe deployment입니다.[1][2][3] 이 모델을 다른 규제 산업에 적용하려면 “좋은 모델”보다 항목 정의, 원문 근거, 전문가 승인, 품질 지표, PHI·민감정보 경계, export 통제를 먼저 설계해야 합니다.[5][7][8] 그렇게 해야 속도 개선이 데이터 품질과 규제 리스크를 희생하지 않는 운영 개선으로 이어집니다.
출처
- Carta Healthcare cuts clinical data processing time by 66% with Claude. Anthropic / Claude. 2026 access 기준. https://claude.com/customers/carta-healthcare. 접근일: 2026-07-07.
- How Carta Healthcare gets AI to reason like a clinical abstractor. Anthropic / Claude. 2026-04-08. https://claude.com/blog/carta-healthcare-clinical-abstractor. 접근일: 2026-07-07.
- Healthcare AI Data Platform. Carta Healthcare. 2026 access 기준. https://www.carta.healthcare/clinical-data-management/ai-platform/. 접근일: 2026-07-07.
- FHIR Overview. HL7 International. FHIR R5, 2023; 2026 access 기준. https://hl7.org/fhir/overview.html. 접근일: 2026-07-07.
- Summary of the HIPAA Security Rule. U.S. Department of Health and Human Services. 2026 access 기준. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html. 접근일: 2026-07-07.
- Pricing. Anthropic Claude Platform Docs. 2026 access 기준. https://platform.claude.com/docs/en/about-claude/pricing. 접근일: 2026-07-07.
- AI Risk Management Framework. National Institute of Standards and Technology. 2023/2024/2026 access 기준. https://www.nist.gov/itl/ai-risk-management-framework. 접근일: 2026-07-07.
- OWASP Top 10 for LLM Applications 2025. OWASP Foundation. 2025. https://genai.owasp.org/llm-top-10/. 접근일: 2026-07-07.