Клинические подразделения - Интеграция данных о медицинских процедурах, операциях и назначениях для анализа клинической активности

В контексте цифровой трансформации медицинских организаций данные о процедурах, операциях и назначениях остаются одними из наиболее фрагментированных источников. Разрозненные информационные потоки из EHR, LIS, RIS, PACS и регистров обусловливают узкие места при анализе клинической активности: задержки в получении данных, слабая сопоставимость кодов, неоднозначность временных меток и несогласованность терминологий. Глава фокусируется на том, как спроектировать архитектуру DWH, обеспечить высокое качество данных и управляемость в рамках клинических подразделений, чтобы аналитика по объему операций, времени выполнения, распределению по отделениям и эффективности процессов могла быть оперативной и устойчивой к изменениям в клинике.

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

Архитектура и целевые модели данных
Интеграция источников и потоки данных
Качество данных, соответствие требованиям и прозрачность происхождения
Безопасность, доступ и управление изменениями

Архитектура данных для клинических подразделений

Архитектура должна объединить источники данных, обеспечить единый контекст для аналитики и поддержать гибкость в разворачивании локальных и корпоративных витрин. Основной принцип - разделение зон по ответственности: зона «снятия сырья» (landing), зона «нормализации и согласования» (conformed), зона «аналитических витрин» (consumed). В клиниках чаще применяется гибридный подход: хранение «данных в лоад-слое» в data lake (для необработанных и полуобработанных данных) и создание централизованной DW/мартов под клиническую активность.

Ключевые элементы архитектуры:

Источники данных: EHR (рабочие листы пациентов, процедурационные записи, наркоз, наряду с назначениями), LIS (лабораторные анализы), RIS/PACS (операционные журналы, видеоматериалы и изображения), регистры операций и анонсов, ADT-сообщения. Термины и коды должны приводиться к единым стандартам: ICD-10-CM/PCS, CPT, SNOMED CT, LOINC, RxNorm.
Потоки и каналы: пакетная загрузка для исторических данных и потоковая доставка ключевых событий (реальное время в операционных системах, изменения расписания, отмены). В качестве технологического стека наиболее часто встречаются Apache Kafka или Apache NiFi для инжекции и маршрутизации данных, Apache Spark или PySpark для обработки и агрегаций, Airflow или Prefect как оркестрационная платформа.
Канонический уровень: унифицированная модель данных для клиники, предпочтительно в виде звездной или снежинки (Star/Snowflake) с фактами по процедурам, операциям и назначениям и размерностями по пациентам, сотрудникам, отделениям, времени и кодам процедуры.
Целевые витрины: отраслевые marts для OR-деятельности, дневных операций, планирования расписания, качества оказания помощи и операционных KPI; возможность адаптации под локальные требования отделений (напр., урочные KPI, среднее время на цикл операции, доля запланированных процедур).
Согласование терминологий: поддержка таблиц соответствий кодов и концептов; сервис терминологий (терминологический консолидатор) с регулярной синхронизацией кодов ICD/LOINC/SNOMED/CPT и версионированием.

Поддерживаемые схемы данных часто включают Data Vault как альтернативу классической звезде для растущих хранилищ с частой эволюцией источников и необходимости фиксировать источники данных и их изменение во времени. В то же время для оперативной аналитики в клинике нередко применяется «звезда» в чистом виде или «снежинка» в зависимости от сложности денормализации.

Схема данных для клиник обычно формируется вокруг следующих фактов и размерностей:

Факты: ProcedureFact (процедуры), SurgeryFact (операции), OrderFact (назначения), possibly AnesthesiaFact (наркоз) и AdmissionFact (поступление).
Размерности: Dim_Patient, Dim_Provider, Dim_Department, Dim_Time, Dim_ProcedureCode, Dim_Anatomy, Dim_Diagnosis (при необходимости).
Элементы качества кодирования: mappinты между локальными кодами клиники и международными стандартами с поддержкой изменений и истории соответствий.
Временная гранулярность: по операциям** - минуты/часы; по назначениям - день; по пациенту - визит.

Для иллюстрации можно рассмотреть минимальный пример архитектуры витрины в PostgreSQL/классическом DWH:

CREATE TABLE fact_procedure (
  procedure_id bigserial PRIMARY KEY,
  patient_id bigint,
  provider_id bigint,
  department_id bigint,
  start_time TIMESTAMP,
  end_time TIMESTAMP,
  duration_min INT,
  procedure_code VARCHAR(32),
  code_system VARCHAR(16),
  order_id BIGINT,
  encounter_id BIGINT
);

CREATE TABLE dim_time (
  time_id BIGINT PRIMARY KEY,
  date DATE,
  year INT,
  quarter INT,
  month INT,
  day INT,
  day_of_week INT
);

CREATE TABLE dim_patient (
  patient_id BIGINT PRIMARY KEY,
  external_id VARCHAR(50),
  gender VARCHAR(10),
  birth_date DATE,
  risk_score FLOAT
);

Продвинутые сценарии предусматривают использование OLAP-кузов, индексов по времени и партиционирование по годам, а также функционал SCD (Slowly Changing Dimensions) для Dim_Patient и Dim_Provider.

Таблица ниже показывает типовые паттерны интеграции и их характеристики.

Паттерн интеграции	Источник данных	Преимущества	Недостатки	Примеры технологий
ETL в классическом виде	Источники с консистентной структурой	Гарантированная консистентность, чистые витрины	Большой лаг между поступлением и доступностью данных	Apache NiFi, Talend, Informatica (часто в коммерческих проектах)
ELT с конвертацией в аналитическом слое	Источники с большой разнородностью	Гибкость, простота адаптации под новые источники	Требует мощной аналитической платформы	PostgreSQL/Greenplum, Snowflake, BigQuery
Потоковая обработка	Реальное время: события и изменения	Быстрый доступ к KPI в реальном времени	Сложнее обеспечить консистентность на больших объемах	Apache Kafka + Spark Structured Streaming, Flink
Голографическая интеграция	Разнородные источники с частыми изменениями	Гибкость, масштабируемость	Повышенная сложность моделирования	Data Vault 2.0, специализированные мастер-данные платформы

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

Моделирование данных: схемы и конвенции

Эффективная аналитика клиник базируется на устойчивой модели данных, которая обеспечивает единообразие агрегаций по всем источникам и поддерживает историзацию изменений. Основной подход - зрелая модель данных в виде звездной схемы (Star Schema) или снежинки (Snowflake), с четкой формализацией фактов по процедурам, операциям и назначениям и размерностей по пациентам, сотрудникам, отделениям, времени и кодам.

Основные принципы:

Факты должны отражать конкретные события - факт выполнения процедуры, факт назначений, факт оперативного вмешательства - с временными признаками и ссылками на соответствующие dimension records.
Размерности обязаны поддерживать историческое соответствие кодировок и идентификаторов; рекомендуется реализация SCD-2 для Dim_Patient и Dim_Provider, чтобы сохранить изменения в демографических данных и назначениях.
Терминология и соответствие: таблица соответствий кодов** - основа для кросс-системной аналитики; обновления должны кэшироваться и версионироваться.
OMOP CDM в качестве ориентира: для межклинической совместимости и возможности применения стандартных аналитических методов, особенно для клинических исходов и сопутствующих кодов. В рамках корпоративной DW возможно частичное картирование к OMOP, сохраняя специфику локальных кодов.

Типичная структура:

Факты: fact_procedure, fact_surgery, fact_order
Размерности: dim_patient, dim_provider, dim_department, dim_time, dim_procedure_code, dim_unit, dim_order_type
Таблицы конгломератов: mapping_concept (локальный код -> стандартный код), terminology_service (версионирование, поиск терминов)

Далее приведены примеры конвенций и основных полей, которые часто присутствуют в клинико-аналитических витринах:

dim_time: time_id, date, year, month, quarter, day_of_week, is_weekend
dim_patient: patient_id, external_id, gender, birth_date, race, ethnicity, active_flag
dim_procedure_code: code, code_system, description, synonyms
fact_procedure: procedure_id, patient_id, provider_id, department_id, start_time, end_time, duration_min, procedure_code, code_system, priority, status, encounter_id

Важно учитывать требования к конфиденциальности и доступу к персональным данным. В рамках проекта следует реализовать механизмы псевдонимизации и/или де-идентификации для аналитических витрин, оставляя оригинальные идентификаторы только в защищённых операционных средах.

Раздел, иллюстрирующий концепцию, можно дополнить следующей схемой:

Dim_Time связывает факты с календарными периодами.
Dim_ProcedureCode обеспечивает анализ по кодам процедур и их классификацию.
Dim_Patient отвечает за демографию и клинико-какие-либо ограничения.
Fact_Surgery и Fact_Order объединяют события, а Fact_Procedure может агрегировать оба типа для гибких KPI.

Пример кода создания таблиц можно привести только как иллюстрацию структуры и не использовать как демонстрацию. Например, создание Dim_Time и Fact_Procedure и их связь - допустимый минимальный уровень демонстрации, если это действительно помогает объяснению. Это не должно затмевать концепцию; цель - показать, как будут храниться ключевые элементы.

Таблица: Архитектурная схема хранения и связи

Компонент	Роль	Тип данных	Примечания
fact_procedure	Факты выполнения процедур	bigint, timestamp, varchar	Связь с dim_time, dim_patient, dim_provider, dim_procedure_code
dim_time	Временная размерность	date, int, int	SCD-2 рекомендуется для изменений времени
dim_patient	Размерность пациента	bigint, varchar, date, varchar	Опционально - псевдонимы для ДПИ
dim_provider	Размерность персонала	bigint, varchar	Включает докторов, медсестер
dim_department	Размерность отделения	bigint, varchar	Включает OR, отделение анестезии и др.
dim_procedure_code	Размерность кода процедуры	varchar, varchar	Поддерживает соответствие ICD/CPT/LOINC/ SNOMED

Для клинической аналитики добавляется таблица соответствий, чтобы обеспечить кросс-системные конвертации кодов и поддержать историзацию изменений кода.

Чтобы продемонстрировать практический аспект моделирования, можно применить подходы к терминологическому управлению: создаются таблицы соответствий и сервисы справочников, которые обеспечивают единый взгляд на коды в разных системах. В качестве примера можно рассмотреть простую схему соответствий (source_code → standard_code) с явной датой обновления, чтобы позволить повторно рассчитывать показатели при смене кодировок.

Интеграция и потоки данных

Интеграция клиник с DWH - один из самых сложных участков проекта из-за различий в форматах, частоте обновления и юридических ограничениях. Рациональная архитектура должна обеспечивать:

Надежность и повторяемость загрузок: детальная документация источников, расписание загрузок, мониторинг ошибок и автоматическое повторение.
Поддержку реального времени и пакетной обработки: критически важна доля событий (например, время начала операции) для KPI по операционному времени и качеству планирования.
Управление качеством и согласованием: автоматические проверки на полноту, корректность временных меток, согласование кодов и дат посещений.

Паттерны интеграции включают:

HL7 v2 и HL7 FHIR для EHR/ADT и клинических данных; DICOM для визуализаций и изображения; LOINC/SNOMED для лабораторной и клинико-терминологической информации.
Потоковая обработка: события изменений расписания, статуса операции, назначения; соответствующая платформа - Kafka + Spark/Flink.
Пакетная загрузка: исторические данные за период до начала проекта; идентификаторы и временные версии сохраняются для обеспечения консистентности.

Технологический стек, применяемый в клиниках:

Интеграция и обмен данными: Apache Kafka (сообщения), Apache NiFi (потоковая маршрутизация), HL7/FHIR адаптеры.
Обработка и агрегации: Apache Spark, PySpark; Spark SQL для сильной аналитики по большим массивам данных.
Оркестрация и контроль качества: Apache Airflow или Prefect; Data Quality Checks встроены в пайплайны.
Хранилища: PostgreSQL/Greenplum для аналитических витрин, ClickHouse для высокопроизводительных агрегаций, Data Lake на базе HDFS или облачных услуг (S3, GCS, Azure Blob) для сырого и полуобработанного контента.

Опробованные подходы и зависимости:

Канонический слой и подпроекты: слой конвейеров данных, который нормализует данные всех систем в единый набор таблиц фактов и размерностей.
Модель терминологий: создание таблицы соответствий code_mapping, которая хранит связь «локальный код → стандартный код» с датами обновления. Это позволяет гибко пересчитывать показатели, когда обновляются коды.
Модель времени: Dim_Time поддерживает полноту по календарю, праздники и смену часовых поясов, чтобы корректно считать длительности и задержки, особенно в OR.

Иллюстративный пример

SQL

для загрузки факт-операций и времени:

INSERT INTO fact_procedure (procedure_id, patient_id, provider_id, department_id, start_time, end_time, duration_min, procedure_code, code_system, order_id, encounter_id)
SELECT s.procedure_id, s.patient_id, s.provider_id, s.department_id, s.start_time, s.end_time, EXTRACT(EPOCH FROM (s.end_time - s.start_time))/60,
       s.procedure_code, s.code_system, s.order_id, s.encounter_id
FROM staging_procedure s;

И то же для Dim_Time:

INSERT INTO dim_time (time_id, date, year, quarter, month, day, day_of_week)
## SELECT DISTINCT
  CAST(TO_CHAR(start_time, 'YYYYMMDD') AS BIGINT) AS time_id,
  DATE(start_time) AS date,
## EXTRACT(YEAR FROM start_time) AS year,
  EXTRACT(QUARTER FROM start_time) AS quarter,
  EXTRACT(MONTH FROM start_time) AS month,
## EXTRACT(DAY FROM start_time) AS day,
  EXTRACT(DOW FROM start_time) AS day_of_week
FROM fact_procedure;

Реализация потоков может базироваться на паттерне «перекрестный конвейер» между зонами ingest, conform и consume, где каждый элемент предоставляет событийные данные соседним слоям. Это обеспечивает:
- **Прозрачность происхождения данных**: каждый факт имеет ссылку на источник и версию схемы.
- **Контроль версий**: возможность повторной загрузки и восстановления данных по времени.
- Гибкость адаптации под новые источники и новые стандарты кодирования.

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

Качество данных, соответствие требованиям и прозрачность происхождения

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

Правила контроля качества: встраивание проверки на полноту записей (покрытие по пациентам, по операциям, по отделениям); верификация временных меток и последовательности событий; проверка уникальности ключевых идентификаторов.
Терминология и соответствие: поддержка таблицы mapping и механизмов обновления терминов в рамках таймера (еженедельное обновление справочников, версионирование терминов). Это особенно важно для сопоставления данных между системами.
Жизненный цикл данных: политика retention и архивирования, чтобы обеспечить соответствие требованиям регуляторов и экономическую эффективность хранения больших массивов операций и назначений.
Метрики качества: полнота попадания кодов, точность дат и временных интервалов, согласование между процедурами и назначениями, соответствие между кодами и их описаниями.

Best practices:

Встроенные проверки на входе: схемы в staging-зоне должны валидировать форматы данных, валидность кодов и корректность временных меток.
Верификация консистентности: cross-source checks, например, сопоставление количества процедур и поступивших записей по источникам за один период.
Управление изменениями: контроль версий схем, регистр изменений и журнал изменений в справочниках кодов; регламент обработки изменений в исторических витринах.
Документация и прозрачнось: поддерживайте карту источников, описание полей и их источников, а также политики обработки ошибок и уровни допуска.

Вопросы качества, которые стоит отслеживать:

Полнота: сколько ключевых полей отсутствуют в записях по процедурам и назначениям?
Точность: соответствуют ли коды и временные метки фактическим данным клиники?
Согласованность: нет ли противоречий между данными по процедурам в EHR и нарратах по операционному учету?
Своевременность: обновляются ли данные в витрине в приемлемое время?
Уникальность: нет ли дубликатов в ключевых измерениях (procedure_id, order_id)?

Инструменты для обеспечения качества включают:

Встраиваемые проверки качества в пайплайны (DQ rules) и отчеты об ошибках.
Мониторинг данных и алерты: уведомления о пропусках, несоответствиях, задержках.
Разделение тестовых и продакшн сред: окружение с контролируемыми данными и синтетическими наборами для тестирования изменений.

Безопасность, доступ и аудит

Управление безопасностью в DWH для клиник требует интеграции строгих политик доступа и защиты персональных данных. Основные принципы:

Принцип минимального доступа: пользователи получают доступ только к тем витринам и данным, которые необходимы для их задач.
Контроль аутентификации и авторизации: роль-базированный доступ (RBAC) и атрибутно-ориентированный доступ (ABAC) для задач анализа, планирования и аудита.
Псевдонимизация и де-идентификация: персональные данные пациентов должны быть обезличены или псевдонимизированы для аналитических задач, особенно в многопользовательской среде.
Шифрование: данные работают в покое и в транзите, используются ключевые менеджеры (KMS/CMK) и безопасная передача через TLS.
Аудит и соответствие: детальные журналы доступа, изменений и экспорта данных; политика защиты и отката при инцидентах.

Соответствие регуляторным требованиям (в зависимости от региона) требует документирования процессов, регулярного аудита и внедрения механизмов защиты.

Эксплуатация данных: безопасность, производительность и управление изменениями

Эффективная эксплуатация витрин клинической аналитики требует баланса между скоростью доступа и надежной архитектурой. Основные принципы:

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

Примеры внедрения и практические рекомендации

Внедрение начинается с определения бизнес-показателей клиники: объем операций, средняя длительность, пропускная способность операционных залов, точность назначения лекарств и пр.
Затем формируется канонический слой: унифицированная витрина с фактами по процедурам и назначениями, и размерностями по пациентам, отделениям и времени.
Далее реализуются контура интеграции для источников: EHR, LIS, RIS, PACS с поддержкой HL7/FHIR и соответствиями кодов.
Важен пилотный этап на одном подразделении (например, отделение планирования операций) для верификации архитектуры и расчета KPI, после чего расширяются витрины на клиники и регионы.
В ходе проекта применяются методологии data governance, включая регламент версионирования кодов и механизм аудита доступа и изменений, чтобы обеспечить соответствие требованиям регуляторов.

Пример сценария внедрения можно разместить как дорожную карту: определение источников, проектирование канонического слоя, создание витрин по KPI OR, настройка мониторинга качества данных и запуск пилота, затем масштабирование на другие подразделения.

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

Key takeaways

Интеграция данных о процедурах, операциях и назначениях требует единого канонического слоя и четкой терминологической стратегии, чтобы обеспечить сопоставимость и аналитику по всей клинике.
Архитектура должна сочетать data lake для сырого контента и витрины DW/мартов для аналитических запросов; важна поддержка как пакетной, так и потоковой обработки.
Моделирование данных в виде фактов и размерностей обеспечивает гибкость агрегаций и устойчивость к изменениям кодов и источников.
Контроль качества данных и прозрачность происхождения являются основой доверия к аналитике; внедряются проверки на полноту, точность, консистентность и соответствие кодировкам.
Безопасность и аудит данных - неотъемлемая часть проекта: RBAC/ABAC, псевдонимизация, шифрование, журналы доступа и изменения.
Реализация должна идти по циклу: пилот в одном подразделении, верификация KPI, масштабирование на всю клинику, сопровождение изменений схем и терминологий.

FAQ

Какие источники данных являются основными для анализа клиник по процедурам и назначениям?

Основные источники включают EHR с записями процедур и назначений, RIS/PACS для информации об операциях и изображениях, LIS для лабораторных назначений и анализов, а также регистры операций и ADT-сообщения для движения пациентов. Важно обеспечить единое сопоставление по терминологиям и датам, чтобы данные можно сопоставлять между системами.

Какой подход к моделированию данных предпочтительнее для клиник: звезда или снежинка?

Обычно применяется звезда (Star) для простоты аналитики и скорости расчета KPI. В сложных сценариях возможна снежинка, если есть сильная нормализация полей и необходимость повторной агрегации. Важно обеспечить SCD-2 для Dim_Patient и Dim_Provider, чтобы сохранять изменения демографии и изменений в персонале.

Какие стандарты кодирования интегрируются в DW клиник и как их поддерживать?

Распространены ICD-10-CM/PCS, CPT, SNOMED CT, LOINC, RxNorm. Поддержка таблицы mapping обеспечивает кросс-подстановку локальных кодов в стандарты и хранение версий обновлений. Регулярная синхронизация справочников и документация изменений критичны для устойчивости аналитики.

Что такое «канонический слой» и зачем он нужен?

Канонический слой объединяет данные из разных источников в единый набор таблиц фактов и размерностей, что обеспечивает единообразие аналитики. Он служит мостом между источниками и витринами и упрощает адаптацию под новые источники без переработки существующих витрин.

Как обеспечить качество данных в рамках интеграционных пайплайнов?

Встраивайте проверки на входе (форматы, типы, валидность кодов), контролируйте полноту и уникальность, проводите cross-source проверки между источниками, храните версии правил качества и ведите журнал изменений. Включайте мониторинг и алерты по критическим KPI (например, пропуски по коду операции).

Какие технологии чаще всего применяются для потоковой обработки клинических данных?

Для потоковой обработки часто применяют Apache Kafka для передачи событий и Apache Spark Structured Streaming или Apache Flink для обработки в реальном времени. NiFi может использоваться для интеграции потоков из разных источников. В качестве витрины применяют OLAP-системы и облачные хранилища.

Какие требования к безопасности данных учитываются в DW клиник?

Принцип минимального доступа (RBAC/ABAC), псевдонимизация/деидентификация для аналитических витрин, шифрование данных в покое и в транзите, журналы аудита и контроль экспорта. Важно обеспечить соответствие локальным регуляциям и регламентам по защите персональных данных.

Какие KPI чаще всего используются для анализа клинической активности по процедурам и назначениям?

KPI охватывают: общую частоту процедур, среднюю длительность операций, время простоя операционного зала, долю запланированных vs выполненных процедур, отклонения по плану и частоту изменений в расписании, точность и своевременность назначения лекарств. KPI требуют точной привязки ко времени и к кодам процедур.

Как организовать миграции схем и версий терминологий без разрушения существующих витрин?

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

Как начать внедрение в клинике с минимальными рисками?

Начинайте с пилота на одном подразделении (например, отделение ОР) с ограниченным набором KPI, затем по мере проверки расширяйте витрины. Разделяйте инфраструктуру и бизнес-логическую часть: отдельные каналы данных, канонический слой, аналитические витрины. Включайте бизнес-пользователей в тестирование, чтобы обеспечить соответствие ожиданиям и требованиям.

Примечание: в тексте были упомянуты открытые и общепринятые решения для примера - Apache Kafka, Apache NiFi, Apache Spark и PostgreSQL/Greenplum - как части практик интеграции и хранения. В рамках российского контекста возможно использование локализованных сервисов/платформ, если они действительно применимы и поддерживают соответствие требованиям по безопасности и локализации данных.

← Предыдущая статья

Клинические подразделения - Хранение истории лечения пациентов для анализа клинических исходов и эффективности медицинских протоколов

Следующая статья →

Клинические подразделения - Формирование витрин данных для анализа повторных госпитализаций и осложнений