Экономика программной инженерии в здравоохранении

Почему это важно для экономики здравоохранения

Каждая современная организация здравоохранения, признаёт она это или нет, является оператором программного обеспечения. Записи пациентов, назначения, расписания, лабораторные результаты, претензии по оплате и наблюдение за населением — всё работает на коде, купленном у поставщиков, построенном собственными силами, унаследованном от предшественников или сшитом из всех трёх. Задействованные деньги велики и повторяются: национальные программы электронных медицинских карт поглотили миллиарды долларов публичных средств, а текущие издержки медицинского программного обеспечения — обслуживание, интеграция, обновления, безопасность — обычно многократно превышают цену, фигурировавшую в исходном экономическом обосновании. Однако большая часть обучения экономике здравоохранения ничего не говорит о том, как программное обеспечение ведёт себя как экономический актив, а большая часть обучения программной инженерии ничего не говорит об альтернативной издержке в системе, которая также покупает медсестёр и лекарства.

Разрыв важен, потому что программное обеспечение проваливается экономически характерными способами, которые обычные рефлексы закупки не улавливают. Систему покупают по цене покупки и демонстрационным функциям; бремя интеграции, миграции данных и обслуживания приходит позже, против бюджетов, с которыми никогда не консультировались. Отношения с поставщиком затвердевают в зависимость, поэтому каждое продление переговаривается со слабой позиции. Сокращения, принятые под давлением сроков, накапливаются невидимо, пока систему, на которой работает больница, больше нельзя безопасно менять, — в этот момент организация сталкивается со счётом модернизации, который она никогда не планировала и не может отложить, потому что программное обеспечение теперь несёт клинический риск. История крупных программ медицинских ИТ, включая Национальную программу по ИТ Великобритании (демонтированную в 2011 году после оценённой издержки около 10 миллиардов фунтов), — это история этой динамики в национальном масштабе.

Для руководителя ставки трояки. Во-первых, деньги: программное обеспечение — обязательство на весь жизненный цикл, и дешёвый вариант при покупке рутинно оказывается дорогим вариантом на протяжении десятилетия. Во-вторых, безопасность: в клинической обстановке сбой, ошибка данных или неподдерживаемая система — это не неудобство, а опасность, с издержками, которые приземляются в теме 3.11 «Экономика качества и безопасности». В-третьих, суверенитет: выборы между построением и покупкой, между проприетарными и открытыми системами и между стандартными и нестандартными интерфейсами определяют, сколько свободы будет у организации действовать через пять лет, — а свобода действия, как утверждает эта книга на протяжении всего изложения, является экономическим активом.

Основные понятия

Программная инженерия — дисциплинированное проектирование, построение и сопровождение программного обеспечения, — и слово сопровождение несёт большую часть экономики. В отличие от здания, программное обеспечение никогда не завершено: требования сдвигаются, регулирование меняется, зависимости стареют, а угрозы безопасности эволюционируют. Сопровождение программного обеспечения — исправительная, адаптивная и профилактическая работа над системой на службе — обычно поглощает большую часть издержки на протяжении жизни системы. Экономическая единица анализа поэтому никогда не покупка; это совокупная стоимость владения: приобретение плюс интеграция, миграция данных, обучение, хостинг, поддержка, обновления, безопасность и итоговый вывод из эксплуатации на протяжении реалистичной жизни системы.

Вторая концепция — технический долг: подразумеваемая будущая издержка выбора удобного дизайна сейчас вместо надёжного. Метафора достаточно точна, чтобы использовать её на финансовой встрече. Долг не является изначально плохим — намеренное сокращение, поставляющее нужную способность раньше, может быть рациональным займом, — но он начисляет проценты: каждое будущее изменение системы стоит из-за него больше, а неуправляемый долг накапливается, пока изменение не станет запретительно дорогим или опасным. Организация здравоохранения, не видящая свой технический долг, несёт неучтённое обязательство, точно как если бы у неё было незарегистрированное заимствование.

В-третьих, унаследованная система (legacy system): программное обеспечение, остающееся на службе за точкой, где оно может экономично поддерживаться, — часто потому что оно работает, все от него зависят, а замена пугает. Унаследованное — это технический долг в организационном масштабе, и оно представляет подлинную проблему оценки: издержки его сохранения (растущее обслуживание, уязвимость безопасности, персонал, которого больше нельзя нанять, заблокированные улучшения в других местах) рассеяны и постепенны, тогда как издержка замены концентрирована, видима и политически рискованна. Системы здравоохранения по всему миру ведут критические услуги на программном обеспечении десятилетней давности именно по этой причине.

В-четвёртых, зависимость. Привязка к поставщику — состояние, при котором переключение от поставщика стоит настолько много — в миграции данных, переобучении, повторной интеграции и клиническом нарушении, — что покупатель потерял эффективную переговорную силу. В здравоохранении это усугубляется данными: десятилетие записей пациентов, удерживаемых в проприетарном формате, — заложник. Привязка — не случайность; это ценовая стратегия, и время её оценить — до подписания, а не при продлении. Противовесы контрактны (права экспорта данных, эскроу, помощь при выходе) и архитектурны — прежде всего стандарты.

В-пятых, интероперабельность: способность систем обмениваться информацией и использовать обмениваемое. Её экономика — это экономика сетевого эффекта — каждая система, говорящая на общем стандарте, повышает ценность каждой другой системы, которая на нём говорит, — что как раз объясняет, почему интероперабельность хронически недопредоставлена рынками: выгоды накапливаются в системе в целом, тогда как издержки падают на каждого поставщика и покупателя, а действующий игрок может получать прибыль от неинтероперирования. Такие стандарты, как Fast Healthcare Interoperability Resources (FHIR), семейство HL7, к которому он принадлежит, и openEHR существуют для снижения этих издержек обмена, а регуляторы — например, Соединённые Штаты через правила против блокирования информации Закона о лечении в XXI веке, и Европейский союз через Европейское пространство медицинских данных — начали обязывать то, что не предоставил рынок.

В-шестых, спектр «производить или покупать», включая программное обеспечение с открытым исходным кодом — программное обеспечение, чей исходный код свободно используем и модифицируем. Открытый исходный код не бесплатен: издержка лицензии исчезает, но внедрение, хостинг и попечительство остаются, и кто-то должен поддерживать код. Его экономическое отличие иное — он устраняет премию привязки и превращает программное обеспечение в общее благо, которое многие покупатели могут совместно финансировать, что объясняет, почему такие платформы, как DHIS2 и OpenMRS, несут большую часть нагрузки медицинской информации в странах с низким и средним доходом. Решение «производить или покупать», аналогично, — не технологическое предпочтение, а портфельный вопрос: производите там, где способность отличительна, а организация может поддерживать инженерную команду; покупайте там, где потребность стандартна; и никогда не производите то, что не можете поддерживать.

Наконец, надёжность как экономическая величина. Клиническое программное обеспечение ведёт услуги, где простой имеет издержку здоровья, поэтому инженерные дисциплины, поддерживающие системы надёжными — включая инженерию надёжности эксплуатации (site reliability engineering), которая управляет надёжностью против явных целей и бюджетов на допустимый провал, — лучше всего понимать как покупку страхования, чья премия — инженерное усилие. Надёжность выше того, что нужно клинической обстановке, — это растрата; ниже неё — дефицит оплачивается инцидентами. Механизм оценки для всего этого остаётся темой 2.1 «Экономическая оценка» и дисциплиной доступности темы 2.5 «Влияние на бюджет и доступность»; эта тема даёт специфичную для программного обеспечения структуру издержки, которой должны питаться эти методы. Оценка цифрового инструмента как вмешательства в здоровье — улучшает ли приложение или служба телездравоохранения исходы по приемлемой цене — относится к теме 5.2 «Экономика цифрового здравоохранения»; экономика моделей ИИ конкретно — к теме 5.3 «Экономика ИИ в здравоохранении».

Лучшие практики

1. Оценивайте совокупную стоимость владения на протяжении реалистичной жизни системы, никогда не цену покупки. Требуйте, чтобы каждое экономическое обоснование программного обеспечения оценивало приобретение, интеграцию, миграцию данных, обучение, хостинг, поддержку, безопасность, обновления и вывод из эксплуатации на протяжении заявленного горизонта — обычно десятилетие или более — и называло, какой бюджет несёт каждую повторяющуюся строку. Лицензионная плата, сравниваемая ни с чем, — не экономическое обоснование; это видимая верхушка обязательства.

2. Внесите технический долг в бухгалтерские книги. Пусть инженерные руководители ведут реестр значимых сокращений и стареющих компонентов в комплексе, с честной оценкой процентов, которые каждый начисляет, — более медленные изменения, более высокий риск инцидентов, заблокированные улучшения. Пересматривайте его с той же серьёзностью, что и финансовое обязательство, и закладывайте в бюджет постоянную долю инженерной мощности (обычно от пятой до трети) на его погашение, потому что отложенное обслуживание долга — это накопленный долг.

3. Финансируйте обслуживание как операционную издержку с первого дня. Программное обеспечение, которое «завершено», — это программное обеспечение, которое распадается: зависимости стареют, угрозы эволюционируют, регулирование меняется. Встройте поток обслуживания в исходную оценку и повторяющийся бюджет и относитесь к предложению без строки обслуживания как к неполному — деньги будут потрачены в любом случае, и единственный вопрос в том, были ли они спланированы или извлечены кризисом.

4. Оценивайте привязку до подписания, а не при продлении. Для каждой крупной покупки оценивайте выход, пока у вас ещё есть альтернативы: кто владеет данными, в каком формате их можно экспортировать, какую помощь при выходе должен предоставить поставщик, и сколько правдоподобно стоила бы миграция. Ведите переговоры о правах экспорта данных и открытых интерфейсах в контракте, и относитесь к сопротивлению поставщика этому как к информации о предстоящих переговорах о продлении.

5. Осознанно покупайте интероперабельность, потому что рынок её недопредоставляет. Требуйте поддержку открытых стандартов — FHIR и родственных — как условие покупки, проверяйте заявленное соответствие против ваших фактических потоков данных, а не брошюры, и отказывайтесь от нестандартных интерфейсов там, где существует стандартный. Каждый проприетарный интерфейс, который вы принимаете, — это издержка переключения, которую вы подарили поставщику, и налог на каждую будущую интеграцию.

6. Решайте «производить или покупать» как портфель, сопоставленный с вашей инженерной мощностью. Производите только там, где способность отличает вашу услугу, а вы реалистично можете нанять, удержать и профинансировать команду для поддержания произведённого, — внутренняя система без устойчивой команды — это унаследованная система с дополнительными шагами. Покупайте стандартные потребности; рассматривайте платформы с открытым исходным кодом там, где их поддерживает сообщество или публичный консорциум; и вписывайте план поддержания в решение, каким бы оно ни было.

7. Относитесь к открытому исходному коду как к закупочной опции с собственной структурой издержки, а не как к бесплатному. Сравнивайте его по совокупной стоимости владения: нет платы за лицензию, но есть реальные издержки внедрения, хостинга, поддержки и попечительства, будь то собственными силами или через поставщика поддержки. Взвешивайте его отличительные выгоды — отсутствие премии привязки, проверяемый код, способность совместно финансировать общее благо с другими органами здравоохранения — и его отличительное обязательство: если вы от него зависите, вносите вклад в его поддержание.

8. Устанавливайте цели надёжности из клинических последствий и тратьте под цель. Решайте, услуга за услугой, во что фактически обходится час простоя — в отложенной помощи, небезопасных обходных путях и потерянном доверии, — и устанавливайте цели доступности и восстановления соответственно. Затем держите инженерные расходы у цели с обеих сторон: оплата меньшей надёжности, чем нужно клинике, покупает инциденты, а оплата большей, чем нужно, покупает избыточность.

9. Планируйте замену унаследованного до того, как она станет вынужденной. Пересматривайте возраст и поддерживаемость критических систем циклически и начинайте замену, пока действующая система ещё работает, — миграция, выполненная под провалом, — самый дорогой вид. Предпочитайте инкрементальную миграцию (постепенное вытеснение старой системы интерфейс за интерфейсом) одномоментным переходам, чей провальный режим в здравоохранении измеряется отменёнными клиниками и потерянными записями.

10. Сделайте миграцию данных строкой первого класса в каждой оценке. Данные пациентов переживают каждую систему, которая их держит, а их перемещение — чисто, полно, с обеспеченной клинической безопасностью — рутинно является одной из крупнейших и наиболее заниженных издержек любого перехода. Оценивайте её явно, тестируйте её рано на реальных записях и держите ваши данные в экспортируемой форме на протяжении жизни системы, чтобы миграция никогда не была заложницей уходящего поставщика.

11. Держите инженерию клинической безопасности внутри экономики. Медицинское программное обеспечение — это программное обеспечение, значимое для безопасности: изменения нуждаются в тестировании, релизы нуждаются в путях отката, инциденты нуждаются в расследовании, а юрисдикции всё чаще налагают формальные стандарты клинического риска на медицинские ИТ. Эти дисциплины стоят инженерного времени и принадлежат экономическому обоснованию — «более дешёвая» доставка, пропускающая их, перекладывает издержку на пациентов как риск (издержка вреда — тема 3.11 «Экономика качества и безопасности»).

12. Направляйте решения о программном обеспечении через ту же проверку ценности, что и любую другую инвестицию в здоровье. Программная программа конкурирует за тот же ограниченный бюджет, что и лекарства и персонал, поэтому она несёт ту же дисциплину: заявленную выгоду, реальный компаратор (включая «улучшить то, что у нас есть»), профиль доступности во времени и пересмотр после внедрения против данных обещаний (механизм — тема 2.1 «Экономическая оценка» и тема 2.5 «Влияние на бюджет и доступность», а закупочное мастерство — тема 3.10 «Стратегические закупки и заказ услуг»).

Вопросы для обсуждения с командой

1. Сколько на самом деле стоит наш комплекс программного обеспечения в год, и какую долю этого мы спланировали? Большинство организаций могут назвать свои лицензионные платы, но не издержки интеграции, обслуживания, безопасности и обходных путей, которые прячутся в операционных бюджетах и времени персонала по всей организации. Попросите команду собрать истинную годовую цифру для нескольких главных систем и сравнить её с тем, что обещали исходные экономические обоснования. Напряжение в том, что рассеянные издержки не имеют единственного владельца, поэтому никто не подотчётен за их рост, а люди, одобрившие покупку, редко являются людьми, оплачивающими содержание. Честный ответ производит цифру за весь жизненный цикл, называет, какие бюджеты её несут, и признаёт, где расход незапланирован, — потому что издержка, которую вы обнаруживаете ежегодно постфактум, — это издержка, которой вы не можете управлять.

2. Где наш технический долг, и какие проценты мы по нему платим? Инженерные команды обычно точно знают, где долг, — модуль, который никто не смеет трогать, интерфейс, скреплённый ручными шагами, платформа на два поколения отставшая от поддержки безопасности, — но это знание редко достигает совета директоров на экономическом языке. Попросите реестр: значимые долги, что каждый из них замедляет или ставит под угрозу, и во что обошлось бы его погашение. Напряжение в том, что погашение долга конкурирует с видимыми новыми функциями и всегда проигрывает по видимости, что как раз объясняет, как долг накапливается. Честный ответ количественно оценивает проценты (более медленная доставка, подверженность инцидентам, заблокированные проекты), закладывает постоянную долю мощности на сокращение и принимает, что некоторый долг рационально нести — при условии, что его несут осознанно.

3. Если бы нам пришлось уйти от нашего основного поставщика системы через три года, смогли бы мы — и во что бы это обошлось? Этот вопрос вскрывает привязку, пока ещё есть время её снизить. Проверьте, кто владеет данными и в каком формате они могут уйти, что говорит контракт о помощи при выходе, сколько нестандартных интерфейсов пришлось бы перестроить, и какое переобучение и клиническое нарушение наложила бы миграция. Напряжение в том, что все надеются никогда не воспользоваться выходом, поэтому никто не хочет платить за его сохранение открытым, — однако выход, который невозможен, — это уже проигранные переговоры о продлении. Честный ответ оценивает выход, определяет два-три действия, которые бы его удешевили (права экспорта данных, стандартные интерфейсы, документация), и относится к этой цене как к переговорной позиции, которую организация активно поддерживает.

4. Какие системы нам следует производить, какие покупать, и соответствует ли наша инженерная мощность этому ответу? Разделение «производить или покупать» — портфельное решение, которое многие организации принимают накоплением, а не выбором, в итоге производя стандартные вещи и покупая то, что их отличает. Спросите, какие из ваших систем подлинно воплощают нечто отличительное для вашей услуги, а какие являются стандартными потребностями, которые уже обслуживает рынок или сообщество открытого кода. Затем протестируйте заявление о мощности: для всего произведённого собственными силами, есть ли профинансированная, набираемая команда, обязующаяся поддерживать это на протяжении его жизни, — а не только проект, который это создал? Напряжение в том, что производство льстит амбиции, а покупка льстит осмотрительности, и ни один инстинкт не является анализом. Честный ответ называет отличители, признаёт, где прошлые разработки следует упразднить или заменить стандартными продуктами, и отказывается начинать любую разработку, чьё обслуживание не профинансировано.

5. Во что фактически обходится час простоя в нашей самой критической системе, и соответствуют ли ему наши расходы на надёжность? Решения о надёжности часто принимаются инженерами без информации о клинической издержке или советами директоров без информации об инженерной издержке, поэтому расход соответствует привычке, а не последствию. Проработайте конкретный сценарий: электронная запись недоступна в загруженный день — что откладывается, какие небезопасные обходные пути появляются, какой вред правдоподобно следует, во что обходится восстановление? Затем сравните это с тем, что вы тратите на устойчивость, резервные копии, переключение при отказе и реагирование на инциденты. Напряжение работает в обе стороны: недорасход покупает инциденты, но избыточность низкоставочной системы тратит деньги, нужные другой услуге. Честный ответ устанавливает явную цель доступности и восстановления на каждую критическую услугу, выведенную из клинического последствия, и может показать инженерный расход, соответствующий ей, — не больше, не меньше.

6. Каков наш план для унаследованных систем, которые все боятся трогать? У каждой зрелой организации здравоохранения они есть: системы за пределами экономической поддерживаемости, оставленные живыми, потому что они работают, а замена пугает. Назовите свои. Спросите, что каждая из них блокирует — непостроенные интеграции, невнесённые улучшения, несённую уязвимость безопасности — и каков путь замены: инкрементальная миграция, полная замена или намеренное, спланированное сохранение с ограниченным риском. Напряжение временнóе: издержки сохранения унаследованного рассеяны и ежегодны, тогда как издержка его замены концентрирована и видима для карьеры, поэтому кажущаяся рациональной отсрочка — умолчание, пока провал не вынудит вопрос по худшей возможной цене. Честный ответ планирует замену, пока действующая система ещё работает, предпочитает инкрементальную миграцию в стиле постепенного вытеснения одномоментному переходу и относится к «мы решим в следующем году» как к решению, которым это фактически является.

На практике: пример из экономики здравоохранения

Министерство здравоохранения вымышленной восточноафриканской страны сталкивается с решением о продлении. Девять лет её региональные больницы вели проприетарную систему больничной информации, поставляемую зарубежным поставщиком. Система работает, но котировка продления резко выросла, каждый новый интерфейс — к национальной страховой схеме, к лабораторной сети — является нестандартным, оценённым поставщиком проектом, а контракт молчит об экспорте данных. Тем временем районные управления здравоохранения министерства уже ведут DHIS2, платформу с открытым исходным кодом, используемую для национальной статистики здоровья, а соседняя страна внедрила платформу медицинских записей с открытым исходным кодом с региональным консорциумом поддержки.

Подразделение экономики здравоохранения министерства переформулирует решение с «продлить или нет» на сравнение трёх вариантов на протяжении всего жизненного цикла за десять лет: продлить действующую систему, продлить краткосрочно, строя права выхода, или мигрировать инкрементально на платформу с открытым исходным кодом. Оценка вариантов раскрывает реальную экономику. Лицензия действующей системы составляет лишь треть её истинной годовой издержки, как только посчитаны нестандартные интерфейсы, обязательные проекты обновления и зарубежные поездки поддержки. Вариант с открытым исходным кодом не несёт лицензии, но требует от министерства финансирования национальной команды поддержки, регионального хостинга и вклада в сообщество платформы — реальные, повторяющиеся деньги, которые скрыла риторика «бесплатного программного обеспечения». Решающая строка, однако, ни то ни другое: это миграция данных. Девять лет записей пациентов лежат в проприетарной схеме, и цена поставщика за помощь в извлечении — по сути, цена ухода.

Подразделение всё же оценивает выход, и это число меняет переговоры. Вооружённое оценённой альтернативой, министерство ведёт переговоры о двухлетнем продлении по более низкой цене, включающем контрактный экспорт данных в документированном формате и стандартные интерфейсы FHIR к страховой схеме и лабораторной сети, — купленное, в экономических терминах, как опцион на более дешёвый будущий выход, оценённый так же, как тема 3.12 «Экономика пандемий и готовности к чрезвычайным ситуациям» оценивает любой опцион на будущую свободу действия. В течение этих двух лет пилот мигрирует три районные больницы на платформу с открытым исходным кодом, тестируя консорциум поддержки, инструментарий миграции данных и, критически важно, может ли министерство нанять и удержать инженеров, нужных платформе, опираясь на кадровую экономику темы 3.6 «Кадры здравоохранения и рынки труда».

Пилот преуспевает в двух больницах и испытывает трудности в третьей, где кадровые пробелы превращают каждый инцидент в кризис — предупреждение о мощности, а не программном обеспечении. Министерство продолжает поэтапную национальную миграцию на протяжении пяти лет, больница за больницей, держа действующую систему работающей параллельно, пока данные каждой площадки не верифицированы. Итоговая оценка делает урок явным: выигрышным ходом было не предпочтение открытого исходного кода проприетарному, а оценка всего жизненного цикла каждого варианта, покупка прав выхода до того, как зависимость затвердела дальше, и сопоставление инженерного обязательства с тем, что министерство фактически могло поддерживать.

Четыре отраслевых ракурса

Стартап

Стартап медицинского программного обеспечения живёт экономикой этой темы с продающей стороны: его оценка вознаграждает скорость доставки, что как раз объясняет, как накапливается технический долг, а его модель дохода может незаметно зависеть от привязки, которой должны сопротивляться его клиенты. Дисциплина — осознанно брать долг (сокращение, выигрывающее ключевого клиента, может быть рациональным), ведя при этом реестр и план погашения, потому что кодовая база, которую нельзя изменить, — это компания, которая не может развернуться. Интероперабельность — это стратегия, а не соответствие: стандартные интерфейсы (прежде всего FHIR) — это то, как малый продукт зарабатывает место внутри комплексов, доминируемых действующими игроками. А инженерия клинической безопасности — не бюрократия, которую можно отложить до масштаба; единственный инцидент целостности данных в клинической обстановке может закончить молодую компанию.

Малый бизнес

Небольшой, но устоявшийся поставщик — группа клиник, сеть аптек, диагностическая лаборатория — покупает почти всё своё программное обеспечение и не имеет инженерного персонала для компенсации плохой покупки, поэтому его экономика — это экономика зависимости. Совокупная стоимость владения и права выхода имеют значение здесь больше, чем где-либо, потому что неверно оценённая система пропорционально составляет большую долю бюджета, а провалившаяся миграция может остановить бизнес. Разумная позиция — стандартизация: мейнстримные продукты, интерфейсы открытых стандартов, размещённые услуги, а не самоуправляемые серверы, и контракты, прочитанные на предмет оговорок об экспорте данных до цены. Его отличительный риск — тихое унаследование — система управления практикой, которая стареет на месте, пока её поставщик не закроется, — поэтому даже небольшому покупателю следует знать каждый год, во что обошлось бы уйти от каждой системы, от которой он зависит.

Предприятие

Крупная больничная группа или страховщик ведёт сотни систем, поэтому его проблема — портфель: перекрывающиеся продукты, купленные разными отделами, паутина интеграции, которую никто полностью не картирует, и технический долг, распределённый по комплексу, слишком большому для обзора любой единственной командой. Зрелое предприятие управляет комплексом так же, как управляет инвестиционным портфелем — инвентарём систем с владельцами, издержками жизненного цикла, рейтингами долга и риска и запланированными горизонтами замены, — и финансирует постоянную инженерную способность для интеграции, надёжности и погашения, а не относится к каждому улучшению как к проекту, за который нужно бороться. Масштаб также даёт ему закупочную власть, которой не хватает меньшему покупателю: он может требовать стандартные интерфейсы, права экспорта данных и эскроу как условия входа, и его архитектурные выборы дисциплинируют его поставщиков, а не наоборот.

Государство

Министерство или национальный плательщик формирует эту экономику для всех остальных. Оно устанавливает правила интероперабельности, определяющие, вознаграждает ли рынок открытость или наказывает её, — как сделали Соединённые Штаты положениями против блокирования информации Закона о лечении в XXI веке, а Европейский союз — Европейским пространством медицинских данных, — а его собственные закупки учат поставщиков тому, что покупатели будут терпеть. Его отличительный провальный режим — национальная мегапрограмма: централизованная, одномоментная, политически расписанная доставка программного обеспечения, чей крах измеряется миллиардами, как продемонстрировала Национальная программа по ИТ Великобритании. Дисциплина — обратная позиция: стандарты и платформы централизованно, доставка инкрементально, с серьёзно взвешенными опциями открытого исходного кода и локально поддерживаемыми там, где коммерческие рынки тонки (политический механизм — тема 3.2 «Политика здравоохранения», а закупочное мастерство — тема 3.10 «Стратегические закупки и заказ услуг»).

Типичные ошибки

• Покупка лицензии, а не жизни. Одобрение программного обеспечения по цене покупки, тогда как интеграция, миграция, обслуживание и выход остаются неоценёнными. Решение: требуйте совокупную стоимость владения на весь жизненный цикл, с названными бюджетами для каждой повторяющейся строки, в каждом экономическом обосновании.

• Невидимый долг, пока он не накопится. Позволение техническому долгу накапливаться незарегистрированным, пока комплекс больше нельзя безопасно менять. Решение: ведите реестр долга, отчитывайтесь о нём в экономических терминах и закладывайте постоянную мощность на погашение.

• Незаметное сползание в привязку. Принятие проприетарных форматов и нестандартных интерфейсов, пока выход не станет недоступным по средствам, а продления диктуются. Решение: ведите переговоры о правах экспорта данных и стандартных интерфейсах при покупке и оценивайте выход ежегодно.

• Производство того, что нельзя поддерживать. Заказ внутренних систем без профинансированной команды на весь их жизненный цикл. Решение: никакого производства без плана поддержания; покупайте или принимайте платформы с открытым исходным кодом там, где мощность тонка.

• Отношение к открытому исходному коду как к бесплатному. Принятие платформ сообщества без финансирования хостинга, поддержки и попечительства. Решение: оценивайте открытый исходный код по совокупной стоимости владения и закладывайте в бюджет нужное поддержание.

• Надёжность на надежде. Оставление целей доступности неустановленными, пока сбой не раскроет клиническую издержку простоя. Решение: устанавливайте цели доступности и восстановления на каждую критическую услугу из клинического последствия и тратьте под цель.

• Одномоментная замена унаследованного под принуждением. Отсрочка модернизации, пока провал не вынудит поспешный, полный переход. Решение: планируйте замену, пока действующая система работает, и мигрируйте инкрементально с параллельным ведением и верифицированными данными.

• Программное обеспечение вне дисциплины ценности. Позволение ИТ-программам пропускать проверку, применяемую к лекарствам и услугам. Решение: те же правила — заявленная выгода, реальный компаратор, профиль доступности, пересмотр после внедрения.

Модель зрелости

Контрольный список

• Оценивайте каждое решение о программном обеспечении по совокупной стоимости владения на его реалистичный жизненный цикл, с названными бюджетами для каждой повторяющейся строки.
• Ведите реестр технического долга, отчитывайтесь о нём в экономических терминах и закладывайте постоянную инженерную мощность на погашение.
• Финансируйте обслуживание как запланированную операционную издержку с исходного экономического обоснования и далее.
• Ведите переговоры о правах экспорта данных, стандартных интерфейсах и помощи при выходе в контрактах при покупке.
• Оценивайте выход из каждой крупной системы ежегодно и держите оценённую альтернативу живой до продлений.
• Требуйте проверенное соответствие открытым стандартам (например, FHIR) как условие покупки.
• Решайте «производить или покупать» как портфель и не начинайте никакого производства без профинансированного плана поддержания на весь жизненный цикл.
• Оценивайте опции открытого исходного кода по совокупной стоимости владения, закладывая в бюджет хостинг, поддержку и попечительство.
• Устанавливайте цели доступности и восстановления на каждую критическую услугу из клинического последствия и сопоставляйте расход с ними.
• Планируйте замену унаследованного, пока действующие системы ещё работают, предпочитая инкрементальную миграцию одномоментному переходу.
• Оценивайте и тестируйте миграцию данных рано и держите данные пациентов экспортируемыми на протяжении жизни каждой системы.
• Направляйте программные программы через ту же проверку ценности, что и любую другую инвестицию в здоровье, с пересмотром после внедрения.

Ключевые источники

• 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.

Список литературы

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