5 Learnings From a Cross-Border EHR Integration
저는 두 국가 간의 환자 기록을 연결하는 데 수개월을 보냈습니다. 10년의 임상 경험을 가진 리드 비즈니스 분석가(Lead Business Analyst)와 함께 일했습니다. 그녀의 접근 방식은 제가 헬스케어 소프트웨어를 바라보는 관점을 바꾸어 놓았습니다.
그 프로젝트에서 얻은 다섯 가지 교훈은 다음과 같습니다.
- Terminology mapping is harder than data mapping
엔지니어들은 종종 통합을 스키마 문제로 취급합니다. 필드 A를 필드 B에 매핑하면 끝이라고 생각하죠. 하지만 헬스케어 분야에서는 이 방식이 통하지 않습니다.
한 시스템은 ICD-10을 사용하고 다른 시스템은 ICD-11을 사용했습니다. 이 둘은 깔끔하게 매핑되지 않습니다. 한 시스템은 검사 결과에 LOINC를 사용했지만, 다른 시스템은 오래된 내부 코드를 사용했습니다.
저희 BA는 코드를 작성하기 전에 개념 크로스워크(concept crosswalk)를 구축했습니다. 그녀는 로컬 코드를 SNOMED CT와 같은 표준 세트로 매핑했습니다. 이것이 없었다면 임상적 의미가 왜곡되었을 것입니다.
잘못된 필드 매핑은 잘못된 값을 생성합니다. 하지만 잘못된 용어 매핑은 그럴듯해 보이지만 임상적으로는 틀린 값을 생성합니다. 후자가 훨씬 더 위험합니다.
- Data laws shape architecture early
저는 데이터 모델을 먼저 설계하고 컴플라이언스(compliance)는 나중에 처리하면 될 것이라고 생각했습니다. 제 착각이었습니다.
국경을 넘는 환자 데이터는 HIPAA나 GDPR과 같은 여러 법률의 적용을 받습니다. 어떤 국가는 건강 데이터가 국경 밖으로 나가는 것을 금지하기도 합니다.
저희 BA는 초기 단계부터 법무 팀과 협력했습니다. 그녀는 어떤 필드를 복제할 수 있는지, 어떤 필드에 비식별화(de-identification)가 필요한지를 결정했습니다.
이는 우리의 아키텍처를 바꾸어 놓았습니다. 우리는 단일 복제 데이터베이스 대신 연합 쿼리 레이어(federated query layer)를 구축했습니다. 또한 스키마에 데이터 분류 태그를 직접 추가했습니다.
데이터 모델을 설계하기 전에 컴플라이언스 전문가와 BA를 회의에 참여시키십시오.
- Standards are not enough
두 시스템 모두 HL7을 지원했습니다. 하지만 한 시스템은 HL7 v2를 사용했고, 다른 시스템은 FHIR R4를 사용했습니다. 변환 레이어(translation layer) 없이는 서로 통신할 수 없었습니다.
FHIR 내에서도 프로필 불일치(profile mismatches) 문제가 발생했습니다. 두 시스템 모두 표준을 준수한다고 주장했지만, 서로 다른 구현 가이드(implementation guides)를 사용하고 있었습니다.
시스템이 표준을 지원한다고 해서 통합이 쉬울 것이라고 가정하지 마십시오. 항상 구체적인 버전과 프로필을 확인해야 합니다. 어댑터 레이어(adapter layer)를 위한 시간을 예산에 반영하십시오.
- Workflow diagrams catch hidden edge cases
저는 예전에 워크플로우 다이어그램을 불필요한 추가 문서로 여겼습니다. 제 착각이었습니다.
저희 BA는 환자 전원을 상세하게 매핑했습니다. 그녀는 치료 중간에 환자가 이동하거나, 퇴원 후에 검사 결과가 도착하는 경우에 어떤 일이 발생하는지를 살펴보았습니다.
병원에서 이런 일은 예외 케이스(edge cases)가 아닙니다. 매일 일어나는 일입니다.
이 다이어그램들은 우리의 데이터 모델을 바꾸어 놓았습니다. 우리는 두 시스템 간의 연속적인 케어를 추적하기 위해 케어 에피소드(care episode) 개념을 추가했습니다.
- Build a shared glossary early
encounter(내원)나 discharge(퇴원)와 같은 단어는 시스템마다 의미가 다릅니다. 팀마다 용어를 다르게 해석했기 때문에 시간을 낭비했습니다.
저희 BA는 공유 용어집을 만들었습니다. 모든 이해관계자가 이 정의를 검토하고 동의했습니다. 우리는 모든 요구사항에서 이 문서를 참조했습니다.
모든 도메인 용어는 모호하다고 가정하십시오. 양측이 서명하는 문서에 그 의미를 정의하십시오.
Summary
유능한 BA는 단순히 티켓(ticket)을 작성하는 것 이상의 일을 합니다. 그들은 규제 제약과 임상적 의미를 위한 아키텍트 역할을 합니다. 복잡한 소프트웨어를 구축한다면, 이 역할을 단순한 오버헤드(overhead)로 보지 마십시오. 이 역할은 기술적 성공이 임상적 실패로 이어지는 것을 방지해 줍니다.
Optional learning community: https://t.me/GyaanSetuAi