Служба персональных демографических данных (PDS) - это национальная электронная база данных о пациентах NHS. Это безопасная база данных, содержащая демографическую информацию, такую как имя, адрес, дату рождения и номер NHS, чтобы помочь медицинским работникам идентифицировать пациентов и сопоставлять их с их медицинскими записями. Это также позволяет им контактировать и общаться с пациентами.

PDS существует около 15 лет и ранее использовал SOAP API. Одной из самых больших проблем была интеграция, поскольку было технически сложно подключиться к цифровым службам NHS. В опросе внешние разработчики оценили NHS Digital Services на 2 из 5 баллов за простоту интеграции.

Цель

Миссия этого проекта заключалась в том, чтобы «упростить интеграцию». Команда NHS Digital сформулировала видение управления API с целями, чтобы облегчить разработчикам:

• на борту, прося разработчиков делать то, что необходимо
• узнать, сделав документацию доступной в Интернете
• проектировать и строить, делая API-интерфейсы доступными в Интернет и используя открытые стандарты
• test, предоставляя разработчикам среды песочницы для раннего тестирования
• получить помощь и поддержку с помощью самообслуживания и надежных справочных ресурсов

В дополнение к этим общим принципам, команда могла бы переработать PDS API как образец API. Это поможет показать возможности платформы и подтвердить процесс управления.

Получение одобрения и работа с заинтересованными сторонами

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

У команды было старшее спонсорство программы со стороны Кабинета министров, что помогло обеспечить бюджет и расставить приоритеты для проекта.

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

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

Улучшение опыта адаптации разработчиков

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

Делаем документацию доступной для поиска

Команда приложила много усилий, чтобы документация была максимально понятной и доступной в Интернете. Ранее цифровая документация NHS создавалась в виде файлов Microsoft Word. Это означало, что всем, кому нужна была документация, приходилось запрашивать файлы по электронной почте, а централизованного места для поиска и просмотра документации не было.

Использование платформы управления API позволило команде централизовать свою документацию в центре разработчиков . Документацию теперь легко просматривать всем, будь то владельцы продукта или разработчики.

Платформа управления API также помогла наладить процесс публикации документации. Это упростило для команды создание, публикацию и поддержку документации наряду с разработкой.

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

Песочница

Еще одной важной частью создания удобного интерфейса для разработчиков была функция песочницы. Это предоставляет разработчикам среду самообслуживания, к которой они могут получить доступ без какой-либо авторизации, что позволяет им быстро начать интеграцию с API.

Песочница возвращает данные пациента-заполнителя в стандартном формате RESTful с правильными ответами для API. Это помогает внешним командам начать создание сервисов с использованием API в песочнице, пока они все еще находятся в процессе авторизации для использования живого API.

Уверенность

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

Настройка круглосуточной поддержки

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

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

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

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

Команда также установила процесс управления инцидентами для выявления, определения приоритетов, решения и сообщения о технических неполадках и сбоях. NHS Digital использует классификацию серьезности инцидентов, также известную как уровни «sev», для категоризации инцидентов.

Использование современных технологий для достижения баланса между гибкостью и безопасностью

Ранее API PDS обслуживался через сеть здравоохранения и социального обеспечения (HSCN) , сеть передачи данных для организаций здравоохранения и здравоохранения государственного сектора по всей Англии. Это создало проблемы для служб, ориентированных на граждан, поскольку ограничивало доступ к этим услугам для помещений NHS. Новый API использует Fast Healthcare Interoperability Resources (FHIR) , глобальный отраслевой стандарт для передачи медицинской информации между системами.

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

Использование платформы управления API в качестве прокси позволило им применить этот шаблон безопасности ко всем API. Это также позволило им подключиться к модулю Identity Platform (IDP) и Identity and Access Management (IAM) для обработки авторизации.

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

Итоги проекта

Сокращенное время выполнения заказа

С момента запуска до ввода в эксплуатацию команде потребовалось около 7 месяцев, чтобы настроить платформу управления API и создать соответствующее управление для поддержки первоначального образца API. После этого команды смогли развернуть 2 API - PDS FHIR API и Ambulance Data Submission FHIR API - всего за несколько месяцев. Раньше время выполнения заказа составляло около года.

Повышение рейтинга разработчиков и вовлеченности

При принятии решения о том, какие показатели успеха следует рассматривать, команда сосредоточилась на повышении рейтинга разработчика как четкой метрики для измерения того, насколько хорошо сервис удовлетворяет потребности пользователей.

Команда поставила цель повысить рейтинг разработчиков с 2 из 5 до 4 из 5. Они чувствовали, что создание минимально жизнеспособного продукта (MVP) доведет их до 3, но знали, что для этого потребуется много работы. 4. В январе 2020 года они провели опрос, который показал рейтинг 3 из 5. К началу 2021 года аналогичные опросы показали результаты 4-5 из 5.

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

Повышение мотивации команды

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

Уроки выучены

Команда сочла бета-тестирование особенно ценным для проекта, поскольку оно помогло выявить проблемы, которые команда упустила при тестировании. Например, 3 разработчика связались с получением неудавшихся ответов с именами с апострофами, где фигурные апострофы отклонялись. Это не могло бы проявиться в собственном тестировании команды, поскольку этот очень конкретный вариант использования не был тем, о чем они думали.

Модель будущих API

PDS FHIR API с самого начала задумывался как образцовый сервис на платформе управления NHS Digital API. С тех пор, как он был запущен, был добавлен ряд других API-интерфейсов с использованием как технических, так и управленческих подходов, подтвержденных этим API. Таким образом, была создана структура или шаблон для будущих интеграций. Это упростит работу командам, выполняющим аналогичные проекты, не только для потребителей API, как это было изначально задано здесь, но и для производителей API.