Тема 1.0 — Способы работы в цифровом здравоохранении и уходе

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

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

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

Здравоохранение и уход отличаются так, что это определяет каждую практику в этой книге. Безопасность не подлежит обсуждению: дефект цифровой услуги может навредить пациенту, поэтому управление клиническими рисками (см. тему 1.6 — Клиническая безопасность и управление рисками) пронизывает поставку, а не навешивается сверху. Равенство важно, потому что услуга, работающая только для уверенных пользователей цифровых технологий, увеличивает неравенство в здоровье; группы Core20PLUS5 и люди с ограниченным цифровым доступом должны учитываться при проектировании, а не исключаться из него. Законодательные обязанности, то есть обязательство NHS обеспечивать всестороннюю помощь, законодательство о защите данных, обязанность соблюдать конфиденциальность, ограничивают то, что вы можете делать с данными и как обязаны проводить консультации. Государственные деньги требуют соразмерного контроля расходов и демонстрируемой ценности. И почти ничего не создаётся одной организацией: партнёрство между интегрированными системами ухода (ICS), местными органами власти, поставщиками социального ухода и подрядчиками — обычное условие работы.

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

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

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

Проектирование, ориентированное на пользователя означает, что отправной точкой служат потребности людей, пользующихся услугой (пациентов, лиц, осуществляющих уход, клиницистов, администраторов), а не предполагаемое решение. Британская Government Digital Service (GDS) и NHS закрепили это в стандартах услуг: поймите пользователей и их потребности, прежде чем строить, и продолжайте проверку с реальными пользователями на всём протяжении работы.

Гибкая (agile), итеративная поставка означает, что работающая услуга как можно раньше попадает к реальным пользователям, вы учитесь и адаптируетесь, а не расписываете всё заранее. Руководство по цифровым услугам NHS прямо говорит, что гибкие, ориентированные на пользователя способы работы снижают риск создания не того, что нужно. Agile здесь — не только метод поставки, но и стратегия управления рисками.

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

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

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

1. Начинайте с потребностей пользователей, подтверждённых исследованием. Прежде чем браться за разработку, поймите, кто пользователи, чего они пытаются добиться и где текущая услуга их подводит. Профинансируйте исследование (см. тему 3.4 — Фазы исследования) и считайте «мы предположили» тревожным сигналом. Опорой для всех последующих решений служат потребности пользователей, а не внутренние предпочтения.

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

3. Работайте открыто и двигайтесь малыми шагами. Выпускайте тонкие срезы, измеряйте и корректируйтесь. Небольшие частые релизы безопаснее запусков «большим взрывом», потому что проблемы выявляются, пока они малы, и потому что проверка клинической безопасности и управления информацией успевает за изменениями, а не превращается в барьер в конце.

4. С первого дня делайте безопасность и равенство первоочередными. Проводите управление клиническими рисками (DCB0129/DCB0160) и анализ равенства и неравенства в здоровье параллельно с поставкой, а не как согласование на последнем этапе. Рано спрашивайте, кто может быть исключён или пострадать, и проектируйте под самые трудные случаи: маршруты с цифровой помощью, доступность (WCAG) и офлайн-запасные варианты.

5. Решайте на основании доказательств и записывайте решение. Различайте клинические доказательства (работает ли это и безопасно ли?) и доказательства поставки (хорошо ли мы строим и пользуются ли этим?) и ведите лёгкий журнал решений, чтобы обоснование пережило текучесть кадров (см. тему 1.3 — Решения на основе доказательств). Доказательства важнее мнения самого высокооплачиваемого человека.

6. Проектируйте для интероперабельности и повторного использования. Данные здравоохранения и ухода должны безопасно перемещаться между организациями; стройте на открытых стандартах (HL7 FHIR, SNOMED CT) и используйте платформы повторно, а не изобретайте заново (см. «тончайшую жизнеспособную платформу» в теме 1.1 и тему 4.3 — Интероперабельность и стандарты данных). Услуга, не способная делиться данными, — это изолированный «силос», который ждёт, чтобы стать риском.

7. Управляйте соразмерно. Соотносите вес гарантий с уровнем риска. Высокорисковые клинические изменения заслуживают глубокой проверки; низкорисковые изменения содержания не должны неделями ждать совета. Соразмерное управление делает вас одновременно безопасными и быстрыми.

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

9. Проектируйте на длительную перспективу и для передачи. Цифровые услуги в здравоохранении живут дольше, чем команды и контракты, которые их создают, поэтому фиксируйте решения, избегайте недокументированных «геройских» знаний и проектируйте для людей, которые будут годами эксплуатировать и менять услугу (см. тему 10.3 — Управление знаниями и документация). Рассматривайте устойчивость команды, технологии и модели финансирования как первоочередное ограничение, а не запоздалую мысль.

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

1. Где наши нынешние способы работы унаследованы, а не выбраны, и какая унаследованная привычка обходится нам дороже всего в безопасности, равенстве или впустую потраченных средствах? Этот вопрос заставляет честно проверить практики, которые никто не выбирал, но все соблюдают: финансирование программ с фиксированным объёмом, команды проектов, которые распускают и собирают заново, согласование управления только перед запуском. Это важно, потому что унаследованные привычки обычно невидимы, пока не названы, а в здравоохранении и уходе они имеют реальную цену: общая карта, которой не доверяют клиницисты, услуга, исключающая группы Core20PLUS5, или повторная сборка одной и той же «сантехники» входа за государственный счёт. Противоречие для обсуждения в том, что унаследованные способы кажутся безопасными именно потому, что знакомы и поддаются аудиту, поэтому отказ от них выглядит как принятие риска, а не его устранение. Опирайтесь в обсуждении на конкретные артефакты: посмотрите три последних бизнес-кейса, текучесть команд между проектами и момент, когда впервые подключили клиническую безопасность, а не обменивайтесь мнениями. Хороший ответ называет одну-две конкретные привычки с доказательствами их цены, отделяет те, что стоит сохранить, от тех, что активно вредят результатам, и обязуется провести изменение, за которое будет отвечать старший руководитель.

2. Действительно ли в наших командах есть полный мультидисциплинарный набор навыков, включая клиническую безопасность и управление информацией, или эти дисциплины по-прежнему навешены как барьеры на последнем этапе? Тема утверждает, что MDT — атом цифровой поставки и что большинство сбоев восходит к отсутствию дисциплины за столом, поэтому вопрос проверяет, реален ли этот принцип в вашей организации или лишь декларируется. Это важно, потому что специалист по клинической безопасности или Caldicott Guardian, подключённый лишь перед запуском, вынуждает либо переделывать работу, либо идти на небезопасные упрощения, тогда как подключённый с первой недели ведёт живой журнал опасностей, задающий темп поставке. Компромисс, который стоит вынести на свет, — стоимость и дефицит: время узких клинических, юридических и IG-специалистов действительно ограничено, поэтому «встроить всех в каждую команду» сталкивается с реальными ресурсными ограничениями, и команде нужно решить, где допустимы частичные или общие роли, а где нет. Возьмите действующую услугу и составьте карту: кто на самом деле входит в постоянную команду, а кого привлекают как внешнее согласование, и есть ли у команды право решать в границах или ей приходится постоянно эскалировать. Честный, хороший ответ конкретен в том, каких дисциплин не хватает или какие «взяты взаймы», откровенно признаёт ресурсное противоречие и предлагает конкретную модель (полная занятость, частичная или по вызову), позволяющую закрыть разрыв, не делая вид, что дефицита нет.

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

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

5. Где мы заново изобретаем «сантехнику», которая уже существует, и где построение на открытых стандартах и повторное использование общих платформ действительно изменило бы то, что мы поставляем? Проектирование для интероперабельности и повторного использования — одна из лучших практик темы, и этот вопрос заставляет команду увидеть тягу строить своё вместо повторного использования: вход, уведомления, интеграцию с картой, которые уже сделали десятки других команд. Это важно, потому что в раздробленной системе каждый заново изобретённый компонент — государственные деньги, потраченные дважды, и новый «силос», не способный безопасно обмениваться данными; и наоборот, построение на HL7 FHIR и SNOMED CT и повторное использование тончайшей жизнеспособной платформы — то, что вообще позволяет услуге пройти закупку и делиться данными в рамках ICS. Реальный компромисс в том, что повторное использование означает зависимость: общая платформа может быть медленнее, менее подогнана или управляться чужой дорожной картой, поэтому команда должна сопоставить издержки общего компонента с долгосрочной ценой и риском собственного «силоса». Изучите текущую разработку и перечислите, что действительно ново, а что дублирует существующую платформу, стандарт или открытый компонент, и проверьте, является ли «мы не можем это использовать» подтверждённым ограничением или непроверенным допущением. Хороший ответ отделяет то, что стоит строить, от того, что стоит использовать повторно, честно оценивает зрелость и управление предлагаемых платформ и обязуется использовать открытые стандарты для всего, что должно обмениваться данными.

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

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

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

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

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

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

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

Стартап#

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

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

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых или агентство ухода на дому, клиника в одном месте или скромный поставщик health-tech, миновавший стадию без выручки) несёт те же давления безопасности, равенства, обязанности и денег, что и крупный траст, но с долей возможностей для их преодоления. Способы работы здесь должны быть радикально соразмерными: выделенной цифровой или IG-команды почти никогда нет, поэтому «мультидисциплинарная команда» — это часто несколько человек в нескольких ролях плюс общий или аутсорсинговый ресурс по клинической безопасности и защите данных. Ловушка — предположить, что законодательные обязанности уменьшаются вместе с организацией; это не так, поэтому клиническая безопасность DCB0129/DCB0160, оценка воздействия на защиту данных и доступность действуют в полном объёме, даже когда за все отвечает один управляющий практикой. Практическая дисциплина — активно опираться на повторное использование, а не строить: принимайте аккредитованные готовые системы, требуйте от поставщиков соответствия DTAC и открытым стандартам (FHIR, SNOMED CT) и пользуйтесь платформами национального уровня и ICS, чтобы безопасность, интероперабельность и управление информацией были унаследованы, а не изобретены заново на скудные средства.

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

У траста NHS или ICS обратная проблема: изобилие процессов и раздробленная ответственность. Способы работы здесь связаны не только с освоением новых практик, но и с разучиванием: отказом от привычек программ с фиксированным объёмом, прекращением роспуска и пересборки проектных команд. Подотчётность формальна и персональна (старший ответственный владелец, Caldicott Guardian, согласование клинической безопасности на уровне совета), поэтому выигрыш — во встраивании этих ролей в команду поставки, а не в навешивании их как барьеров. Крупный поставщик health-tech или фармацевтики сталкивается с зеркальной картиной: сильная инженерная зрелость, но дистанция от клинической реальности на переднем крае, которую призваны сократить мультидисциплинарные команды с реальным временем клиницистов.

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

Национальный или местный государственный орган (NHS England, DHSC, UKHSA, местный орган власти) задаёт стандарты, по которым работают все остальные, поэтому его способы работы расходятся волнами. Его подотчётность направлена парламенту и обществу, что повышает планку прозрачности, контроля расходов и равенства: стандарт услуг, опубликованный маршрут гарантий и обязанности Core20PLUS5 — инструменты этой подотчётности, а не необязательные дополнения. Риск на этом масштабе — централизованно проектировать для среднего гражданина, которого не существует, и предписывать решение прежде, чем понята местная потребность. Лекарство — та же ориентированная на пользователя итеративная дисциплина, что и везде, но с уклоном в установление открытых стандартов и повторно используемых платформ, на которых могут строить федеративные организации: управление системой, а не только поставка услуги.

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

• Поставка «сначала решение». Обязательство перед конкретным продуктом до понимания потребности. Противоядие: финансировать исследование и сделать потребности пользователей условием начала разработки.
• Управление как поздний барьер. Клиническая безопасность и управление информацией привлекаются только перед запуском, что вынуждает переделывать работу или идти на небезопасные упрощения. Противоядие: встроить обе в команду с первого дня.
• Текучка проектов. Создание и роспуск команд с потерей с трудом добытых знаний предметной области и безопасности. Противоядие: продуктовое финансирование и постоянные команды.
• Чистилище пилотов. Бесконечные пилоты, которые не масштабируются, потому что внедрение, обучение и организационные изменения так и не получили ресурсов (см. тему 8.1 — Управление изменениями). Противоядие: спланировать путь к масштабу до пилота.
• Равенство как запоздалая мысль. Проектирование для уверенного большинства и исключение тех, кому уход нужен больше всех. Противоядие: проектировать сначала для самых трудных случаев.

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

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

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

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

• NHS digital service manual — NHS service standard и его пункты, включая «Use agile ways of working» и «Create a team that includes multidisciplinary skills and perspectives» (service-manual.nhs.uk).
• GOV.UK Service Manual и Government Service Standard — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC).
• Стандарты клинической безопасности DCB0129 и DCB0160 (NHS England / бывший NHS Digital).
• NICE — Evidence Standards Framework for digital health technologies (nice.org.uk).
• NHS England — подход Core20PLUS5 к сокращению неравенства в здоровье.

Ссылки#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/