Моделирование данных HL7 v2X и v3
Компания, в которой я работаю, начала новую инициативу в HL7, где мы торгуем сообщениями как v2X, так и v3 (в частности, CDA). Я нахожусь в состоянии, когда я могу принимать, проверять и подтверждать сообщения, которые мы получаем от наших торговых партнеров, и начал создавать модель данных для внутреннего хранения этих сообщений. После долгих размышлений и исследований я в растерянности, чтобы найти лучший способ приблизиться к этому в MS SQL Server 2008 R2.
В настоящее время моя идея состоит в том, чтобы по существу загрузить данные в хранилище данных непосредственно из моего интеграционного механизма (BizTalk) и отказаться от резервной, нормализованной операционной базы данных. Я настроил базу данных для сообщений v2X в соответствии со спецификациями v2.7, поскольку все версии HL7 v2 обратно совместимы (я могу хранить любые предыдущие версии в той же базе данных). В моем первоначальном проекте есть таблица для каждого сегмента, которая будет привязана к таблице заголовков с указанием, которое я генерирую и храню во время выполнения. Самая большая проблема с этим подходом - это количество столбцов в каждой таблице, с которым у меня нет опыта. Например, сегмент PV1 имеет 569 столбцов для размещения всех возможных данных. В дополнение к этому мне нужно сделать все столбцы varchar и сделать их достаточно большими, чтобы вместить любой возможный сценарий настройки от наших поставщиков. Я планирую использовать varchar(1024) для достижения этой цели. Многие из этих столбцов (вероятно, большинство) будут NULL, поэтому я бы использовал столбцы SPARSE. Мне это кажется плохим дизайном, но для полной нормализации этих таблиц потребуется куча работы как на BizTalk, так и на SQL-сервере, и я не уверен, что получу от этого. Я пытаюсь быть прагматичным, так как у меня есть крайний срок.
Если бы все было полностью нормализовано, мне, по сути, пришлось бы создавать хранимые процедуры, которые имели бы тонну параметров, ИЛИ разбивать эти сообщения на n-ую степень, чтобы выполнить отдельные загрузки в меньшие подтаблицы и убедиться, что все они соотносятся с исходным указателем. Я также хотел бы поддерживать обработку ACID, которая может стать сложной и вызвать много накладных расходов в BizTalk. Я полагаю, что третьим вариантом будет использование nHapi для создания объектов из сообщений, которые я могу связать с Entity Framework, но nHapi кажется мертвым проектом, и у меня нет опыта работы с Entity Framework на данный момент.
Я в основном в растерянности и нуждаюсь в помощи некоторых профессионалов отрасли, которые имеют опыт моделирования данных HL7. Стоит ли дополнительных усилий полностью нормализовать таблицы? Будет ли производительность на стороне SQL плачевной, если я буду использовать эти денормализованные таблицы сегментов с сотнями столбцов (большинство из которых будет NULL для каждой строки)? Я не администратор баз данных, поэтому я пытаюсь понять подводные камни каждого подхода. Я также посмотрел на RIMBAA, но HL7 RIM кажется мне иностранным языком, как новичку HL7, и перевод сообщений v2 в RIM, вероятно, займет гораздо больше времени, чем я должен завершить этот проект. Я надеюсь, что я обдумываю это, и есть более простое решение, смотрящее мне в лицо. Надеюсь, этот вопрос не слишком открыт.
5 ответов
Я ни при каких обстоятельствах не пытался бы моделировать что-либо, используя HL7 v3 RIM. Причина в том, что эта схема является очень общей, откладывая большую часть метаданных до самого сообщения. Вы знакомы с таблицей EAV? RIM такой.
С другой стороны, HL7 v2 должен быть довольно простой основой для схемы БД. Вы можете создавать таблицы вокруг типов сегментов и столбцы вокруг имен полей.
Я думаю, что проблема втягивания всего убивает проект, и вы не должны этого делать. Как правило, сообщения HL7 v2 несут небольшое подмножество целого, поэтому создание всей этой вещи было бы полной тратой, и это было бы очень запутанным.
Кроме того, версия v2, которую вы моделируете, сильно повлияет на ваши схемы, с более поздними версиями все больше и больше полей становятся повторяющимися полями, и ваши отношения соединения изменятся.
Я рекомендую вам сделать ставку на песок и начать с v2.4, который довольно прост, но все же более сложен, чем большинство используемых интерфейсов. Сосредоточьтесь на нескольких сегментах и нескольких полях. MSH и PID в первую очередь.
Добавьте таблицу EAV, чтобы зафиксировать то, что может появиться в ваших таблицах. Затем вы можете посмотреть, что со временем попадет в эту таблицу, и использовать ее, чтобы решить, что делать дальше. Ваш EAV может выглядеть следующим образом: MSG_ID, SEGMENT, SET_ID, FIELD_NAME, FIELD VALUE. Просто сохраните неразобранное содержимое HL7 значения поля.
HL7 не является "жестким" стандартным входом, и ожидаемые выходы различаются в зависимости от системы, с которой вы разговариваете. В этом случае добавление в брокере, таком как Mirth, Rhaposdy или BizTalk, является очень хорошей идеей.
Какое бы решение вы ни использовали, убедитесь, что вы можете справиться с "нестандартным" вводом и выводом, поскольку вскоре вы обнаружите, что все меняется. На HL7 версий 2X и 3 имейте в виду, что очень немногие больницы имеют версию 3, большинство из которых по-прежнему работают с 2X.
Я шел по дороге работы с базой данных, которая пыталась следовать структуре HL7, она может работать, однако это потребует времени и усилий. Учитывая, что у вас жесткая мертвая черта, возможно, вам нужно разбить биты данных, по которым вам нужно будет выполнить поиск, и иметь поля (например, PID-сегмент 3 - это идентификатор пациента, который будет полезен), остальные могут быть в вашем varchar. Также, если вы не индексируете столбец, вы можете использовать varchar(max).
Что касается ваших гидов в базе данных, это может работать нормально, но будьте осторожны, чтобы не кластеризовать какие-либо индексы с помощью Guid, так как это фрагментирует ваши данные. Проведите здесь свое исследование и, если сомневаетесь, используйте вместо этого столбцы идентификации.
Я тоже порекомендую структуру сущностей, отличный ORM, который стоит изучить.
Итак, мой общий совет. Перейти на гибрид сейчас, вырывая то, что вам нужно. Ожидайте, что он будет развиваться с течением времени, разбивая куски HL7 на их собственные области по мере необходимости. Напишите общий HL7-парсер (не так уж сложно, я делал это пару раз) и держите его гибким. Но больше всего ожидают, что HL7 будет отличаться по структуре, не относитесь к спецификации как к 100% -ной правде, вы получите вариации.
В большинстве случаев попытка создания нормализованной реляционной модели данных для сохранения данных HL7 V2 или V3 является пустой тратой времени. Я бы порекомендовал просто хранить все сообщения или документы в виде значений одного столбца XML. Затем выполните запрос с использованием SQLXML и / или XQuery. Все современные реляционные базы данных поддерживают это сейчас.
Я могу только комментировать стороны CDA (и некоторые очень ограниченные HL7v2), основываясь на личном опыте.
Мы получаем и отправляем документы CDA, завернутые в оболочки HL7v3, от внешних поставщиков (а также внутренних систем - см. Ниже). Оболочки содержат метаданные для таких вещей, как отправка / получение систем / дат и других высокоуровневых данных. Очень ограниченные метаданные сообщения извлекаются и сохраняются в хранилище данных сообщения. Внутри оболочки находится фактический CDA, который затем берется и сохраняется как тип данных XML в базе данных SQL.
Используя эту модель, мы можем затем искать на уровне метаданных, а также сужать его на основе CDA с использованием запросов Xpath. Это делает базу данных намного проще... Я даже представить себе не могу создание столбцов на основе схемы CDA.
Что касается того, чтобы клиенты следовали схеме CDA, в рамках проекта мы создали руководство по внедрению, которому должны следовать клиенты, если они хотят, чтобы их сообщения принимались.
Используя руководство по внедрению + schematron + BizTalk и проверку XSD, мы принимаем только сообщения, которые следуют схеме CDA. Затем мы проверяем некоторые поля данных, используя проверку схематматрона, и отклоняем, если какое-либо из них не удалось. Это передается отправителю с помощью сообщения HL7v3 обратно с недопустимым конкретным сообщением об ошибке и / или полями. Это точка, в которой сообщение будет храниться в базе данных.
Все это делается в BizTalk/SQL Server. А поскольку схема CDA в значительной степени предопределена группой HL7, вы можете заставить потребителей этой системы следовать схеме. Это не похоже на то, что я видел в HL7v2, где кажется, что люди просто сгибают схему по мере необходимости.
Что касается HL7v2, я на 99% уверен, что "мы" (как в "моей компании") хранят сообщения почти одинаково. За исключением того, что поскольку схема HL7v2 настолько открыта, мы не проверяем, а просто принимаем / храним все сообщения. Синтаксический анализатор HL7v2 был написан для анализа HL7v2 с использованием вариаций схем, о которых мы знаем.
В случае моего проекта мы отправляем HL7v2 из нашего HCIS -> Mirth -> BizTalk, который затем следует Схеме руководства по внедрению + CDA вместе с преобразованием XSLT для сопоставления HL7v2 с CDA, ТОГДА отправляет его в OTHER BizTalk CDA Submission service как будто это был внешний поставщик.
Сейчас это тонна чтения, поэтому, пожалуйста, задавайте вопросы, так как я хотел бы поговорить об этом.
Моделирование на HL7 может быть болезненным.
Я бы сделал следующее;
- используйте стандарты, описанные в HL7 для промежуточных таблиц, таким образом, даже если у вас есть varchar(1024) и они нулевые, это не повредит вам
- создайте свою фактическую таблицу, которая будет заполнена из промежуточной таблицы в соответствии со стандартами, которые вы применяете или будете применять.
Это означает, что у вас есть 500+ столбцов из сообщения, но только 10 или 50 имеют смысл, вам нужно будет смоделировать только свои 50. Да, это имеет кривую, завтра вы захотите придать больше значения, тогда оно увеличится с 50 до 75 исторические сообщения не будут иметь информации; это хорошо, но вам нужно будет учитывать дизайн.