На это раз статья, которая должна быть многим гораздо ближе, чем просто описание каких-то там EHR-S FM стандартов, так что комменты welcome. Если всё ниже сказанное кому-то покажется из серии «я вообще не понимаю о чём это», предлагаю прочитать несколько моих ранних статей про Health Level 7.

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

Можно выделить следующие три:
Electronic Patient Record-centric – сюда входит то, что относится к конкретному пациенту. Приложения не ограничиваются только хранением демографических данных пациента и его истории болезни. В эту же категорию можно отнести телемедицину, медицинские порталы и т.д.
Public Health Information Networks – системы этого уровня абстрагируются от индивида и агрегируют количественные данные со множества систем ориентированных на пациента для прогноза развитие событий таких как эпидемии, биотероризм и т.п.
Clinical Research Support – в этой группе системы для принятия решений, моделирования лекарств и т.п.

Между категориями нет явной границы, данные перетекают из одной в другую, обрабатываются, дополняются и возвращаются обратно. Не имея опыта в конкретной области или категории зачастую весьма трудно предположить, какие данные могут быть в ней использованы, и в этом случае HL7 Reference Information Model (RIM) предлагает неоценимую помощь предоставляя опыт множества экспертов денно и нощно корпевших над структурой классов и их отношениями.

В связи с этим, когда FHIR ещё даже на горизонте не было, возникла такая тема – если стандарт HL7 такая классная вещь и описывает всё что нужно для обмена мед данными, почему бы не использовать её как структуру базы данных, тогда точно всё что будет принято в сообщении от любой другой системы можно будет как-то сохранить. Бери весь RIM, или RMIM или DMIM относящийся к нужному домену, и используй для проектирования базы данных только нужные для разрабатываемой системы классы. Ну что же, посмотрим на HL7 RIM во всей его красе:



где цветом закодировано следующее: какая-то сущность (зелёный), выступающая в роли (жёлтый), участвует (синий) в каком-то действии (красный), которое является частью (розовый) другого действия (красный). Всё, больше ни чего такого в RIM нет! На первый взгляд, это как-то мало похоже на готовую модель для ЭМК.

Сейчас посмотрим, что там на «второй» взгляд. А на второй взгляд типы данных HL7, которые, в большинстве случаев, отличаются от «обычных» типов данных. Типы данных в виде UML диаграммы в стандарте представлены так:



Например, HL7 Point-In-Time аналогичен типу Timestamp в базах данных, но поскольку первый наследуется от абстрактного типа ANY, то обязательное свойство NullFalvor портит всю картину.

Более сложный пример, тип Concept Descriptor (CD), который описывается атрибутами: code, codeSystem, codeSystemName, codeSystemVersion, displayName, originalText, qualifier, translation. Два последних, к тому же, является списками. От типа CD наследуются типы Coded with Equivalents (CE), Coded Value (CV), Coded Ordinal (CO) и Coded Simple Value (CS). Тип CS содержит только code и NullFalvor. Возникает вопрос, создавать или нет отдельную таблицы для CD и хранить ли в ней все наследуемые типы? Или создать поле CS внутри создаваемой таблицы, а данные с типом CD вынести в отдельную таблицу?

Давайте теперь возьмём какую-то простую сущность, например, Place и посмотреть на поле ADDR с типом данных AD, оно состоит из:
• use типа DSET;
• useablePeriod типа GTS который, в свою очередь есть QSET;
• isNotOrdered типа BL;
• formatted типа ST.NT.

С точки зрения логической структуры базы данных, аттрибуты use и usablePeriod есть отношения один ко многим.
Аттрибут isNotOrdered не просто Boolean в терминах базы данных, а может иметь третье состояния null.

Аттрибут formatted типа ST.NT (StringNoTranslations), в свою очередь имеет следующие компоненты:
• data типа BIN;
• mediaType типа CS;
• charset типа CS;
• language типа CS;
• headCharacter типа ST.NT;
• tailString типа ST.NT;

в которой каждый элемент с типом данных CS, упомянутым выше, состоит из:
• code типа ST.SIMPLE;
• codeSystem типа UID;
• codeSystemName типа ST.NT;
• codeSystemVersion типа ST.SIMPLE.

И такая матрёшка (как легко заметить в некоторых случаях закольцованная) почти с каждым полем классов HL7 RIM.

Отсюда вытекают два крайних способа реализации схемы базы данных основанной и не основанной на RIM, а также их производные:
• Каждый тип данных в своей таблице. В этом случае нетрудно представить каким будет запрос даже для формирования простейшего Ack (MCCI_IN000002).
• Все типы данных в таблицах. Тоже возможный подход, но тогда база данных становится ненормализованной.
• Вполне логично избавиться от крайностей и использовать смешанный подход – взять RMIM для конкретного области, некоторые типы данных в отдельных таблицах, некоторые внутри таблиц.
• Создать структуру базы с нуля так, как это необходимо для приложения, не оглядываясь на RIM.

Пример реализации по первому типу представил Abdul-Malik Shakir, тот самый, который в своё время «причесал» гроздья классов в RIM до его нынешнего вида — www.slideshare.net/AShakir/rim-based-relational-database-design-tutorial-september-2008

На мой взгляд это больше академический подход, чтобы показать, что создать структуру базы данных на основе RIM всё таки возможно. В реальности производительность такой системы будет под большим вопросом. И, к слову сказать, по крайне мере одна такая реализация, которая мне известна, была весьма «тормознутая».

Другая реализация, коммерческая, по внутренней структуре которой не так уж и много информации – это Oracle Healthcare Transaction Base (Oracle HTB). Насколько я знаю из общения, только некоторые типы данных, такие как Entity Name (EN), Address Part (ADXP), Telecommunication Address (TEL), вынесены в отдельные таблицы. Тесты на производительность HTB показывают, что на хорошем железе база крутится достаточно шустро. (Линк сдох.)

Насчёт внутренней структуры InterSystems Cache или 1С или прочих реализаций ни чего не знаю, они сами, при желании, напишут.

Так что простор для манёвров в деле база-строительства для медсистем вполне достаточный.

=====
RMIM — Refined Message Information Model
DMIM — Domain Message Information Model
FHIR — Fast Healthcare Interoperability Resources

Комментарии (8)


  1. Wayfarer15 Автор
    08.05.2015 21:46

    Список систем на основе RIM — wiki.hl7.org/index.php?title=Category:RIMBAA


  1. Wayfarer15 Автор
    09.05.2015 01:04

    Из почти 2 тыс посмотревших (на данный момент) ни кто не упомянул про openEHR и Think!EHR из-за лени? :)


    1. father_gorry
      10.05.2015 13:24

      OpenEHR вроде бы позиционируется как стандарт уровнем выше HL7 — из него можно получить HL7-документ, но обратная процедура не имеет смысла без специфического интерпретатора. Пост — о том, как медицинские стандарты всё более вязнут в энтропийном барьере, так зачем их упоминать?:)


      1. Wayfarer15 Автор
        10.05.2015 17:52

        Сам openEHR позиционирует себя примерно так:



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


  1. 4dmonster
    13.05.2015 10:43

    Скажите пожалуйста я правильно понимаю, что VA VistA можно считать референсным воплощением HL7?


    1. Wayfarer15 Автор
      13.05.2015 17:41
      +1

      Как в Одессе любят отвечать вопросом на вопрос, так и я спрошу, а у вас есть спецификации интерфейсов этих "163 hospitals, over 800 clinics, and 135 nursing homes"? В противном случае какая вам польза от того, что вы знаете является ли она референсным воплощением HL7 или нет? Вот один из наших интерфейсов был прототипом одного из доменов HL7v3 NE, но с тех пор прошло много лет, Normative Edition изменился и тот же самый интерфейс стал не нормативным. Будем ли мы его подгонять под стандарт, нет, не будем, вполне устраивает как он сейчас работает. Тоже самое может быть с интерфейсами VistaA — даже если в крайних 90-х они стали прототипами chapters во второй версии, то к v2.7 возможно они уже в пролёте. А может быть и нет, без спеки и внимательного изучения я этого утверждать не могу. Ответил на вопрос?


      1. 4dmonster
        14.05.2015 08:43

        Да, нормально ответили.

        Просто я где-то читал «возмущения», что чуть ли не HL7 был «тупо содран» с VA Vista, и «нормальным» разработчикам от этого одни неудобства.


        1. Wayfarer15 Автор
          14.05.2015 09:08

          Желательно бы ещё версию HL7 указывать. В начале каждой спеки (будь то chapter в v2 или домены в v3) есть список кто его разрабатывал, так что вполне возможно там есть кто-то из US Department of Veterans Affairs. Другой крупный «поставщик» экспертов — Mayo Clinic.