Тема 4.3 — Интероперабельность и стандарты данных

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

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

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

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

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

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

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

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

Данные здравоохранения обмениваются по стандартам. Health Level 7 (HL7) — семейство стандартов, наиболее используемое в здравоохранении. Его старый обмен сообщениями HL7 версии 2 (v2), использующий текст с разделителями «вертикальная черта и каретка», по-прежнему лежит в основе огромной части больничного обмена и останется там на годы. Его современный стандарт, HL7 Fast Healthcare Interoperability Resources (FHIR), моделирует клиническую информацию как «ресурсы», обмениваемые по веб-подобным программным интерфейсам приложений (API), что намного облегчает работу современным разработчикам.

Стандартов для сообщения мало; нужны также стандартные словари для содержания. SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) — клиническая терминология, обязательная во всей помощи NHS для записи диагнозов, симптомов, процедур и прочего. NHS Dictionary of medicines and devices (dm+d) — стандартный словарь лекарств и медицинских изделий, лежащий в основе электронного назначения. Международная классификация болезней, 10-го и 11-го пересмотров (МКБ-10 и МКБ-11), поддерживаемая Всемирной организацией здравоохранения, используется для классификации, статистики и возмещения расходов, а не для повседневной клинической записи. openEHR — открытая спецификация структурирования самой медицинской записи через общие, клинически управляемые «архетипы»; её используют некоторые организации, чтобы клинические модели данных не зависели от какого-либо одного поставщика.

Ещё две идеи фундаментальны. Номер NHS (NHS Number) — общий идентификатор пациента, позволяющий надёжно связывать записи об одном и том же человеке между организациями; без общего идентификатора сопоставление — гадание. А Integrating the Healthcare Enterprise (IHE) публикует «профили», точно задающие, как сочетать существующие стандарты для решения конкретных задач, например обмена документами, чтобы разные поставщики реализовывали их одинаково.

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

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

1. Различайте семантическую и техническую интероперабельность и проектируйте для обеих. Легко праздновать, что сообщение теперь течёт между двумя системами, и не заметить, что принимающий клиницист не может безопасно полагаться на его смысл. Всегда спрашивайте: интерпретирует ли другая сторона эти коды, единицы и отрицания в точности так же, как мы? Вкладывайтесь в общие терминологии (SNOMED CT, dm+d) и наборы значений, а не только в форматы сообщений, потому что правильно переданная, но неверно понятая аллергия опаснее отсутствия сообщения.

2. Стройте на открытых стандартах и повторно используйте платформы, а не изобретайте заново. Примите широко одобренный принцип: стройте на открытых стандартах и повторно используйте существующие национальные платформы и услуги, прежде чем строить свои. В NHS это значит предпочитать API HL7 FHIR, использовать номер NHS как идентификатор и подключаться к национальным службам, таким как Spine, GP Connect и общие записи ухода, а не создавать индивидуальные связи «точка-точка». Повторное использование снижает стоимость, распределяет бремя сопровождения и означает, что ваши данные могут путешествовать.

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

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

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

6. Используйте опубликованные профили и тестирование на соответствие, а не местные трактовки. Стандарты гибки, и две команды могут реализовать «один и тот же» ресурс FHIR несовместимо. Принимайте национальные руководства по реализации и профили IHE, фиксирующие детали, и требуйте от поставщиков демонстрации соответствия им до запуска. Тестирование на соответствие превращает «мы поддерживаем FHIR» — утверждение, само по себе значащее очень мало, — в проверяемый, договорной факт.

7. Вписывайте требования интероперабельности и открытых стандартов в закупки и контракты. Дешевле всего избежать привязки до подписания. Требуйте открытые, документированные API, право извлечь свои данные в стандартном формате, соблюдение названных стандартов и отсутствие платы за стандартные интеграции. Работайте с коммерческими коллегами (см. тему 6.3 — Закупки и коммерческие вопросы), чтобы это стало обязательными критериями оценки, а не пожеланиями, которые потом выторгуют обратно.

8. Управляйте интероперабельностью с клинической безопасностью и управлением информацией в одной комнате. Каждый новый поток данных меняет клинический риск и обращение с конфиденциальной информацией. Привлекайте клинических офицеров безопасности и руководителей по управлению информацией к проектным решениям с самого начала, а не как к финальной подписи, чтобы общие записи были и безопасны, и законны. Это напрямую связано с темой 1.6 — Клиническая безопасность и управление рисками и темой 1.7 — Управление информацией, защита данных и кибербезопасность.

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

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

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

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

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

5. Кто владеет стандартами, терминологией и соответствием в нашей организации и есть ли у него мандат сказать «нет»? Без стюардства интероперабельность распадается: наборы значений дрейфуют, местные руководства расходятся, и каждый новый проект тихо изобретает свою трактовку. Спросите, есть ли названная функция, отвечающая за стандарты, подмножества SNOMED CT и dm+d и соответствие, или это знание сидит в головах нескольких человек. Подумайте о напряжении между центральным единообразием и скоростью местной поставки: команды под давлением построят самое быстрое, если у функции стандартов нет реальных полномочий требовать повторного использования. Обсудите, как финансируется сопровождение терминологии, учитывая, что оно неблагодарное, непрерывное и выгодно всем, а не какому-то одному проекту. Посмотрите, как вы поддерживаете реализации в согласии по мере развития FHIR, SNOMED CT и национальных руководств, а не замораживаетесь на версии, принятой первой. Честный ответ называет ответственного владельца, его финансирование и недавний пример, когда он либо обеспечил соблюдение стандарта, либо не смог.

6. Информированы ли люди, чьи записи мы объединяем, и согласны ли они с тем, как текут их данные? Интероперабельность — не только техническое и клиническое дело, но и вопрос общественного доверия и правового основания. Люди разумно полагают, что NHS уже разумно делится их информацией, и разочарованы и тогда, когда это не так, и тогда, когда это делается неожиданным для них образом. Обсудите, понимают ли пациенты, какие организации видят их общую запись, как соблюдается National Data Opt-Out или местная модель согласия по всему потоку и как доступ фиксируется и поддаётся аудиту. Подумайте о измерении равенства: люди, чьи данные наиболее фрагментированы, — с сложными потребностями — менее всего способны ориентироваться в отказах и информационных уведомлениях. Привлекайте управление информацией и, где уместно, пациентов или их представителей к проектированию, а не рассматривайте согласие как галочку в конце. Честный ответ может описать правовое основание каждого потока, то, как человек узнал бы, кто видел его запись, и то, как его выбор соблюдается от начала до конца.

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

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

Соблазн — купить у одного поставщика «дашборд лекарств» и подключить его напрямую к базе данных каждой системы. Руководитель по интероперабельности сопротивляется. Вместо этого программа принимает подход «строить на открытых стандартах». Каждая исходная система открывает данные о лекарствах как ресурсы HL7 FHIR; каждое лекарство кодируется по dm+d, чтобы «один и тот же препарат» везде значил одно и то же; а каждая запись привязана к проверенному номеру NHS, чтобы нужные лекарства относились к нужному человеку. Данные общей практики берутся через GP Connect, а не через индивидуальный канал: повторно используется национальная возможность, а не изобретается местная.

Ранее профилирование данных сразу доказывает свою пользу. Система одной практики записывала некоторые лекарства свободным текстом, а не закодированными записями dm+d, из-за чего они были бы невидимы для любой автоматической проверки взаимодействий. Это исправляется у источника до запуска. Команда также находит группу записей с непроверенными номерами NHS и пропускает их через национальную демографическую службу для сопоставления.

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

Секторные линзы#

Стартап#

Стартап в цифровом здравоохранении живёт или умирает в зависимости от того, как легко он подключается к существующим системам, поэтому относитесь к интероперабельности как к основной функции, а не к формальности соответствия. Создание API FHIR и использование SNOMED CT и dm+d с самого начала делает вас намного проще для покупки и интеграции и сигнализирует зрелость осторожным покупателям NHS. Сопротивляйтесь желанию изобретать свою модель данных, когда стандарт существует; ваше отличие должно быть в продукте, а не в проприетарном формате, который станет обузой. Правильная работа с номером NHS и управлением информацией на раннем этапе позволяет перейти от пилота к закупке. Проектируйте так, чтобы клиент в принципе мог извлечь свои данные и уйти: парадоксально, эта открытость и зарабатывает доверие, чтобы его удержать.

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

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или клиника на одной площадке — несёт те же обязанности безопасно делиться данными, что и крупнейший траст, но с долей технических возможностей. Здесь интероперабельность — в основном дисциплина закупки и конфигурации, а не инженерии: выбирайте системы, уже говорящие на FHIR, подключайтесь к национальным службам, таким как GP Connect и Spine, и кодируйте по SNOMED CT и dm+d «из коробки», чтобы стандарты вам достались, а не строились вами. Сделайте фиксацию проверенного номера NHS частью повседневной практики, потому что без команды интеграции, которая позже согласует несовпадения, правильный идентификатор в момент регистрации — ваша самая дешёвая защита. Опирайтесь на программы общих записей ухода и общую инфраструктуру вашей интегрированной системы ухода, а не заказывайте индивидуальные связи, которые не сможете поддерживать. Подписывая или продлевая контракт на систему, простыми словами настаивайте на правах извлечения данных и открытых интерфейсах, потому что малая организация острее всех ощущает привязку к поставщику и меньше всех имеет рычагов вырваться после факта.

Предприятие#

Крупный поставщик услуг или организация-поставщик обычно несёт десятилетия унаследованных систем: интерфейсы HL7 v2, несколько электронных систем записей и интеграционные движки, всё это скрепляющие. Реалистичная стратегия — не выбросить всё, а поставить перед этим хозяйством API-ориентированный слой на стандартах, поэтапно переводя потоки на FHIR и сохраняя v2 там, где это необходимо. Жёстко берегитесь привязки при каждом продлении и настаивайте на тестировании на соответствие, чтобы «соответствие стандартам» проверялось, а не декларировалось. Создайте внутреннюю функцию по стандартам и соответствию, чтобы отдельные проекты не изобретали каждый свою трактовку. Это тесно связано с тем, как вы управляете основными операционными платформами в теме 5.4 — Планирование ресурсов предприятия (ERP), где действует та же дисциплина повторного использования и открытых интерфейсов.

Правительство#

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

Типичные виды отказов#

• Путаница технического соединения с семантическим пониманием. Объявление победы, когда сообщение течёт, без подтверждения, что обе стороны одинаково интерпретируют его коды, единицы и отрицания. Результат — данные, выглядящие интегрированными, но тихо понимаемые неверно.
• Более быстрая передача плохих данных. Расширение канала до исправления качества данных, из-за чего ошибки кодирования, свободный текст и отсутствующие номера NHS распространяются в решения других клиницистов и в каждый последующий анализ.
• «Мы поддерживаем FHIR» как пустое утверждение. Принятие метки стандарта без тестирования на соответствие конкретному руководству по реализации, так что две «совместимые» системы по-прежнему не могут общаться друг с другом.
• Индивидуальные интеграции «точка-точка». Построение прямых связей между каждой парой систем, порождающее хрупкую паутину, которую становится экспоненциально труднее и дороже поддерживать по мере роста.
• Привязка по умолчанию. Подписание контрактов с проприетарными интерфейсами и без прав извлечения данных, цена ловушки обнаруживается лишь при попытке сменить поставщика.
• Управление как финальный шлюз. Привлечение клинической безопасности и управления информацией только для подписи, из-за чего проблемы всплывают поздно и дорого или проходят под давлением поставки.
• Стандарты без стюардства. Принятие терминологий и профилей без финансирования тех, кто будет поддерживать наборы значений, следить за соответствием или держать реализации в согласии по мере развития стандартов.

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

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

• Каждая релевантная запись и интерфейс несут проверенный номер NHS, с процессом разрешения отсутствующих или несопоставленных.
• Новые интерфейсы используют HL7 FHIR и названные национальные руководства по реализации, а HL7 v2 сохраняется лишь там, где миграция ещё не оправдана.
• Клиническое содержание кодируется по SNOMED CT, а лекарства — по dm+d, по согласованным наборам значений.
• Качество данных для всего, чем вы намерены делиться, профилируется, измеряется, закреплено за владельцем и улучшается у источника до расширения канала.
• Поставщики должны пройти тестирование на соответствие конкретному профилю до подключения: «поддерживает FHIR» никогда не принимается само по себе.
• Национальные платформы (Spine, GP Connect, общие записи ухода) используются повторно до построения любой индивидуальной интеграции.
• Контракты вменяют открытые документированные API, права извлечения данных в стандартном формате и отсутствие платы за стандартные интеграции.
• Руководители по клинической безопасности и управлению информацией входят в проектную группу с самого начала, а не только на подписи.
• Архитектура API-ориентирована и слабо связана, так что компонент можно заменить, не перестраивая всё вокруг.
• Названная функция отвечает за стандарты, соответствие и сопровождение терминологии по всей организации.

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

• NHS England — стандарты интероперабельности, Spine, GP Connect и программы общих записей ухода.
• HL7 International — стандарт FHIR и спецификации HL7 v2.
• SNOMED International — терминология SNOMED CT и руководство по внедрению.
• NHS Business Services Authority — Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — профили интероперабельности.
• openEHR International — открытые спецификации структурирования медицинской записи.
• Всемирная организация здравоохранения — Международная классификация болезней (МКБ-10 и МКБ-11).

Литература#

1. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipedia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipedia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipedia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipedia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipedia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipedia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipedia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases