3.8 상호운용성과 개방형 표준

개요와 동기

상호운용성은 둘 이상의 시스템이 어느 쪽도 상대의 내부 동작을 알 필요 없이 정보를 교환하고 교환된 정보를 사용할 수 있는 능력입니다. 개방형 표준은 공개적으로 이용할 수 있고, 투명하고 합의에 기반한 과정으로 개발 및 유지되며, 구현이 무료(또는 공정하고 합리적이며 비차별적)인 명세로, 누구나 단일 벤더의 허락 없이 부합하는 시스템을 만들 수 있게 합니다. 상호운용성을 위한 설계란 맞춤형 통합, 즉 정확히 두 시스템만 잇고 어느 한쪽이 바뀔 때마다 다시 만들어야 하는 일회성 맞춤 커넥터 대신, 이런 공유되고 공개된 명세를 통해 연결되는 시스템을 만드는 것입니다.

대규모 조직에서 상호운용성은 호의가 아닙니다. 그 위에서 다른 모든 것이 돌아가는 기반입니다. 기업은 회사를 인수하고, 벤더를 교체하고, 수십 개의 내부 및 제3자 시스템을 엮으며, 개방형 표준이 새 구성 요소를 재작성 없이 끼워 넣게 해 줍니다. 정부에서는 이해관계가 훨씬 더 높습니다. 공공 서비스는 여러 기관, 정부 계층, 민간 공급자에 걸쳐 제공되며, 어떤 단일 기관도 전체 자산을 통제하지 않습니다. 급여를 신청하는 시민은 서로 다른 부서가 소유한 신원, 세금, 건강, 복지 시스템을 건드릴 수 있습니다. 그 시스템들은 상호운용되어야 하며, 아니면 서비스가 실패합니다. 공공 기관은 또한 몇 년 단위의 조달 주기로 공급자를 바꾸므로, 단일 벤더의 독점 인터페이스에 대한 어떤 의존도 길고 비싼 함정이 됩니다.

되풀이되는 실패 방식은 상호운용성의 반대인 독점 종속입니다. 조직의 데이터와 프로세스가 한 벤더의 비표준 형식과 인터페이스에 너무 얽혀서 나중에 전환하거나, 통합하거나, 데이터를 읽는 것조차 엄청나게 비싸집니다. 개방형 표준이 주된 방어입니다. 이 장은 시스템이 상호운용해야 하는 수준, 그것을 가능하게 하는 표준, 그것을 위해 설계하고, 조달하고, 인증하는 방법을 다룹니다. API와 인터페이스 설계(2.3장), 분산 시스템(3.3장), 데이터 전략과 거버넌스(7.1장), 조달과 오픈 소스(10.3장), 컴플라이언스와 거버넌스(4.6장)와 밀접하게 연결됩니다.

핵심 원칙

상호운용성은 설계에 넣는 것이지 덧붙이는 것이 아닙니다. 구축 전에 표준을 정하십시오. 사후에 도입하면 인터페이스를 다시 쓰고 데이터를 이전해야 합니다.
맞춤형 통합보다 개방형 표준을 선호하십시오. 부합하는 인터페이스는 현재와 미래의 모든 파트너를 섬기고, 맞춤 커넥터는 정확히 하나만 섬깁니다.
상호운용성에는 수준이 있습니다. 바이트를 전선 너머로 보내는 것(기술적)은 양측이 그 바이트가 무엇을 뜻하는지(의미적)에 동의하지 않으면 쓸모없습니다.
의미는 공유된 어휘에 있습니다. 식별자, 코드 체계, 용어집이 교환된 데이터를 단지 전송 가능한 것이 아니라 쓸 수 있게 만듭니다.
표준은 부합할 때만 실재합니다. 적합성 테스트 없는 ”FHIR 지원” 주장은 상호운용성이 아니라 마케팅입니다.
종속은 총소유비용의 결정입니다. 오늘의 싼 독점 선택지는 흔히 내일의 갇힌 자산입니다.
정부는 필요를 곱절로 만듭니다. 공공 서비스는 아무도 통제하지 않는 조직 경계에 걸치므로, 개방형 표준은 흔히 선호가 아니라 의무입니다.

권장 사항

상호운용성의 네 수준 모두를 위해 설계한다

유럽 상호운용성 프레임워크와 관련 모델은 네 수준을 기술하며, 시스템이 진정으로 상호운용하려면 모두를 충족해야 합니다. 기술적 상호운용성은 배관, 곧 시스템 사이에 바이트를 옮기는 네트워크, 프로토콜, 전송(예: HTTPS)입니다. 구문적 상호운용성은 구조와 형식, 곧 메시지의 문법에 대한 합의로, JSON(JavaScript Object Notation, 가벼운 텍스트 데이터 형식)이나 XML(eXtensible Markup Language) 같은 것입니다. 의미적 상호운용성은 의미에 대한 합의입니다. gender라는 필드나 코드 250.00이 양측에 같은 것을 뜻한다는 것입니다. 조직적 상호운용성은 프로세스, 거버넌스, 역할, 법적 합의의 정렬입니다. 누가 누구에게 무엇을 보낼 수 있는지, 어떤 데이터 공유 협정 아래, 어떤 목적으로. 대부분의 통합 프로젝트는 첫 두 수준은 해내고 셋째와 넷째에서 실패합니다. 의미적, 조직적 상호운용성을 사후 생각이 아니라 일급 설계 작업으로 다루십시오.

데이터 교환과 API 계층을 표준화한다

시스템이 인터페이스를 기술하고 노출하는 방식에 개방적이고 널리 구현된 표준을 채택하십시오. 웹 API(Application Programming Interface, 한 시스템이 다른 시스템을 호출하는 정의된 계약)에는 OpenAPI 명세를 쓰십시오. 인터페이스를 문서화하면서 클라이언트 코드, 서버, 테스트, 목을 생성하는 REST(Representational State Transfer) API에 대한 벤더 중립적이고 기계가 읽을 수 있는 기술입니다. 페이로드 형식에는 보편성과 사람이 읽기 쉬움 때문에 JSON을 선호하고, 생태계가 이미 XML로 표준화된 곳에서는 XML을 쓰십시오. 서비스 간 고성능의 강한 타입 통신이 필요하면 gRPC(원격 프로시저 호출 프레임워크)와, 그 자체로 개방형 명세인 컴팩트하고 스키마가 정의된 이진 형식 프로토콜 버퍼(Protobuf)를 고려하십시오. 요점은 특정 기술이 아닙니다. 계약이 공개되고, 기계가 읽을 수 있고, 독립적으로 구현 가능하다는 것입니다. 인터페이스 설계의 깊이는 2.3장을 보십시오.

도메인에서 인정된 표준을 채택한다

대부분의 분야는 도메인별 상호운용성 표준으로 수렴했습니다. 직접 발명하지 말고 그것을 쓰십시오. 의료가 대표적인 예입니다. HL7(Health Level Seven, 표준 기구와 그 옛 메시징 표준)은 새 작업에서 대체로 FHIR(Fast Healthcare Interoperability Resources)로 대체되었는데, 이는 임상 개념(환자, 관찰, 약물)을 JSON이나 XML을 쓰는 REST API로 교환되는 웹 자원으로 모델링하는 현대적 표준입니다. 금융에서 ISO 20022는 구조화되고 풍부하게 주석이 달린 결제 및 금융 메시징의 개방형 표준으로, 이제 전 세계 결제 시스템이 채택하고 있습니다. 지리공간 데이터에서 OGC(Open Geospatial Consortium)는 지도 및 피처 서비스를 위한 WMS와 WFS 같은 표준을 발행합니다. 다른 예로 비즈니스 문서를 위한 OASIS와 UBL, 건설을 위한 IFC(BuildingSMART)가 있습니다. 인정된 표준을 고르면 부합하는 도구, 공급자, 훈련된 인력의 전체 생태계를 삽니다.

의미를 식별자, 코드 체계, 온톨로지에 고정한다

의미적 상호운용성은 공유된 어휘를 요구합니다. 같은 현실 세계의 사물이 어디서나 같은 참조를 갖도록 표준 식별자(예: ISO 국가 코드, 법인을 위한 LEI, 국가 환자 식별자)를 쓰십시오. 자유 텍스트 대신 공개된 코드 체계와 용어집(정의된 의미를 가진 코드화된 개념의 통제된 목록)을 쓰십시오. 임상 용어에는 SNOMED CT와 LOINC, 진단에는 ICD(국제 질병 분류), 텍스트에는 Unicode입니다. 개념 간의 관계가 중요한 곳에서는 RDF와 OWL(W3C Web Ontology Language) 같은 표준으로 표현된 온톨로지(개념과 그 관련 방식에 대한 형식적이고 기계가 읽을 수 있는 모델)를 쓰십시오. 이런 어휘의 거버넌스는 데이터 거버넌스의 책임입니다. 7.1장을 보십시오.

점대점 배선이 아니라 표준 기반 패턴으로 통합한다

통합의 수를 조합적이 아니라 선형으로 유지하는 아키텍처 패턴을 선호하십시오. 점대점으로 엮인 N개 시스템은 최대 N×(N−1)/2개의 맞춤 커넥터가 필요할 수 있습니다. 공유 표준에 각각 부합하는 같은 N개 시스템은 그 표준의 구현 N개만 필요합니다. 게이트웨이, 공개된 API 계약, 정준 데이터 모델을 써서, 새 참여자가 모든 기존 시스템에 맞추지 않고 표준에 대해 한 번 통합하게 하십시오. 이는 종속의 해독제이기도 합니다. 계약이 개방적이므로 벤더를 그에 연결된 모두를 건드리지 않고 교체할 수 있습니다.

적합성과 인증을 요구한다

표준은 구현이 실제로 부합할 때만 가치를 전달합니다. 공개된 테스트 스위트와 검증기(예: FHIR 검증기와 Touchstone 테스트, 또는 빌드 파이프라인의 OpenAPI 스키마 검증)를 써서 적합성 테스트(구현이 명세를 충족하는지 확인하는 자동화된 검사)를 고집하십시오. 공식 인증 프로그램(국가 의료 IT 인증 제도처럼 독립 기관이 적합성을 증명)이 있는 곳에서는 인증된 제품을 선호하고 계약에서 인증을 요구하십시오. 적합성 검사를 지속적 통합에 넣어, 표준에서 벗어난 표류가 프로덕션에서 드러나는 대신 빌드를 실패시키게 하십시오.

장단점

접근 방식	장점	단점 / 비용
개방형 표준	많은 공급자. 종속 없음. 생태계 도구. 미래 파트너가 싸게 통합	표준이 넓거나 복잡할 수 있음. 틈새 기능 채택이 느림. 위원회 속도의 진화
맞춤형 점대점 통합	첫 연결이 빠름. 정확히 맞음. 초기 학습 최소	비용이 조합적으로 증가. 취약. 변경마다 다시 함. 종속을 낳음
독점 벤더 형식/API	풍부한 기능. 벤더 지원. 한 생태계 안에서 빠른 시작	종속. 전환 비용. 나중에 데이터를 빼내기 어려움. 가격 결정력이 벤더에게 이동
도메인 표준 (FHIR, ISO 20022)	공유된 의미. 훈련된 인력. 규제 기관과 정렬	학습 곡선. 레거시 데이터 매핑. 버전과 프로파일 관리 오버헤드

핵심 트레이드오프는 단기 편의 대 장기 선택 가능성입니다. 맞춤형이나 독점 통합은 가장 첫 연결에는 거의 항상 세우기가 더 빠르며, 그래서 조직은 합리적인 결정 하나씩으로 종속으로 표류합니다. 개방형 표준은 비용을 앞에 몰아(명세 학습, 기존 데이터 매핑, 적합성 테스트 구축) 새 파트너, 공급자, 시스템이 재작성 없이 합류할 때마다 갚습니다. 수명이 길고 참여자가 많은 시스템, 곧 거의 모든 기업과 정부 플랫폼에는 표준 기반의 길이 결정적으로 이깁니다. 정말 버릴 일대일 연결이라면 맞춤형이 합리적일 수 있습니다. 실수는 장수하는 플랫폼을 버릴 연결처럼 다루는 것입니다.

팀과 논의할 질문

기술적 통합이 의존하는 조직적 상호운용성(데이터 공유 협정, 동의 모델, 프로세스 정렬)은 누가 소유합니까? 대부분의 프로젝트는 기술적, 구문적 수준은 해내고 조직적 수준에서 멈춥니다. 바이트는 도착해 파싱되지만, 누가 누구에게 무엇을, 어떤 목적으로, 어떤 동의 아래 보낼 수 있는지를 다스리는 합의가 없습니다. 정부에서 시민의 데이터는 각자 시스템을 소유하고 서로 다른 법적 근거에 답하는 기관들을 가로지르므로, 공유 협정과 동의 모델이 존재하기 전에는 완벽한 FHIR 인터페이스도 쓸모없습니다. 가장 중요한 경계 간 교환을 가져와 API만이 아니라 법적 문서와 각 측의 책임 소유자를 지명하십시오. 그 소유자가 지명되지 않았다면 통합은 모든 기술 테스트를 통과하고도 프로덕션에서 막힐 것입니다. 이런 협정을 메시지 스키마와 같은 엄밀함으로 설계 산출물로 다루십시오.
표준의 독점 확장에 얼마나 크게 기대며, 다른 부합하는 구현이 여전히 여러분과 대화할 수 있습니까? 표준에는 탈출구가 있고, 그것의 남용은 개방형 배지를 단 사실상의 종속입니다. FHIR이나 ISO 20022를 지원한다고 주장하지만 어떤 독립 벤더도 여러분의 방언과 실제로 상호운용할 수 없습니다. 이것은 합리적인 맞춤화 하나씩 스며들므로 큰 자산은 이를 의도적으로 측정해야 합니다. 실제 메시지를 가져와 그 의미 중 얼마가 표준 필드에 실리고 얼마가 맞춤 확장에 실리는지 세어 보십시오. 맞춤 비중이 높을수록 이식성이 약하고 기존 벤더의 가격 결정력이 강합니다. 사적 확장보다 표준의 규칙 안에서 프로파일링하고 간극을 표준에 되돌려 기여하는 쪽을 선호하십시오. 개방형 길의 요점은 벤더를 그에 연결된 모두를 건드리지 않고 교체할 수 있다는 것이며, 확장은 이를 조용히 침식합니다.
각 표준의 어느 버전과 프로파일을 쓰며, 자산 전반에 걸쳐 그 선택은 누가 다스립니까? “표준을 지원한다”는 버전과 프로파일 규율 없이는 의미가 없습니다. 두 시스템이 모두 FHIR이나 ISO 20022를 주장해도 다른 버전이나 프로파일을 구현하면 대화하지 못할 수 있기 때문입니다. 많은 공급자와 긴 조달 주기를 가진 대규모 조직에서 버전은 통합이 깨질 때까지 조용히 갈라집니다. 모든 인터페이스, 그 표준, 버전, 프로파일의 목록을 가져오고, 그것들을 정렬해 유지하고 업그레이드를 계획할 책임자를 지명하십시오. 버전과 프로파일을 파이프라인의 적합성 테스트에 넣어, 표류가 프로덕션에서 드러나는 대신 빌드를 실패시키게 하십시오. 이런 거버넌스가 없으면 명목상 부합하는 시스템도 상호운용할 수 없으며, 이것이 바로 개방형 표준이 막으려던 실패입니다.
계약이나 공급자가 “표준을 지원한다”고 말할 때, 어떤 독립적 테스트가 그것을 입증하며 그 테스트는 어디서 실행됩니까? 테스트 없는 적합성 주장은 마케팅이며, 최악의 장소에서 실패합니다. 돈이 오가고 시스템이 가동 중인 프로덕션에서입니다. 많은 공급자에게서 구매하는 대규모 조직에서 유혹은 설문지의 체크박스를 받아들이는 것입니다. 검증된 적합성을 고집하면 조달이 느려지고 입찰자 풀이 좁아지기 때문입니다. 의존하는 각 표준의 공개된 검증기나 테스트 스위트(예: FHIR 검증기와 Touchstone, 또는 OpenAPI 스키마 검증), 그것을 통과시킨 실제 메시지 표본, 인수와 지불을 그 통과에 묶는 계약 조항을 가져오십시오. 상충하는 끌림은 속도 대 증명입니다. 인증된 제품은 비용이 더 들고 온보딩이 오래 걸릴 수 있지만, 검증되지 않은 것은 실패를 통합 팀에 전가합니다. 국가 의료 IT나 결제 인증 제도가 존재하는 정부와 규제 환경에서는 계약에서 인증을 요구하고 검증기를 지속적 통합에 연결해 표류가 빌드를 실패시키게 하십시오. 테스트하지 않은 주장은 감사나 장애 중에 발견할 부채이기 때문입니다.
통합 중 얼마나 많은 것이 여전히 점대점이며, 그렇게 두는 것의 진정한 조합적 비용은 무엇입니까? 맞춤형 일대일 커넥터는 첫 링크에는 만들기 가장 빠르고 자산 전체에서는 소유하기 가장 비싼 것입니다. 수가 N×(N−1)/2로 향해 커지는 반면 공유 표준은 구현 N개만 필요하기 때문입니다. 대규모 조직에서 이 난립은 합리적인 결정 하나씩 쌓여 통합 지도가 유지할 수 없게 되고 모든 시스템 변경이 열두 개의 취약한 커넥터로 파급될 때까지 갑니다. 점대점 대 표준 기반으로 분류한 통합 목록, 마지막 주요 시스템 교체가 건드린 커넥터 수, 맞춤 링크 유지에 쓴 엔지니어링 시간의 추정을 가져오십시오. 긴장은 가동 중인 점대점 배선을 게이트웨이나 정준 모델 뒤로 이전하는 것이 즉각적인 기능 수익이 없는 실제 작업이어서, 누군가 유지 비용을 정량화하지 않는 한 로드맵에 진다는 점입니다. 수십 년 살며 계속 참여자를 더하는 기업과 정부 플랫폼에서 점대점 경로는 느린 세금입니다. 통합 아키텍처의 소유자를 지명하고, 새 참여자를 모든 기존 시스템에 맞추는 대신 표준을 통해 라우팅할 계획을 세우십시오.
공개된 코드 체계나 용어집이 실어야 할 의미를 어디서 자유 텍스트로 전달하고 있으며, 그 어휘는 누가 다스립니까? 의미적 상호운용성은 대부분의 통합이 조용히 실패하는 곳입니다. 바이트는 도착해 파싱되지만, 제약 없는 문자열로 저장된 진단, 통화, 국가는 발신자에게 하나를, 수신자에게 미묘하게 다른 것을 뜻합니다. 대규모 조직에서 비용은 보고, 분석, 규제 기관이 같은 개념이 세 시스템에서 세 가지로 코드화되었음을 드러낼 때까지 보이지 않습니다. 현재 자유 텍스트로 있는 필드의 예, 그것을 대체할 수 있는 표준 식별자와 코드 체계(임상 데이터에는 SNOMED CT와 LOINC, 국가와 통화에는 ISO 코드, 법인에는 LEI), 자유 텍스트가 숨기고 있는 오류율이나 조정 노력을 가져오십시오. 상충하는 고려는 레거시 데이터를 통제된 어휘로 매핑하는 일이 고되고 시연되지 않아 전송 계층에 비해 만성적으로 재원이 부족하다는 점입니다. 시민의 기록이 많은 독립 시스템에서 조립되고 일치하지 않는 코드 하나가 급여를 거부하거나 건강 기록을 손상시킬 수 있는 정부에서는, 어휘 거버넌스를 각 팀에 맡긴 구현 세부가 아니라 이름 붙은 데이터 거버넌스 책임(7.1장)으로 다루십시오.

분야별 관점

스타트업. 속도가 이기며, 개방형 표준은 아주 작은 팀이 많은 커넥터를 만들지 않고 많은 고객에게 닿는 방법입니다. 모든 파트너가 이미 지원하는 형식(로그인에 OAuth, 일정에 iCalendar, 이벤트에 웹훅, OpenAPI 계약 위의 JSON)을 쓰면, 하나의 통합이 수천 고객에게 닿고 벤더 교체가 어댑터 하나만 건드립니다. 자체 형식을 발명하거나 각 고객의 스택을 손으로 엮는 것은 피하십시오. 인력을 댈 수 없는 미래의 유지보수입니다. 표준의 길은 약간 더 선행 비용이 들지만 아직 예측할 수 없는 시장에서 전환을 싸게 유지합니다.

소기업. 통합 전문가도 빠듯한 예산도 없으니 상호운용성을 구축 프로젝트가 아니라 구매 결정으로 다루십시오. 분야의 개방형 표준을 이미 쓰고 문서화된 API를 노출하는 도구를 선호해, 공급자를 바꿔도 데이터가 이식 가능하게 유지하십시오. 서명하기 전에 벤더에게 데이터를 어떻게 어떤 형식으로 빼낼 수 있는지 물으십시오. 오늘의 싼 독점 선택지는 내일의 갇힌 자산이기 때문입니다. 적합성 테스트를 직접 돌리는 일은 드물 것이므로, 인증되었거나 널리 상호운용되는 제품에 기대십시오.

대기업. 과제는 많은 팀, 공급자, 긴 조달 주기에 걸쳐 상호운용성을 다스리는 것입니다. 도메인 표준(FHIR, ISO 20022, OGC)과 공개된 OpenAPI 계약을 의무화하고, 명목상 부합하는 시스템이 갈라지지 않도록 모든 인터페이스의 버전, 프로파일, 책임 소유자를 담은 목록을 유지하십시오. 새 참여자는 점대점 배선이 아니라 게이트웨이와 정준 모델을 통해 라우팅하고, 적합성 검증을 지속적 통합에 연결하고, 트래픽 중 얼마가 표준 필드에 실리고 얼마가 독점 확장에 실리는지 측정하십시오. 종속과 이식성을 우연이 아니라 의도적인 총소유비용 입장으로 관리하십시오.

정부. 개방형 표준은 흔히 의무입니다. 공공 서비스가 어떤 단일 기관도 통제하지 않는 기관들에 걸치고 공급자가 여러 해 주기로 바뀌기 때문입니다. 모든 계약에서 적합성 테스트와, 제도가 있는 곳에서는 국가 인증을 요구하고, 떠나는 벤더가 공공의 데이터를 볼모로 삼지 못하도록 데이터 이식성을 요구하십시오. 시민의 기록이 부서 전반에서 같은 것을 뜻하도록 의미를 국가 식별자와 공개된 용어집에 고정하고, 조직적 상호운용성은 책임 소유자를 지명한 명시적 데이터 공유 협정과 동의 모델로 처리하십시오. 투명성과 공공 재정 모두 어떤 독점적 편의보다 개방적이고 독립적으로 구현 가능한 길을 지지합니다.

사례

스타트업. 팀 생산성 앱을 만드는 작은 스타트업은 맞춤형 커넥터 대신 개방형 표준으로 고객의 기존 도구에 연결합니다. 로그인에 OAuth, 일정에 iCalendar, 이벤트에 웹훅입니다. 모든 캘린더와 신원 제공자가 이미 지원하는 형식을 쓰므로 하나의 통합이 한 곳이 아닌 수천 고객에게 닿고, 나중에 결제나 이메일 벤더를 바꿔도 어댑터 하나만 건드립니다. 각 고객의 스택에 맞춤 링크를 손으로 만들었다면, 새 고객사마다 쓰고 유지할 커넥터가 하나씩 늘었을 것입니다.

대기업. 한 다국적 은행이 레거시 독점 메시지 형식에서 ISO 20022로 이전하여 국경 간 결제를 현대화합니다. 표준이 자유 텍스트가 아닌 구조화되고 풍부하게 주석이 달린 데이터(지불인, 수취인, 목적, 규제 필드)를 담기 때문에, 사기 심사, 조정, 보고용 다운스트림 시스템은 열두 개의 맞춤 파서 대신 하나의 정준 형식을 소비합니다. 은행이 나중에 결제 게이트웨이 벤더를 교체할 때 새 공급자는 이미 ISO 20022를 쓰므로, 전환은 그 뒤의 백 개 시스템이 아니라 게이트웨이만 건드립니다. 개방형 표준이 벤더 이전을 여러 해짜리 재구축에서 한정된 교체로 바꾸었습니다.

정부. 한 국가 보건 서비스는 병원, 의원, 검사실, 환자용 앱(20년에 걸쳐 서로 다른 공급자가 구축)이 기록을 안전하게 공유하기를 필요로 합니다. 데이터 교환에 FHIR를 의무화합니다. 각 시스템이 환자, 관찰, 약물 데이터를 REST API 위의 FHIR 자원으로 노출하고, 표준 식별자(국가 환자 ID)와 임상 용어집(질환에 SNOMED CT, 검사 결과에 LOINC)을 써서 코드가 어디서나 같은 것을 뜻하게 합니다. 공급자는 연결하기 전에 FHIR 적합성 검증을 통과하고 국가 의료 IT 인증을 보유해야 합니다. 새 의원 시스템은 모든 기존 시스템에 맞춤 링크를 만드는 대신 FHIR 표준에 대해 한 번 통합하며, 시민은 많은 독립 시스템에서 조립된 통합 기록을 볼 수 있습니다. 조직적 상호운용성은 누가 무엇을 왜 접근할 수 있는지를 다스리는 데이터 공유 협정으로 처리되어 컴플라이언스 의무(4.6장)를 충족합니다.

비즈니스 사례: 동기, ROI, TCO

개방형 표준의 재무적 논거는 첫 통합의 정가가 아니라 시스템 수명에 걸친 총소유비용(TCO)에 관한 논거입니다. 맞춤형 통합 비용은 연결의 수에 비례해 커지고 변경마다 다시 치릅니다. 표준 기반 통합 비용은 참여자당 한 번 치르고 전체 자산에 걸쳐 상각됩니다. 투자 수익(ROI)은 통합 노동의 감소, 새 파트너와 공급자의 더 빠른 온보딩, 벤더가 부진할 때 더 낮은 전환 비용, 경쟁자가 입찰할 수 없으므로 단독 공급자가 가격을 올리는 전형적 종속세의 회피로 나타납니다.

리더십에게는 선택 가능성과 경쟁을 중심으로 논거를 세우십시오. 개방형 표준은 조달을 경쟁적으로 유지합니다(10.3장). 인터페이스가 공개되고 적합성이 테스트되면 여러 벤더가 동등한 조건으로 입찰할 수 있어, 연속된 계약에 걸쳐 가격은 내리고 품질은 올라갑니다. 또한 미래의 위험을 낮춥니다. 데이터와 인터페이스가 이식 가능하면 규제 변화, 합병, 현대화 프로그램이 모두 더 싸지기 때문입니다. 표준을 무시하는 것의 가장 큰 숨은 비용은 결국의 강제 이전입니다. 원래 벤더가 사라졌거나 비협조적일 때 사후에 독점 형식에서 데이터를 추출하는 일은 일상적으로 표준 기반 설계가 선행으로 들었을 비용의 여러 배가 듭니다. 정부는 이를 점점 인식하고 수십 년에 걸친 종속으로부터 공공 재정을 보호하려고 정확히 그 때문에 개방형 표준을 의무화합니다.

안티패턴과 함정

전체 일로 오인된 기술적 상호운용성. 메시지는 도착해 파싱되지만 양측이 필드가 무엇을 뜻하는지에 동의하지 않아 데이터가 조용히 틀리는 것.
이름뿐인 “표준 기반”. 제품이 표준을 지원한다고 주장하지만 적합성 테스트를 통과한 적이 없고 실제로는 어긋나는 것.
코드 체계가 있는데 자유 텍스트. 진단, 통화, 국가를 제약 없는 문자열로 저장해 의미적 상호운용성을 파괴하는 것.
표준을 삼키는 독점 확장. 표준의 탈출구를 너무 많이 써서 다른 어떤 구현도 상호운용할 수 없게 하는 것. 개방형 배지를 단 사실상의 종속.
점대점 난립. 통합 지도가 유지할 수 없는 조합적 난장판이 될 때까지 매번 맞춤 커넥터를 하나 더하는 것.
버전과 프로파일의 혼란. 표준의 어느 버전이나 프로파일이 쓰이는지 거버넌스가 없어 명목상 부합하는 시스템도 여전히 대화하지 못하는 것.
조직적 상호운용성 무시. 데이터 공유 협정, 동의 모델, 프로세스 정렬이 없어 완벽한 기술적 교환이 막히는 것.
자체 표준 만들기. 성숙하고 채택된 도메인 표준이 이미 있는데 맞춤 형식을 발명하고 그 모든 유지보수를 영원히 물려받는 것.

성숙도 모델

1단계: 시작. 통합이 즉흥적이고 점대점입니다. 형식은 독점적이거나 문서화되지 않았습니다. 의미는 자유 텍스트와 암묵지로 전달됩니다. 어떤 시스템이나 벤더를 교체하든 큰 프로젝트입니다. 종속이 만연하고 대체로 인식되지 않습니다.
2단계: 발전. JSON이나 XML 같은 공통 형식이 나타나고 일부 API가 문서화되지만, 실천은 팀마다 다릅니다. 상호운용성은 여전히 대부분 구문적이며, 의미적 합의는 일관되지 않고 프로젝트별입니다. 표준은 반응적으로 선택되고, 적합성은 주장되지만 테스트되지 않습니다.
3단계: 표준화. 개방형 데이터 교환 표준(OpenAPI, 그리고 FHIR이나 ISO 20022 같은 관련 도메인 표준)이 조직 전체에 문서화되고 의무화됩니다. 공유 식별자, 코드 체계, 용어집이 의미적 상호운용성을 제공합니다. 적합성 테스트가 전달 파이프라인의 일부이고, 통합은 점대점 배선이 아니라 표준 기반 패턴을 따릅니다.
4단계: 관리. 상호운용성이 기준선에 대해 측정되고 통제됩니다. 표준 기반 대 점대점 통합의 비율, 표준 필드 대 독점 확장에 실린 메시지 의미의 비중, 파이프라인의 적합성 테스트 통과율, 자산 전반의 버전과 프로파일 표류, 새 참여자 온보딩의 통합 리드 타임과 결함률이 추적되고 검토됩니다. 버전과 프로파일이 다스려지고, 공급자에게 인증이 요구되고 검증되며, 종속 위험은 느낌이 아니라 정량화됩니다. 인터페이스를 채택, 업그레이드, 퇴역시키는 결정은 이 증거에 근거합니다.
5단계: 오케스트레이션. 상호운용성이 조직 전체에서 지속적으로 개선되고 통합됩니다. 조직적 상호운용성(협정, 동의, 프로세스 정렬)이 기술 계층과 함께 체계적으로 처리되고, 조직은 의존하는 표준에 되돌려 기여하며, 이식성은 영구적인 설계 제약입니다. 자산은 표준이 진화하고 참여자가 합류하거나 떠남에 따라 적응하며, 사고가 아니라 측정된 증거에 따라 통합 아키텍처와 어휘 거버넌스를 재균형합니다.

논의를 위한 아이디어

가장 핵심적인 데이터 교환은 네 수준(기술적, 구문적, 의미적, 조직적) 중 오늘 어디가 가장 약합니까?
주요 벤더가 갱신 시 가격을 두 배로 올린다면 전환하는 데 얼마나 오래, 얼마나 비용이 들며, 무엇이 그렇게 만듭니까?
통합 중 어느 것이 점대점이며, 그것을 공유 개방형 표준 뒤로 옮기려면 무엇이 필요합니까?
공개된 코드 체계나 용어집이 대체할 수 있는 자유 텍스트를 어디에 저장하고 있으며, 그 자유 텍스트는 어떤 오류를 숨기고 있습니까?
계약의 “표준을 지원한다”는 독립적인 적합성이나 인증 테스트 통과를 요구합니까, 아니면 단지 주장됩니까?
어떤 개방형 표준 의무(국가 또는 분야)가 이미 적용되며, 실제로 충족하고 있습니까 아니면 충족한다고 주장만 합니까?

핵심 요점

상호운용성은 교환된 정보를 단지 전송하는 것이 아니라 사용하는 것을 뜻합니다. 네 수준, 곧 기술적, 구문적, 의미적, 조직적 수준 모두를 위해 설계하십시오.
종속과 조합적 비용을 낳는 맞춤형 통합과 독점 형식보다 개방적이고, 공개되고, 독립적으로 구현 가능한 표준을 선호하십시오.
API와 데이터 교환 계층(OpenAPI, JSON/XML, gRPC/Protobuf)을 표준화하고 도메인의 인정된 표준(의료의 FHIR, 금융의 ISO 20022, 지리공간의 OGC)을 채택하십시오.
의미를 공유된 식별자, 코드 체계, 용어집, 온톨로지에 고정하십시오. 의미적 상호운용성은 대부분의 통합이 조용히 실패하는 곳입니다.
적합성 테스트와, 가능한 곳에서는 인증을 요구하십시오. 표준은 구현이 입증 가능하게 부합할 때만 실재합니다.
선택을 시스템 수명에 걸친 총소유비용과 선택 가능성으로 판단하십시오. 장수하고 다자간인 플랫폼(거의 모든 기업과 정부 시스템)에서는 개방형 표준이 이기며, 정부는 점점 이를 의무화합니다.

참고 문헌과 더 읽을거리

HL7 International, FHIR (Fast Healthcare Interoperability Resources) specification (hl7.org/fhir)
ISO 20022, Universal financial industry message scheme (iso20022.org)
OpenAPI Initiative, OpenAPI Specification (Linux Foundation)
Open Geospatial Consortium (OGC) standards (WMS, WFS, and successors)
European Commission, European Interoperability Framework (EIF) and the Interoperable Europe Act
UK Government, Open Standards Principles and the Technology Code of Practice (GOV.UK)
W3C, RDF, OWL (Web Ontology Language), and semantic-web standards
SNOMED International (SNOMED CT), Regenstrief Institute (LOINC), and WHO (ICD) terminologies
gRPC and Protocol Buffers specifications (Cloud Native Computing Foundation / open source)
NIST and IEEE literature on systems interoperability and conformance testing