소프트웨어 공학 보건경제학

보건경제학에서 이것이 중요한 이유

모든 현대 보건 조직은 인정하든 않든 소프트웨어 운영자입니다. 환자 기록, 처방, 일정 관리, 검사 결과, 지급 청구, 인구 집단 감시가 모두 코드 위에서 돌아가며, 그 코드는 공급업체에서 사 오거나, 자체 개발하거나, 전임자에게서 물려받거나, 세 가지를 모두 엮어 붙인 것입니다. 관련된 돈은 크고 반복됩니다. 국가 전자 건강 기록 프로그램은 수십억 달러의 공적 재원을 소비했고, 보건 소프트웨어의 운영 비용, 곧 유지 관리, 통합, 업그레이드, 보안은 보통 원래의 사업적 논거에 나타난 가격을 왜소하게 만듭니다. 그러나 대부분의 보건경제학 교육은 소프트웨어가 경제적 자산으로서 어떻게 행동하는지 아무 말도 하지 않고, 대부분의 소프트웨어 공학 교육은 간호사와 의약품도 사는 체계에서의 기회비용에 대해 아무 말도 하지 않습니다.

이 간극이 중요한 이유는 소프트웨어가 보통의 조달 반사 신경이 포착하지 못하는 특징적인 방식으로 경제적으로 실패하기 때문입니다. 체계는 구매 가격과 시연 기능으로 구매되고, 통합, 자료 이전, 유지 관리 부담은 자문받은 적 없는 예산에 나중에 도착합니다. 공급업체와의 관계는 의존으로 굳어지고, 그래서 갱신마다 약한 입장에서 협상합니다. 마감의 압박 아래 택한 지름길은 눈에 보이지 않게 쌓이다가, 병원을 돌리는 체계를 더는 안전하게 바꿀 수 없게 되며, 그 시점에 조직은 계획한 적도 없고 소프트웨어가 이제 임상 위험을 지니므로 미룰 수도 없는 현대화 청구서에 직면합니다. 영국의 국가 IT 프로그램(추정 비용 약 100억 파운드 뒤인 2011년에 해체됨)을 포함한 대규모 보건 IT 프로그램의 역사는 이러한 역학이 국가 규모로 나타난 역사입니다.

책임자에게 쟁점은 세 가지입니다. 첫째, 돈입니다. 소프트웨어는 전 수명의 약속이며, 구매 시점의 싼 선택지는 10년에 걸쳐서는 일상적으로 비싼 선택지입니다. 둘째, 안전입니다. 임상 환경에서 장애, 자료 오류, 유지할 수 없는 체계는 불편이 아니라 위험이며, 그 비용은 주제 3.11 — 의료의 질과 안전 경제학에 떨어집니다. 셋째, 주권입니다. 만들지 살지, 독점 체계와 개방 체계, 표준 인터페이스와 맞춤 인터페이스 사이의 선택은 5년 뒤 조직이 행동할 수 있는 자유가 얼마나 될지를 결정하며, 이 책이 내내 주장하듯 행동의 자유는 경제적 자산입니다.

핵심 개념

소프트웨어 공학은 소프트웨어의 규율 있는 설계, 구축, 유지이며, 유지 관리라는 말이 경제학의 대부분을 담고 있습니다. 건물과 달리 소프트웨어는 결코 완성되지 않습니다. 요구 사항이 바뀌고, 규제가 변하고, 의존성이 낡고, 보안 위협이 진화합니다. 운영 중인 체계에 대한 교정, 적응, 예방 작업인 소프트웨어 유지 관리는 흔히 체계 수명 비용의 대부분을 흡수합니다. 따라서 경제적 분석 단위는 결코 구매가 아니라 총소유 비용, 곧 체계의 현실적 수명에 걸친 취득에 통합, 자료 이전, 교육, 호스팅, 지원, 업그레이드, 보안, 최종 폐기를 더한 것입니다.

두 번째 개념은 기술 부채, 곧 건전한 설계 대신 편의적인 설계를 지금 선택하는 데 따른 암묵적 미래 비용입니다. 이 은유는 재무 회의에서 쓸 만큼 정확합니다. 부채는 본질적으로 나쁜 것이 아닙니다. 필요한 기능을 더 일찍 내놓는 의도적 지름길은 합리적인 대출일 수 있습니다. 그러나 이자가 붙습니다. 체계에 대한 모든 미래 변경이 그 때문에 더 많은 비용이 들고, 관리되지 않은 부채는 변경이 감당할 수 없을 만큼 비싸거나 위험해질 때까지 복리로 불어납니다. 자신의 기술 부채를 보지 못하는 보건 조직은 기록되지 않은 차입이 있는 것과 똑같이 장부에 오르지 않은 부채를 안고 있는 것입니다.

세 번째는 레거시 시스템, 곧 경제적으로 유지할 수 있는 시점을 지나서도 운영 중인 소프트웨어로, 흔히 작동하고, 모두가 의존하며, 교체가 무섭기 때문입니다. 레거시는 조직 규모의 기술 부채이며, 진정한 평가 문제를 제기합니다. 이를 유지하는 비용(오르는 유지 관리, 보안 노출, 더는 채용할 수 없는 직원, 다른 곳에서 막힌 개선)은 분산되고 점진적인 반면 교체 비용은 집중되고, 눈에 보이며, 정치적으로 위험합니다. 전 세계 보건의료체계가 핵심 서비스를 수십 년 된 소프트웨어 위에서 운영하는 것은 바로 이 때문입니다.

네 번째는 의존입니다. 공급업체 종속은 공급업체를 떠나는 데 자료 이전, 재교육, 재통합, 임상 교란에서 너무 많은 비용이 들어 구매자가 실질적인 협상력을 잃은 상태입니다. 보건에서는 자료가 이를 악화시킵니다. 독점 형식으로 보관된 10년의 환자 기록은 인질입니다. 종속은 우연이 아니라 가격 전략이며, 가격을 매길 때는 갱신 때가 아니라 서명 전입니다. 이에 대한 균형추는 계약적(자료 내보내기 권리, 에스크로, 종료 지원)이고 구조적이며, 무엇보다 표준입니다.

다섯 번째는 상호운용성, 곧 체계가 정보를 교환하고 교환된 것을 사용하는 능력입니다. 그 경제학은 네트워크 효과의 경제학입니다. 공통 표준을 쓰는 각 체계는 다른 모든 체계의 가치를 높이며, 그래서 상호운용성은 시장이 만성적으로 과소 공급합니다. 편익은 체계 전체에 돌아가는 반면 비용은 각 공급업체와 구매자에게 떨어지고, 기존 사업자는 상호운용하지 않음으로써 이익을 낼 수 있기 때문입니다. FHIR(Fast Healthcare Interoperability Resources), 그것이 속한 HL7 계열, openEHR 같은 표준은 이러한 교환 비용을 낮추기 위해 존재하며, 미국의 21세기 치유법(21st Century Cures Act) 정보 차단 규칙과 유럽연합의 유럽 보건 데이터 공간 같은 규제는 시장이 제공하지 못한 것을 의무화하기 시작했습니다.

여섯 번째는 오픈소스 소프트웨어, 곧 소스 코드를 자유롭게 사용하고 수정할 수 있는 소프트웨어를 포함한 만들기-사기의 스펙트럼입니다. 오픈소스는 공짜가 아닙니다. 사용료는 사라지지만 구현, 호스팅, 관리 책임은 남고, 누군가는 코드를 유지해야 합니다. 그 경제적 특징은 다릅니다. 종속 프리미엄을 없애고 소프트웨어를 많은 구매자가 공동 재원을 댈 수 있는 공동선으로 바꾸며, 그래서 DHIS2나 OpenMRS 같은 플랫폼이 저소득 및 중소득 국가 보건 정보의 상당 부분을 짊어집니다. 만들기 대 사기의 결정도 마찬가지로 기술 선호가 아니라 포트폴리오의 질문입니다. 역량이 차별화되고 조직이 공학 팀을 유지할 수 있는 곳에서는 만들고, 필요가 일반 상품인 곳에서는 사며, 유지할 수 없는 것은 결코 만들지 마십시오.

마지막으로, 경제적 양으로서의 신뢰성입니다. 임상 소프트웨어는 가동 중단에 건강 비용이 따르는 서비스를 돌리므로, 체계를 믿을 만하게 유지하는 공학 규율, 곧 명시적 목표에 견주어 신뢰성을 관리하고 허용 가능한 실패에 예산을 편성하는 사이트 신뢰성 공학은 보험료가 공학적 노력인 보험을 사는 것으로 이해하는 것이 가장 좋습니다. 임상 환경이 필요로 하는 것 이상의 신뢰성은 낭비이고, 그 아래에서는 부족분을 사건으로 치릅니다. 이 모든 것의 평가 기구는 여전히 주제 2.1 — 경제성 평가이고 감당 가능성의 규율은 주제 2.5 — 예산영향과 감당가능성이며, 이 주제는 그러한 방법에 공급해야 할 소프트웨어 특유의 비용 구조를 제공합니다. 디지털 도구를 보건 개입으로 평가하는 것, 곧 앱이나 원격의료 서비스가 용인할 수 있는 비용으로 성과를 개선하는지는 주제 5.2 — 디지털 보건경제학에, AI 모형 자체의 경제학은 주제 5.3 — 인공지능 보건경제학에 속합니다.

모범 사례

1. 구매 가격이 아니라 체계의 현실적 수명에 걸친 총소유 비용을 평가하십시오. 모든 소프트웨어 사업적 논거가 정해진 기간(보통 10년 이상)에 걸쳐 취득, 통합, 자료 이전, 교육, 호스팅, 지원, 보안, 업그레이드, 폐기의 비용을 계산하고, 각 반복 항목을 어느 예산이 지는지 밝히도록 요구하십시오. 아무것과도 견주지 않은 사용료는 사업적 논거가 아닙니다. 눈에 보이는 약속의 끝자락입니다.

2. 기술 부채를 장부에 올리십시오. 공학 책임자들이 시설 안의 중요한 지름길과 낡아 가는 구성 요소의 등록부를 유지하고, 각각이 부과하는 이자, 곧 더 느린 변경, 더 높은 사고 위험, 막힌 개선에 대한 정직한 추정치를 갖게 하십시오. 이를 재무 부채와 같은 진지함으로 검토하고, 이를 갚는 데 공학 역량의 상시적 몫(흔히 5분의 1에서 3분의 1)을 예산에 편성하십시오. 미룬 부채 상환은 복리로 불어난 부채이기 때문입니다.

3. 유지 관리를 첫날부터 운영 비용으로 재원을 대십시오. "완성된" 소프트웨어는 퇴화하고 있는 소프트웨어입니다. 의존성이 낡고, 위협이 진화하고, 규제가 바뀝니다. 유지 관리의 흐름을 원래의 평가와 반복 예산에 내장하고, 유지 관리 항목이 없는 제안은 불완전한 것으로 다루십시오. 돈은 어차피 쓰이며, 유일한 질문은 계획된 것이었는지 위기에 의해 쥐어짜인 것이었는지입니다.

4. 종속의 가격은 갱신 때가 아니라 서명 전에 매기십시오. 모든 주요 구매에 대해 아직 대안이 있을 때 출구의 비용을 계산하십시오. 누가 자료를 소유하는지, 어떤 형식으로 내보낼 수 있는지, 공급업체가 어떤 종료 지원을 제공해야 하는지, 이전에 그럴듯하게 얼마가 들지입니다. 자료 내보내기 권리와 개방 인터페이스를 계약에 협상해 넣고, 이에 대한 공급업체의 저항을 다가올 갱신 협상에 대한 정보로 다루십시오.

5. 상호운용성을 의도적으로 사십시오. 시장이 과소 공급하기 때문입니다. 구매 조건으로 FHIR 같은 개방 표준의 지원을 요구하고, 주장된 준수를 안내 책자가 아니라 실제 자료 흐름에 견주어 확인하며, 표준 인터페이스가 있는 곳에서는 맞춤 인터페이스를 거부하십시오. 받아들이는 모든 독점 인터페이스는 공급업체에 기증한 전환 비용이자 모든 미래 통합에 대한 세금입니다.

6. 만들기 대 사기를 포트폴리오로 결정하되, 공학 역량에 맞추십시오. 역량이 서비스를 차별화하고 만든 것을 유지할 팀을 현실적으로 모집하고, 붙잡고, 재원을 댈 수 있는 곳에서만 만드십시오. 지속적인 팀 없는 자체 개발 체계는 단계가 하나 더 붙은 레거시 시스템입니다. 일반 상품 필요는 사고, 공동체나 공공 컨소시엄이 유지하는 곳에서는 오픈소스 플랫폼을 고려하며, 어느 쪽이든 결정에 지속 계획을 쓰십시오.

7. 오픈소스를 공짜가 아니라 고유한 비용 구조를 지닌 조달 선택지로 다루십시오. 총소유 비용으로 비교하십시오. 사용료는 없지만 자체적으로 지든 지원 공급업체를 통하든 실제 구현, 호스팅, 지원, 관리 책임의 비용이 있습니다. 독특한 이점, 곧 종속 프리미엄 없음, 검사할 수 있는 코드, 다른 보건 기관과 공동선에 공동으로 재원을 댈 수 있는 능력과, 독특한 의무, 곧 의존한다면 이를 지속하는 데 기여하라는 것을 따져 보십시오.

8. 신뢰성 목표를 임상적 결과에서 정하고, 목표에 맞게 지출하십시오. 서비스별로 한 시간의 가동 중단이 실제로 얼마의 비용인지, 곧 지연된 진료, 안전하지 않은 임시방편, 잃은 신뢰에서 어떤 비용이 드는지 결정하고, 그에 맞춰 가용성과 복구 목표를 정하십시오. 그다음 공학 지출을 양쪽에서 목표에 묶으십시오. 의원이 필요로 하는 것보다 적은 신뢰성에 지불하면 사건을 사는 것이고, 필요보다 많이 지불하면 금도금을 사는 것입니다.

9. 레거시 교체를 강제되기 전에 계획하십시오. 핵심 체계의 연령과 유지 가능성을 주기적으로 검토하고, 기존 체계가 아직 작동하는 동안 교체를 시작하십시오. 실패 속에서 실행하는 이전은 가장 비싼 종류입니다. 일시 전환(big-bang cutover)보다 점진적 이전(오래된 체계를 인터페이스 하나씩 졸라매기)을 선호하십시오. 보건에서 일시 전환의 실패 방식은 취소된 진료와 잃은 기록으로 측정됩니다.

10. 자료 이전을 모든 평가의 일급 항목으로 만드십시오. 환자 자료는 그것을 보유하는 모든 체계보다 오래 살며, 이를 깔끔하고, 완전하게, 임상 안전을 보장하면서 옮기는 일은 어떤 전환에서든 일상적으로 가장 크고 가장 과소평가된 비용의 하나입니다. 명시적으로 비용을 계산하고, 실제 기록으로 일찍 시험하며, 이전이 떠나는 공급업체의 인질이 되지 않도록 체계 수명 내내 내보낼 수 있는 형식으로 자료의 보관권을 유지하십시오.

11. 임상 안전 공학을 경제학 안에 두십시오. 보건 소프트웨어는 안전과 관련된 소프트웨어입니다. 변경에는 시험이 필요하고, 배포에는 되돌릴 경로가 필요하며, 사건에는 조사가 필요하고, 관할권은 점점 보건 IT에 공식적인 임상 위험 기준을 부과합니다. 이러한 규율은 공학 시간이 들며 사업적 논거에 속합니다. 이를 건너뛰는 "더 싼" 전달은 비용을 위험으로서 환자에게 떠넘기는 것입니다(해악의 비용은 주제 3.11 — 의료의 질과 안전 경제학).

12. 소프트웨어 결정을 다른 어떤 보건 투자와도 같은 가치 정밀 조사를 거치게 하십시오. 소프트웨어 프로그램은 의약품과 직원과 같은 제한된 예산을 두고 경쟁하므로 같은 규율을 져야 합니다. 명시된 편익, 실제 비교 대상("우리가 가진 것을 개선"을 포함), 시간에 걸친 감당 가능성 프로필, 한 약속에 견준 시행 후 검토입니다(기구는 주제 2.1 — 경제성 평가와 주제 2.5 — 예산영향과 감당가능성이며, 구매의 기예는 주제 3.10 — 전략적 구매와 계약).

팀과 논의할 질문

1. 우리 소프트웨어 자산이 실제로 연간 얼마의 비용이 들며, 그중 계획한 비율은 얼마입니까? 대부분의 조직은 사용료는 말할 수 있어도 조직 전반의 운영 예산과 직원 시간에 숨은 통합, 유지 관리, 보안, 임시방편 비용은 말하지 못합니다. 팀에게 상위 몇 개 체계의 실제 연간 수치를 모아 원래의 사업적 논거가 약속한 것과 비교하게 하십시오. 긴장은 분산된 비용에는 단일 책임자가 없어 그 증가에 책임지는 사람이 없고, 구매를 승인한 사람들은 유지비를 지불하는 사람들인 경우가 드물다는 점입니다. 정직한 답은 전 수명 수치를 내고, 어느 예산이 이를 지는지 밝히며, 지출이 계획되지 않은 곳을 인정합니다. 해마다 사후에 발견하는 비용은 관리할 수 없는 비용이기 때문입니다.

2. 우리의 기술 부채는 어디에 있으며, 그에 대해 어떤 이자를 지불하고 있습니까? 공학 팀은 보통 부채가 어디 있는지 정확히 압니다. 아무도 손대지 못하는 모듈, 수작업 단계로 이어 붙인 인터페이스, 보안 지원에서 두 버전 뒤처진 플랫폼 같은 것입니다. 그러나 그 지식이 경제적 언어로 이사회에 닿는 경우는 드뭅니다. 등록부를 요구하십시오. 중요한 부채, 각각이 늦추거나 위태롭게 하는 것, 이를 갚는 데 드는 비용입니다. 긴장은 부채 상환이 눈에 보이는 새로운 기능과 경쟁하여 겉보기에는 늘 지고, 바로 그렇게 부채가 복리로 불어난다는 점입니다. 정직한 답은 이자(더 느린 전달, 사고 노출, 막힌 프로젝트)를 수량화하고, 역량의 상시적 몫을 감축에 약속하며, 일부 부채를 지고 가는 것이 합리적임을, 알고서 진다면, 받아들입니다.

3. 3년 뒤에 주요 체계 공급업체를 떠나야 한다면 우리는 그럴 수 있으며, 얼마가 들겠습니까? 이 질문은 아직 줄일 시간이 있을 때 종속을 드러냅니다. 누가 자료를 소유하고 어떤 형식으로 나갈 수 있는지, 계약이 종료 지원에 대해 무엇을 말하는지, 다시 만들어야 할 맞춤 인터페이스가 몇 개인지, 이전이 어떤 재교육과 임상 교란을 부과할지 따져 보십시오. 긴장은 모두가 출구를 행사하지 않기를 바라므로 아무도 이를 열어 두는 데 돈을 쓰고 싶어 하지 않지만, 불가능한 출구는 이미 진 갱신 협상이라는 점입니다. 정직한 답은 출구의 가격을 매기고, 이를 싸게 만들 두세 가지 행동(자료 내보내기 권리, 표준 인터페이스, 문서화)을 식별하며, 그 가격을 조직이 적극 유지하는 협상 입지로 다룹니다.

4. 어떤 체계를 만들고 어떤 체계를 사야 하며, 우리의 공학 역량은 그 답과 맞습니까? 만들기 대 사기의 분할은 많은 조직이 선택이 아니라 누적으로 내리는 포트폴리오 결정이며, 일반 상품을 만들고 자신을 차별화하는 것을 사는 결과가 됩니다. 어떤 체계가 서비스의 독특한 무언가를 진정으로 구현하고 어떤 것이 시장이나 오픈소스 공동체가 이미 섬기는 일반 필요인지 물으십시오. 그다음 역량 주장을 시험하십시오. 자체 개발한 모든 것에 대해 이를 만든 프로젝트만이 아니라 수명 내내 유지하기로 약속한, 재원이 마련되고 모집 가능한 팀이 있습니까? 긴장은 만들기는 야망에 아첨하고 사기는 신중함에 아첨하며, 어느 본능도 분석이 아니라는 점입니다. 정직한 답은 차별화 요소의 이름을 밝히고, 과거의 개발물이 폐기되거나 표준 제품으로 대체되어야 할 곳을 인정하며, 유지 관리에 재원이 없는 어떤 개발도 시작하기를 거부합니다.

5. 가장 중요한 체계의 한 시간 가동 중단은 실제로 얼마의 비용이 들며, 우리의 신뢰성 지출은 그에 맞춰져 있습니까? 신뢰성 결정은 흔히 임상 비용 정보가 없는 공학자나 공학 비용 정보가 없는 이사회가 내리므로, 지출이 결과가 아니라 습관에 맞춰집니다. 구체적인 시나리오를 따라가 보십시오. 전자 기록이 바쁜 하루 동안 전반적으로 다운되면, 무엇이 지연되고, 어떤 안전하지 않은 임시방편이 나타나고, 어떤 해악이 그럴듯하게 따르며, 복구에 얼마가 듭니까? 그다음 이를 회복력, 백업, 장애 조치, 사건 대응에 쓰는 것과 비교하십시오. 긴장은 양방향입니다. 과소 지출은 사건을 사고, 위험이 낮은 체계의 금도금은 다른 서비스가 필요로 하는 돈을 낭비합니다. 정직한 답은 임상적 결과에서 도출한 핵심 서비스별 명시적 가용성과 복구 목표를 정하고, 그것을 충족하는 공학 지출을 더도 덜도 없이 보여 줄 수 있습니다.

6. 모두가 손대기를 두려워하는 레거시 시스템에 대한 우리 계획은 무엇입니까? 모든 성숙한 보건 조직에는 그런 것이 있습니다. 경제적 유지 가능성을 지났지만 작동하고 교체가 무서워서 살려 둔 체계입니다. 우리 것의 이름을 밝히십시오. 각각이 막고 있는 것, 곧 만들지 못한 통합, 하지 못한 개선, 짊어진 보안 노출과, 교체 경로가 무엇인지, 곧 점진적 이전인지, 전면 교체인지, 위험이 통제된 의도적이고 계획된 유지인지 물으십시오. 긴장은 시간적입니다. 레거시를 유지하는 비용은 분산되고 연간인 반면 교체 비용은 집중되고 경력에 눈에 띄므로, 그럴듯해 보이는 미룸이 실패가 최악의 가격으로 문제를 강제할 때까지의 기본값입니다. 정직한 답은 기존 체계가 아직 작동하는 동안 교체를 일정에 올리고, 일시 전환보다 졸라매기 방식의 점진적 이전을 선호하며, "내년에 결정하겠다"를 그것이 실제로 내리는 결정으로 다룹니다.

실무 사례: 보건경제학의 한 예

가상의 동아프리카 국가의 보건부는 갱신 결정에 직면합니다. 9년 동안 지역 병원들은 해외 공급업체가 제공하는 독점 병원 정보 체계를 운영해 왔습니다. 체계는 작동하지만 갱신 견적이 급등했고, 국가 보험 제도나 검사 네트워크로 가는 새로운 인터페이스마다 공급업체가 가격을 매기는 맞춤 프로젝트이며, 계약은 자료 내보내기에 대해 침묵합니다. 한편 부의 지구 보건 사무소들은 이미 국가 보건 통계에 쓰는 오픈소스 플랫폼 DHIS2를 운영하고 있고, 이웃 나라는 지역 지원 컨소시엄과 함께 오픈소스 의무 기록 플랫폼을 도입했습니다.

보건부의 보건경제학 부서는 결정을 "갱신할 것인가 말 것인가"에서 10년에 걸친 세 선택지, 곧 기존 체계를 갱신, 종료 권리를 구축하면서 단기 갱신, 오픈소스 플랫폼으로 점진적 이전의 전 수명 비교로 다시 틀 짓습니다. 선택지의 비용을 계산하면 실제 경제학이 드러납니다. 맞춤 인터페이스, 의무적 업그레이드 프로젝트, 해외 지원 출장을 세면 기존 체계의 사용료는 실제 연간 비용의 3분의 1에 불과합니다. 오픈소스 선택지는 사용료가 없지만 부가 국가 지원 팀, 지역 호스팅, 플랫폼 공동체에 대한 기여에 재원을 대야 하며, "무료 소프트웨어"의 수사가 숨겼던 실제 반복 비용입니다. 그러나 결정적인 항목은 이 둘이 아니라 자료 이전입니다. 9년의 환자 기록이 독점 스키마에 있으며, 추출 지원에 대한 공급업체의 가격이 사실상 떠나는 가격입니다.

부서는 그래도 출구의 가격을 매기며, 그 수치가 협상을 바꿉니다. 비용이 계산된 대안으로 무장한 부는 문서화된 형식의 계약상 자료 내보내기와 보험 제도 및 검사 네트워크에 대한 표준 FHIR 인터페이스를 포함하는 더 낮은 가격의 2년 갱신을 협상하며, 경제적으로는 더 싼 미래의 출구에 대한 옵션으로 구매한 것이고, 주제 3.12 — 팬데믹과 비상 대비 경제학이 미래의 행동 자유에 대한 어떤 옵션이든 가치 평가하는 방식으로 평가됩니다. 이 2년 동안 시범 사업이 세 곳의 지구 병원을 오픈소스 플랫폼으로 이전하여 지원 컨소시엄, 자료 이전 도구, 그리고 결정적으로 부가 플랫폼이 필요로 하는 엔지니어를 모집하고 붙잡을 수 있는지를 시험하며, 주제 3.6 — 보건의료 인력과 노동시장의 인력 경제학을 끌어옵니다.

시범 사업은 두 병원에서 성공하고 세 번째에서 어려움을 겪는데, 인력 공백이 모든 사건을 위기로 바꾸는 곳입니다. 소프트웨어가 아니라 역량에 대한 경고입니다. 부는 병원별로 5년에 걸쳐 단계적 국가 이전을 진행하며, 각 현장의 자료가 확인될 때까지 기존 체계를 병행해 돌립니다. 최종 평가는 교훈을 명시합니다. 이긴 수는 독점 대신 오픈소스를 고른 것이 아니라 각 선택지의 전 수명에 가격을 매기고, 의존이 더 굳어지기 전에 종료 권리를 사고, 공학적 약속을 부가 실제로 지속할 수 있는 것에 맞춘 것이었습니다.

네 가지 부문별 관점

스타트업

보건 소프트웨어 스타트업은 이 주제의 경제학을 파는 쪽에서 삽니다. 기업 가치는 출시 속도에 보상하며, 바로 그렇게 기술 부채가 쌓이고, 수익 모형은 고객이 저항해야 할 종속에 조용히 의존할 수 있습니다. 규율은 부채를 의도적으로 지는 것, 곧 핵심 고객을 따내는 지름길은 합리적일 수 있되 등록부와 상환 계획을 유지하는 것입니다. 바꿀 수 없는 코드베이스는 방향 전환을 할 수 없는 회사이기 때문입니다. 상호운용성은 준수가 아니라 전략입니다. 표준 인터페이스(무엇보다 FHIR)는 작은 제품이 기존 사업자가 지배하는 시설 안에 자리를 얻는 방법입니다. 그리고 임상 안전 공학은 규모가 될 때까지 미룰 관료주의가 아닙니다. 임상 환경의 자료 무결성 사건 하나가 젊은 회사를 끝낼 수 있습니다.

소규모 사업체

진료소 그룹, 약국 체인, 진단 검사실처럼 작지만 자리 잡은 공급자는 소프트웨어를 거의 전부 구매하며 나쁜 구매를 보상할 공학 직원이 없으므로, 이들의 경제학은 의존의 경제학입니다. 잘못 가격이 매겨진 체계는 비례적으로 예산의 더 큰 몫이고 실패한 이전은 사업을 멈출 수 있으므로, 총소유 비용과 종료 권리는 여기서 어느 곳보다 중요합니다. 합리적인 자세는 표준화입니다. 주류 제품, 개방 표준 인터페이스, 자체 운영 서버가 아닌 호스팅 서비스, 가격보다 먼저 자료 내보내기 조항을 읽는 계약입니다. 이들의 독특한 위험은 조용한 레거시, 곧 공급업체가 망할 때까지 제자리에서 낡아 가는 진료 관리 체계이므로, 작은 구매자도 의존하는 각 체계를 떠나는 데 얼마가 들지 해마다 알아야 합니다.

대기업

대형 병원 그룹이나 보험자는 수백 개의 체계를 운영하므로 문제는 포트폴리오입니다. 서로 다른 부서가 산 겹치는 제품, 아무도 완전히 지도화하지 못한 통합의 거미줄, 어느 한 팀도 볼 수 없을 만큼 큰 시설에 분산된 기술 부채입니다. 성숙한 대기업은 시설을 투자 포트폴리오를 관리하듯 관리합니다. 책임자, 전 수명 비용, 부채와 위험 등급, 계획된 교체 시계를 갖춘 체계 목록이며, 모든 개선을 입찰해야 할 프로젝트로 다루는 대신 통합, 신뢰성, 부채 상환을 위한 상시 공학 역량에 재원을 댑니다. 규모는 또한 작은 구매자에게 없는 구매력을 줍니다. 표준 인터페이스, 자료 내보내기 권리, 에스크로를 진입 조건으로 요구할 수 있고, 그 아키텍처 선택은 공급업체를 규율하지 그 반대가 아닙니다.

정부

부처나 국가 지불자는 다른 모든 이를 위해 이 경제학을 형성합니다. 시장이 개방성에 보상하는지 벌하는지를 결정하는 상호운용성 규칙, 곧 미국이 21세기 치유법의 정보 차단 조항으로, 유럽연합이 유럽 보건 데이터 공간으로 한 것처럼 정하며, 자체 조달은 공급업체에게 구매자가 무엇을 용인할지 가르칩니다. 이들의 독특한 실패 유형은 국가 초대형 프로그램, 곧 중앙집중적이고, 일시 전환이고, 정치적으로 일정이 정해진 소프트웨어 전달이며, 그 붕괴는 영국의 국가 IT 프로그램이 보여 주었듯 수십억으로 측정됩니다. 규율은 그 반대의 자세입니다. 표준과 플랫폼은 중앙에서, 전달은 점진적으로 하며, 상업 시장이 얇은 곳에서는 오픈소스와 지역에서 유지할 수 있는 선택지를 진지하게 따져 봅니다(정책 기구는 주제 3.2 — 보건정책, 구매의 기예는 주제 3.10 — 전략적 구매와 계약).

흔한 실패 유형

• 수명이 아니라 사용료를 사기. 통합, 이전, 유지 관리, 출구의 비용을 계산하지 않은 채 구매 가격으로 소프트웨어를 승인하는 것. 해결책: 모든 사업적 논거에 각 반복 항목에 이름 붙은 예산을 갖춘 전 수명 총소유 비용을 요구하십시오.

• 복리가 될 때까지 보이지 않는 부채. 체계를 안전하게 바꿀 수 없을 때까지 기술 부채가 기록되지 않은 채 쌓이게 두는 것. 해결책: 부채 등록부를 유지하고, 경제적 용어로 보고하며, 상환에 상시 역량을 약속하십시오.

• 종속으로 몽유병처럼 걸어 들어가기. 출구를 감당할 수 없고 갱신이 일방적으로 정해질 때까지 독점 형식과 맞춤 인터페이스를 받아들이는 것. 해결책: 구매 시 자료 내보내기 권리와 표준 인터페이스를 협상하고 해마다 출구의 가격을 매기십시오.

• 유지할 수 없는 것을 만들기. 수명 내내 재원이 마련된 팀 없이 자체 체계를 의뢰하는 것. 해결책: 지속 계획 없는 개발은 하지 말고, 역량이 얇은 곳에서는 오픈소스 플랫폼을 사거나 채택하십시오.

• 오픈소스를 공짜로 다루기. 호스팅, 지원, 관리 책임에 재원을 대지 않고 공동체 플랫폼을 채택하는 것. 해결책: 오픈소스를 총소유 비용으로 평가하고 그것이 필요로 하는 지속에 예산을 편성하십시오.

• 희망에 의한 신뢰성. 장애가 가동 중단의 임상적 비용을 드러낼 때까지 가용성 목표를 정하지 않는 것. 해결책: 임상적 결과에서 핵심 서비스별 가용성과 복구 목표를 정하고 목표에 맞게 지출하십시오.

• 강요에 의한 일시 전환 레거시 교체. 실패가 서둘러 전면 전환을 강제할 때까지 현대화를 미루는 것. 해결책: 기존 체계가 작동하는 동안 교체를 계획하고, 병행 운영과 확인된 자료로 점진적으로 이전하십시오.

• 가치 규율 밖의 소프트웨어. IT 프로그램이 의약품과 서비스에 적용하는 정밀 조사를 건너뛰게 두는 것. 해결책: 같은 규칙, 곧 명시된 편익, 실제 비교 대상, 감당 가능성 프로필, 시행 후 검토를 적용하십시오.

성숙도 모델

체크리스트

• 모든 소프트웨어 결정을 각 반복 항목에 이름 붙은 예산을 갖춘 현실적 수명에 걸친 총소유 비용으로 평가한다.
• 기술 부채 등록부를 유지하고, 경제적 용어로 보고하며, 상환에 상시 공학 역량을 약속한다.
• 유지 관리를 원래의 사업적 논거부터 계획된 운영 비용으로 재원을 댄다.
• 구매 시 자료 내보내기 권리, 표준 인터페이스, 종료 지원을 계약에 협상해 넣는다.
• 각 주요 체계의 출구 가격을 해마다 매기고, 갱신 전에 비용이 계산된 대안을 살려 둔다.
• 구매 조건으로 확인된 개방 표준 준수(예: FHIR)를 요구한다.
• 만들기 대 사기를 포트폴리오로 결정하고, 재원이 마련된 전 수명 지속 계획 없이는 어떤 개발도 시작하지 않는다.
• 오픈소스 선택지를 호스팅, 지원, 관리 책임을 예산에 편성하며 총소유 비용으로 평가한다.
• 임상적 결과에서 핵심 서비스별 가용성과 복구 목표를 정하고 지출을 그에 맞춘다.
• 기존 체계가 아직 작동하는 동안 레거시 교체를 일정에 올리고, 일시 전환보다 점진적 이전을 선호한다.
• 자료 이전을 일찍 비용 계산하고 시험하며, 각 체계 수명 내내 환자 자료를 내보낼 수 있게 유지한다.
• 소프트웨어 프로그램을 시행 후 검토를 갖춰 다른 어떤 보건 투자와도 같은 가치 정밀 조사를 거치게 한다.

Key sources

• WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
• HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
• openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
• U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
• DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
• UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

References

1. Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
2. Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
3. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
4. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
5. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
6. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
7. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
8. Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
9. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
11. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
12. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
13. World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
14. HL7 International — FHIR specification — https://hl7.org/fhir/
15. National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
16. National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT