Глава 3. Интегрирование блокчейн решения в бизнес-процессы фармацевтической компании и рассмотрение структуры блока с транзакциями
В данной главе будет описана сама модель системы блокчейн, которая будет интегрирована в бизнес-процессы фармацевтической компании. На данном этапе важно не только детализировать концепцию блокчейн решения, а именно, способы участия в нем, принципы проведения транзакций и записи их в блок, набор узлов, принимающих решения о включении блока в цепочку блокчейн, но и само верхнеуровневое видение интеграции данной системы с бизнес-процессами внутри фармацевтической компании, связанных с внесением данных по лекарственному препарату и дальнейшее его сканирование, с целью отслеживания.
Cеть блокчейн - это техническая инфраструктура, которая предоставляет участникам сервисы главного распределенного реестра и функционал смарт-контрактов. В первую очередь, смарт-контракты используются для генерации и проведения транзакций (в случае системы для фармацевтической отрасли процесс передачи прав собственности на лекарственный препарат), которые впоследствии распределяются по каждому равноправному узлу в сети в составе блока и, где происходит запись этого блока в копии регистра в числе узлов. Участниками системы будут являться как конечные потребители, использующими клиентские приложения, так и администраторами цепочки блоков, т.е. производители продукции.
Как правило, на практике несколько организаций объединяются в консорциум для формирования сети, и процессы в этой сети определяются набором политик, согласованных консорциумом при первоначальной настройке сети. Более того, сетевые правила и базовые функции могут со временем меняться в зависимости от соглашений организаций в консорциуме, то есть данная система является гибкой.
Далее будет детально рассмотрена блокчейн-система, ее архитектура, методы интеграция архитектуры с бизнес-процессами компании, структура записи и хранения информации по лекарственным препаратам.
3.1 Архитектура блокчейн-системы в рамках деятельности отдельной фармацевтической компании
Для начала следует определить, кто будет являться узлами рассматриваемой системы и какими полномочиями они будут обладать.
На узлах системы должно происходить выполнение бизнес-логики (смарт-контракта), так же chaincode, будет осуществляться хранение состояния самого распределённого реестра (ledger data), а также выполнение дополнительных служб системы. Сам по себе узел является логической единицей, при условии, что разные по функционалу узлы могут присутствовать на одном и том же физическом сервере. Более важным является то, что какие функции выполняет тот или иной узел и как они сгруппированы.
Далее будет изображена общая архитектура все блокчейн-системы со всеми типами узлов, функционала и реестров, а также будет описан каждый субъект данной системы (см. рис. 8).
Рис. 8. Архитектура блокчейн-системы в рамках деятельности отдельной фармацевтической компании
Пользовательские приложения (Submitting Clients) - это приложения (а именно совокупность функционала и интерфейса), через который все пользователи (операторы на производстве фармацевтической компании, сканирующие и заносящие информацию по лекарственному препарату, а также операторы на складах дистрибьюторов и аптечных сетей) взаимодействуют с блокчейн-системой. Чтобы начать работать с системой необходимо авторизоваться в системе и иметь соответствующие права на различные действия в системе.
Сами узлы, которые являются представлением в системе ее участников (от производителя до отдельной аптеки, и даже до отдельного пользователя, сканирующего пачку с лекарством с помощью мобильного приложения) могут выполнять несколько ролей.
Подтверждающие узлы (Endorsing Peers) - узлы, симулирующие исполнение операций по передаче прав владения единицы лекарственного препарата (при этом проводится операция смарт-контракта). Проверив операцию и выполнив алгоритм смарт-контракта узел отправляет результаты своего выполнения пользовательскому приложению вместе со своей подписью. В рассматриваемой системе роль подтверждающих узлов будут выполнять участники цепочки движения лекарственного препарата. Допустим происходит отгрузка фармацевтической продукции со склада дистрибьютера на распределение по аптечным сетям и оператор на складе дистрибьютера путем сканирования паллеты или коробки с продуктом производит его сканирование, тем самым отправляя сведения об отгрузке со своего склада по всем важным участникам цепочки. Участники цепочки получают данные сведения и с помощью выполнения смарт-контракта проверяют достоверность информации, при этом подписывая выполнение операции. Более подробно данный процесс будет рассмотрен далее.
Функционал добавления блоков представляет собой распределенный сервис на числе узлов и предназначен для формирования блоков с операциями в реестре и формирования очередности исполнения операций. Данный функционал не добавляет блоки в реестр - эта функция предназначена формирующим узлам.
Формирующие узлы в свою очередь хранят последнюю версию системы распределенного реестра (сформированный функционалом добавления блоков), а также добавляют новые блоки в системный реестр. Все данные узлы хранят у себя локальную копию реестра. При этом, в процессе добавления блока в локальную копию на узлах происходит проверка нового блока на валидность его операций. В рассматриваемой системе данную роль будут выполнять наиболее заинтересованные в прозрачности участники - производители и крупнейшие дистрибьютеры.
Функционал проверки действий на валидность определяет какие узлы должны взять на себя проверку и выполнение смарт-контракта для признания валидности операций.
Распределенный реестр в свою очередь состоит из двух частей - блокчейн-система (последовательности блоков, хранящей в себе все операции и изменения произошедших в системе) и компоненты, которая сохраняет последние состояния (значения) всех объектов системы. Данная компонента состоит из пара ключ-значение, где ключ это, допустим, срок годности, а значение это срок годности отдельной пачки с препаратом. Она также, как и реестр хранится в узлах.
Центр сертификации содержит в себе набор текущих ключей участников системы, а выдаваемых ключей в целях того, чтобы все участники были аутентифицированы.
Функционал проверки принадлежности предназначен для выполнения проверки принадлежности субъекта системы тому или иному каналу или компании.
В рассматриваемой системе, как уже было описано ранее, транзакции будут представлять из себя операцию по передаче прав собственности на лекарственный препарат и в системе будут отображаться обязательно все операции. Операция инициируется пользовательским соглашением и после всех процедур по верификации записывается в реестр.
Канал представляет собой подсеть блокчейн системы, которая будет закрытой и состоять из двух и более участников, причем данные участники будут известны. Канал, как показано на рис.8 состоит из участников, своего отдельного распределённого реестра, смарт-контрактов, функции добавления блоков, данных состояния системы и т.д. Участники данного канала должны пройти авторизацию (с помощью проверки принадлежности) для доступа и способен проводить операции внутри него.
В рассматриваемой системе канал может быть представлен различными секторами отрасли - по географическому признаку, по типу продукции. Например, блокчейн система может содержать в себе несколько каналов, одним из которых будет канал движения фармацевтической продукции внутри РФ (или же Дальнего Востока), включающей в себя только рецепторные препараты. Также, канал может затрагивать только определенных участников отрасли - консорциума компаний, которые интегрировали блокчейн решение для демонстрации прозрачности внутри своей доли рынка.
3.2 Интеграция блокчейн-системы в текущие бизнес-процессы фармацевтической компании
В этом разделе будет рассмотрена интеграция блокчейн-системы в бизнес-процессы при отгрузке лекарственного препарата со склада отправителя (со склада фармацевтической компании) и его приемке получающей стороной (на складе дистрибьютера лекарственной продукции).
Как было указано в предыдущей главе, при отгрузке лекарственного препарата со склада фармацевтической продукции происходит сканирование оператором маркировки коробки, в которую упакованы пачки с лекарственным препаратом с последующей отправкой данной операции в базы данных ИС МДЛП. Та же ситуация происходит при приемке и сканировании лекарственных препаратов оператором на складе дистрибьютора. На моменте трансляции операций в корпоративную ERP и отправление в реестр ИС МДЛП происходит интеграция ПО блокчейн-системы. Дальше рассмотрим процесс занесения информации на этом этапе в распределенную блокчейн систему (см. рис. 9).
Рис. 9. Диаграмма бизнес-процессов фармацевтической компании «Отгрузка ЛП со склада отправителя и приемка ЛП на склад получателя и внесение данных в блокчейн реестр»
Инициация транзакции. Оператор склада фармацевтической компании после сканирования отгружаемых упаковок с лекарственной продукцией с помощью своего пользовательского приложения отправляет запрос в систему на подтверждение статуса отгрузки данных упаковок со склада и передачи им соответствующего статуса. Запрос на данную операцию рассылается на подтверждающие узлы со смарт-контрактами (см. рис.10).
Важным моментом является то, что будет происходить сканирование маркировки лекарственного препарата и занесение информации по операции исходя из данных, заложенных в этот код, а также дополнительные данные по операции. В целом эта информация будет состоять из следующих составляющих:
Дата проведения операции;
Идентификатор места, где осуществляется деятельность отправляющей стороны, с которой была выполнена отгрузка препарата;
Идентификатор места, где осуществляется деятельность принимающей стороны, на которой выполняется приемка препарата;
Тип отгрузочной операции со склада (реализация или возврат);
Источник финансирования;
Тип договора;
Номер контракта из реестра (в случае проведения отгрузки лекарственного препарата в рамках муниципального фармацевтического обеспечения);
Дата отгрузочного документа;
Номер отгрузочного документа;
Цена реализации лекарственного препарата в рублях (НДС включается);
Сумма НДС (при условии, что сделка облагается НДС);
SGTIN и/или SSCC.
Как ранее обсуждалось, в рассматриваемой системе роль подтверждающих узлов будут выполнять участники цепочки движения лекарственного препарата - производитель, дистрибьютор, аптечная сеть, промежуточные участники цепочки, а также государство в лице госпредприятия ИС МДЛП. Для дальнейшего добавления информации по данным операциям в блок необходимо, чтобы данные узлы одобрили эти операции согласно бизнес-логике, а именно произвели выполнение смарт-контракта с одинаковыми результатами. Пользовательское приложение оператора склада производителя проходит проверку функционалом принадлежности и отправляет запрос на нужные узлы по выполнению операции присвоения статуса отгрузки лекарственной продукции. Технически на данном этапе происходит отправление запроса с параметрами транзакции, добавление клиентской подписи и отправка всех этих данных по специальному протоколу на требуемые подтверждающие узлы.
Рис. 10. Инициация операции по отгрузке лекарственного препарата со склада фармацевтической компании
Выполнение смарт-контракта. Подтверждающие узлы (государство, другие производители, дистрибьюторы, и по необходимости аптечные сети) получают запрос на проведение операции по отгрузке, происходит проверка клиентской подписи с их стороны и, при условии, что все валидно, запускают симуляцию по исполнению смарт-контракта (см. рис. 11).
Рис. 11. Выполнение смарт-контракта на подтверждающем узле системы
Производится проверка отгружаемой продукции по ключам и параметрам, соотношение их с данными текущего состояния системы. По итогу исполнения смарт-контракта на подтверждающих узлах генерируется следующие наборы данных - Read Set и Write Set - исходные и новые параметры значений состояния системы.
Возврат данных клиентскому приложению. По завершении выполнения симуляции смарт-контракта подтверждающие узлы возвращают изначальные данные и результаты симуляции клиентскому приложению, а также два упомянутых набора данных, которые подписываются его сертификатом. Происходит проверка подписей подтверждающих узлов, данных по операциям (сравнение отправленных и вернувшихся данных) - проверка на искажение (см. рис. 12).
Рис. 12. Возврат проверенных операций клиентскому приложению оператора склада производителя
В случае если операция заключалась только в запросе на чтение данных из реестра, то клиентское приложение просто получает Read Set и никаких изменений в реестре не происходит. Если же операция направлена на изменение данных в реестре, то дополнительно со стороны клиентского приложения проводится проверка действий узлов на валидность.
Отправка Read Set на процедуру подготовки добавления блоков. После предыдущих действий клиентское приложение отправляет информацию по операции на процедуру подготовки добавления блоков в реестр. Данная информация включает RW Set, подписи от подтверждающих узлов и идентификатор канала, в рамках которого производятся операции (см. рис. 13).
Основная задача функционала добавления блоков - выстраивание поступающих операций в корректном порядке, формирование нового блока с операциями и доставка сформированных блоков формирующим узлам. Это важный момент, так как важно поддерживать консистентность данных по операциям на всех формирующих узлах. Здесь пока еще не происходит изменение самого реестра, а готовятся данные для его изменения - прием операций с определенными идентификаторами канала, выстраивание их в определенном порядке и формирование нового блока. Данный функционал способен работать с операциями по нескольким каналам, поэтому может обслуживать целую фармацевтическую отрасль.