저는 지난 몇 달 동안 두 국가의 병원 시스템에 걸쳐 환자 기록을 연결하는 프로젝트, 즉 국경 간 EHR 통합 작업에 참여했습니다. 저희의 리드 비즈니스 분석가(BA)는 임상 정보학 분야에서 10년 이상 경력을 쌓은 후 BA 업무로 전환했는데, 그녀와 함께 일하면서 저는 의료 소프트웨어에 대한 사고방식이 근본적으로 바뀌었습니다. 실제로 제가 깊이 새긴 다섯 가지 내용은 다음과 같습니다.

1. 용어 매핑(Terminology mapping)은 데이터 매핑보다 더 어려운 문제입니다

엔지니어로서 우리는 통합을 스키마 문제로 생각하는 경향이 있습니다: 필드 A를 필드 B에 매핑하고, 변환 로직을 작성하면 끝입니다. 하지만 이 사고방식은 의료 분야에서는 거의 즉시 무너집니다.

저희가 연결한 두 건강 시스템은 서로 다른 진단 코딩 표준을 사용했습니다. 한쪽은 여전히 주로 ICD-10-CM을 사용했고, 다른 쪽은 부분적으로 ICD-11로 마이그레이션되었습니다. 이 둘은 깔끔하게 매핑되지 않습니다. ICD-11은 전체 장(chapter)을 재구성하고 사후 코디네이션(post-coordination, 보다 구체적인 임상 개념을 나타내기 위해 코드를 결합하는 능력)을 도입했는데, 이는 직접적인 ICD-10 등가물이 없습니다. 비슷한 문제가 검사 결과에서도 발생했습니다. 한쪽은 LOINC를 일관되게 사용했지만, 다른 쪽은 LOINC 채택 이전에 존재했던 내부 실험실 식별자로 코딩된 수년간의 레거시 데이터를 가지고 있었습니다.

저희 BA는 통합 코드를 작성하기 전에 '개념 교차 참조표(concept crosswalk)'라고 부르는 것을 만들었습니다. 이는 살아있는 스프레드시트였고, 나중에는 제대로 된 용어 서비스가 되어 로컬 코드들을 표준화된 집합(임상 소견의 경우 SNOMED CT, 관찰값의 경우 LOINC, 의약품의 경우 RxNorm)에 매핑했습니다. 이 단계를 건너뛰고 데이터베이스 필드를 직접 매핑했다면, 단순히 데이터 형식만 아니라 임상적 의미가 조용히 손상되었을 것입니다.

교훈: 대부분의 소프트웨어 통합에서 깨진 필드 매핑은 명백하게 잘못된 값을 생성합니다. 하지만 의료 분야에서는 깨진 용어 매핑이 그럴듯하지만 임상적으로 틀린 값을 생성하는데, 이는 훨씬 더 위험하고 QA 단계에서 발견하기가 훨씬 어렵습니다.

1. 데이터 거주지 법률(Data residency law)은 단 하나의 API가 설계되기 전에 아키텍처를 형성합니다

저는 데이터 모델을 먼저 설계한 다음 그에 맞춰 컴플라이언스 (Compliance)를 해결할 수 있을 것이라고 가정하고 투입되었습니다. 하지만 국경 간 의료 데이터 (Cross-border health data)의 경우, 이는 순서가 잘못된 접근 방식입니다.

국경을 넘는 환자 데이터는 동시에 여러 규제 체계에 저촉됩니다. 미국 데이터가 포함되면 HIPAA가 적용되고, EU 또는 인접 관할 구역이 관여하면 GDPR 방식의 데이터 보호 규칙이 적용되며, 여기에 데이터 소스 국가의 기록에 적용되는 현지 의료 데이터 주권 법률 (Health-data-sovereignty law)이 추가됩니다. 일부 관할 구역은 매우 제한적인 조건(연구 동의, 환자의 직접 요청, 특정 치료 연속성 예외 사항)을 제외하고는 의료 데이터가 국외로 나가는 것을 완전히 금지합니다. 저희 BA (Business Analyst)는 법무 및 컴플라이언스 팀과 조기에 협력하여, 어떤 필드가 국경을 넘어 복제될 수 있는지, 어떤 필드가 먼저 비식별화 (De-identification)를 거쳐야 하는지, 그리고 어떤 필드가 어떤 상황에서도 소스 시스템의 관할 구역을 벗어날 수 없는지를 결정했습니다.

이 과정에서 전체 아키텍처 (Architecture)를 재편해야 하는 제약 사항들이 도출되었습니다. 단일 복제 데이터베이스 대신 연합 쿼리 계층 (Federated query layer)을 도입하고, 스키마 (Schema)에 필드별 데이터 분류 태그를 내장하며, 정확히 어떤 필드가 언제 어떤 법적 근거로 국경을 넘었는지 증명할 수 있을 만큼 세밀한 감사 추적 (Audit trail)을 구축하게 되었습니다.

교훈: 국경 간 의료 프로젝트의 경우, 데이터 모델이 존재하기 전 단계에 컴플라이언스 담당자와 규제의 미묘한 차이를 이해하는 BA를 참여시켜야 합니다. 이미 설계된 스키마에 데이터 거주지 (Data residency) 제어 기능을 사후에 끼워 넣는 것은 첫날부터 이를 고려하여 설계하는 것보다 훨씬 더 많은 비용이 듭니다.

2. 상호운용성 (Interoperability) 표준은 필수적이지만 그것만으로는 결코 충분하지 않다

두 병원 시스템 모두 기술적으로는 HL7을 지원했습니다. 하지만 한 곳은 핵심 레거시 EMR 소프트웨어로부터 나오는 HL7 v2 메시징 (ADT 피드, ORU 결과 메시지)을 여전히 사용하고 있었고, 다른 한 곳은 최신 서비스에는 FHIR R4를 채택했지만 오래된 모듈을 위해 하부에서 HL7 v2를 계속 실행하고 있었습니다. "둘 다 HL7을 지원한다"는 말은 결국 변환 계층 (Translation layer) 없이는 서로 통신할 수 없는 두 시스템을 의미한다는 것이 밝혀졌습니다.

기존 EMR 소프트웨어의 메시징 인터페이스 (messaging interface)를 재작성하는 것은 고려 대상이 아니었기 때문에, 결국 레거시 (legacy) 측에 HL7 v2-to-FHIR 어댑터 (adapters)를 갖춘 FHIR 대응 통합 계층 (FHIR-facing integration layer)을 구축하게 되었습니다. FHIR 내에서도 프로파일 불일치 (profile mismatches) 문제에 직면했습니다. 두 시스템 모두 FHIR R4 준수를 주장했지만, 서로 다른 구현 가이드 (implementation guides, US Core 대 지역별 상응 가이드)를 사용하고 있었으며, 국가 건강 식별자 (national health identifiers)와 같이 지역적으로 중요한 데이터에 대해 서로 다른 필수 필드와 확장 (extensions)을 사용하고 있었습니다.

교훈: "우리는 HL7/FHIR를 지원한다"는 말은 대화를 시작하기 위한 출발점일 뿐, 통합이 수월할 것이라는 확증이 아닙니다. 항상 어떤 버전인지, 어떤 프로파일인지, 그리고 어떤 구현 가이드를 사용하는지 물어보세요. 그리고 두 "표준 준수" 시스템 사이에서도 어댑터 계층 (adapter layer)을 위한 실제 시간을 예산에 반영해야 합니다.

1. BA의 워크플로우 다이어그램 (workflow diagrams)은 엔지니어가 구조적으로 놓치는 예외 케이스 (edge cases)를 포착한다

초기에 저는 BA의 임상 워크플로우 다이어그램을 문서화 작업의 부수적인 부담 (documentation overhead) 정도로 취급했습니다. 이해관계자들에게는 보기 좋지만, 무언가를 만드는 데 필수적인 것은 아니라고 생각했습니다. 저는 틀렸습니다.

그녀는 국경 간 환자 이송 시나리오를 상세하게 그려냈습니다. 치료 중간에 환자가 전원될 때 어떤 일이 발생하는지, 처방 규칙이 다른 관할 구역으로 진료가 넘어갈 때 활성화된 약물 처방 (medication order)은 어떻게 되는지, 환자가 이미 국경을 넘어 퇴원한 후에 검사 결과가 돌아오면 어떻게 되는지 등을 정리했습니다. 임상적 관점에서 이 중 어느 것도 예외 케이스가 아닙니다. 이는 일상적인 일입니다. 하지만 엔지니어들이 "환자가 시스템 A에 존재하고, 시스템 B로 복사된다"는 해피 패스 (happy path)를 기준으로 설계할 때 정확히 놓치게 되는 시나리오들입니다.

이러한 워크플로우 중 여러 개가 우리의 데이터 모델 (data model)을 직접적으로 변경했습니다. 예를 들어, 각 시스템의 만남 기록 (encounter records)을 독립적인 것으로 취급하는 대신, 임상적 현실이 국경을 중간에 넘나드는 하나의 연속된 진료 에피소드 (episode of care)였기 때문에, 두 시스템을 아우르는 명시적인 "진료 에피소드 (care episode)" 개념을 추가했습니다.

교훈: 실제 임상 운영 (clinical operations)을 이해하는 사람으로부터 얻은 워크플로우 다이어그램 (workflow diagrams)은 단순한 문서화용 미사여구가 아닙니다. 이는 엔지니어링 측면의 분석만으로는 스스로 찾아낼 수 없는 엣지 케이스 (edge cases)를 드러내는 요구사항 수집 (requirements-gathering) 기법입니다.

1. 공유 용어집 (shared glossary)은 첫 번째 오해(miscommunication)가 발생한 후가 아니라, 첫 번째 요구사항 문서 (requirements doc)가 작성되기 전에 존재해야 합니다.

지나고 보면 당연한 소리처럼 들리겠지만, 우리는 이를 수정하기 전까지 실제 많은 시간을 허비했습니다. "encounter", "episode", "active patient", 그리고 "discharge"와 같은 단어들은 각 의료 시스템의 소스 EMR 소프트웨어와 각 국가의 임상 문서화 관례 (clinical documentation conventions)에 따라 미묘하게 다른 의미를 가졌습니다. 한 시스템에서 "active" 환자는 현재 입원 중인 환자를 의미했지만, 다른 시스템에서는 입원 상태와 관계없이 기록 시스템에 열려 있는 환자를 의미했습니다. 우리는 양측이 공유된 용어를 서로 다르게 해석한 상태로 최소 두 개의 요구사항 문서를 검토하고 승인했으며, 이는 통합 테스트 (integration testing) 단계에 이르러서야 드러났습니다.

결국 우리의 BA (Business Analyst)는 양측의 임상 및 기술 이해관계자 (stakeholders)가 공동으로 검토하는 살아있는 문서 (living document)로서 공유 용어집을 구축했습니다. 모든 모호한 용어는 명시적으로 정의되었으며 요구사항과 함께 버전 관리되었습니다. 이후의 모든 요구사항 문서는 용어를 본문 내에 다시 정의하는 대신 용어집을 직접 참조했습니다.

교훈: 두 국가와 두 개의 규제 체제 (regulatory regimes)를 넘어 두 조직에 걸쳐 있는 어떤 프로젝트에서든, 양측이 단순히 훑어보는 것이 아니라 실제로 합의한 문서에 명시적으로 정의되기 전까지는 모든 도메인 용어 (domain term)가 모호하다고 가정하십시오.

맺음말

이 교훈들은 특별히 EHR 시스템에 국한된 것이 아닙니다. 이는 도메인 복잡성(임상 워크플로우 (clinical workflows), 규제 법률 (regulatory law), 용어 표준 (terminology standards))이 일반적인 엔지니어링 요구사항 프로세스 (engineering requirements process)가 처리할 수 있도록 설계된 범위를 앞지를 때 발생하는 현상에 관한 것입니다. 유능한 BA (Business Analyst)는 단순히 이해관계자의 요청을 티켓 (tickets)으로 번역하는 역할만 수행하지 않습니다. 이와 같은 프로젝트에서 그녀는 코드베이스 (codebase) 외부의 모든 것—규제 제약 (regulatory constraints), 임상 의미론 (clinical semantics), 그리고 조직 간 커뮤니케이션 (cross-organizational communication)—에 대한 시스템 아키텍트 (systems architect)에 더 가까운 역할을 수행했습니다. 만약 국경을 넘어 EMR 소프트웨어를 구축하거나 통합하고 있다면, 해당 역할을 위한 시간과 인력을 충분히 예산에 반영하십시오. 이는 부수적인 비용 (overhead)이 아닙니다. 기술적으로는 정확하지만 임상적으로는 잘못된 통합이 되지 않도록 막아주는 핵심 요소입니다.