На це раз стаття, яка повинна бути багатьом набагато ближче, ніж просто опис якихось там 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. Виникає питання, створювати чи ні окремі таблиці для КД і зберігати в ній всі спадні типи? Або створити поле CS всередині створюваної таблиці, а дані з типом КД винести в окрему таблицю?
Давайте тепер візьмемо якусь просту сутність, наприклад, Place і подивитися на поле ADDR з типом даних AD, воно складається з:
- use типу DSET;
- useablePeriod типу GTS який, у свою чергу є QSET;
- isNotOrdered типу BL;
- 1916 atted типу ST.NT.
З точки зору логічної структури бази даних, атрибути use і usablePeriod є стосунки один до багатьох.
Аттрибут isNotOrdered не просто Boolean в термінах бази даних, а може мати третій стан null.
Аттрибут 1916 atted типу 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