Как происходит обмен медицинскими данными

Всем привет! Меня зовут Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионалов, с которыми можно поговорить простым человеческим языком. Сегодня мы будем разбираться в передаче и хранении электронных медицинских данных. Может показаться, что это какая-то узкоспециализированная тема, которая к нам имеет довольно малое отношение. На самом деле мы все с этим сталкиваемся. Например, вы переехали и хотите прикрепиться к новой поликлинике. Раньше это можно было сделать, просто перенеся свою медицинскую книжку бумажную. А теперь практически в каждой стране есть какая-то система, которая помогает хранить медицинские данные пациентов и передавать их между организациями, между врачами. Работают они, скажем так, так себе. При этом задачу хранения и передачи медицинских данных решают уже очень давно. Достаточно сказать, что один из первых протоколов передачи медицинских данных появился в конце 70-х. даже раньше, чем протокол HTTP, на котором построен весь современный интернет. Почему за 40 лет не могут решить такую, казалось бы, простую задачу? Что в ней вообще сложного? В этом мы сегодня разберёмся с экспертом, с человеком, который уже больше 15 лет внедряет ведущий протокол в области передач медицинских данных. Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс Практикум. У Практикума есть курсы по разработке, по анализу данных и по английскому языку. Если вы хотите освоить цифровую профессию, приходите на сайт Яндекс Практикум и учитесь. А еще 30 мая Практикум проведет онлайн день открытых дверей. Там они расскажут о том, что такое программирование, какие профессии есть и как выбрать себе по душе. Еще они поделятся секретом, как они помогают найти работу после обучения. 30 мая, 5 вечера. Ссылка есть в описании. к этому эпизоду.

Меня зовут Николай Рыжиков, я CTO и кофаундер компании HealthSamurai. Мы занимаемся информатизацией медицины и разрабатываем платформу нового поколения в современном стандарте FHIR, который позволяет встроить и донастраивать новые гибкие системы передачи и обработки медицинской информации.

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

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

Какие вообще данные хранятся в электронной карте пациента?

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

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

То есть исторический врач, он писал эпикриз, это была такая некая маленькая история сначала как бы про все болезни и здоровье пациента. Сейчас же мы, получается, можем разбить это на более мелкие кусочки, хранить их по отдельности и связывать уже при помощи информационных технологий. Ну и базовый набор данных пациента, о которых ты сказал, конечно, до сих пор основным является что-нибудь типа выписного эпикриза. Пока еще переход, на самом деле, окончательных цифр не произошел. Поэтому врач пишет этот документ, пришел пациент, сколько-то лет, какие-то болезни. То есть это вот некий атавизм, но просто в электронной форме. Иногда он в виде PDF-документа, иногда он в виде какого-то более структурированного текстового документа, хотя бы с параграфами. Также сами демографические данные пациента. Его лаборатория уже достаточно неплохо оцифрована. Как раз исторически она одна из первых была оцифрована. Можно хранить диагностику МРТ, КТ как бы в виде сырых данных и в виде некоторого summary (саммари). Хотят хранить диагнозы, там иногда говорят о списке проблем, некий проблем-лист или список диагнозов. Ну, а обязательно хранят, конечно, медикамент в каком-то дискретном, какие медикаменты прописаны, если получается детектировать, когда их пациент принимал, записывать, то вот что он принимал, что не принимал. Аллергии стараются тоже хранить, чтобы каждый раз вас не спрашивали, у вас есть аллергия на что-то или нет, потому что ошибка дорого может стоить. Ну, вот такой вот наборчик.

то есть хранят демографическую информацию в каком-то машиночитаемом виде и такой медицинский стори-теллинг, когда врач описывает в удобном ему формате, просто текст пишет. Да. Еще интересный момент про МРТ, потому что это же 3D-изображение, они очень много весят, и я так понимаю, там какие-то сложные форматы, и это все тоже хранится прямо внутри карты пациента.

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

Коля, а в чем вообще проблема бумаги? Это цифровизация ради цифровизации или там какая-то цель преследуется?

Бумага – это как бы хардкопия. Одна копия. Ее очень сложно передавать. Пациент лечится в разных местах, переезжает с места на место. И это как раз то, что цифра умеет очень хорошо делать. Умеет хорошо копироваться и передаваться на расстояние. Врачу, медсестре, родным пациентам. У каждого будет по копии. Плюс она будет вживую обновляться. Если вы ходили в две поликлиники, у вас там две бумажные карточки, никто их ручками не смешит. Цифру легко слить воедино.

Эти книжки пациента, они хранятся в единой системе или у каждой клиники своя изолированная система?

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

Вот в мире офисных программ есть компания Microsoft. Она делает продукт офис, в котором есть Word, Excel и все остальные продукты. И вот все остальные компании так или иначе копируют или должны как-то уметь работать с решениями от Microsoft. Как устроен рынок хранилищ медицинских карт и вообще медицинских данных?

которая бы навязала бы всем свой проприетарный некий формат передачи данных. Исторически сложился и, наверное, самый сейчас активно используемый, но и самый старый— это стандарт HL7 v2. То есть HL7— это организация, она когда-то 50 лет назад выпустила стандарт v2. Она его постепенно обновляла, v2.1, v2.2, v2.3. Как бы был разработан он для лабораторных анализов, для обмена данными лабораторкой. И с тех пор уже используется, лет 50. И на нем сейчас большинство систем умеет разговаривать, умеет отдавать по событиям сообщения. То есть как устроен этот формат? Пришел пациент, завели его карточку, зарегистрировали его. Система административная породила сообщения, которые, типа, пришел новый пациент. Это сообщение разлетелось в радиологическую систему, в лабораторную, еще куда-то, может быть, на государственный уровень улетело, кто-то сагрегировал. Пациента госпитализировали, еще одно сообщение. Лабораторный анализ заказали, сообщение в лабораторию. Но слушать его могут все. Если мы говорим про Штаты, ну или про какую-то Европу, где это все было настроено, то есть много систем, которые хранят так, как умеют, а между ними летают вот эти V2 сообщения. Если их недостаточно, начинают что-то изобретать, какие-то велосипеды, какие-то сервисы прикручивать, доставая недостающую информацию или дописывая то, что невозможно передать в виде этого устаревшего V2 сообщения.

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

Да, это протокол. Никто тут как бы не доминирует. Тут правят стандарты обмена, а какая там домашняя кухня, типа, неважно. Протокол, он создавался где-то одновременно вместе с HTTP протоколом. Ну, я даже не смеюсь, там, я думаю, даже одни и те же люди руку прикладывали в каких-то... Всё-таки вот если

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

Конечно, есть коробок сотни. Вы идёте на рынок и смотрите, какие там есть решения. Там различают inpatient, outpatient. Inpatient – это больницы, outpatient – это всякие клиники, практики. К каждому из них есть длиннющие списки того, что можно себе поставить. Есть свои лидеры. Например, на рынке больничных систем победил Эпик. Такая система, она, наверное, сожрала сейчас больше половины американских больниц. За ним Cerner и потом там уже хвостик сильно проигравший. На outpatient-рынке больше систем разных. Всякие Athenahealth, Kareo, DrChrono. Ну их прямо достаточно много.

Супер, получается, что самому программировать с нуля по стандарту, наверное, не обязательно, можно взять что-то готовое. Может ли российская клиника взять и поставить себе американское решение?

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

Выставлять ему счета.

Да, выставлять счета даже в основном страховым. И на самом деле как раз в этих так называемых EHR как бы там…

А как это расшифровывается?

EHR – Electronic Health Record. Но так закрепилось, что медицинская информационная система – это обычно EHR. Больше половины, наверное, их составляет именно выставление вот этого клейма, это как бы счет в страховую, и его оплата, и обработка.

Я себе представляю ад программистов, которым нужно программировать бизнес-логику, выставление счетов, в каком случае, кому что. И это все неприменимо в России, насколько я понимаю, да? То есть вот эта большая часть программирования, она просто сразу идет лесом.

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

А что на рынке в России?

Есть 5-6 МИС. По-русски это называется Медицинская информационная система или МИС. То есть есть большие гибриды типа там БАРСов, которые прямо все нужды пытаются закрыть, включая обмен с государством как бы данными. И есть чистые МИСки, там какие-то на Одинессе написаны.

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

Медиалог, Самсон, но их там меньше десятка активно.

Как лучше, брать что-то готовое или самим пробовать?

Это философский вопрос.

Вопрос нефилософский. Нужно взять Microsoft Office и никому не тратить время.

Но если делается серьезный документный оборот, он все равно не будет на Microsoft Office. Хотя бы SharePoint или еще что-то. В чем проблема? Ваша медицинская деятельность каждого учреждения в какой-то степени уникальна. Задача системы— автоматизировать эти процессы. Вот эта автоматизация и оптимизация этих процессов – штука сложная. В разных местах принято по-разному что-то делать. Даже от одной к другой больницы ты перейдёшь, и там всё немножко по-другому, какие-то свои правила. Медицинской информации много. Передать я её могу разными способами. Отчерпнув вот этим нечитаемым почерком на бумажке. Или если мы идём в цифру, то нужно придумать некий формат, что каждое поле означает, какой у этого смысл. Вот этот словарь, эти правила, по которым эти фразы строятся, это и называется информационная модель. Зачастую люди, которые разрабатывают систему, они создают свою внутреннюю модель, некий сленг. То есть они начинают в больнице разрабатывать систему, они берут сленг этой больницы, И как бы его закладывают в модель. И мы так сделали, например, в свое время. Но потом, когда твоя система начинает разговаривать с другими системами, там выясняется, что там другой сленг, другой диалект. Зачастую эти диалекты не способны вообще друг друга понимать. Ну вот, например, как передавать данные о визите. То есть пришел пациент в больницу. Самый простой первый вопрос, как будет называться сам визит?

Факт посещения.

Да, факт посещения. Ему нужно придумать название. визит или encounter (энкаунтер).

А что, есть разные варианты?

Конечно. Часто народ смешивает то, что называется запись на прием и визит. Оказывается, что технически и логически правильно их разделять. То есть когда у вас запись на приём – это одна сущность, а когда по ней происходит визит – это другая. То есть визит – это уже факт того, что пациент пришёл, и там у него есть время, свои атрибуты, а запись на приём – пациент может не прийти, может перенестись. И разбить на вот эти сущности информационные единицы, решить, как они называются, как называются в них поля. Вот куда мы пишем паспорт пациента? Куда мы запишем СНИЛС? И вот здесь вы должны придумывать эти таблички свои, давать им имена, и, как выясняется, это очень тяжелый на самом деле процесс, потому что программист склонен, если ты ему скажешь, не знаю, сложи СНИЛС, он идет и добавляет колоночку СНИЛС. Потом этих колоночек становится 100. Потом выясняется, что некоторые идентификаторы со временем протухают. И таким образом такая эволюционная схема обычно склонна стать достаточно уродливой. Потом уже эту схему смотришь внутрь базы данных, и уже вообще ничего не понимаешь. Там еще ребята решили сокращение ввести, или назвали F1, F2, F3. Попробуй теперь передай эту информацию. Зачастую те, кто дизайнили, и те, кто будут потом дописывать эти модули интеграционные, это разные люди. Им не передается вот это наследство. Зачастую приходится то, что называется реверс инжинирить вот эту базу, пытаясь понять, как же она устроена.

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

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

SAP— это старший брат 1С. Это немецкая платформа, на которой делают софт для очень больших корпораций. Обычно проекты там огромные, много инженеров, месяцы, если не годы разработки.

Люди тратят кучу денег, кучу времени, ресурсов, и все равно получаются чудовищные процессы. чем бумага по эффективности. Это очень хорошо можно увидеть сейчас, например, в России, когда всем поставили эти компьютеры врачам. Теперь ты на визите с врачом как бы сидишь и смотришь, как он одним пальчиком тыкает в клавиатуру. Вместо того, чтобы разговаривать с тобой, осматривать тебя и думать, как же тебя вылечить, он две трети времени, я просто специально засекал, сидит, и вколачивает это в систему, которая по сути тоже система не помогающая сейчас врачу, а некая просто отчетная система. И это огромная проблема, признанная, до нее только пытаются подобраться, потому что уровень сложности большой, и сама предметная область сложная, и IT сложная, и как это все совместить, еще много вопросов. Ну, я верю все-таки в то, что если мы движемся к цифровизации, лучше пойти, ну, я как программист, конечно, лучше пойти путем того, что у вас будет своя сильно айтишная команда, которая сможет быстро и гибко реагировать на меняющуюся реальность. Надо встроить Uber или там Яндекс.Такси, чтобы привозить пациентов. Три недели встроено, да? На самом деле, как показывает наш опыт, маленькая командочка, человек 8-10 программистов может обслуживать большую больницу. Так что, если правильно выстроить процессы, все будут счастливы. Мы с нашей компанией уже достаточно много похожих систем сделали с людьми, которым не понравилось то, что есть на рынке, и они решили сделать для себя.

Ты сказал, что 6-8 программистов могут обслуживать большую больницу. Они программируют это с нуля, или есть все-таки какие-то конструкторы, или нужно брать вот этот большой условный САП и его этими своими 6-8 докручивать?

Ну, тут есть опции. Ну то есть почти все системы в той или иной степени позволяют кастомизироваться. Тут надо идти, наверное, от программистов. То есть если у вас есть программисты, которые знают 1С, наверное, не идеально, но на самом деле оптимально для вас, вы сможете донастроить МИС на основе 1С под то, что вам нужно. Если у вас есть деньги на САП и на людей, которые этот САП кастомизируют, можете попробовать это на САПе сделать. Даже современные российские Вот эти системы, они позволяют в какой-то степени себя настраивать. Есть еще другой подход. Вы берете просто известный фреймворк, там Ruby on Rails, Django или еще что-то, да, и начинаете строить поверх него. То есть он уже дает какой-то bootstrap, он немного знает про медицину, но он заточен под быструю разработку. И если у вас сообразительные ребята, то как бы что-то будет получаться. Мы пытаемся сделать такой вот медицинский фреймворк, который уже знает про медицину, то есть вам не нужно будет принимать как бы программистам и вам множество решений, там моделирование данных, то есть можно сразу приступить к автоматизации своих процессов. Легко как бы не будет, но результат может стоить того.

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

вашей, что вы на основе нее, Ну, это классическое путешествие. Мы через эти путешествия тоже прошли. Ну, мы первую систему писали госпитальную для Соединенных Штатов. Она стояла там в трех-четырех достаточно больших госпиталях. Мы взяли Ruby on Rails и начали писать систему. Мы ее писали 8 лет, ну, наверное, там. Через годик мы уже вышли в продакшн с какими-то первыми вещами, и потом еще лет 7 мы дописывали. Это нормально, это стандартно, даже многие успешные EHR, потому что внутри у них там получился как бы ад и Израиль, ну то есть это вот разработка, которая слоистая, итеративная, то есть получилось что-то, что уже тяжело поддерживать, поэтому хорошие системы как бы там по нескольку раз переписываются, каждый раз с каким-то новым виженом, с новыми целями.

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

Самая простая интеграция— это централизованная. В России полуцентрализованная, принята картинка, то есть есть регионы, в регионах стоят вот эти аккумулирующие системы, которые помогают обмениваться. Ну или иногда в самом простом варианте там просто ставится одна большая система, которая внутри себя все это делает, какой-нибудь бар ставится. Или ставить какая-нибудь шина в виде нетриковской шины.

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

И много разных МИСов к ней подсоединяются. И они умеют обмениваться с этой шиной сообщений. То есть, например, из МИСок выгружаются документы. Или если там заводятся пациенты, то они тоже туда. выгружаются какие-то отчеты из МИСок, выгружаются в региональную шину, из региональной шины оно улетает в централизованную. Причем по дороге мы теряем часть информации, потому что вы уже в централизованную шину будете выгружать лишь часть, какие-то внутренние данные останутся. У программистов хватило сил, чтобы все это выковырить. Под такую выгрузку обычно продумывается некий протокол. То есть, например, сейчас вот эти ЕГИС-СЗ, то есть единые государственные сегменты, вот они требуют выгружать определенные в виде документов. Они делают попытку дать какие-то реестры пациентов. Ну и общий флоу выглядит очень просто. То есть все выгружают в центр, и из центра все потом могут запросить.

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

Была программа, она стартовала лет 10 назад, с нуля. Как раз каждому региону предложили разработать такую систему или купить. Каждый регион поступил по-своему. Кто-то купил так называемую Monomis на весь регион и поставил ее во все больницы. Пример Monomis – это Барс. Барс в Москве стоит. Некоторые регионы взялись и написали просто сами. Ну, их там безнаметное число. Ну, то есть те, которые просто сделали некое свое внутреннее решение. Например, из Питера пошел подход через Шину. То есть Нетрика разработала только Шину с протоколами. То есть какая информация складывается, там, реестры пациентов, там, врачей. протокол записи на прием, и сказала, что в регионах можете ставить разные МИСы, интегрировать, и отдельно эти МИСы с ней общаются. Эта информация, я думаю, публичная, то есть можно посмотреть на отчеты, какой вендор стоит в каком регионе, и как он обеспечивает этот обмен данными. Сейчас, например, мы в Чувашии помогли разработать вот такую шину централизованную, уже на основе стандарта FHIR. Сейчас первая версия сделана, она еще достаточно бумажно ориентирована, то есть люди мыслят не дискретными данными, а дискретными документами. Все-таки основное хранилище представляет из себя почти вот эту распухшую папочку только из цифровых документов, о которых ты говорил. Но теперь ты ее можешь из любого места запросить, и пациент ее может запросить.

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

теряются не данные, теряются информация на преобразованиях. То есть вот у вас, например, стоит какой-нибудь инфоклиник или медиалог. Внутри него данные лежат определенным образом. Какой-нибудь региональный реестр потребовал от вас выгружать документы в неком формате X. Конечно, ни медиалог, ни инфоклиник про этот формат X не знали. Садятся программисты и перекладывают те данные, которые есть, в то, что попросили. Во-первых, где-то попросили не все, что есть, А где-то попросили того, чего нет, и это заткнули чем-то. Получается, что в этот момент трансформации информация теряется, данные не теряются. Данные лежат в инфоклинике, но часть информации потеряна. Потом, если из региона передают в центр, там другой формат, другой отчет. Опять кто-то садится, это все перемапливает. И по дороге что-то теряется. Иногда может потеряться почти всё. Ну, в Штатах мы сталкивались с тем, что, например, вот как раз там тоже был придуман нечто вот электронное в виде карточки пациента, так называемый CCD, там, continue care документ. То есть сертификация заставила систему их отдавать, но он такой сложный был формат, что народ туда как получилось, лишь бы пройти сертификацию. Ты иногда заходишь в систему, как бы пытаешься через CCD получить карточку, а там по сути просто какие-то моки тебе отдаются.

МОКИ – это в смысле просто пустые данные?

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

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

Но там длинная история. 50 лет назад появился HL7 V2, и он оказался очень прагматичным стандартом, то есть работающим стандартом. На нем до сих пор сидит куча западных стран, а не только западных. Например, если вы лабораторное устройство покупаете, какой-нибудь анализатор крови, он с большой долей вероятностью поддерживает этот протокол. То есть он умеет отдавать данные или радиологическую систему. Но ему уже 50 лет. Он писался по принципу, а давайте вот хотя бы это передадим, а потом добавим вот это, добавим вот это. И там такой как бы pipe separated, типа csv, файлик разделенный запятой. То есть это еще до XML, до JSON, до каких-то современных форматов. Но он работает. И, например, в Штатах, если самый надежный источник протокола для данных искать, который поддержит большинство систем, это будет V2. В России он тоже заехал через различные лабораторные, радиологические системы, но прямо основательного применения везде не получил. начали думать, что же делать с этим, потому что сам стандарт устаревший, хочется уже как-то попроще с этими данными быть, какой-то информационной модели. И, например, та же организация HL7 придумала стандарт V3, но она там очень сильно за-оверинженерила, то есть она посадила академиков там, которые все красиво придумали, но когда это начали инженеры делать, казалось, что как-то очень сложно. Голова взрывается, и очень велик соблазн сделать то, что я говорил, как бы просто неправильно сделать, не доделать, не передать информацию. Потом началась как бы некая волна, и, по сути, вот стандарт FHIR, который пишется F-H-I-R. FHIR описывает некий сервер, на котором лежат ресурсы, они программистам близки, это там просто джессоновые модельки с человеческими именами. FHIR сейчас там около 10 лет, и вот он начинает уже внедряться постепенно. Как раз он внедряется снизу, не потому что заставили, а потому что многим программисты при взгляде на FIRE, устав от этой жути V3 и древности в виде V2, видят в FIRE что-то знакомое для программиста. То есть какой-то JSON, хорошую документацию, открытое сообщество. И он их привлекает как хороший фундамент для того, чтобы построить систему. Ну и в частности, мы, например, евангелируем этот подход, что берите как бы внутрь своей системы прямо вот эту информационную модель FIRE, подсоединяйтесь к сообществу, спрашивайте, не делайте вот эту очередную закрытую систему, с которой все будут мучиться. То, что называется interoperability, когда одна система способна понимать другую.

Окей, мы с тобой много поговорили про клиники, про систему внутри клиник, но ведь есть ещё и другие участники медицины. Вот, например, лаборатория. Это самый, мне кажется, очевидный участник. Я иду в лабораторию, сдаю кровь, условно, «Инвитро». Как в идеальном мире эти анализы попадают в врачу и как это происходит сегодня? Кроме того, что я там ПДФ-ку отправляю на почту врачу. Есть какие-то технические решения для этого?

Лабораторные системы одни из самых продвинутых в медицине, на самом деле, в плане структурированных данных и обмена данными. Например, про «Инвитро» точно не знаю, там Helix, большая тоже сеть лабораторная, она уже внутри использует FHIR. То есть да, она пришлет вам PDF, даже она там интегрировано с ЕГИС-СЗ, и может туда отосвать какой-то отчет. Внутри у нее уже файл, т.е. как только все начнут говорить на этом протоколе, она сможет разговаривать. В общем, процесс, если это направление от врача, должен выглядеть так, что врач с сообщением электронным, это вот В2 так было сделано. отправляет в лабораторию заказ, что этому пациенту нужно сделать тот. Лаборатория там собирает пробу, делает анализ и обратным сообщением отправляет результат. В России получается, если по государственной линии все это идет, То есть, если заказывающий был врач в какой-нибудь государственной больнице или поликлинике, и даже если вас обслуживает коммерческая лаборатория, она обязана отчитываться в этот центр, в региональный сегмент. Поэтому теоретически, и, возможно, много где практически, ваши данные в дискретном виде лежат. Как минимум, в лаборатории они лежат, как максимум, лаборатория их передала в центр, если договорились о протоколе. Опять же, очень сильно зависит от региона. То есть я уверен, что, наверное, во многих регионах уже это работает.

А для этого обмена используется FHIR? Потому что это, кажется, самое логичное место для применения этого стандарта.

Пока нет. То есть пока используется СЭМД.

Эта система построена на старом протоколе HL7 версии 2.

«Фаер» для России, вот мы только сейчас введем работу, это мы уже два раза пытались начать, вот сейчас вроде начали достаточно неплохо, то есть собралась группа энтузиастов, включая вот «Снеуиз», это служба заказчика государственного, которые написали уже первую версию своего центрального сегмента и чувствуют, что надо бы как-то подумать, как это сделать правильно. Там же лаборатории в виде «Инвитро» и «Хеликса», и их участники. Та же фирма Нетрика, наши передовые разработчики нового поколения, МИСы типа Мирамедикса, фирмы. И это всё пока только в процессе разработки. На региональном уровне эти решения принимаются. В некоторых регионах это уже так. Если мы говорим про Чувашию, например, где наша платформа была использована, и компания Алькона написала поверх неё такую мономисс, и шину, если мы говорим про нетриковскую шину, то у нее уже часть протоколов действительно на FIRE, и в частности лабораторка на FIRE у нетрики, то есть если в вашем регионе стоит нетрика, с ней с интегрированной лабораторией, то внутри там уже протокол FIRE.

Еще один такой важный потребитель данных— это не больница и не лаборатория, а аптека. Вот в Латвии, например, я даже не уверен, что вообще существуют бумажные рецепты, потому что врач пишет что-то на компьютере, дальше ты приходишь в любую аптеку на территории Латвии, показываешь ID-карту и получаешь лекарство. Есть ли вообще аптеки в стандарте FHIR?

Сам стандарт описывает этот домен. Если мы говорим про e-prescription, то есть электронные рецепты, то как раз на FIRE в Литве сделаны электронные прескрипшены. На FIRE сделаны эдак лет 6 назад. То есть там еще первая версия стандарта, как только появился, Литва оказалась впереди, как бы планеты все. И там электронные рецепты. То есть, например, в Белоруссии ребята тоже взяли нашу опенсорсную базу Fhirbase и написали e-prescription. А понимать, что если мы говорим про электронные рецепты, это в значительной степени именно организационный вопрос. Понятно, что в маленькой стране, где две аптечные сети, это несложно сделать. Если мы говорим про большую страну и про такую толстую нишу, как фарма, как аптеки, то тут это нужно еще суметь организовать. А это технически, на самом деле, вообще не сложно сделать. Я так понимаю, что у нас оно пока не организовано. Потому что это сложный процесс между государством, бизнесом, медицинскими учреждениями.

Я внезапно понял, что для меня IT встречается со здоровьем. Это приложение Apple Health. И еще у меня есть много гаджетов Withings. У них тоже есть свое приложение. Вот они обмениваются друг с другом данными через вот этот протокол, через вот эту систему, которую сделала компания Apple. У Google есть что-то подобное свое тоже в Android, Google Health или Google Fit он называется. Как эти две системы вообще интегрируются, или как интегрируются ли они как-либо с больницами и с этими региональными государственными системами?

Ну, они могут интегрироваться. У тебя какое-то устройство передает данные, например, тот же Apple Health предоставляет свой облачный диск, чтобы на него эти данные сохранять. сохранив эти данные на этом диске, оно может отдавать условный пользователь телефона, может его передать другой системе, которая их тоже вытащит и сохранит к себе. То есть на самом деле таким образом эти данные через эти протоколы. Вот так оно и происходит. Тот же Apple HealthKit уже и FHIR поддержал, и поддержал интеграцию, например, с МИСами американскими, И пациент даже может запросить и получить свою карточку из больницы на устройство и передать куда-то. Большинство этих облачных типа Гугла и Эппла с данными ничего не делают, они их просто передают из одного места в другое. В крайнем случае, хранят зашифрованными на диске. То есть в этом плане они инфраструктурные. И эта инфраструктура, в принципе, доступна и у нас. Вопрос только как ей воспользоваться. То есть теоретически, наверное, ваше приложение госуслуги на телефоне могло бы начать собирать ваши данные с фитбита, с браслетика. Также оно могло бы их раздавать, то есть, например, какому-то коммерческому или опенсорсовому приложению вы бы могли предоставить доступ к своей карточке. Если у вас есть, например, место, где лежат ваши данные в дискретной форме, passionportal или сегмент региональный, в принципе, полшага до того, чтобы устроить эту экосистему приложений, получающих доступ. Может быть, какое-нибудь приложение из App Store, которое проанализирует карточку или подскажет, какой медикамент купить. Как бы есть вот эта фантазия про вот этот некий апстор медицинский, имея свои данные в портале условном, может отдать некому приложению эти данные, чтобы оно что-то полезное ему подсказало или дозаполнило. К этому пытаются сейчас приближаться.

Хочу вернуться обратно к тому, как это реально все реализуется. Ты упомянул несколько раз свой проект в Chuvashia, то, что там региональный мисс построили на основе твоей платформы. Можешь немножко про это рассказать? Хочу реальных примеров и баек из жизни, как это вообще произошло.

Ну, там Чувашия пошла путем своей, по этой программе написать свою систему. Ребята написали, основной подрядчик был Алькона. И в какой-то момент они пришли и сказали, что хотим сделать это все правильно, модернизировать существующую систему. Они взяли нашу платформу, FIRE-платформу, за основу. И там еще был титанический труд, как эту платформу превратить в МИС или в реестры всяких пациентов. И достаточно большая команда, от нас было парочка инженеров, а всё остальное делала «Алькона». Она и до сих пор активно разрабатывает эти части, такой региональный МИС, много МИС с неким региональным центром. В основе лежит FIRE. Заработала, сделали запись на приём симпатичную, сделали неплохие реестры разных заболеваний, вот эта новая тема последних двух лет, что стали отдельно собирать специализированные карточки, реестры, чтобы кардио. Эта вся система открытая, то есть она внутри на самом деле устроена, как множество сервисов, просто общающихся по протоколам, поэтому к ней можно присоединять другие системы. Протокол известен, задокументирован. В частности, предыдущие миссы как раз уже через протокол FIRE были интегрированы в эту систему. И она активно развивается.

Можешь рассказать, какие были вводные у этого проекта? Например, как выглядели медицинские карты в Чувашии до начала?

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

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

Ну вообще, мне кажется, сейчас силой 50% айтишников, которые занимаются медициной, тратится именно на то, что они сидят и перекидывают из одного поля в другое. В большинстве случаев делается как бы руками, да, потому что они не всегда тривиальны эти преобразования. Те, кто делают это много, они начинают писать какие-то фреймворки, какие-то библиотеки, позволяющие это каким-то образом сделать более декларативно, более надежно, проверить. Но мы за нашу историю 15-летнюю наработали, в общем случае, больше десятка подобных библиотек написали под разные вкусы. Но и ни одна из них не является идеальной. Если данные структурированы и достаточно осмысленно структурированы, то это поддается автоматизации или хотя бы полуавтоматизации. И это то как раз, чем программисты занимаются. Если это нарративы какие-то в виде, там, выписных эпикризов, там народ пытается всякими natural language processing утилитами, там, какой-то экстракцией выдергивать данные. Это сейчас такая, как бы, авангардная область, что-то экспериментально-академическое такое. Конечно, хочется автоматически, но если данные относительно структурированы, зачастую как бы программист при помощи каких-то скриптов и так далее может это все, хотя бы значительную часть этого перебросить, да, и где-то может там сделать инструментик, где уже человек там пройдет его проверит. Это так называемый data quality, контроль качества данных. Большая, обширная тема, пока еще тоже до конца не проработана. Потому что там встает еще второй вопрос, можешь ли ты верить этим данным. Вопрос качества данных, он включает не только то, что у тебя эти данные в правильном формате, а и то, что ты им, в принципе, можешь доверять. На основании этих данных будут приниматься решения какие-то. Если что-то к тебе залетело, может быть, по ошибке вообще, а врач принял решение. Качество данных— это вопрос, который будет стоять на повестке сразу после того, как у нас появится приемлемая интероперабилити на техническом уровне.

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

Но тут есть ряд вопросов. Сделать сверху вниз. Скажем так, ты можешь поставить эксперимент. Ты сделаешь одну версию системы. Насколько она хороша, с чем ты будешь сравнивать? Такой есть подход. Это как раз Monomisa. Например, Bars стоит в N регионах. Они сделали один раз, чуть-чуть поднастроили и встали. Насколько он хорош? Вопрос. Надо спрашивать пользователей. Я не знаю. Стоит с ними поговорить, посмотреть. Например, с точки зрения стандартизации, скорее всего, не очень. Потому что задача очень получается с вызовом. И тут вопрос, что ты можешь сделать одну правильную систему. Но если ты всё поставишь на одну систему, то есть риск получить не самую хорошую, но одну систему. С точки зрения административной, так, наверное, проще. с точки зрения какой-то экономии ресурсов. Но экономия ресурсов вот как бы in the small, да, сделали одну, поставили всем. In the large, если эта система неоптимальна, то вы сделали плохо и поставили всем. То есть вы растиражировали эту неоптимальность. Поэтому здесь, мне кажется, даже достаточно интересно, Разные регионы могут по-своему попробовать это реализовать, но оно же будет перемешиваться. Постепенно, наверное, кто-то сильнейший или какие-то гибриды, или тот, кто более удачное решение, или тот, у кого лучше продавцы, я не знаю, начнет эту нишу занимать, более централизованную. Я думаю, что тут пока хорошо, что есть конкуренция, что есть Нетрика, что есть Чувашия, что есть Барсы. что они друг с другом это все притирают. Так просто не получается. Вот напиши мне идеальную систему. Многие страны пытаются так сделать. Например, какая-нибудь Белоруссия выставила тендер на то, чтобы им написали всю систему одним вендором. Но они его выставили сколько лет назад, 3-4. До сих пор я так понял, что процесс так и не запустился. Потому что даже не нашли того, кто бы это мог сделать.

Недавно утекли в сеть кучи персональных данных из Яндекс.Еды и из СДЭКа. И страшно представить, что будет, если утекут аналогичным образом медицинские данные. Когда карты были бумажными, то нельзя было взять и украсть все данные одним кликом. Чтобы реально украсть медицинские данные, надо было попасть в больницу и утащить эти карты. Они еще тяжелые, большие. Как защитить медицинские карты, когда все в цифровом виде?

Ну, как в любом случае защиты нужно рассматривать угрозы. Но нет просто защиты в абстрактном виде, потому что тут есть противоречия. Мы с одной стороны хотим обмениваться этими карточками как можно более просто и легко. В моем андроиде есть прикольное приложение, которое мне поможет с моими медикаментами разобраться. Я хочу ему отдать свои данные. Но куда оно их дальше денет, откуда я знаю. Есть еще другой вопрос. Кому эти данные нужны, и что плохого он с ними может сделать? Опять надо разговаривать про риски. Кто сможет эти данные получить, кто за ними охотится, накладывать на эти системы какие-то сертификации делать по безопасности. Данные, по сути, рано или поздно утекают. Ничего не сделаешь, они утекут. Потому что это суть информации, ее очень легко скопировать и передать. У нас есть законодательство, забыл название, где как раз предъявляются требования к железу, на котором хранится, к тому, что диски заинкрипчены, к тому, что там правильная операционная система, шифрование включено. уровни доступа, контроль к этому железу. В Штатах есть подобный, тоже HIPAA, она там вообще self-declared, ее даже не проверяют, пока ничего не случится. То есть, применяя просто такие базовые хорошие практики по безопасности, это единственное, наверное, что можно сделать.

Ты просто упомянул HIPAA. Вообще есть ли какие-то специализированные штуки в медицине именно про защиту персональных данных и вообще защиту данных?

Да нет. Есть подход, который называется деидентификация, когда все идентификационные данные, паспорта, имена, иногда даты рождения убирают, но он достаточно бессмысленен на самом деле, потому что есть понятие фингерпринта, и по датам и времени двух твоих визитов к Зубному я тебя отличу от ста миллионов других людей. даже не зная твой паспорт. Если я буду знать, что ты во вторник в 3 часа и в четверг в 5 сходил к Зубному, то таких в России полтора человека. Поэтому я тебя вычислю. Если я буду централизованно тебя вычислять, я не смогу. В этом плане один из приемов – это деидентификация. когда просто убираются идентификационные данные. Другой прием – это анонимизация. Но тут оно немножечко бессмысленно, потому что задача анонимизации ставится так, что я не могу отличить карточку одного пациента от, например, пяти других. Но тогда там встает, например, проблема, и эти данные становятся бесполезными. Можно, наверное, шифровать и в блокчейн хранить ключи. Не знаю, что-то подобное тоже возможно. Рано или поздно будет.

Когда появится слово блокчейн, сразу понятно, что какой-то буллшит.

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

Коль, ты упомянул, что сущность данных— это расползаться и протекать, так что рано или поздно все утечет. В этой связи у меня такая первая мысль— так надо хранить поменьше. Ну, как минимум, не хранить данные вечно, а хранить их только тогда, когда они нужны. Есть ли какие-то штуки про data retention, про то, что со временем данные удаляются? Или все данные хранятся вечно?

Ну, скажем так, если ты будешь говорить с дата-сатанистом, он тебе скажет, что все данные должны храниться вечно, потому что данных мало не бывает. Вот ты сейчас удалил данные, а у тебя завтра появился какой-нибудь новый великий алгоритм, который предскажет, когда ты заболеешь. А данных уже нет. То есть данные лучше хранить, потому что это больше информации. Это как книги сжигать. Если ты будешь сжигать данные. То есть эта информация может пригодиться. Где-то рядом с singularity эта информация, видимо, пригодится. В хорошую, в плохую сторону, не знаю. Тут надо понимать, что это о двух концах. Если у тебя есть данные, то добрый алгоритм сделает тебе хорошо, а плохой алгоритм сделает тебе плохо. Если ты считаешь, что риск плохого алгоритма велик, можно удалять. Ну, в Европе, например, сделали вот этот закон о том, что ты можешь в любой системе пойти и сказать, что удали все мои данные, и система обязана удалить их вообще отовсюду, везде, чуть ли не из архивов. Это технически почти нереально. Как бы это вот GDPR, да? Возможность, чтобы тебя забыли. Причем система обязана как бы юридически полностью тебя выпилить.

Такие немножко развлекательные вопросы, но мне кажется, ты вполне можешь там что-то интересное ответить. Где в мире самая крутая цифровизация медицинских данных?

Ну, в маленьких странах, типа Литвы какой-нибудь, Эстонии. Тебе одну деревню цифровизовать, это практически как одну больницу. В ней можно найти 10 хороших программистов, которые все осознанно сделают. В Финляндии, Литва, хотя в той же Финляндии тоже куча есть вопросов по реализации. Они заплатили полмиллиарда за ЭПИК, и вообще много вопросов, стоило ли это того или нет. Но в Литве ребята сделали сами, поставили, все прекрасно работает, небольшая компания.

Я все время думаю, что 10 программистов и мы сделаем что угодно— это мой рефрен. А тут ты его так много раз повторяешь, что меня прямо душу греет. На самом деле маленькая команда из 10 программистов обычно может сделать гораздо больше, чем корпорации из тысячи. В смысле, окей, конечно, все зависит от задачи, но в этом-то и прикол— найти такую задачу, которую могут сделать команды из 10 человек.

Согласен. Тут есть же про human scale, и он не скейлится. У вас там типа 10 программистов, между 100 и 10 разница в производительности уже всего лишь в разы, а до 1000 уже может быть отрицательна.

Вот ты сказал, что самая классная цифровизация – это маленькие страны. Ну и то не все, но вот кому-то повезло, кто-то сделал классно. Где в этом списке России?

Ну, тут не рейтинг, тут надо понимать специфику. У России как бы есть своя специфика. Например, достаточно сильная централизация и в основном, получается, государственная медицина, которая опять-таки позволяет делать сверху вниз. Сделать что-то сверху вниз в какой-то степени проще, потому что тебе мало с кем договариваться. Если тебе повезет, опять-таки, будут делать люди с головой, то может получиться очень хорошо, очень быстро и очень эффективно. Если будут делать люди без головы, может получиться очень плохо. Например, те же Штаты, они очень сильно распределенные, то есть там сотни страховых. сотни провайдеров, сотни вендоров. И им договориться очень сложно. Там очень много легоси, который очень... Например, тот же легоси, когда оно размазано тонким слоем, тебе его не выпилить. Поэтому 50 лет V2 используется, хотя понятно, как сделать лучше. Ну, ты просто X-12 этот ходит для клеймов. Хуже не придумаешь. Это древняк. Его не собрать. С другой стороны, есть диверсификация. Где-то островки образуются прорывные. Поэтому в этом плане Россия преодолела пропасть. У нас цифровизация медицины есть. В регионах есть. Экспертиза есть. Есть компания. Создан целый этот рынок, который существует. Есть страны, в которых этого нет. Дальше уже начинаются детали, как можно сделать лучше и что можно сделать лучше.

Окей. Последний вопрос. Когда в больнице совсем пропадут бумажные карты?

Да их уже, в принципе, почти нет на самом деле. Когда идеология бумажная пропадет, это другой вопрос. То есть сейчас первый виток цифровизации— это просто перенести бумажную карту в документик, у нее мощность маленькая. Она уже полезна, потому что ее можно быстро передавать туда-сюда. Но у нее мощность маленькая с точки зрения, какую дополнительную информацию можно из нее выводить. И вот этот процесс, он уже почти прошел. Ты можешь на телефоне писать. Иногда просто на бумажке реально чуть-чуть эффективнее. Потому что если ты вобьешь скорость, с которой сейчас врач печатает, и с которой он пишет, она там на порядок отличается. А когда от идеи бумажного документа, снапшота такого, откажутся и научатся работать с дискретными медицинскими данными, когда врачи осознают, что у них под рукой весь массив данных пациента, с которым они могут взаимодействовать умным способом, Это еще длинный-длинный процесс, десятилетия на это уйдут. Вначале стандартизуем, потом настроим протоколы, потом качество данных обеспечим, потом появятся инструменты, которые позволят этим врачу манипулировать. И появится новое поколение врачей, которые будут понимать, Вот это я могу попросить у данных. Сейчас врач считает, что я прочитаю документы предыдущих пяти врачей. Система ничем не поможет, только покажет мне эти документы. Я их прочитаю. Врач будущего, скорее всего, будет немножко иначе видеть систему. Он скажет, вот у меня есть база знаний, как лечить, база данных с данными пациента, и вот дай-ка я алгоритм из базы знаний применю на базу данных пациента и посмотрю, что получится. Когда врачи станут частично как бы такими айтишниками, ну, а этот процесс идёт, тогда изменится качество лечения, потому что у врача руки станут гораздо длиннее. Память врача сильно ограничена. Здесь вот с таким расширением, скорее всего, можно будет очень эффективно всё это действовать. Можно сравнить, не знаю как, сейчас у нас есть карта на телефоне, Google Map, и вы добираетесь в неизвестном месте куда-то, а врачи до сих пор идут и спрашивают прохожих или смотрят на бумажную карту, типа, где я, куда повернуть. То есть подобного рода оптимизация, точнее, качественный скачок возможен, и туда пытаемся двигаться.

Очень круто, что мы пытаемся туда двигаться, и, судя по всему, ты один из людей, которые сейчас как раз делают эти Google Maps, когда люди еще не знали, что такое Google Maps. Спасибо тебе большое, что нашел время поговорить.

Спасибо, Самат.

Это подкаст «Студии либо-либо», и мы его сделали вместе с сервисом онлайн-образования «Яндекс.Практикум». Над подкастом работали редакторка Маша Агличева, продюсерка Настя Медведева, звукорежиссерка Нина Мамотина. За джингл спасибо Алексею Зеленскому.

Редактор субтитров А.Семкин Корректор А.Егорова