Кратко об авторе исходной статьи: Адам Босворт (Adam Bosworth) начал карьеру в Borland, где работал над системой электронных таблиц Quattro. Перейдя в Microsoft он занимал различные руководящие должности, включая пост главного руководителя группы WebData, занятой созданием и продвижением XML. Кроме этого он занимался Access и движком Internet Explorer 4.0 с кодовым именем Trident. Уйдя из Microsoft Адам вошел в число сооснователей Crossgain, после ряда поглощений их основной продукт превратился в Oracle Workshop for WebLogic. В 2004-2007 годах Босворт занимал пост вице-президента по разработке продуктов в Google, где занимался Google Docs и руководил разработкой Google Health (закрыта с 1 января 2012, когда-то о ней писали на хабре). После ухода из Google он основал стартап Keas, использующий элементы социальных сетей и игр для улучшения здоровья.
На этой неделе меня любезно попросили принять участие в качестве эксперта на правительственном совещании (1) о стандартах. В это время я обычно сплю, но в нужный момент я был бодр и сидел у телефона, несмотря на все свое отвращение к недосыпанию. Что заставило меня так поступить? Обсуждались способы, с помощью которых медицинские данные можно было бы на самом деле сделать прозрачными. Какие стандарты надо использовать для совмещения подобных данных?
К собственному удивлению и в какой-то степени боли, я успел поучаствовать в разработке нескольких стандартов. Один из них использовался для обмена данными между базами данных и пользовательскими приложениями вроде электронных таблиц или Access. Он назывался ODBC и отлично показал себя, несмотря на некоторые затруднения в начале. Другим был стандарт того, что сейчас называется AJAX, создания сложных, интерактивных веб-страниц вроде Gmail. Наверное самым важным был XML. Это все успехи. Были и провалы. Особенно хорошо я помню OLE DB, которым мы хотели заменить/вытеснить ODBC. Одним из балансировавших на грани успеха и провала был/является XML Schema. В результате всех этих усилий я выучил несколько уроков, которыми постараюсь поделиться с вами. Каковы они?
1. Делайте стандарты предельно простыми и глупыми. Вероятность провала — это как минимум квадрат сложности стандарта. Успешные стандарты как правило просты, сосредоточены и легко читаемы. В мире медицины это означает, что надо прежде всего сосредоточиться на тех данных, которые могут быть однозначно закодированы: демографических параметрах, результатах анализов, лекарствах. Не надо стараться охватить все виды медицинских данных из всех областей медицины. Не надо сосредотачиваться на правах доступа ваших партнеров к различным данным (смотрите пункты 2, 3 и 4 далее).
2. Данные, которыми будут обмениваться, должны быть человекочитаемы и понятны. Судьба стандартов зависит от инженеров, которые будут воплощать их в коде. Они сделают это только в том случае, если смогут легко понять (см. выше) и протестировать стандарт. Именно поэтому в течение последних 15 лет побеждают текстовые стандарты вроде HTTP, HTML и XML. Разработчики могут просмотреть принятые/переданные данные в любом редакторе и убедиться, что все идет как надо. Когда Тим Бернес Ли впервые применил этот подход при создании интернета, большинство «серьезных» специалистов по сетям считали использование текста в HTTP безумием. Но оно очень хорошо работало. Очевидно, что в случае с XML оно работало не хуже. Из этого можно сделать определенные выводы. Недостаточно просто сказать «XML». Средний инженер (который будет воплощать стандарт в жизнь) должен быть в состоянии посмотреть формат и понять его. Видя понятные только компьютеру XML-грамматики, можно сразу спрогнозировать, что они не получат широкого распространения. Есть несколько так называемых XML-грамматик, скрывающих XML внутри модели абстрактных знаний, вроде RDF, по моим ощущениям они гораздо сложней в чтении/понимании и не получили широкого распространения. По моему мнению, Hl7 страдает от этого.
3. Лучше всего работают сосредоточенные стандарты. Не стройте здоровенный грузовик для поездок в соседние кварталы. Стандарты очень часто проваливаются просто потому, что комитеты с очень разнообразными сложными целями работают без создания рабочих версий для проверки сложности (см пункт 1) и ясности (см пункт 2). Часть гениальности веба была в том, что Тим Бернерс-Ли правильно отделил протокол (HTTP) от того, что браузер должен выводить на экран (HTML). Это похоже на отделение письма от конверта. Это основа. И необходимость. Стандарты, в которых слои или уровни втиснуты в одну большую сущность, склонны к провалу, так как бедные инженеры должны понимать все, хотя на самом деле им нужно понимать только что-то одно — и поэтому они объявляют бойкот. В здравоохранении это значит, что не надо включать в один стандарт правила и для кодирования данных и для доступа к ним и для обеспечения безопасности. Если мне, как инженеру, нужно лишь закодировать список выписанных пациенту лекарств и послать его куда-то, где он действительно нужен, не надо вынуждать меня делать что-то еще. Итоговый XML должен быть похожим на список лекарств. Если что-то не работает, я смогу позвонить моему коллеге и за пять минут выяснить, что именно пошло не так. В большинстве случаев я смогу решить задачу за пару дней, так как мне не надо будет изучать спецификацию толщиной с телефонный справочник. Мне не надо будет понимать «абстрактную модель данных». Основная часть исходной спецификации XML была крохотной. Преднамеренно. Я слышал, как кто-то с негодованием сказал про попытки упростить информационные стандарты для здравоохранения, что мы должны «поднимать уровень стандартов», вместо того, чтобы опускать его. Это аналогично требованию учить наших детей управлению самолетом для того, чтобы они могли выйти на улицу. Отличительной чертой всех успешных стандартов была предельная простота, а не предельная сложность.
4. Стандарты должны включать в себя точные правила кодировки. ODBC точно определял типы данных. В описании XML все было кратким, за исключением точных правил кодирования символов в тексте, юникода. Это, наверное, самая важная часть стандарта, так как она гарантирует точность кодировки. В здравоохранении это означает, что что стандарт должен четко определять правила кодировки лекарств, результатов анализов, демографических данных, данных о состоянии больного и гарантировать, что все смогут использовать эти правила без выплаты лицензионных отчислений. Правительство может повлиять на это, требуя NPI для всех данных о действиях врачей, SNOMED CT для всех данных о состоянии больного, LOINC для всех лабораторных данных, определенных правил кодировки для всех лекарств (которыми могут быть NDC, rxNorm или FDB) и гарантируя, что использование этих правил всегда будет бесплатным.
5. Всегда должны быть существующие на практике реализации, которые на самом деле учитываются при конструировании стандарта. Не сделав что-то очень сложно понять, будет ли оно работать и иметь инженерный смысл. При создании ODBC многие из нас реализовывали его в процессе работы. В мире здравоохранения многие из нас развивали и использовали CCR в ходе его создания, сразу разбираясь с тем, что работает, а что не особенно полезно, благодаря чему он стал хорошим, простым в использование стандартом по интеграции медицинских данных. Рядовой инженер должен быть в состоянии разобраться в реализации стандарта за несколько недель.
6. Учитывайте возможность возникновения непредвиденных обстоятельств. С этим очень хорошо справляются сетевые стандарты. Если в HTTP есть что-то непонятное для получателя, он игнорирует это. Он не ломается. Если в HTML есть что-то непонятное браузеру, он игнорирует это. Он не ломается. Учитываете закон Постела. Допускайте непредвиденное. Ложная точность — это кладбище успешных стандартов. XML Schema очень плох в этом отношении, CCR гораздо лучше.
7. Сделайте сам стандарт бесплатным и опубликуйте его в интернете вместе с множеством простых примеров. Инженеры тоже люди, им проще всего учиться на примерах и если стандарт следует вышеописанным принципам, примеры будут ясными и очевидными. Обычно можно сразу предсказать успех стандарта, если на его сайте есть четкое описание и простые, понятные всем примеры. Сложность, обобщенность и абстрактность HL7 полностью ошеломляет обычного человека, зашедшего на его сайт. Она приводит в замешательство даже меня. Не заблуждайтесь, инженеры — это обычные люди, у которых очень мало времени. Большинство из них не имеют ученой степени.
Честно говоря, большинство стандартов созданы вовсе не для обеспечения совместимости. Некоторые созданы для защиты уже имеющегося положения или получения прибыли с интеллектуальной собственности. Другие существуют сами по себе, поддерживая бесконечное существование тела стандарта и давая возможность авторам зарабатывать очень неплохие деньги на банальном объяснении бедным инженерам особенностей работы своего стандарта. Наверное все согласятся, что хорошими такие стандарты не назовешь. Совместимость медицинских данных слишком важна для нас всех, чтобы мы позволили ей пасть жертвой подобного подхода.
Примечания:
1. Ссылка на описание совещания не работает. Блога, в котором оно было опубликовано, тоже уже нет. По названию ссылки можно предположить (не зная американской специфики), что это был блог FACA — одной из специальных совещательных организаций, созданных на основе закона 1972 года и предназначенных для выработки общедоступных рекомендаций правительственным органам и президенту
Автор: Vedomir
