На это раз статья, которая должна быть многим гораздо ближе, чем просто описание каких-то там 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 Caché или 1С или прочих реализаций ни чего не знаю, они сами, при желании, напишут.
Так что простор для манёвров в деле база-строительства для медсистем вполне достаточный.
=====
RMIM — Refined Message Information Model
DMIM — Domain Message Information Model
FHIR — Fast Healthcare Interoperability Resources
Приступим. Почему-то считается, что если речь идёт о создании медицинской системы, то это обязательно электронная медицинская карта пациента и, может быть, что-то ещё, но совсем немного. Однако, ЭМК пациента не единственная категория медицинских систем.
Можно выделить следующие три:
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 Caché или 1С или прочих реализаций ни чего не знаю, они сами, при желании, напишут.
Так что простор для манёвров в деле база-строительства для медсистем вполне достаточный.
=====
RMIM — Refined Message Information Model
DMIM — Domain Message Information Model
FHIR — Fast Healthcare Interoperability Resources
