В этой статье рассказывается о второй части нашего финального проекта в Makers. В первой части рассказывалось о том, что такое блокчейн и как мы создали доказательство концепции блокчейна. Если вы не читали первую статью, вы можете прочитать ее здесь.
В этой статье я расскажу, как мы интегрировали алгоритм блокчейна в полнофункциональное веб-приложение. Я собираюсь обсудить, как приложение можно использовать для обеспечения безопасной истории рецептов пациентов.
Сначала мы планировали, как приложение впишется в систему здравоохранения. Оттуда мы создали три типа пользователей, которые будут взаимодействовать с приложением на разных уровнях.
Затем я перейду к структуре и потоку данных приложения с точки зрения одного из пользователей. Причина, по которой я рассматриваю только один тип пользователей, заключается в том, что разные пользователи имеют много схожих функций, поэтому охват всех из них будет повторяться. Наконец, я расскажу об улучшениях и дополнительных функциях для будущих итераций.
Гомер посещает доктора
Чтобы понять, как люди будут использовать приложение в реальном мире, нам нужно было подумать о том, как люди заказывают рецепты.
Допустим, у Гомера Симпсона начинает болеть спина. Боли в спине могли быть вызваны чем угодно. Поэтому он идет к специалисту, доктору Хибберту, чтобы понять причины болей в спине и разработать стратегию для облегчения причин и симптомов.
Доктор Хибберт прописывает Гомеру Симпсону противовоспалительные препараты и рекомендует изменить образ жизни. Он рассказывает Гомеру Симпсону о рецепте и добавляет его в систему рецептов пациентов.
Затем Гомер идет в аптеку, где фармацевт имеет доступ ко всем рецептам пациентов. В течение 5 минут он оплатил свой рецепт. Он возвращается домой, принимает рецепт и приступает к новым упражнениям.
Пользователи системы
Вышеприведенная история дает представление о различных типах пользователей в рецептурной системе и их обязанностях.
- Врач добавляет рецепты в систему
- Фармацевт имеет возможность просмотреть все рецепты
- Пациент может получить доступ к своей личной информации рецепта
Этих пользователей не волнуют (и не должны) технологии, лежащие в основе системы; все, о чем им нужно заботиться, это то, что он работает и предлагает безопасную и надежную среду для управления рецептами.
Как только мы поняли три основных типа пользователей, мы разработали пользовательские истории для приложения. Мы придумали три основных пользовательских истории, которые обобщают опыт Гомера (и большинства людей):
- Как врач, чтобы улучшить здоровье своих пациентов, я хочу иметь возможность просматривать все рецепты и добавлять рецепты в систему.
- Как фармацевт, чтобы быстро получать нужные рецепты, я хочу иметь возможность просматривать все рецепты пациентов.
- Как пациент, чтобы отслеживать свои лекарства, я хочу иметь возможность просматривать только свои рецепты
Разработка функций Доктора
Первое, что мы сделали, — разбили эти пользовательские истории на более мелкие фрагменты и выяснили, что у них общего. Наиболее важным сходством, которое они разделяли, была необходимость входа в систему и выхода из нее. Различные уровни авторизации могут быть установлены при входе в систему.
Для этой функции приложению требовался общедоступный интерфейс, контроллер для проверки правильности входа в систему и база данных для хранения вошедших в систему пользователей.
Мы решили использовать архитектуру модель-представление-контроллер (MVC) для управления пользовательским интерфейсом и создали разные маршруты (или веб-адреса), которые каждый тип пользователя будет использовать для входа в приложение. Модель используется для управления подключениями к базе данных, а представления управляют общедоступным интерфейсом приложения (то, что видит пользователь). Контроллер действует как API. Он проверяет данные от пользователя, а затем отправляет данные в модель.
С помощью контроллера все маршруты/веб-адреса определяются для представления различных состояний приложения (успешный вход в систему/неудачный вход в систему, добавление рецепта и т. д.).
Как только пользователь посещает приложение, он перенаправляется на страницу входа, где присутствуют три разных типа пользователей.
Допустим, я врач и хочу зарегистрироваться. Я нажимаю на кнопку регистрации и меня направляют на маршрут регистрации к врачу. За кулисами контроллер регистрации врачей управляет всеми входами в систему и регистрацией.
Затем я заполняю правильную информацию, и приложение затем посещает маршрут почтового запроса. Почтовые запросы используются для управления любой частной информацией о пользователях.
Здесь могут произойти две вещи.
- Пользователь вводит неверную регистрационную информацию или пытается зарегистрироваться у существующего пользователя.
- Новый врач успешно зарегистрирован и авторизован
Регистрационная информация проверяется двумя простыми функциями, которые гарантируют, что каждая запись в форме заполнена, а два пароля одинаковы. Второй шаг немного сложнее.
Вызывается функция входа в систему нового врача. Перед входом в систему врач просматривает базу данных всех регистраций врачей. Если какие-либо врачи совпадают с текущей регистрационной информацией, то регистрируется ошибка.
Если регистрация прошла успешно, информация о регистрации врачей сохраняется в базе данных. Схема базы данных или структура для организации регистрационных данных управляется через файл модели.
Каждая запись из формы применяется к документу, который будет сохранен в базе данных. Записи проверяются на уникальность. Затем с помощью библиотеки шифрования bcrypt пароли шифруются перед сохранением информации в базе данных. Шифрование используется для того, чтобы гарантировать, что в случае нарушения безопасности базы данных или приложения пароли пользователей останутся скрытыми (если только хакеры не получат доступ к ключу шифрования).
После того, как данные были зашифрованы, мы сообщаем приложению, что врач вошел в систему через сеанс. Сеанс — это часть данных, хранящихся на сервере (внутренняя часть приложения, которую пользователь не видит), которая сохраняется на всех маршрутах. То есть данные не изменятся, если пользователь посетит несколько URL.
Мы используем данные сеанса, чтобы отразить тот факт, что врач вошел в приложение. Если врач войдет в систему, решит ли он посетить другой маршрут (или другую веб-страницу, такую как BBC Sport), это не имеет значения. Состояние вошедшего в систему врача сохраняется во всем приложении.
Если врач не вошел в систему и кто-то пытается посетить страницу добавления рецепта, он перенаправляется обратно на домашнюю страницу (помните, что только врачи имеют право добавлять рецепты). Это связано с тем, что маршрут добавления рецепта перенаправляет обратно на домашнюю страницу, если в приложении нет logged_in_doctor.
После успешной регистрации врач перенаправляется на страницу добавления рецепта.
Очень похожий процесс используется для регистрации существующего врача. Сначала приложение гарантирует, что каждая запись в форме заполнена. Затем приложение выполняет поиск в базе данных и идентифицирует врача по имени пользователя. Затем пароль, связанный с пользователем в базе данных, расшифровывается. Если расшифрованный пароль совпадает с паролем, введенным в форму, сеанс вызывается, и пользователь направляется на страницу добавления рецепта.
А как насчет блокчейна?
Блокчейн не используется для управления разрешениями или пользователями. Роль блокчейна заключается только в хранении данных о рецептах. Таким образом, алгоритм блокчейна доступен только через функцию добавления рецепта.
При инициализации приложения создается экземпляр блокчейна, и контроллер также имеет доступ к объектам предписания и создания блоков.
Создание предписаний и блоков (которое я объяснил в части 1) вызывается через маршруты приложений.
Если врач добавляет рецепт через веб-форму, приложение присваивает данные объекту рецепта через POST-запрос рецептов/подтверждения. Затем объект рецепта добавляется в новый блок, который затем передается в блокчейн.
По завершении приложение направляет пользователя на страницу со всеми рецептами. В консоли вы можете увидеть рост блокчейна и то, что каждая запись содержит зашифрованный хэш предыдущей записи.
То, что видит врач, является абстракцией необработанных данных приложения. Им предоставляется только та информация, которая им необходима; данные рецепта. Разные пользователи также должны заботиться только о потоке данных, который соответствует их потребностям.
Поскольку приложение основано на веб-интерфейсе, его можно использовать на любом компьютере с веб-браузером. Это позволит интегрировать приложение в систему здравоохранения, такую как NHS. Неважно, работает ли в больнице или аптеке Windows, Mac или Linux. Если у хоста есть доступ к веб-браузеру, он может запустить приложение. Если бы это был рабочий стол, вам понадобились бы разные версии для разных операционных систем и, возможно, даже разные версии операционных систем!
Мошенничество с рецептами также можно проверить, так как если какая-либо существующая запись будет изменена или изменена, то действие системы будет нарушено. Таким образом, разработанное нами решение представляет собой интересное решение для управления предписаниями, которое является одновременно безопасным и относительно независимым от ОС.
В то же время, с точки зрения разработчиков, приложение структурировано для разных типов пользователей. Это, в сочетании с модульными и интеграционными тестами, упрощает понимание кода и добавление новых функций.
Улучшения и дополнительные функции
Пока что я показал, как мы интегрировали прототип блокчейна в веб-приложение. Продукт далек от завершения, поэтому я собираюсь быстро завершить некоторые вещи, которые было бы неплохо сделать.
- Улучшенный интерфейс (мы все согласны с тем, что цветовая схема могла бы быть лучше).
- Готовый функционал для пациентов и фармацевтов.
- Мы написали веб-интерфейс для алгоритма поиска рецептов.
- Мы написали веб-интерфейс для проверки валидности блокчейна.
Сама цепочка блоков, являющаяся доказательством концепции (а не реальной рабочей цепочкой блоков), в настоящее время хранится в сеансе. Чтобы развернуть блокчейн в рабочем мире, нам понадобится какая-то база данных или распределенная система для хранения данных. Использование для этого структуры связанного списка имеет смысл, так как новые узлы могут быть добавлены в связанный список при создании каждого предписания.
В целом, хотя это был отличный опыт. Он показал, как многому научились gadiza zerari, Patryk Pilecki Sam Niechcial и я в Makers и сколько вы можете получить сделано в течение 8 дней, следуя передовой практике.
**Если вы хотите подробно ознакомиться с кодом, вы можете здесь**
