Тема 4.1 — Платформы и общие услуги

В здравоохранении и уходе общая платформа — не удобство для экономии, а способ сделать безопасность, равенство и доверие воспроизводимыми, чтобы каждая команда наследовала их, а не изобретала заново, часто плохо.

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

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

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

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

Ключевые понятия#

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

Под этим лежит несколько родственных идей. Общие услуги (shared services) — более старый организационный паттерн предоставления возможности один раз для многих частей организации вместо дублирования в каждой. Цифровая общественная инфраструктура расширяет это до уровня всего общества: общие, повторно используемые, интероперабельные строительные блоки (идентификация, платежи, обмен данными), на которых строятся публичные и частные услуги. «Правительство как платформа» (government as a platform), фраза, придуманная Тимом О'Райли и подхваченная командами цифрового правительства по всему миру, применяет ту же логику к государству: правительство предоставляет общие компоненты, а ведомства составляют из них услуги, а не каждое строит полный стек.

Технически платформы часто выставляют свои возможности через интерфейс прикладного программирования (API): определённый контракт, позволяющий одной системе использовать возможность другой, не зная её внутренностей. Они часто опираются на облачные модели платформы как услуги (PaaS), а общие национальные платформы обычно полагаются на мультиарендность (multitenancy), где единый экземпляр обслуживает многие организации, сохраняя их данные и конфигурацию раздельными.

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

В здравоохранении конкретно национальные общие услуги уже часть ландшафта. Исторические программы вроде NHS Connecting for Health создали NHS Spine, набор национальных услуг, несущих основные данные, такие как Personal Demographics Service. Современные эквиваленты включают национальные API, NHS login для аутентификации граждан и NHS Notify для сообщений: возможности, предлагаемые, чтобы отдельным услугам не приходилось строить их заново. Там, где платформа даёт общий способ доказать, кто человек, она часто выставляет единый вход (single sign-on), так что клиницист аутентифицируется один раз, а не неоднократно. Эта тема касается того, как строить и вести такие платформы; детали того, кто вы и что вам разрешено, относятся к теме 4.2 — Управление идентификацией и доступом, а стандарты, позволяющие системам обмениваться данными, — к теме 4.3 — Интероперабельность и стандарты данных.

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

1. Относитесь к платформе как к продукту, а не проекту. У платформы есть дорожная карта, менеджер продукта, текущее финансирование и пользователи, удовлетворённость которых вы измеряете, а не дата окончания и передача. Проекты заканчиваются и распадаются; платформы нужно вести бессрочно, потому что команды начинают от них зависеть. Финансируйте и комплектуйте соответственно и см. тему 5.0 — Работа, ведомая продуктом для операционной дисциплины, которую это подразумевает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интегрированная система ухода (ICS), охватывающая несколько трастов NHS, общественных поставщиков и службу социального ухода за взрослыми совета графства, раз за разом упирается в одну и ту же стену. Каждая новая цифровая услуга (виртуальное отделение, форма самонаправления на общественную физиотерапию, инструмент надзора за домами престарелых) тратит первые три месяца на пересборку одних и тех же основ: подтверждение, кто пациент, проверка роли специалиста, SMS-напоминания и запись следа аудита. Сопоставление пациентов у команды виртуального отделения оказывается слабее, чем у команды физиотерапии, и происходит почти-происшествие, когда напоминание отправлено не тому человеку. Цифровое руководство ICS распознаёт закономерность: они платят многократно за возможности, которые должны существовать один раз, а вариация — риск безопасности.

Вместо заказа грандиозной платформы ICS они начинают тонко. Они поднимают единую общую услугу, делающую одну вещь хорошо: она оборачивает NHS login и национальный Personal Demographics Service за чистым, документированным API с песочницей, так что любая команда может проверить идентичность гражданина и получить подтверждённую демографическую запись по одному поддерживаемому пути. Небольшая команда платформы из пяти человек относится к ней как к продукту. Они публикуют руководство «мощёной дороги», предлагают самообслуживаемое подключение и задают цель, что новая команда должна сделать первый успешный вызов в течение дня. Решающе важно, что они её не предписывают. Они делают её самым лёгким вариантом и позволяют команде виртуального отделения быть первым готовым принять.

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

Отраслевые перспективы#

Стартап#

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

Малый бизнес#

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

Крупная организация#

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

Государство#

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

Типичные способы сбоя#

• Узкое место. Каждая команда должна ждать центральную команду платформы, чтобы сделать что-либо, так что платформа замедляет поставку вместо ускорения. Лекарство — самообслуживание: команды должны иметь возможность подключаться и действовать без заявки.
• Башня из слоновой кости. Платформу проектируют люди, далёкие от поставки, она технически восхитительна и не подходит потребностям ни одной реальной команды. Лекарство — вести платформу как продукт с непрерывным исследованием пользователей.
• Предписана, но нелюбима. Платформа требуется политикой, но обходится на практике, накапливая теневые системы и раздражение. Лекарство — заработать принятие качеством и слушать, когда команды идут в обход.
• Платформа «всего». Чрезмерно амбициозный объём означает, что платформа приходит поздно, делает слишком много и ничего не делает хорошо. Лекарство — тончайшая жизнеспособная платформа, растущая из доказательств спроса.
• Привязка исподтишка. Платформа тихо привязывает команды к проприетарному поставщику или интерфейсу, и цена ухода становится непосильной. Лекарство — открытые стандарты и документированный, проверенный путь выхода.
• Неопределённость финансирования. Никто не согласовал, кто платит и кто решает, поэтому платформа голодает или становится политическим полем сражений. Лекарство — явная, опубликованная модель финансирования и управления.
• Безопасность как запоздалая мысль. У платформы нет собственного обоснования клинической безопасности, поэтому каждая потребляющая услуга наследует неоценённый риск. Лекарство — считать обоснование безопасности платформы по DCB0129 основополагающим.

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

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

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

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

• GOV.UK Service Manual и тексты Government Digital Service о правительстве как платформе и общих компонентах.
• Matthew Skelton и Manuel Pais, Team Topologies: команды платформы, тончайшая жизнеспособная платформа и когнитивная нагрузка.
• Руководство NHS England для разработчиков и по API (NHS login, NHS Notify, национальные API и услуги Spine).
• Стандарты управления клиническими рисками DCB0129 и DCB0160 для систем медицинских ИТ.
• Тексты Всемирного банка и ООН о цифровой общественной инфраструктуре и повторно используемых общественных строительных блоках.
• Tim O'Reilly, «Government as a Platform», в Open Government (O'Reilly Media).

Ссылки#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation