ПРИМЕЧАНИЕ. Изначально это появилось на FullMetalHealth.com. Для получения контекста предыдущих сообщений и преемственности перейдите к Блокчейн + Здравоохранение: DokChain сейчас.
Мы представили DokChain и обсудили, куда мы движемся в качестве окончательной платформы для бизнеса в области здравоохранения. Хотя мы доказали и решили многие проблемы, связанные с планированием, функциональной совместимостью и идентичностью, мы также меняем всю основу обработки для всех #HealthIT. Имея это в виду, мы теперь приступим к серии блогов, состоящей из нескольких частей (в цепочке?), чтобы обсудить текущие и будущие области DokChain.
Мы внедрили версию ethereum EVM для развертывания DokChain. Кроме того, мы также создали версию DokChain с использованием Microsoft Blockchain как услуга. В настоящее время у нас есть метод подтверждения работы по умолчанию. Как вы увидите в будущих сообщениях, мы считаем, что это неоптимально для использования всех бизнес-механик для создания смарт-контрактов.
Итак, как нам настроить сервисы? Мы уже думали об использовании блокчейна для здравоохранения еще при создании PokitDok в 2011 году. Поэтому с учетом использования API в сфере ИТ в здравоохранении мы разработали систему с учетом этого.
Хотя в настоящее время мы создаем готовые к производству смарт-контракты для 270/271 (право на участие), мы легко запустим остальную часть нашей платформы в сети позже в этом году.
Мы будем предоставлять оперативные услуги для всех текущих API, и по большей части все наши приложения и взаимодействия с торговыми партнерами останутся без изменений.
Итак, чего мы достигли? Ниже приведена архитектурная диаграмма, изображающая то, что мы представили еще в июне для готового кода в Microsoft Azure Infrastructure:
Архитектура DokChain
На верхнем уровне мы сначала автоматически создаем кошелек с мультиподписью для потребителя и для провайдера. Все наши соглашения, включая 270/271 (приемлемость), 835, 837 (претензии) и поиск поставщиков, будут включены в смарт-контракты, которые мы будем генерировать. В будущем, когда вы зарегистрируетесь на нашей платформе, они будут автоматически генерироваться как часть вашей среды DokChain SDK.
На следующем уровне мы используем криптографический конечный автомат pyethapp. Pyethapp генерирует базовую логику, связанную с блокчейном, такую как транзакционная криптография и контракты виртуальных машин. В случае с DokChain мы использовали эту логику и модифицировали ее, чтобы удовлетворить потребности нашей платформы в схеме и данных. Это также позволяет полностью сетевое приложение без каких-либо дополнительных затрат на переоснащение. PokitDok сделал несколько запросов на включение в эту кодовую базу (123, 128, 129, 341).
Следующим на очереди у нас есть ethjsonrpc, который позволяет клиенту python для Ethereum использовать интерфейс JSON-RPC. В частности, он реализует все 62 метода JSON-RPC и предоставляет высокоуровневый интерфейс для создания контрактов в DokChain, а также для динамического создания и вызова методов контрактов и обработки событий. PokitDok также внес свой вклад в эту кодовую базу (8, 9).
Затем мы переходим к связующему коду, который реализует интерфейс между ethjsonrpc и платформой pokitdok. это обеспечивает полный доступ ко всем текущим интерфейсам, включая плательщиков.
Хорошо, учитывая архитектуру, каков фактический поток процесса DokChain для проверки соответствия требованиям? Ниже приведена блок-схема готового кода, который мы демонстрировали в Редмонде, штат Вашингтон:
Процесс DokChain для проверки правомочности
Перед самой транзакцией приемлемости или любой другой транзакцией DokChain в этом отношении должна быть установлена личность взаимодействующих сторон. Идентификация устанавливается с помощью смарт-контракта или кошелька для каждой участвующей организации. Поставщики и потребители получают коды кошельков в блокчейне, которые реализуют контроль доступа и хранение проверенных токенов. Плательщики обычно представлены смарт-контрактами, представляющими услуги, которые они предоставляют, в данном случае проверка правомочности.
Фактический код для генерации потребительского кошелька выглядит следующим образом:
Аналогично, код кошелька провайдера:
Метод eligibilityUpdate в каждом кошельке вызывается контрактом приемлемости для хранения токена, подтверждающего статус страховки физического лица при получении ответа.
Контракт соответствия — это код смарт-контракта, который организует взаимодействие потребителя и поставщика через их кошельки в сети и плательщика или другие данные или систему вне сети:
Учитывая, что потребитель одобрил доступ к провайдеру, который поддерживается в коде кошелька посредством использования функционального модификатора onlyApprovedAccounts, провайдер может активировать контракт правомочности, чтобы запросить текущую проверку приемлемости, выполняемую от имени потребителя. Этот метод проверит, что предыдущий грант доступа был сохранен в кошельке потребителя, и если это так, то опубликует EligibilityEvent. Внечейн-система Платформа PokitDok будет сканировать транзакции EligibilityEvent с использованием клиента ethjsonrpc, обрабатывать устаревший запрос/ответ транзакции ASC X12N 5010 270/271 с соответствующим плательщиком, а затем вызывать метод ответа EligibilityEvent. договор.
Сканирование EligibilityEvent и обработка:
Учитывая, что потребитель одобрил доступ к провайдеру, который поддерживается в коде кошелька с помощью функционального модификатора theonlyApprovedAccounts, провайдер может вызвать контракт соответствия требованиям, чтобы запросить текущую проверку соответствия требованиям, выполненную от имени потребитель. Этот метод проверит, что предыдущий грант доступа был сохранен в кошельке потребителя, и если это так, то опубликует EligibilityEvent. Внечейн-система Платформа PokitDok будет сканировать транзакции EligibilityEvent с использованием клиента ethjsonrpc, обрабатывать устаревший запрос/ответ транзакции ASC X12N 5010 270/271 с соответствующим плательщиком, а затем вызывать метод ответа EligibilityEvent. договор.
Сканирование EligibilityEvent и обработка:
Обработка транзакции приемлемости и вызов метода ответа контракта приемлемости:
Контракт о приемлемости затем обновит токен в кошельках для потребителя и поставщика, учитывая, что доступ все еще предоставляется. Как уже отмечалось, при этом используется Proof Of Work, который, как упоминалось ранее, не оптимален для транзакций здоровья в DokChain. В дальнейшем будем обращаться более подробно.
Мы хотим подчеркнуть, что все наши 500+ подключений плательщиков, которые представляют более 90% охваченных жизней, не должны быть уведомлены о взаимодействиях DokChain. Кроме того, текущий набор приложений автоматически воспользуется преимуществами этой архитектуры. Это запатентованная технология, которая была разработана таким образом, что любой, кто зарегистрировался на нашей платформе, может немедленно воспользоваться ею.
Этот шаблон для создания удостоверений, управления разрешениями на доступ, хранения криптографически проверенных указателей на данные вне сети и организации взаимодействия этих удостоверений со службами здравоохранения является повторяемым средством переноса всего бизнеса здравоохранения на блокчейн.
PokitDok намерен стать не только стандартом де-факто для управления идентификацией в сфере ИТ здравоохранения, но и стать эталоном на пересечении создания смарт-контрактов и услуг на пересечении #FinTech и #HealthTech. Мы также считаем, что, учитывая наш опыт в #машинном обучении, #теории графов и #вычислительной топологии, мы также создадим новый уровень #искусственного_интеллекта, используя DokChain для сектора здравоохранения.
PokitDok продолжит продвигать и совершенствовать эти технологии, чтобы расширить эту основу и обеспечить надежную основу для безопасного и надежного создания смарт-контрактов, а также инфраструктуру для объединения всех данных и систем здравоохранения вне сети с исполнением и аналитикой в сети.
В нашем следующем блоге мы обсудим, как мы разрабатываем технологии, специально предназначенные для проверки смарт-контрактов, поскольку это относится к языкам Тьюринга и не Тьюринга.
До тех пор,
