주제 4.3 — 상호운용성 및 데이터 표준

보건·돌봄에서 상호운용성은 기술적 세련됨이 아니라 임상 안전과 형평성의 요건이다. 시스템이 올바른 데이터를, 올바른 형태로, 모호하지 않은 의미로, 돌봄 현장에서 공유하지 못하면 사람들이 해를 입고 불평등이 증폭된다.

보건·돌봄에서 이것이 중요한 이유#

한 사람의 돌봄은 한 곳에서만 이루어지는 경우가 드물다. 한 번의 에피소드가 일반의 진료소, 구급 서비스, 응급실, 병원 병동, 지역 간호사, 약국, 사회적 돌봄 팀, 집의 돌봄 제공자에 닿을 수 있다. 이들 각각이 기록의 일부를 보유한다. 그 부분들을 안전하고 신속하게 모을 수 없으면 임상의는 정보가 빠진 채 결정을 내린다. 보지 못한 알레르기, 이중 처방된 약물, 불필요하게 반복된 검사, 필요한 팀에게 보이지 않는 안전 보호 표시다.

상호운용성은 단절된 시스템의 집합을 환자의 관점에서 연결된 서비스처럼 행동하는 무언가로 바꾸는 것이다. 통합 돌봄 밑의 배관이다. 작동하면 한 조직의 임상의가 다른 조직이 기록한 것을 보고 그것이 생각한 대로의 의미임을 신뢰할 수 있다. 실패하면 그 실패는 누군가 해를 입기 전까지 소리 없는 경우가 많다.

이는 형평성의 문제이기도 하다. 가장 복잡한 필요를 가진 사람들 — 허약한 고령자, 여러 장기 질환이 있는 사람, 서비스 사이를 오가는 사람 — 이 바로 데이터가 가장 파편화된 사람들이다. 따라서 부실한 상호운용성은 가장 취약한 사람들을 가장 많이 해친다. 그리고 대중 신뢰의 문제다. 사람들은 NHS가 이미 자신의 정보를 합리적으로 공유하고 있다고 당연히 가정하며, 얼마나 자주 그렇지 않은지 알게 되면 낙담한다.

마지막으로, 상호운용성은 공적 자금을 보호한다. 데이터를 교환할 수 없는 독점 시스템은 조직을 비싸고 교체하기 어려운 계약에 묶고 값비싼 점대점 통합을 강제한다. 개방형 표준에 맞춰 구축하는 것이 선택지를 열어 두고, 공급업체를 정직하게 유지하며, 같은 문제를 풀려고 반복해서 값을 치르는 것을 피하는 방법이다.

핵심 개념#

상호운용성은 서로 다른 시스템이 정보를 교환하고 사용하는 능력이다. 두 계층을 구분하는 것이 유용하다. 구문적 또는 기술적 상호운용성은 두 시스템이 메시지를 교환하고 각각 그 구조를 파싱할 수 있다는 뜻이다. 봉투가 도착해 열 수 있다. 의미적 상호운용성은 수신 시스템이 내용의 의미를 발신자가 이해한 것과 같은 방식으로 이해한다는 뜻이다. "페니실린 알레르기"의 코드가 양쪽에서 똑같이 해석된다. 의미적 상호운용성 없는 기술적 상호운용성은 위험하다. 데이터는 흐르지만 의미는 사라지거나 왜곡된다.

보건 데이터는 표준으로 교환된다. Health Level 7(HL7)은 의료에서 가장 많이 쓰이는 표준군이다. 더 오래된 HL7 버전 2(v2) 메시징은 파이프와 캐럿으로 구분된 텍스트를 써서 지금도 방대한 병원 메시징을 떠받치며 앞으로도 몇 년간 그럴 것이다. 현대 표준인 HL7 Fast Healthcare Interoperability Resources(FHIR)는 임상 정보를 웹 방식의 애플리케이션 프로그래밍 인터페이스(API)로 교환되는 "리소스"로 모형화하여, 현대 개발자가 다루기 훨씬 쉽다.

메시지에 대한 표준만으로는 충분하지 않다. 내용을 위한 표준 어휘도 필요하다. SNOMED CT(Systematized Nomenclature of Medicine — Clinical Terms)는 진단, 증상, 시술 등을 기록하기 위해 NHS 돌봄 전반에 의무화된 임상 용어 체계다. NHS Dictionary of medicines and devices(dm+d)는 의약품과 의료기기의 표준 어휘이며 전자 처방을 떠받친다. 세계보건기구가 유지하는 국제질병분류 10차 및 11차 개정(ICD-10과 ICD-11)은 일상적 임상 기록이 아니라 분류, 통계, 상환에 쓰인다. openEHR은 공유되고 임상적으로 거버넌스되는 "아키타입"을 통해 건강 기록 자체를 구조화하는 개방형 명세이며, 일부 조직이 임상 데이터 모델을 어떤 단일 공급업체로부터도 독립적으로 유지하는 데 쓴다.

두 가지 개념이 더 기초적이다. NHS Number는 같은 사람에 대한 기록이 조직 간에 신뢰성 있게 연결되게 하는 공통 환자 식별자다. 공유 식별자가 없으면 일치는 추측이다. 그리고 Integrating the Healthcare Enterprise(IHE)는 문서 공유 같은 구체적 문제를 풀기 위해 기존 표준을 어떻게 결합할지 정확히 명시한 "프로파일"을 공표하여, 서로 다른 공급업체가 같은 방식으로 구현하게 한다.

이 모든 것을 떠받치는 것은 전략적 선택이다. 공표되고 재사용 가능한 API를 갖춘 개방형 표준에 맞춰 구축하면 시장이 경쟁적으로, 데이터가 이식 가능하게 유지된다. 독점 인터페이스에 기대면 공급업체를 바꾸는 비용이 너무 커서 사실상 바꿀 수 없게 되는 공급업체 종속이 생긴다. 그러나 데이터 품질 없이는 어느 것도 가치를 전달하지 못한다. 정확하고, 완전하고, 시의적절하고, 일관되게 코딩된 데이터가 상호운용성의 전제 조건이지 사후 고려가 아니다.

모범 사례#

1. 의미적 상호운용성과 기술적 상호운용성을 구별하고 둘 다를 위해 설계하라. 이제 두 시스템 사이에 메시지가 흐른다고 축하하면서 수신 임상의가 그 의미를 안전하게 신뢰할 수 없다는 점을 놓치기 쉽다. 항상 물으라. 상대편이 이 코드, 단위, 부정을 정확히 우리가 하는 대로 해석하는가? 메시지 형식만이 아니라 공유 용어 체계(SNOMED CT, dm+d)와 값 집합에 투자하라. 올바르게 전송되었지만 오해된 알레르기는 메시지가 없는 것보다 위험하다.

2. 재발명하지 말고 개방형 표준에 맞춰 구축하고 플랫폼을 재사용하라. 널리 지지되는 원칙을 채택하라. 개방형 표준에 맞춰 구축하고, 자체 구축 전에 기존 국가 플랫폼과 서비스를 재사용하라. NHS에서 이는 HL7 FHIR API를 선호하고, NHS Number를 식별자로 쓰며, 맞춤 점대점 연결을 만드는 대신 Spine, GP Connect, 공유 진료 기록 같은 국가 서비스에 연결함을 뜻한다. 재사용은 비용을 줄이고, 유지보수 부담을 분산하며, 데이터가 이동할 수 있게 한다.

3. NHS Number를 모든 기록과 메시지에서 타협할 수 없게 만들라. 신뢰성 있는 기록 연결은 신뢰할 만한 공통 식별자에 달려 있다. NHS Number가 포착되고, 국가 인구통계 서비스에 대해 확인되며, 모든 관련 기록과 인터페이스에 실려 가도록 하라. 없거나 확인되지 않은 곳은 해결할 데이터 품질 결함으로 다루라. 이름과 생년월일만으로 일치시키면 위험한 불일치와 놓친 연결이 모두 생기기 때문이다.

4. 데이터 품질을 일급 산출물로 다루라. 상호운용성은 데이터 품질 문제를 하류의 모두에게 내보낸다. 데이터를 프로파일링하고, 완전성과 코딩 일관성을 측정하며, 오류가 원천에서 발견되고 고쳐지도록 스튜어드십을 마련하라. 코딩 표류, 구조화된 데이터가 필요한 곳의 자유 서술, 일관되지 않은 단위는 모든 하류 분석과 임상 시야를 조용히 오염시키므로, 저절로 일어난다고 가정하지 말고 이 업무에 명시적으로 재원을 대라.

5. 긴밀한 통합보다 API 우선의 느슨하게 결합된 아키텍처를 선호하라. 역량이 잘 문서화되고 버전이 매겨진 API를 통해 노출되어 다른 이들이 맞춤 협상 없이 소비할 수 있도록 설계하라. 이는 직접 데이터베이스 연결보다 처음에는 더 느리지만, 한 구성 요소를 그 주변 모든 것을 다시 만들지 않고 교체하게 해 주는 것이다. 국가 서비스와 현대 공급업체가 이제 통합하기를 기대하는 방식과도 맞고, 주제 3.5 — 딜리버리 수명주기의 딜리버리 접근을 지원한다.

6. 지역적 해석이 아니라 공표된 프로파일과 적합성 시험을 사용하라. 표준은 유연하며, 두 팀이 "같은" FHIR 리소스를 호환되지 않게 구현할 수 있다. 세부를 못 박는 국가 구현 지침과 IHE 프로파일을 채택하고, 공급업체가 가동 전에 그에 대한 적합성을 입증하도록 요구하라. 적합성 시험은 그 자체로는 거의 아무 의미도 없는 주장인 "우리는 FHIR을 지원한다"를 검증 가능하고 계약적인 사실로 바꾼다.

7. 상호운용성과 개방형 표준 요건을 조달과 계약에 명시하라. 종속을 피하기에 가장 저렴한 때는 서명 전이다. 개방적이고 문서화된 API, 자신의 데이터를 표준 형식으로 추출할 권리, 명명된 표준의 준수, 표준 통합에 대한 비청구를 요구하라. 상업 담당 동료와 함께 이를 이후 협상으로 사라질 열망이 아니라 의무적 평가 기준으로 만들라(주제 6.3 — 조달 및 상업 계약 참조).

8. 임상 안전과 정보 거버넌스를 방 안에 두고 상호운용성을 거버넌스하라. 모든 새 데이터 흐름은 임상 위험과 기밀 정보의 처리를 바꾼다. 임상 안전 책임자와 정보 거버넌스 리드를 마지막 승인이 아니라 처음부터 설계 결정에 참여시켜, 공유 기록이 안전하고 합법적이게 하라. 이는 주제 1.6 — 임상 안전 및 위험 관리, 주제 1.7 — 정보 거버넌스, 데이터 보호 및 사이버 보안과 직접 이어진다.

팀과 논의할 질문#

1. 우리 돌봄 경로의 어디에서 빠졌거나 오해된 데이터가 오늘 가장 큰 임상 위험을 만드는가? 상호운용성 투자는 아키텍처의 유행이 아니라 해악과 가치를 따라야 한다. 가장 복잡한 환자가 실제로 거치는 여정을 지도로 그리고 정보가 사라지거나, 지연되거나, 신뢰할 만한 의미 없이 도착하는 인수인계 지점을 찾으라. 임상의에게 어디서 일상적으로 눈을 감고 일하는지 물으라. 이송, 시간외 틈, 보건과 사회적 돌봄 사이의 경계다. 데이터가 아예 흐르지 않는 곳과 흐르지만 신뢰할 수 없는 곳을 구별하라. 필요한 해결책이 다르기 때문이다. 파편화가 가장 복잡한 필요를 가진 사람들에게 가장 세게 떨어지는 경향이 있으므로 어떤 집단이 가장 영향을 받는지 생각하라. 답이 어디서 시작할지 알려 주며, 어떤 기술적 논거보다 더 무게를 지니는 임상 안전 케이스를 준다.

2. 공급업체 종속에 얼마나 노출되어 있으며, 주요 임상 시스템을 바꾸는 데 실제로 얼마가 들겠는가? 많은 조직이 폐쇄형 시스템의 진짜 가격을 떠나려 할 때야 발견한다. 데이터를 사용 가능한 표준 형태로 추출하여 다른 공급업체로 옮기는 데 무엇이 필요한지 구체적으로 따져 보라. 계약에서 데이터를 누가 소유하는지, 어떤 표준 인터페이스가 있는지, 일상이어야 할 통합에 비용이 청구되는지 검토하라. 풀어야 할 독점 인터페이스와 데이터 형식을 식별하라. 이를 대안의 개방성, 그리고 대신 재사용할 수 있는 국가 플랫폼과 견주어 따지라. 이는 공급업체를 계속 바꾸라는 것이 아니다. 자신의 영향력을 이해하고 한 공급업체의 로드맵이 유일한 선택지가 될 위험을 줄이는 것이다.

3. 우리 데이터는 안전하게 공유하기에 충분히 좋은가, 그리고 어떻게 알 수 있는가? 부실한 데이터를 공유하는 것은 창피할 뿐 아니라 오류를 다른 임상의의 결정으로 전파한다. 노출하려는 데이터의 완전성, 정확성, 적시성, 코딩 일관성을 실제로 측정하는지 물으라. 조직에서 누가 데이터 품질을 소유하는지, 원천에서 문제를 고칠 시간과 권한이 있는지 논의하라. 기록의 몇 퍼센트에 확인된 NHS Number가 있고, 임상적으로 중요한 정보의 얼마나 많은 부분이 코딩된 필드가 아니라 자유 서술에 남아 있는지 생각하라. 공유 진료 기록에 닿기 전에 체계적인 코딩 오류를 어떻게 탐지할지 생각하라. 이 질문에 증거로 답할 수 없다면 그것을 그 자체로 발견으로 다루고, 파이프를 넓히기 전에 데이터 품질 업무에 재원을 대라.

4. 공급업체가 "우리는 FHIR을 지원한다"고 말할 때, 가동 전에 실제로 어떻게 검증하는가? 표준 라벨은 특정 구현 지침에 대해 시험되기 전까지는 마케팅 주장이다. 조직에 자체 적합성 시험 역량이 있는지, 단지 공급업체의 말을 믿는지 논의하라. 두 시스템이 각각 "FHIR을 준수"하면서도 쓸 만한 메시지를 교환할 수 없을 수 있다. 표준이 의도적으로 유연하고 의미는 이를 못 박는 프로파일과 값 집합에 있기 때문이다. 해당 인터페이스에 어떤 국가 구현 지침과 IHE 프로파일이 적용되는지, 우리 쪽에서 누가 그것을 읽을 능력이 있는지 물으라. 적합성이 연결의 조건으로 계약에 쓰여 있는지, 통합 중에 고통스럽게 발견되는지 생각하라. 정직한 답은 시험할 구체적 프로파일, 시험을 실행할 사람이나 기능, 실패하는 공급업체를 통과시키지 않고 돌려보내는 일정상의 지점을 명명한다.

5. 조직 전반에서 표준, 용어, 적합성을 누가 소유하며, 아니라고 말할 권한이 있는가? 상호운용성은 스튜어드십 없이는 부패한다. 값 집합이 표류하고, 지역 지침이 갈라지며, 각 새 프로젝트가 자기만의 해석을 조용히 발명한다. 표준, SNOMED CT와 dm+d 부분 집합, 적합성에 책임지는 지정된 기능이 있는지, 이 지식이 몇몇 개인의 머릿속에 있는지 물으라. 중앙의 일관성과 지역의 딜리버리 속도 사이의 긴장을 생각하라. 압박 속의 팀은 표준 기능이 재사용을 요구할 실질적 권한이 없는 한 가장 빠른 것을 만들 것이다. 용어 유지가 화려하지 않고, 지속적이며, 어느 단일 프로젝트가 아니라 모두에게 이익이 되는데 어떻게 재원을 받는지 논의하라. FHIR, SNOMED CT, 국가 지침이 진화함에 따라 처음 채택한 버전에 얼어붙지 않고 구현을 어떻게 정렬해 유지하는지 보라. 정직한 답은 책임 있는 소유자, 그의 재원, 그가 표준을 시행했거나 시행하지 못한 최근 사례를 식별한다.

6. 우리가 기록을 연결하는 사람들은 자신의 데이터가 흐르는 방식을 알고 있으며 이에 만족하는가? 상호운용성은 기술적, 임상적 문제일 뿐 아니라 대중 신뢰와 적법 근거의 문제다. 사람들은 NHS가 이미 자신의 정보를 합리적으로 공유한다고 당연히 가정하며, 그렇지 않을 때도, 기대하지 않은 방식으로 공유될 때도 낙담한다. 환자가 어떤 조직이 자신의 공유 기록을 볼 수 있는지 이해하는지, 국가 데이터 옵트아웃이나 지역 동의 모델이 흐름 전반에서 어떻게 존중되는지, 접근이 어떻게 기록되고 감사 가능한지 논의하라. 형평성 차원을 생각하라. 데이터가 가장 파편화된 사람들 — 복잡한 필요를 가진 사람들 — 은 옵트아웃과 정보 고지를 헤쳐 나가기 가장 어려운 사람들이기도 하다. 동의를 끝에 체크하는 칸으로 다루는 대신 정보 거버넌스와, 관련된 곳에서는 환자나 그 대표를 설계에 참여시키라. 정직한 답은 각 흐름의 적법 근거, 개인이 누가 자신의 기록을 보았는지 알아내는 방법, 그들의 선택이 종단 간 어떻게 존중되는지 설명할 수 있다.

실제 사례: 보건·돌봄 예시#

잉글랜드 북부의 한 통합 돌봄 시스템은 한 환자가 서로의 기록을 볼 수 없는 팀들에게서 상호작용하는 두 약물을 처방받았음을 중대 사건 검토가 발견한 뒤, 일반의 진료소, 병원, 지역사회 약국 전반에 걸쳐 공유 약물에 대한 임상의의 단일 시야를 제공하기로 나선다.

유혹은 한 공급업체에서 "약물 대시보드"를 사서 각 시스템의 데이터베이스에 직접 연결하는 것이다. 상호운용성 책임자는 이에 저항한다. 대신 프로그램은 개방형 표준에 맞춰 구축하는 접근을 채택한다. 각 원천 시스템은 약물 데이터를 HL7 FHIR 리소스로 노출한다. 모든 의약품은 "같은 약"이 어디서나 같은 의미가 되도록 dm+d로 코딩된다. 모든 기록은 올바른 약물이 올바른 사람에게 붙도록 확인된 NHS Number를 키로 삼는다. 일반의 데이터는 맞춤 피드가 아니라 GP Connect를 통해 가져오며, 지역 역량을 발명하는 대신 국가 역량을 재사용한다.

초기 데이터 프로파일링은 즉시 값을 한다. 한 진료소의 시스템이 일부 의약품을 코딩된 dm+d 항목이 아니라 자유 서술로 기록하고 있었고, 이는 어떤 자동 상호작용 점검에도 보이지 않았을 것이다. 가동 전에 원천에서 고친다. 팀은 확인되지 않은 NHS Number가 있는 기록의 묶음도 발견하여 일치를 위해 국가 인구통계 서비스를 거치게 한다.

임상 안전 책임자와 정보 거버넌스 리드는 내내 설계 그룹의 일원이다. 함께 정확히 어떤 데이터를 누구와 어떤 적법 근거로 공유하는지, 임상의의 접근이 어떻게 기록되는지 — 주제 1.7 — 정보 거버넌스, 데이터 보호 및 사이버 보안의 관심사 — 를 정의한다. 공급업체는 연결 전에 국가 FHIR 구현 지침에 대한 적합성 시험을 통과해야 한다. 12개월 뒤 연결된 약물 시야가 라이브이며, 이전에는 놓쳤을 상호작용이 이미 포착되었고, 모든 것이 개방형 인터페이스에 맞춰 구축되었기 때문에 두 번째 사용 사례인 공유 알레르기 정보가 대부분 같은 배관을 원래 비용의 일부로 재사용한다.

부문별 관점#

스타트업#

디지털 보건 스타트업은 기존 시스템에 얼마나 쉽게 연결되느냐에 생사가 달려 있으므로, 상호운용성을 준수 잡무가 아니라 핵심 기능으로 다루라. 처음부터 FHIR API를 구축하고 SNOMED CT와 dm+d를 쓰면 구매와 통합이 훨씬 쉬워지고 신중한 NHS 구매자에게 성숙함을 알린다. 표준이 있는데 자체 데이터 모델을 발명하려는 충동에 저항하라. 차별화는 부채가 되는 독점 형식이 아니라 제품이어야 한다. NHS Number 처리와 정보 거버넌스를 일찍 제대로 하는 것이 파일럿에서 조달로 넘어가게 한다. 고객이 원칙적으로 데이터를 추출하고 떠날 수 있도록 설계하라. 역설적으로 그 개방성이 그들을 붙들어 두는 신뢰를 얻는다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉 — 는 가장 큰 트러스트와 같은 데이터 안전 공유 의무를 지지만 기술 역량은 일부다. 여기서 상호운용성은 엔지니어링이라기보다 대체로 조달과 구성의 규율이다. 이미 FHIR을 말하는 시스템을 고르고, GP Connect와 Spine 같은 국가 서비스에 연결하며, SNOMED CT와 dm+d로 기본 제공되는 코딩을 쓰라. 그러면 표준을 만들지 않고 상속한다. 확인된 NHS Number 포착을 일상 업무의 일부로 만들라. 나중에 불일치를 대조할 통합 팀이 없으므로 등록 시점에 식별자를 맞추는 것이 가장 저렴한 안전장치다. 유지할 수 없는 맞춤 연결을 의뢰하는 대신 공유 진료 기록 프로그램과 통합 돌봄 시스템의 공유 인프라에 기대라. 시스템 계약을 체결하거나 갱신할 때는 데이터 추출 권리와 개방형 인터페이스를 쉬운 말로 고집하라. 소규모 조직은 공급업체 종속을 가장 날카롭게 느끼고 사후에 벗어날 영향력이 가장 적기 때문이다.

대기업#

대형 제공자나 공급업체는 보통 수십 년의 레거시를 짊어지고 있다. HL7 v2 인터페이스, 여러 전자 기록 시스템, 이 모든 것을 묶어 두는 통합 엔진이다. 현실적인 전략은 모든 것을 뜯어내는 것이 아니라 자산 앞에 API 우선의 표준 기반 계층을 두고, 필요한 곳에서는 v2를 계속 돌리면서 흐름을 점진적으로 FHIR로 이전하는 것이다. 갱신마다 종속을 단단히 경계하고, "표준을 준수함"이 주장이 아니라 검증되도록 적합성 시험을 고집하라. 개별 프로젝트가 각자 해석을 발명하지 않도록 내부 표준 및 적합성 기능을 세우라. 이는 같은 재사용과 개방형 인터페이스의 규율이 적용되는 주제 5.4 — 전사적 자원 관리(ERP)의 핵심 운영 플랫폼 관리와 밀접하다.

정부#

국가 및 지역 기관은 시장의 규칙을 정하므로 표준에 대한 선택이 모든 조직으로 파급된다. 정부가 할 수 있는 가장 가치 있는 일은 개방형 표준을 의무화하고, 명확한 구현 지침과 적합성 요건을 공표하며, 지역 조직이 한 번 구축해 재사용하도록 재사용 가능한 국가 플랫폼 — Spine, GP Connect, 공유 진료 기록 프레임워크, NHS Number 서비스 — 을 제공하는 것이다. 일관성이 완벽함보다 중요하다. 엄격히 시행되는 충분히 좋은 표준이 모두가 다르게 구현하는 이론적으로 우월한 표준을 이긴다. 정부는 용어 유지와 데이터 품질 개선이라는 화려하지 않은 업무에도 재원을 대야 한다. 어떤 단일 조직도 혼자 재원을 대지 않는 공공재이기 때문이다. 이러한 청지기 역할은 주제 9.1 — 지방 및 중앙 정부와의 협력, 그리고 주제 9.0 — 협력 기관과의 협업에서 파트너가 협력하는 방식과 이어진다.

흔한 실패 양상#

• 기술적 연결을 의미적 이해와 혼동. 메시지가 흐를 때 승리를 선언하면서 양측이 코드, 단위, 부정을 똑같이 해석하는지 확인하지 않는다. 결과는 통합된 것처럼 보이지만 조용히 잘못 읽히는 데이터다.
• 부실한 데이터를 더 빨리 공유. 데이터 품질을 고치기 전에 파이프를 넓혀, 코딩 오류, 자유 서술, 누락된 NHS Number가 다른 임상의의 결정과 모든 하류 분석으로 전파된다.
• 빈 주장으로서의 "우리는 FHIR을 지원한다". 특정 구현 지침에 대한 적합성 시험 없이 표준 라벨을 받아들여, 두 "준수" 시스템이 여전히 서로 대화하지 못한다.
• 맞춤 점대점 통합. 시스템 쌍마다 직접 연결을 구축하여 자라면서 기하급수적으로 유지하기 어렵고 비싸지는 취약한 그물을 낳는다.
• 기본값으로서의 종속. 독점 인터페이스와 데이터 추출 권리 없는 계약에 서명하고, 공급업체를 바꾸려 할 때야 함정의 비용을 발견한다.
• 거버넌스를 최종 관문으로 취급. 임상 안전과 정보 거버넌스를 승인할 때만 들여, 문제가 늦고 비싸게 드러나거나 납기 압박 아래 통과된다.
• 스튜어드십 없는 표준. 용어와 프로파일을 채택하지만 값 집합을 유지하고, 적합성을 모니터링하고, 표준이 진화함에 따라 구현을 정렬해 유지하도록 재원을 대는 사람이 없다.

성숙도 모델#

체크리스트#

• 모든 관련 기록과 인터페이스에 확인된 NHS Number가 실려 있으며, 누락되거나 일치하지 않은 것을 해결하는 프로세스가 있다.
• 새 인터페이스는 HL7 FHIR와 명명된 국가 구현 지침을 쓰며, HL7 v2는 이전이 아직 정당화되지 않는 곳에만 유지한다.
• 임상 내용은 SNOMED CT로, 의약품은 dm+d로 합의된 값 집합에 대해 코딩한다.
• 공유하려는 모든 것의 데이터 품질이 파이프를 넓히기 전에 프로파일링, 측정, 소유되고 원천에서 개선된다.
• 공급업체는 연결 전에 특정 프로파일에 대한 적합성 시험을 통과해야 하며, "FHIR을 지원한다"만으로는 결코 받아들이지 않는다.
• 맞춤 통합을 구축하기 전에 국가 플랫폼(Spine, GP Connect, 공유 진료 기록)을 재사용한다.
• 계약이 개방적이고 문서화된 API, 표준 형식의 데이터 추출 권리, 표준 통합에 대한 비청구를 의무화한다.
• 임상 안전과 정보 거버넌스 리드가 승인 때만이 아니라 처음부터 설계 그룹에 있다.
• 아키텍처가 API 우선이며 느슨하게 결합되어, 주변 모든 것을 다시 만들지 않고 구성 요소를 교체할 수 있다.
• 지정된 기능이 조직 전반에서 표준, 적합성, 용어 유지를 소유한다.

주요 출처#

• NHS England — 상호운용성 표준, Spine, GP Connect, 공유 진료 기록 프로그램.
• HL7 International — FHIR 표준과 HL7 v2 명세.
• SNOMED International — SNOMED CT 용어 체계와 구현 지침.
• NHS Business Services Authority — Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — 상호운용성 프로파일.
• openEHR International — 건강 기록을 구조화하기 위한 개방형 명세.
• World Health Organization — 국제질병분류 (ICD-10과 ICD-11).

참고문헌#

1. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipedia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipedia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipedia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipedia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipedia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipedia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipedia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases