우리가 진료 전 증상 스키마를 오픈소스로 공개한 이유 — 이해관계자 매핑에서 26개의 변호사 확인 결론까지

불편한 관찰에서 시작합니다

솔직히 말해, 현재 "구조화된 진료 전 증상 문진표" 기능을 실제 제품으로 제공하는 임상 소프트웨어 회사는 많지 않아 보입니다. iRehab은 그중 하나입니다. 저희가 확인한 범위에서는 한국, 대만, 글로벌 시장 모두에서 이 문제를 정확히 같은 방식으로 다루는 사례를 찾기 어려웠습니다.

그렇다면 아직 문제가 나타나지 않았다는 뜻일까요? 아닙니다. 이 문제는 곧 본격적으로 나타날 가능성이 높다는 뜻입니다.

의료 IT의 역사를 보면 같은 패턴이 반복되어 왔습니다. 각 병원은 자체 전자의무기록(EMR) / 병원정보시스템(HIS)을 구축했고, 구조가 서로 맞지 않았으며, 수십 년에 걸친 통합 부채가 뒤따랐습니다. 한국은 높은 EMR 보급률을 갖고 있지만, 대형 상급종합병원과 이른바 "빅5" 병원을 중심으로 한 시스템 집중, 병원별 벤더 구조, 폐쇄적 데이터 포맷 때문에 실제 상호운용성(interoperability)은 여전히 제한적입니다. 2020년 이후 MyData, 의료마이데이터, 의료데이터 중심병원 사업이 표준화와 본인주도 데이터 활용을 밀어붙이고 있지만, 벤더 종속(lock-in)은 아직 강하게 남아 있습니다.

"구조화된 진료 전 문진"이 다음 세대의 보편적 임상 소프트웨어 기능이 된다면, 그리고 AI 확산을 고려하면 그 가능성은 매우 높습니다. 같은 단편화 패턴이 다시 반복될 수 있습니다.

각 벤더가 먼저 자기 방식대로 만듭니다(초기 3년)
경쟁 압력 때문에 표준화 논의가 시작됩니다(5-7년)
그러나 그때는 이미 내부 스키마가 굳어 있고, 통합 부채가 쌓였으며, 마이그레이션 비용이 커져 있습니다

저희는 이 흐름을 실제로 관심을 가질 이해관계자(stakeholder)와 함께 매핑했습니다. HIS 벤더, 제3자 예약 플랫폼, 전문 학회, 개별 전문의, 학술 인용자, 의료기기 및 민간보험 파트너 등입니다. 각 집단은 결국 어떤 형식(format)을 필요로 하게 됩니다. 그러나 독점적(proprietary) 체계에서의 협업은 양쪽 모두에게 마찰이 크고, 느리며, 비쌉니다.

단일 벤더가 양자 간 사업개발(BD)로 이를 해결하려면 10배의 자원이 들고, 그래도 실패할 가능성이 높습니다.

그래서 저희는 모두가 각자 다시 만들고 나중에 협상하기를 기다리는 대신, 지금 참고 형식을 공개하여 논의의 출발점으로 올려두기로 했습니다.

이 청사진이 최종 표준이 되지 않을 수도 있습니다. 그러나 최소한 논의를 테이블 위로 올려놓습니다.

하나의 프레임워크: 분배기와 엔진

Brief 기능을 분해하면 두 개의 층이 보입니다.

"형식" 층은 JSON 스키마, 필드 정의, 적색 경고(red-flag) 모듈의 트리거 지점입니다. 기술적으로 특별히 대단한 것은 아닙니다. FHIR Questionnaire 리소스 명세를 읽어본 사람이라면 주말 동안 재현할 수 있는 층입니다.

"로직" 층이 실제 작업이 존재하는 곳입니다. 적색 경고 파이프라인이 어떻게 판단하는지(임계값, 가중치, 에스컬레이션 문구), AI SOAP 통합을 어떻게 프롬프트하고 조정하는지, 의사의 오버라이드 말뭉치가 어떻게 축적되는지, Composer 편집기가 의사의 저작 경험을 어떻게 설계하는지가 여기에 해당합니다.

이 두 층은 역사적으로 함께 묶여 판매되었습니다. SaaS의 본능은 "전부 판매"이기 때문입니다. 그러나 묶음 판매에는 비용이 있습니다. 어떤 HIS 벤더가 여러분의 형식을 네이티브로 지원하려면 라이선스를 체결하고, 로열티를 지불하고, 법무 검토를 통과해야 합니다. 마찰이 너무 높으면 아무도 움직이지 않습니다.

두 층을 분리하는 순간 전략은 명확해집니다.

형식은 열 수 있습니다. 로직은 영원히 닫아둡니다.

형식은 분배기입니다. 로직은 엔진입니다. 엔진은 닫아두어 상업적 해자를 지키고, 분배기는 무료로 공개하여 채택을 증폭시킵니다.

공개가 가능하게 만드는 것

형식이 공개되면 다음 일들이 구조적으로 가능해집니다. "조금 더 쉬워지는" 것이 아니라, 독점 조건에서는 사실상 불가능했던 일이 가능해집니다.

HIS 벤더가 스키마를 읽고 네이티브 통합을 구현할 수 있습니다. NDA도, 로열티도, 법무 검토도 필요 없습니다
제3자 플랫폼이 형식 상호성(format reciprocity)을 구현할 수 있습니다. "당신의 문진표와 나의 문진표를 같은 파서가 읽을 수 있다"는 것은 독점 조건에서는 불가능합니다
외부 의사가 pull request를 통해 전문과별 팩을 기여할 수 있습니다. 산부인과, 신경과, 정신건강의학과, 재활의학과 등이 가능합니다. 폐쇄형 소스에서는 이런 기여 채널 자체가 존재하지 않습니다
학술 논문이 스키마를 인용 가능한 표준(citable standard)으로 인용할 수 있습니다

이 각각은 양자 간 사업개발 방식에서는 10배 이상의 비용과 높은 실패율을 동반합니다. 오픈소스화는 "우리가 밀어야 하는 일"을 "그들이 올 수 있는 구조"로 바꿉니다.

무엇은 영원히 닫혀 있는가

경계는 명시적이어야 합니다. 그렇지 않으면 오픈코어(open-core) 전략은 쉽게 "아직 충분히 공개하지 않았을 뿐"이라는 도전을 받습니다.

다음 여섯 가지 구성요소는 절대로 이 저장소에 들어가지 않습니다. 이는 LICENSE_STRATEGY.md §6에 문서화되어 있습니다.

적색 경고 파이프라인 내부 로직(임계값, 가중치, 점수 알고리즘, 다중 문항 조합 규칙, 에스컬레이션 문구) — 이는 의료 판단 로직입니다. 공개하면 품질 관문을 잃고, 동시에 저희의 실제 해자도 사라집니다
AI SOAP 통합 프롬프트와 튜닝 — 프롬프트 엔지니어링(prompt engineering)은 계속 진화하는 상업적 지식재산(IP)입니다
환자 개인식별정보(PII) 처리 코드 — 개인정보 보호 컴플라이언스는 가볍게 다룰 수 없습니다. 오픈소스 수정은 곧 컴플라이언스 감사를 유발합니다
iRehab Doctor PWA UI / UX — 워크플로 설계는 상업적 차별화입니다
Outcome registry 데이터 파이프라인 — B2B 매출 흐름의 핵심입니다
Composer, 즉 스키마 저작용 GUI 편집기 — 의사 경험의 핵심 차별화 요소입니다

더 중요하게는, 각 의원, 병원, 서비스 제공자가 이 영역에서 필요로 하는 것이 너무 다릅니다. 저희는 이런 결정을 한 벤더가 중앙집중적으로 정해서는 안 된다고 봅니다. 각 조직과 그 조직의 AI가 스스로 구축하도록 두는 것이 더 건강한 설계입니다.

이중 라이선스 구조

Content	License
Schema files (`spec/v0.1/schema/*.json`), validator code	Apache-2.0 (with patent grant)
Spec documents, examples, tutorials, README	CC BY 4.0 (commercial use / adaptation / redistribution permitted with attribution)

두 라이선스는 서로 바꿔 쓸 수 없습니다. 인용할 때는 파일 유형에 따라 올바른 라이선스를 적용해야 합니다.

이 조합은 의도적입니다. Apache-2.0의 명시적 특허 허여 조항(patent grant)은 스키마 검증기를 채택하는 HIS 벤더와 제3자 플랫폼에 강한 보호를 제공합니다. CC BY 4.0은 오픈 콘텐츠 라이선스의 국제 표준이며, 학술 인용자에게 가장 익숙한 방식입니다.

왜 준거법은 Republic of China (Taiwan)인가

라이선스 제공자는 대만 회사인 De Novo Orthopedics 谷盺生物科技股份有限公司입니다. 상표는 대만에 등록되어 있습니다. "iRehab 愛復健 with logo"는 Nice 9/10/35/44류를, "DE NOVO ORTHOPEDICS / 谷盺生物科技"는 5/9/10/35/42/44류를 포괄합니다. 책임과 분쟁 해결은 대만을 통해 처리하는 것이 가장 직접적입니다.

해당 선언은 저장소와 README에 포함되어 있습니다. 이는 Apache-2.0 / CC BY 4.0 라이선스 문구 자체를 수정하지 않습니다. 두 라이선스 모두 문구 수정을 금지합니다. 대신 라이선스 제공자의 "준거법 선언(governing law statement)"으로 기능합니다. 즉 기본 라이선스 문구를 변경하지 않고, 그 옆에 동반되는 별도 선언입니다. 1심 관할 법원은 De Novo Orthopedics의 등록지인 대만 타이중 지방법원입니다.

전체 문구는 docs/governing-law.md를 참고하십시오.

변호사가 확인한 26개 사전 검토 결론

공개 전에 저희는 네 그룹의 사전 법률 검토 의견을 작성했습니다.

Group A: 개인정보보호법 관련 사항(9개 결론)
Group B: 전자의무기록 및 의료법 관련 사항(6개 결론)
Group C: 오픈소스 라이선스 및 지식재산 관련 사항(8개 결론)
Group D: 개인정보보호위원회 감사 및 기타 사항(3개 결론)

저희 자문 변호사는 2026-05-06에 다음을 확인했습니다. 26/26개 결론 확인, 수정 필요 0건.

이것이 "위험이 없다"는 뜻은 아닙니다. "현재 설계가 대만의 현행 법체계 안에서 견딜 수 있다"는 뜻입니다. 유일한 보완 예정 항목은 D-1c, 내부 감사 백업 문서인 Personal Data File Security Maintenance Plan입니다. 이는 비공개 문서이며 공개를 막는 요소가 아닙니다.

HIS 벤더, 제3자 플랫폼, 임상 학회에 보내는 신호는 명확합니다. 이 저장소의 법적 기반은 단순한 열정으로 공개된 것이 아니라, 실제로 법률 검토를 거쳤습니다.

임상의에게 가장 직접적인 사용법

의사로서 이 글을 읽고 "실제로 무엇을 할 수 있는가"를 생각하신다면, 가장 직접적인 워크플로는 다음과 같습니다.

이 GitHub URL을 본인의 AI 어시스턴트, 즉 ChatGPT / Claude / Gemini / Microsoft Copilot에 전달하고 다음을 요청하십시오.

본인의 전문과에 맞는 8-10문항 구조화 진료 전 문진표 설계(산부인과, 신경과, 정신건강의학과, 가정의학과, 응급의학과, 소아청소년과, 심장내과 등)
기존 종이 문진표를 이 스키마에 맞는 JSON brief로 변환
이 문진표를 의원 / 병원 시스템에 통합하는 방식 기획

엔지니어링 지식은 필요하지 않습니다. AI가 저장소 URL을 받으면 spec/v0.1/authoring-spec.md, examples/orthopedics-complete.json, docs/overview.md, docs/for-doctors.md를 스스로 읽고, 설계를 단계별로 안내한 뒤 바로 사용할 수 있는 JSON 파일을 생성합니다.

컴플라이언스 환경에서는 로컬 대형언어모델(LLM)을 사용하면 됩니다. 많은 병원은 임상 콘텐츠를 외부 AI 서비스로 전송하는 것을 금지합니다. 그러나 "문진표 형식 설계"는 환자 데이터를 포함하지 않습니다. 스키마 자체는 공개되어 있고, AI가 받는 것은 형식 청사진과 전문과의 요구사항입니다. 따라서 엄격한 환경에서도 이 워크플로는 적용 가능합니다. 선택지는 Azure OpenAI 병원 테넌트(tenant), 로컬 서버에서 실행되는 Ollama, HIS 벤더가 제공하는 내부망 LLM 등이 있습니다. Microsoft는 병원 측 컴플라이언스 배포에 가장 적극적입니다. 기관이 이미 Microsoft 365 / Azure를 사용하고 있다면 Copilot이 컴플라이언스 채널을 통해 연결되어 있을 가능성이 높으므로, 병원 IT 부서에 확인하십시오.

예시 프롬프트는 다음과 같습니다.

"I'm a psychiatrist; my outpatient cases are predominantly anxiety / insomnia / mood disorders. Using the spec at https://github.com/Denovortho/open-irehab-brief-schema, design a structured 8-10 question pre-consult brief that outputs valid JSON conforming to brief-template.schema.json. Cover PHQ-9 / GAD-7 territory in spirit, but do not directly transcribe those instruments."

"I have a 12-question paper pre-op questionnaire (attached as image). Convert it into iRehab Brief Schema v0.1 JSON (repo: https://github.com/Denovortho/open-irehab-brief-schema). Preserve the original intent, structure where possible, ensure i18n with at least zh-TW + en."

첫 시도는 완벽하지 않을 수 있습니다. 그러나 "엔지니어 / 예산 / IT 사이클"을 기다리지 않고 오늘 시작할 수 있습니다.

Repo + Releases

Repository: github.com/Denovortho/open-irehab-brief-schema
v0.1.0 release (spec only): releases/tag/v0.1.0
v0.1.1 release (with JSON Schema + 2 examples + overview): releases/tag/v0.1.1

10개 파일로 구성됩니다. spec + 이중 라이선스 + 대만 준거법 + 법률 검토 기록입니다.

다음 단계

Reference validator (Apache-2.0): v0.2 목표, 교차 필드 규칙(cross-field rules) 검증
더 많은 전문과 예시: 커뮤니티 PR 기여 환영
HIS integration patterns documentation
Webhook receiver reference implementation
v1.0 stable release: 2026 Q4 목표, forward-compatibility commitment 활성화

본인 분야의 specialty pack을 기여하고 싶다면 CONTRIBUTING.md의 절차를 참고하십시오.

상업적 통합 / 라이선스 / 상표 문의: service@denovortho.com

왜 이것이 중요한가

"오픈소스 = 좋다"이기 때문이 아닙니다.

중요한 이유는 각 병원이 자기 방식으로 HIS를 만들고, 그 결과 수십 년의 통합 부채를 남긴 역사가 반복되어서는 안 되기 때문입니다. 한국 역시 EMR 보급률은 높지만, 병원별 시스템과 벤더 중심 구조 때문에 환자의뢰서, 처방전, 검사 결과, 재활 기록이 환자 중심으로 매끄럽게 이동하지 못하는 경우가 많습니다. 의료마이데이터와 본인주도 의료데이터 활용은 바로 이 문제를 해결하려는 시도입니다. 그러나 본인이 데이터를 가져와도, 데이터 구조가 제각각이면 활용성은 제한됩니다. Brief Schema 같은 열린 형식은 본인주도 의료데이터 생태계가 단순 열람을 넘어 실제 임상 워크플로와 연결되는 데 도움이 될 수 있습니다.

"오픈소스 = 관대함"이기 때문도 아닙니다.

중요한 이유는 "형식을 먼저 테이블 위에 올려놓은 주체"가 나중에 그 영역의 표준 설정자로 평가되는 경우가 많기 때문입니다. HTTP는 Tim Berners-Lee가 공개했고, TCP/IP는 Vint Cerf와 Bob Kahn이 발표했으며, FHIR는 HL7이 공개했습니다. 이들은 최대 판매가로 이긴 것이 아닙니다. 형식을 먼저 공개적으로 보이게 했기 때문에 이겼습니다.

저희가 반드시 그 위치에 도달한다는 뜻은 아닙니다. 그러나 오늘 하나의 제안을 테이블 위에 올려놓고, 이것이 공통 출발점이 될 수 있는지 확인하고자 합니다.

"구조화된 진료 전 문진"에 공통 형식이 필요하다고 보신다면, 비판, 인용, fork, pull request를 환영합니다. 설계 선택에 대한 도전도 환영합니다. 이 명세의 목적은 애초에 선택지를 공개하고 논의하게 만드는 데 있습니다.