Технология блокчейн в фармацевтике в сфере маркировки лекарственных средств

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

Однако, если рассмотреть данный алгоритм с точки зрения перспективы внедрения в отраслевые бизнес-процессы системы Track&Trace, к примеру, то возникает вопрос неуместности некоторых аспектов алгоритма. Так, в фармацевтической отрасли нет необходимости в майнинге - процессе конкуренции участников сети за нахождение требуемого блока с операциями по передаче прав собственности единиц лекарственных препаратов. В отрасли присутствуют лица, которое заинтересованы в прозрачности движения препаратов. Это, как мы уже говорили, производители, дистрибьютеры и аптечные сети. Для них нелогично бороться за добычу блока с информацией и получение за него награды в виде созданных для сети токенов и в этой системе вообще отсутствует конкуренция. Скорее все участники имеют одну общую цель - прозрачность отрасли. И майнинг, который к тому же подразумевает энергозатраты, совершенно не вписывается в финальную концепцию блокчейн системы, которую мы хотим видеть. Более того, алгоритм PoW, который используется в наиболее популярных криптовалютах и системах Bitcoin и Ethereum, обладает ограниченной скоростью обработки транзакций, а именно скорость транзакции у системы Bitcoin составляет 78 минут, а число транзакций в секунду лежит в диапазоне от 3 до 100. У Ethereum эти показатели равняются 6 минут на транзакцию и число транзакций, обрабатываемых сетью, доходит до 25. (Источник: https://thebcj.ru/2018/06/10/skorost-tranzakcij-kakoj-kriptovalyutoj-perevodit-bystree/). Данные величины крайне малы для процессов производства и мгновенного внесения лекарственных средств в реестр, учитывая производительность линий на заводах.

Однако, на практике существует ряд других алгоритмов по принятию и формированию блока в цепочке. Два наиболее релевантных для фармацевтической отрасли будут рассмотрены далее.

Proof of Stake. PoS имеет много общего с PoW, но также между ними имеются принципиальные отличия. Как и в любом алгоритме консенсуса, основанном на блокчейне, цель по-прежнему заключается в достижении распределенного консенсуса - создании защищенной системы, в которой пользователи заинтересованы в проверке транзакций других людей при сохранении полной прозрачности.

Алгоритмы Proof-of-Stake достигают консенсуса, выбирая пользователя для нахождения блока на основе доли его токенов в кошельке от общего количества токенов в обращении, а также на основе их возраста. Пользователи стремятся повысить свою долю, чтобы иметь возможность быть выбранными для проверки блоков транзакций и получить вознаграждение за это [42].

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

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

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

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

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

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

Еще одно различие, которое стоит отметить между PoW и PoS, состоит в том, что в отличие от систем PoW, где все больше криптовалют постоянно создается в качестве вознаграждения майнерам, общее количество токенов криптовалюты обычно создается при запуске систем PoS.

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

PoS часто рассматривается как один из лучших вариантов среди алгоритмов консенсуса в сфере криптовалюты. Причины этому следующие:

Алгоритмы PoS являются энергосберегающими, особенно по сравнению с PoW. Выключение энергоемкого процесса добычи делает PoS более экологичным вариантом.

Злоумышленники должны поставить свои активы - свою долю - на риск быть конфискованной при неудаче, чтобы попытаться атаковать на 51%. Большой сдерживающий фактор. Для сравнения, злоумышленники не теряют свое оборудование при попытке 51% атак на PoW-системы.

Крупные майнинг-пулы (группы майнеров, объединяющих свои ресурсы) могут контролировать более 51% сетей, работающих под управлением систем PoW, что приводит к реальной угрозе централизации. Это происходит в результате экспоненциального увеличения вознаграждения за инвестиции в системы PoW, в отличие от линейного увеличения в системах PoS. Если пользователь в сети на основе PoS инвестирует в два раза больше, чем другой пользователь, у него будет в два раза больше контроля. Тот же сценарий на PoW предоставит пользователю значительно больший контроль.

Данный алгоритм уже гораздо более гармонично вписывается в систему Track&Trace фармацевтической продукции. В нем нет майнинга, который является излишним для участников фармацевтической отрасли и подразумевает дополнительные издержки в виде оборудования для майнинга. В нем гораздо выше производительность за счет отсутствия необходимости решения задачи по нахождению решения. Если брать блокчейн систему EOS, которая создана на базе PoS, то в ней скорость транзакции занимает в среднем 1,5 секунды, а производительность самой сети равна около 50000 транзакций в секунду. Данные показатели гораздо более близки к нагрузке по транзакциям по передаче прав собственности, имеющейся в фармацевтической индустрии. Однако, появляется вопрос об излишней необходимости распределения токенов между участниками. Возникает вопрос о распределении токенов при запуске системы - должны ли они быть распределены равномерно между производителями (тогда какой смысл в этом), либо должны быть распределены в соотношении по доле рынка по выручке среди фармацевтических компаний. Однако для этого требуется специальное ПО для эмиссии, а также эмиссии при вхождении в систему новых участников. Более простым и подходящим алгоритмом был бы алгоритм, где список валидаторов определяется заранее и каждый валидатор (прописано в коде системы) будет ответственным за формирование собственных блоков и блоков с его фармацевтической продукцией. В нашем случае роль валидаторов бы выполняли фармацевтические производители, которые при производстве и выпуске партий ЛП в оборот записывали сведения по продукции в блоки и публиковали эту информацию в общую сеть. При этом, производители заинтересованы в полной прозрачности и отсутствии каких-либо мошеннических схем в процессе движения товара, что делает их достаточно надежным и справедливым валидатором [43].

Для такой специфики взаимодействия и функционирования будет рассмотрен еще один алгоритм консенсуса, который объединяет в себе вышеуказанные преимущества алгоритма PoS (производительность, устойчивость), а также соответствует замечанию по изначальном выборе валидаторов при запуске системы. (Источник: https://medium.com/m/signin).

Proof of Authority. Алгоритм консенсуса PoA - это, по сути, оптимизированная модель Proof of Stake, которая использует идентичность как форму ставки, а не на самом деле ставку токенов. Идентификация представлена группой валидаторов (органов), которые предварительно одобрены для проверки транзакций и блоков в соответствующей сети участниками этой самой сети. Предполагается, что группа валидаторов обычно остается достаточно небольшой (~ 25 или менее) для обеспечения эффективности и управляемой безопасности сети.

Основными характеристиками сети PoA являются низкое требование вычислительной мощности, отсутствие необходимости обмена данными между узлами для достижения консенсуса. Более того, непрерывность сети не зависит от количества доступных подлинных узлов, так как они предварительно одобрены и проверяемы с помощью перекрестной проверки в открытом доступе [44].

PoA разработан с учетом использования меньшей вычислительной мощности, чем модели PoW, для решения которых требуются дополнительные затраты электроэнергии. Кроме того, PoA устраняет основную проблему в рамках модели PoS, которая заключается в том, что, хотя ставки между двумя сторонами могут быть равными, их ценность для каждой из сторон может значительно различаться в зависимости от их владений. Например, у Алисы может быть разыграно 1000 жетонов XYZ, а у Боба также может быть разыграно 1000 жетонов XYZ, однако у Алисы есть 10 миллионов долларов вне ее ставки, а у Боба только 10 тысяч долларов вне его. Таким образом, Боб, скорее всего, инвестирует в успех сети XYZ, чем Алиса, поскольку его доля представляет собой значительно большую часть его общих финансов.

Есть три основных требования для того, чтобы стать валидатором, которые имеют важные последствия для структуры мотивации, которая направляет действия участников на честное поведение:

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

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

В процессе установления валидаторов должно быть полное единообразие.

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

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

Преимущества консенсусной сети PoA довольно очевидны. Они заключаются в повышении эффективности во время транзакций и общее сетевое согласие. Модели, использующие консенсус PoA, также намного более эффективны с децентрализованными приложениями и легко масштабируются по сравнению с децентрализованными сетями. Кроме того, инновации в соответствующих технологиях могут помочь в дальнейшей защите таких сетей, где валидаторы независимы друг от друга и подвержены вмешательству третьей стороны. Например, технология Intel SGX для безопасного функционирования анклава используется как метод защиты программного обеспечения валидатора, работающего на их узле, от внешнего вмешательства. (Источник: https://blockonomi.com/proof-of-authority/) [45].



2.2 Бизнес-процессы фармацевтической компании при вводе лекарственных препаратов в оборот

В текущем разделе будут рассмотрены бизнес-процессы российской фармацевтической компании, входящей в топ десять фарм компаний России по объему выручки за 2018 год. Сотрудник, предоставивший следующие данные о компании, изъявил желание об анонимности компании и анонимных данных, поэтому в дальнейшем данная фармацевтическая компания будет фигурировать как «Компания» и соответствующие синонимы.

Что касается рассмотренных бизнес-процессов, то они будут касаться тех сфер компании, в которых происходит производство лекарственного препарата, выводе его в оборот, процессы отгрузки препаратов со склада отправителя и их приемка на складе получателя - все те бизнес-процессы, которые потенциально могут содержать элементы взаимодействия участников блокчейн track&trace системы с лекарственными препаратами (точнее с их маркировкой).

Сначала будут рассмотрены бизнес-процессы при вводе лекарственного средства в оборот.

Генерирование персональных серийных номеров для кодировки вторичной (потребительской) упаковки ЛП имеет возможность реализоваться автономно отечественными производителями фармацевтических средств или же оператором ИС МДЛП по запросу. В итоге оригинальная комбинация GTIN и персонального серийного номера вторичной (потребительской) упаковки ЛП именуется SGTIN и определяет оригинальный идентификационный код вторичной (потребительской) упаковки ЛП для прослеживаемости в ИС МДЛП.

На любую вторичную (потребительскую) пачку с лекарственным препаратом печатается двумерный штриховой код DataMatrix, имеющий следующий набор полей:

SGTIN (обязательно);

код испытания (предоставляется оператором ИС МДЛП при наличии прибора регистрации эмиссии);

производственный серийный номер (не обязательно);

срок годности (не обязательно).

Получение русским изготовителем фармацевтических средств от оператора ИС МДЛП кодов испытания осуществляется с применением приборов регистрации эмиссии, предоставляемых оператором ИС МДЛП методом передачи или же предоставления удаленного доступа (по заключению русского производителя фармацевтических средств).

На каждой третичной (транспортной) упаковке лекарственного препарата печатается средство идентификации в формате линейного штрихового кода Code128, содержащего в себе персональный серийный номер групповой упаковки - SSCC.

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

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

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

По результатам регистрации сведений об окончании этапа конечной упаковки лекарственного препарата в ИС МДЛП для SGTIN присваивается категория эмиссии: тип «Эмитирован владельцем» при собственном изготовлении и тип «Эмитирован в рамках контрактного производства» при контрактном производстве.

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

Рассмотрим бизнес-процессы по вводу лекарственного препарата в оборот и опишем выполняемые при этом действия. Данные БП будут отображены в виде UML-диаграммы (см. рис. 7) и в виде упорядоченного по своей последовательности выполнения списка.

Генерирование персональных серийных номеров вторичной (потребительской) упаковки ЛП.

Получение кодов маркировки у оператора ИС МДЛП (при наличии специального оборудования или же удаленного подключения к устройству регистрации эмиссии).

Упаковка или фасовка лекарственного препарата во вторичную (потребительскую) и третичную (транспортную) упаковку.

- 5. Занесение в ИС МДЛП информации о завершении этапа окончательной упаковки.

При регистрации в ИС МДЛП операций окончания финальной маркировки изготовителем фармацевтических средств выполняется передача следующего перечня информации (по каждой единице товара):

Дата совершения операции;

Идентификационный номер места осуществления своей деятельности российским производителем лекарственных препаратов;

Производственный тип заказа (контрактное или собственное);

Персональный регистрационный номер собственника лекарственного препарата в ИС МДЛП (используется при контрактном производстве);

Номер производственной серии;

Дата истечения срока годности лекарственного препарата;

GTIN;

SGTIN;

Информация об используемом для регистрации сведений устройства (при передаче информации с использованием оборудования регистрации эмиссии).

Рис. 7. Диаграмма бизнес-процессов фармацевтической компании «Ввод в оборот ЛП, произведенных на территории Российской Федерации»

6. Проведение отбора контрольных, архивных образцов, а также образцов, подтверждающих соответствие лекарственного препарата.

7. - 8. Занесение в ИС МДЛП информации по отбору образцов лекарственных препаратов.

При регистрации в ИС МДЛП информации по операциям отбора образцов изготовителем фармацевтических средств выполняется передача следующей информации:

Дата совершения операции;

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

Категория отбора образцов;

SGTIN.

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

10. - 11. Внесение и регистрация в ИС МДЛП информации по выпуску фармацевтической продукции.

При регистрации в ИС МДЛП информации по операциям выпуска фарм-продукции изготовителем фармацевтических средств выполняется передача следующей информации:

Дата совершения операции;

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

Документ, подтверждающий соответствие ЛП;

Дата документа, подтверждающего соответствие ЛП;

Номер документа, подтверждающего соответствие ЛП;

SGTIN и/или SSCC.

12. Загрузка информации в Подсистему «Выборочный контроль» автоматической ИС Росздравнадзора о выпуске фарм-продукции и вводе лекарственного препарата в оборот.

В Подсистему «Выборочный контроль» для регистрации ввода лекарственного препарата в оборот осуществляется предоставление следующей информации:

Торговое наименование препарата;

Международное непатентованное наименование препарата;

Параметры упаковки;

Производитель (текущий собственник);

Регистрационный удостоверительный номер лекарственного препарата;

Дата регистрации в системе лекарственного препарата;

Код подтверждения наличия в перечне ЖНВЛП;

Серийный производственный номер;

Номер сертификата или декларации;

Дата регистрации сертификата или декларации;

Место или площадка производства (место хранения) лекарственного препарата;

GTIN;

Суммарное число единиц лекарственных препаратов, введенных в оборот на данном этапе.

В российской практике на данный момент происходит тестирование функционала передачи информации в ИС МДЛС с применением специального оборудования по отслеживанию эмиссии.



2.3 Бизнес-процессы фармацевтической компании при отгрузке ЛП со склада отправителя и приемке ЛП на складе получателя

Теперь рассмотрим бизнес-процессы при отгрузке лекарственного препарата со склада и его приемке. Будет рассмотрен прямой порядок подтверждения процессов.

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

Для осуществления возврата лекарственного препарата покупающей и продающей сторонами происходит регистрация операции согласно данному разделу - в роли отправителя выступает покупатель, в роли получателя - продавец. Отправителем вносится информация в ИС МДЛП об отгрузке с соответствующим статусом «Возврат поставщику».

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

Занесение в ИС МДЛП информации об отгрузке лекарственного препарата в рамках муниципального фармацевтического обеспечения выполняется отправителем согласно описанным процессам в разделе при «прямых» поставках в места отпуска препарата (без использования услугами промежуточных складирований от поставщиков логистических услуг) или при отгрузке препарата на склад поставляющей стороны логистических услуг для дальнейшей передачи в места отпуска препарата.

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

Рассмотрим бизнес-процессы при отгрузке лекарственного препарата со склада и его приемке и опишем выполняемые при этом действия. Данные БП будут отображены в виде UML-диаграммы (Рис. 8) и в виде упорядоченного по своей последовательности выполнения списка.

1. Подготовка продукта к отгрузке, упаковка лекарственного препарата в тару для транспортировки.

2. Проведение отгрузки лекарственного препарата со склада отправляющей стороны.

3. - 4. Регистрирование в ИС МДЛП информации по отгрузке лекарственного препарата со склада отправляющей стороны.

При регистрировании в ИС МДЛП факта отгрузки лекарственного препарата отправляющая сторона сообщает следующую информацию в ИС МДЛП:

Дата проведения операции;

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

Идентификатор места, где осуществляется деятельность принимающей стороны, на которой выполняется приемка препарата;

Тип отгрузочной операции со склада (реализация или возврат);

Источник финансирования;

Тип договора;

Номер контракта из реестра (в случае проведения отгрузки лекарственного препарата в рамках муниципального фармацевтического обеспечения);

Дата отгрузочного документа;

Номер отгрузочного документа;

Цена реализации лекарственного препарата в рублях (НДС включается);

Сумма НДС (при условии, что сделка облагается НДС);

SGTIN и/или SSCC.

В случае необходимости указания каких-либо цен внутри упаковки для группы отправляющая сторона сообщает дополнительно следующую информацию для SSCC:

GTIN;

Номер серии производства;

Цена реализации лекарственного препарата (для указанного GTIN и серийного номера вместе с НДС);

Сумма НДС (при условии, что партия облагается НДС).

5. Уведомление получающей стороны об отгрузке лекарственного препарата со склада отправляющей стороны.

Уведомление получающей стороны о факте отгрузки препарата формируется на основании прежде зарегистрированной отправляющей стороной операции и содержит следующую информацию:

Дата проведения операции;

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

Идентификатор места, где осуществляется деятельность принимающей стороны, на которой выполняется приемка препарата;

Тип отгрузочной операции со склада (реализация или возврат);

Источник финансирования;

Тип договора;

Номер контракта из реестра (в случае проведения отгрузки лекарственного препарата в рамках муниципального фармацевтического обеспечения);

Дата отгрузочного документа;

Номер отгрузочного документа;

Цена реализации лекарственного препарата в рублях (НДС включается);

Сумма НДС (при условии, что сделка облагается НДС);

SGTIN и/или SSCC.

Рис. 7. Диаграмма бизнес-процессов фармацевтической компании «Отгрузка ЛП со склада отправителя и приемка ЛП на склад получателя»

В случае необходимости указания каких-либо цен внутри упаковки для группы отправляющая сторона сообщает дополнительно следующую информацию для SSCC:

GTIN;

Номер серии производства;

Цена реализации лекарственного препарата (для указанного GTIN и серийного номера вместе с НДС);

Сумма НДС (при условии, что партия облагается НДС).

6. Приемка ЛП на склад получающей стороны.

7. Выполнение проверки получающей стороной информации по отгрузке лекарственного препарата со склада отправляющей стороны.

8. - 9. Подтверждение получающей стороной информации по отгрузке лекарственного препарата со склада отправляющей стороны.

Для выполнения подтверждения прежде зарегистрированной отправляющей стороной информации по отгрузке лекарственных препаратов получающая сторона обеспечивает передачу в ИС МДЛП следующей информации:

Дата проведения операции;

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

Идентификатор места, где осуществляется деятельность принимающей стороны, на которой выполняется приемка препарата;

Подтверждение приемки приостановленного товара (вводится если, Росздравнадзор решил временно вывести из обращения лекарственный препарат);

SGTIN и/или SSCC.

10. Уведомление отправляющей стороны о подтверждении получающей стороной информации по отгрузке лекарственного препарата со склада отправляющей стороны.

Уведомление отправляющей стороны о подтверждении получающей стороной информации по отгрузке лекарственного препарата формируется на основании прежде зарегистрированного действия и включает в себя следующие пункты:

Дата проведения операции;

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

Идентификатор места, где осуществляется деятельность принимающей стороны, на которой выполняется приемка препарата;

Подтверждение приемки приостановленного товара (вводится если, Росздравнадзор решил временно вывести из обращения лекарственный препарат);

SGTIN и/или SSCC.

На базе рассмотренных бизнес-процессов далее будет проанализирована и построена структура процессов с интегрированной блокчейн-системой на базе Proof of Authority консенсус алгоритма. Потребуется рассмотреть на каких этапах движения лекарственного препарата после его производства будет производиться его сканирование и занесение его в отраслевую/корпоративную блокчейн систему, кто будет производить сканирование и в каком виде будут записывать данные. Последний вопрос довольно актуален, так как потребуется детальный обзор способа записи транзакций (в нашем случае операции по передачи прав собственности на лекарственный препарат) в блок, а также обзор самой транзакции. Далее будут описаны возможные дальнейшие точки сканирования упаковки лекарственного препарата после его выхода со стороны производителя вплоть до контакта с конечным потребителем.



Глава 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).

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

Рис. 13. Отправка данных по операции на процедуру подготовки добавления блоков

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

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

Добавление блока в реестр. На следующем этапе происходит добавление операции в локальную копию реестра. При условии валидности операции к текущему состоянию системы применяется Write Set, обновляя текущее значения объектов. Если же произошла проблема двойного расходования, а именно, произошло две операции с одними и тем же объектом в рамках одного блока, то операция признается не валидной, поскольку исходные состояния системы уже были изменены другой операцией. Если же операция валидна, то добавляется вместе со своим блоком в распределенный реестр и пользовательское приложение получает уведомление, что операция добавлена в реестр и является валидной. (см. рис. 15).

Рис. 14. Отправка сформированного блока с операциями на формирующие узлы

Рис. 15. Добавление блока с информацией по операции отгрузки со склада производителя в распределенный реестр

3.4 Принципы идентификации участников блокчейн-системы

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

Чтобы личность участника могла быть проверена, она должна быть определена указанием от доверенного органа. Поставщик услуг членства (в случае рассматриваемой системы это государство) -- это участник, который определяет правила, управляющие действительными удостоверениями для каждого отдельного участника сети.

Так, для безопасного функционирования сеть и безопасного ведения деятельности в ней используется инфраструктура публичных ключей. Элементы инфраструктуры открытых ключей (PKI) представляют из себя центры сертификации, которые выдают цифровые сертификаты участникам системы (например, пользователям услуг, поставщикам услуг), которые затем используют их для аутентификации в операциях в ходе взаимодействия с медицинскими препаратами. Список отозванных сертификатов CA (CRL) представляет собой ссылку на сертификаты, которые больше не действительны. Отзыв сертификата может произойти по ряду причин. Например, сертификат может быть отозван, потому что был раскрыт криптографический закрытый материал, связанный с сертификатом.

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

В PKI есть четыре ключевых элемента:

Цифровые сертификаты

Публичные и частные ключи

Центры сертификации

Списки отзыва сертификатов

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

Криптография позволяет участнику системы представить свой сертификат другим, чтобы подтвердить свою личность, если другая сторона доверяет издателю сертификата, известному как Центр сертификации (роль которого на себя будет брать государственная компания ИС МДЛП, либо специально отдельно созданная для этого структура). До тех пор, пока центр сертификации надежно хранит определенную криптографическую информацию (т.е. его собственный закрытый ключ подписи), любой, кто читает сертификат, может быть уверен, что информация об участнике не была подделана.

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

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

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

Как уже указывалось ранее, участник или узел может участвовать в сети цепочки блоков с помощью цифрового удостоверения, выданного ему органом, которому доверяет система. В наиболее распространенном случае цифровые идентификаторы (или просто идентификаторы) имеют форму криптографически-подтвержденных цифровых сертификатов, которые соответствуют стандарту X.509 и выпускаются центром сертификации (CA).

Центр сертификации выдает сертификаты различным субъектам. Эти сертификаты подписаны ЦС в цифровой форме и связывают участника с его открытым ключом (и с полным списком параметров участника). В результате, если участники доверяют СА (и знают его открытый ключ), они могут доверять тому, что конкретный субъект связан с открытым ключом, включенным в сертификат, и владеет включенными атрибутами, проверяя подпись СА на сертификате субъекта.

В рассматриваемой системе центром сертификации должно стать государство, а именно государственная компания, возможно совместная организация с ИС МДЛП, как уже указывалось ранее.

Список отзыва сертификатов (CRL) прост для понимания -- это просто список ссылок на сертификаты, которые CA помечает как отозванные по той или иной причине.

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

3.5 Концепция смарт-контракта по регистрации лекарственного препарата в блокчейн системе

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

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