Библиотека Интернет Индустрии I2R.ru

Пытаетесь создать интегрированное досье клиента? Вот несколько полезных уроков построения Хранилище данных в области здравоохранения

Когда вы сталкиваетесь с необходимостью извлечь информацию из терабайтов данных, возможно, первое, что вы скажите: "Нам необходимо Хранилище данных". Однако, если вы сначала подумаете немного, вы измените свое суждение: "Нам нужно Хранилище данных, которое может решить определенную бизнес-проблему". При этом, вы сможете сэкономить массу времени и усилий (и дорогостоящих ресурсов). В идеале, решение этой бизнес-проблемы должно быть направлено на реализацию всех стратегических задач вашей организации. Например, вашей компании для того, чтобы выполнить план по увеличению продаж в магазинах, необходимо определить демографическую характеристику определенного покупателя. В данном случае корпоративный бизнес-план - увеличение удельного веса компании на рынке. Только согласовывав цели IT-отдела с бизнес-задачами, можно надеется на успешное развертывание Хранилища данных.

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

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

Доступ к данным

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

• Загружать различные данные, чтобы пользователь мог легко к ним обращаться.
• Обеспечивать два режима просмотра данных:
  1. На стратегическом уровне: иерархическое представление, начиная от высшего уровня организации и заканчивая данными, собранными для отдельной клиники.
  2. На уровне отдельного пациента.
• Загрузить три терабайта исторических данных.
• Поглощать более 50 тысяч файлов в месяц и загружать их Хранилище данных во время простоя.

Модель Хранилища данных отвечает первым двум требованиям, а информационная архитектура - двум вторым. Предпочтение было отдано схеме "звезда", поскольку пользователи смогли бы легко адаптировать ее для формулирования бизнес-вопросов, и она может относительно быстро давать ответы на эти вопросы. Реальную сложность представляло определение метода развертывания этой схемы.

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

Факты и измерения

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

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

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

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

Демографический факт. Одна строка загружалась для каждого месяца, в течение которого пациент получал медицинское обслуживание по своему страховому плану. Эта строка идентифицировалась по последней действительной дате месяца. Меры состояли из общего числа пациентов, приписанных к программе HMO (программа корпоративных медицинских страховок), а также тех, кто может получать медицинское обслуживание вне HMO. Эти меры предоставляют "исчерпывающее досье" пациента: его местожительства, семейное положение, наличие/число иждивенцев. Демографический факт может связать факт посещения для определения специфических демографических характеристик.

Эти факты совместно использовали некоторые измерения, благодаря чему пользователи могли выполнять запросы к схемам звездочка для релевантных вопросов. В эту модель были включены следующие измерения:

• Время включало иерархическую структуру для календарных и фискальных дат. Минимальный интервалом времени был один день.
• Организация - информация о ресурсах организации - была структурирована, начиная от географических областей, в которых находились медицинские учреждения, до отдельных клиник, посещаемых больными.
• Тип квитанции об оплате включал информацию о различных квитанциях, состояние счета к оплате, сумме каждой поправки в квитанции об оплате.
• Учреждение охватывало характеристики медицинского учреждения: идентификационный номер, специализация, страна, штат и почтовый индекс.
• Тип лечения содержал информацию о полученной медицинской услуге: амбулаторная или стационарная, были ли хирургические операции в течение вышеупомянутых дней, и проводился ли осмотр лечащим врачом.
• Демографические данные включали информацию о клиенте, которая оставалась относительно постоянной: идентификационный номер, пол, дата рождения и так далее. Эти характеристики меняются редко, или никогда, и поэтому хранятся отдельно от тех атрибутов, что периодически изменяются.
• Субъект охватывал SSN (social security number, номер социального обеспечения), а также системный ID. Разделяя SSN на свои собственные измерения и используя системный ID в большинстве запросов, можно гарантировать конфиденциальность информации. Одно из требований заказчика заключалось в том, чтобы ограниченное число пользователей могло связывать карты пациентов с их реальными файлами. Эти пользователи, и только эти пользователи, имели доступ к этому измерению.
• Место жительства предоставляло возможность отслеживать услуги по различным регионам страны. Город пациент, страна, штат и почтовый индекс делали возможность связать предоставленную услугу с географической областью.
• Детальные демографические данные включали информацию, которая могла измениться со временем, эти данные были крайне важны для принятия бизнес-решений, к ним относились: семейное положение, число иждивенцев, возрастная группа. Так, например, потребности пациентов в возрастной категории от 21 года до 30 лет и 0 - 10 лет существенно отличаются друг от друга.

Информационная архитектура

Решение опиралось на четырехслойную архитектуру, которая состояла из хранилища операционных данных (Transactional Data Store, TDS), слоя извлечения, преобразования и загрузки (ETL); сервера реляционной базы данных и процессора метаданных, комбинированного с пользовательским OLAP-инструментом.

Первый слой: хранилище операционных данных. TDS загружает каждый файл в базу данных по его поступлению. Каждый исходный файл имеет свою таблицу в базе данных. Каждая строка во входных данных соответствует одной строке в целевой таблице. К каждой строке в таблице добавляется дата файла (для того, чтобы установить, какой исходный файл посылается каждый день) и дата обработки (используется ETL для определения, какая запись обрабатывается). Исходные файлы могут быть удалены после обработки или поддерживаться в интерактивном режиме до тех, пока не станет очевидно, что данные устойчивые.

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

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

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

Наличие ETL в отдельном слое имеет рядом преимуществ. Во-первых, это неограниченная масштабируемость, поскольку ETL не является частью процессора базы данных. Если число источников увеличивается, или обработка становится более сложной, вы можете просто добавить еще несколько ETL-систем. Во-вторых, благодаря переносу большей части процесса обработки с платформы процессора базы данных на вторую платформу, процессор базы данных становится незанятым и может использоваться для обработки пользовательских запросов. Кроме того, ETL-слой реализует функции целостности данных, которые обычно выполняются базой данных 3NF (Third Normal Form). Процессы ETL отслеживали уникальные записи и, таким образом, знали о необходимости ввода или обновления данных. Кроме того, они использовали справочные таблицы, чтобы гарантировать достоверность данных.

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

Благодаря разделению процессов извлечения и загрузки данных в одном слое, процессор базы данных полностью доступен для обработки пользовательских запросов. Этот слой также позволял получить больше "удовольствия за свои деньги". Дело в том, что платформы, на которых работают процессоры баз данных, обычно более дорогостоящие по сравнению с NT-системами, используемыми в ETL-слое. Таким образом, больше инвестиций может быть отведено на поддержку бизнес-решений.

Четвертый слой: пользовательский интерфейс. Смысл Хранилища данных - в предоставлении данных пользователю. Пользователь может получать данные, только если они доступны, так что успех любого проекта по развертыванию Хранилища данных зависит от того, выбран ли удобный для пользователя инструмент. Сложность состоит в том, что необходимо найти такое средство, которое будет приемлемо и для неопытного пользователя и искушенного аналитика. Мы выбрали пользовательский инструмент, который выполнял функции OLAP.

По получении пользовательского запроса инструмент агрегации рассматривал SQL-операторы, используемые для создания таблиц агрегатов, чтобы определить, вычислен ли ответ (В идеале таблицы агрегатов разрабатываются так, чтобы удовлетворять 90% этих запросов.) Только тогда, когда ответ не мог быть получен посредством агрегатов, происходило обращение в базе данных. Этот инструмент также использовался для отслеживания используемых запросов и выработки предложений по дополнению или измерению агрегатов. Кроме того, можно реализовать средства, которые отслеживают запросы по каждому пользователю. Эта информация позволяет определить, кто и какие данные запрашивает и как часто, ее можно использовать для выделения ресурсов и сокращения расходов.

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

Гибкое решение

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

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