Здравствуйте!

Такой вопрос... делаем медицинскую учетно-аналитическую систему. Есть 3 учетных сущности: посещение, работы, протокол работ. Связи:
1) посещение (0..1) - работы (0..*)
2) работы (1) - протокол работ (0..1) - в принципе, протоколов может быть несколько, но один из них основной

Есть 3 типа пользователей, условно назовем их так: регистратор (вносит в базу посещения), оператор (вносит работы), врач (вносит протоколы работ). И ещё есть аналитик, который в DWH анализирует посещения и работы, но не протоколы. Если протокол работ содержит что-то интересное для аналитики, то это переносится в атрибуты работы.

Интерфейс пользователей 3-х уровневый. 1) Сначала создается новое или выбирается существующее посещение, 2) затем по нему заводятся работы, 3) для работ заводятся протоколы.

В таком виде у схемы есть недостатки:

1) При вводе работ может быть создано лишнее посещение или выбрано не то посещение. Часть работ вообще не подразумевает посещений, в этом случае операторы и врачи заносят фейковые посещения. Правила, определяющие какие работы являются посещениями, какие - нет, и как работы нужно группировать в посещения достаточно не тривиальные. Лучше бы пользователям вообще запретить заводить посещения, пусть они генерятся (уже в DWH) автоматически на основе работ. Но проблема в том, что далеко не все работы вносятся в базу, часто есть только посещения без работ. Единственное, что приходит в голову: пусть регистраторы вносят не посещения, а как бы фейковые работы. Тогда из OLTP посещения убираем вообще.

2) Интерфейс удобен только для регистраторов. Операторам и врачам приходится делать много лишних движений. Если вместо посещений сделать фейковые работы, то интерфейс упрощается: оператор будет сразу заводить работы, не создавая посещение. Но, чтобы всё совсем упростить нужно объединить протоколы и работы в одну сущность. Тогда получается, что врачи будут вносить в базу протоколы работ, операторы - фейковые протоколы (т.е. протоколы которые содержат только информацию о факте работы, но не содержат самой протокольной информации), регистраторы - дважды фейковые протоколы (тут нет ни протокольной информации, ни деталей проводимых работ - только то, что важно для факта посещения).

В общем, изначально мы заносили абстрактные сущности, важные для аналитики (посещения), потом реально существующие факты (работы), теперь получается, что будем хранить документы о фактах. Много всего написал, сам ответил на свои вопросы )) Вопрос: что вы думаете по поводу всего этого? Сталкивались ли с такими задачами и как решали?

Злой Бобр,

зачем такой обидный слова говоришь? ) Во что именно я не вникнул? Это маленький фрагмент большой вполне работающей системы. Задачи, которые перед ней стоят, она решает. На счет связи осознания с переписыванием, Вы совершенно правы. Но переписывается она уже в 4 раз, так что степень осознания больше, чем Вы думаете.

И вообще, медицина только для примера. Меня в принципе интересуют правила выбора сущностей для учета. По сути, тут 4 типа пользователей, которые работают с сущностями на 3 уровнях детализации. Мне интересно, какие есть варианты организации такой схемы, какие у них преимущества/недостатки и какой лучше в моем случае.

Злой БобрУ вас полный писец.Очень хочется узнать, почему Вы так думаете. Я считаю, что полный писец в здравоохранении. И я пытаюсь найти там какой-то здравый смысл. Под теми же посещениями могут пониматься совершенно разные вещи:
1) любой (с кучей оговорок) контакт врача с пациентом
2) некая абстрактная (в отличие от 1) сущность, определенная набором правил: такие-то контакты с таким-то врачом в рамках такого-то временного периода считаются посещениями, такие-то - нет
3) форма оказания помощи или разновидность случая оказания помощи

Сейчас мы остановились на том, что 2 - это посещение, а 1 - работы (или услуги), выполняемые врачом.

softwarerРегистратор вносит посещения, причём крайне желательно сделать этот процесс неявным, без кнопки "создать посещение". Лучше привязать этот процесс к выдаче карты, отметке "пациент пришёл" для врача или чему-то подобному.У нас такое было, только это "Назначение приема", оно было привязано к созданию талона амбулаторного пациента (ТАП). Но пользователи не оценили. Ну, это не принципиально, мы не очень сильно настаивали.

Ares_ekbИнтерфейс пользователей 3-х уровневый. 1) Сначала создается новое или выбирается существующее посещение, 2) затем по нему заводятся работы, 3) для работ заводятся протоколы.Похоже, я ввел всех в заблуждение. Это не схема работы и не очередность ввода данных, а то как сейчас построен интерфейс.

На самом деле сценарии такие:

1) Пациент приходит в регистратуру, там заносятся данные о нем, печатаются документы (в т.ч. ТАП). Пациент идет к врачу. Врач заполняет бумажные протоколы и ТАП. Затем ТАПы сдаются в регистратуру. Через некоторое время ТАПы (список врачебных посещений) в пакетном режиме заносятся регистраторами в базу. Т.е. тут задним числом вносятся посещения и всё (ни работ, ни протоколов). Посещение - это фактически выжимка из протокола. Если бы врач во время приема внес протокол в базу, то посещение можно было бы получить автоматически.

2) Пациент приходит в регистратуру платных услуг. Регистратор (в первом сообщении я назвал его оператор) вносит в базу список планируемых работ (тут учет ведется по работам, и посещения их мало интересуют, но эти не заведенные посещения нужны статистикам), печатает договор. Пациент идет к врачу. Тут, как Вы и предлагаете, врач может (пока очень малая доля врачей будет это делать) дополнить работы протоколами. Однако, возможна ситуация, что пациент попадет к врачу минуя регистратуру. В этом случае врачу будет не удобно заводить сначала работу, а потом протокол.

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

Получается, в каждом сценарии основная работа идет с разными сущностями. Важно не то, чтобы между сущностями были связи, а то, чтобы работы и посещения были синхронизированы. Например, во 2 и 3 сценариях посещения не заводятся, но они должны быть. Непонятно как лучше: 1) создавать/удалять/редактировать посещения незаметно для пользователя при создании/удалении/редактировании работ или 2) генерить эти посещения потом в ETL?.. 2-ой вариант, как мне кажется проще, но тогда будет 2 вида посещений: введенные (1 сценарий) и сгенерированные (2 и 3 сценарии). Это сложно. Тогда уж лучше сделать вообще все посещения сгенерированными. Пусть регистраторы в 1 сценарии добавляют/редактируют/удаляют работы, а посещения будут генериться. Как видно на (условной) схеме посещения и работы достаточно похожи, регистраторы не должны сильно возмутиться... Хотя, не факт, что не возникнут ещё какие-то сложности...

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



MasterZiv, я надеялся, что кто-нибудь мне скажет: "о, да это же типовая задача - паттерн 128 из книги "Шаблоны проектирования баз данных"" )))

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

Ы,

статистик ответил бы, что это 3 посещения (гастроэнтеролог, хирург и офтальмолог). Это "полноценные" врачебные посещения.

Стоматологов они считают отдельно. Рентгенологов и УЗИ тоже. Для них какие-то свои отчетные формы. У стоматологов учет по манипуляциям. У диагностов по диагностическим процедурам.

Но с нашими статистиками мы договорились, что всё это будут посещения (6 штук). Статистики группируют их по отделениям, в которых работают врачи (поликлиника, стоматология, лучевая диагностика, функциональная диагностика). Поликлинические посещения они используют в отчетах, а остальные смотрят просто для информации.

Тут диагноз не имеет значения, важна специальность врача.

Ы,

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

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

Ы,

схема рисовалась дома в текстовом редакторе , слишком буквально её воспринимать не надо, это просто визуализация идеи, чтобы не перечислять атрибуты и связи словами.

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

Приведу примеры, поясняющие разницу между посещениями и работами.

1) Допустим, стоматолог Иванов И.И. удалил пациенту зуб (и оплачиваться это будет из средств ТФОМС). Так же этот врач предложил пациенту сделать в этот же день платно массаж десен у стоматолога Петрова П.П. Очевидно, что выполнено две работы, причем, разными врачами и с разными видами оплаты. Но это будет одно посещение. Дата посещения очевидна, она совпадает с датами работ. Диагноз тоже должен совпадать, иначе будет 2 разных посещения. Как определить врача, которому мы припишем это посещение, и какой у посещения будет вид оплаты уже менее очевидно. Ну, мы можем принять правило, что эти атрибуты посещения будут определяться на основе первой работы.

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

2) Врач делает пациенту операцию в стационаре. Это будет работой, но не будет посещением. Однако, если этот же врач делает эту же операцию амбулаторно, то это будет уже посещение. Работы могут выполняться средним мед. персоналом, но это не посещения.

Т.е. посещение - это одна или совокупность (!) работ, удовлетворяющих определенным условиям. Можно, в принципе, добавить работам атрибуты:
1) первая/не первая работа в течение дня
2) работа сделана в поликлинике/стационаре
3) работа сделана в рамках стандарта/выходит за рамки стандарта
4) работа сделана врачом / сред. мед. персоналом

А статистики (в BI-системе) будут отбирать нужные работы, которые они считают посещениями. Но это немного вынос мозга... безумная схема для элементарнейшего показателя...

Ещё проблема с 5-ым типом пользователей - регистраторы ТФОМС. Им нужны уже пофамильные списки посещений, а не просто количество как статистикам.

zeon11,

у нас есть и пациенты, и карты, и идентификаторы. Картинка выше - это просто картинка, а не точная схема всей БД.

_мод,

а где-нибудь написано подробней про идею сущностей и событий?

alexeyvg,

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

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

Обычно делается очень просто. Под каждую службу создается отдельная МИС: регистратура, платная регистратура, АРМ врача, стоматология, косметология, физиотерапия, функциональная диагностика, лаборатория и т.п. - 100500 систем. Мы же считаем, что между всеми этими системами гораздо больше общего, чем все думают, хотим сделать что-то универсальное.

alexeyvg,

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

Чтобы зафиксировать всю это первичку, нужно поставить в кабинете видеокамеру или диктофон. А врача нужно заставить озвучивать все свои мысли.

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

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

Если у врача много времени, он может сделать очень подробные записи, приближенные к реальным фактам. Может просто перечислить работы: выполнен первичный прием, сделано узи, наложен гипс. А может вообще написать: было первичное посещение, диагноз - такой-то.

В реальности ведутся параллельно все 3 вида учета, причем разными людьми. Проблема в том, как сделать, чтобы эти данные не были противоречивыми, не велся двойной учет.