|
|
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Такой вопрос... делаем медицинскую учетно-аналитическую систему. Есть 3 учетных сущности: посещение, работы, протокол работ. Связи: 1) посещение (0..1) - работы (0..*) 2) работы (1) - протокол работ (0..1) - в принципе, протоколов может быть несколько, но один из них основной Есть 3 типа пользователей, условно назовем их так: регистратор (вносит в базу посещения), оператор (вносит работы), врач (вносит протоколы работ). И ещё есть аналитик, который в DWH анализирует посещения и работы, но не протоколы. Если протокол работ содержит что-то интересное для аналитики, то это переносится в атрибуты работы. Интерфейс пользователей 3-х уровневый. 1) Сначала создается новое или выбирается существующее посещение, 2) затем по нему заводятся работы, 3) для работ заводятся протоколы. В таком виде у схемы есть недостатки: 1) При вводе работ может быть создано лишнее посещение или выбрано не то посещение. Часть работ вообще не подразумевает посещений, в этом случае операторы и врачи заносят фейковые посещения. Правила, определяющие какие работы являются посещениями, какие - нет, и как работы нужно группировать в посещения достаточно не тривиальные. Лучше бы пользователям вообще запретить заводить посещения, пусть они генерятся (уже в DWH) автоматически на основе работ. Но проблема в том, что далеко не все работы вносятся в базу, часто есть только посещения без работ. Единственное, что приходит в голову: пусть регистраторы вносят не посещения, а как бы фейковые работы. Тогда из OLTP посещения убираем вообще. 2) Интерфейс удобен только для регистраторов. Операторам и врачам приходится делать много лишних движений. Если вместо посещений сделать фейковые работы, то интерфейс упрощается: оператор будет сразу заводить работы, не создавая посещение. Но, чтобы всё совсем упростить нужно объединить протоколы и работы в одну сущность. Тогда получается, что врачи будут вносить в базу протоколы работ, операторы - фейковые протоколы (т.е. протоколы которые содержат только информацию о факте работы, но не содержат самой протокольной информации), регистраторы - дважды фейковые протоколы (тут нет ни протокольной информации, ни деталей проводимых работ - только то, что важно для факта посещения). В общем, изначально мы заносили абстрактные сущности, важные для аналитики (посещения), потом реально существующие факты (работы), теперь получается, что будем хранить документы о фактах. Много всего написал, сам ответил на свои вопросы )) Вопрос: что вы думаете по поводу всего этого? Сталкивались ли с такими задачами и как решали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 08:50 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb Вопрос: что вы думаете по поводу всего этого? Сталкивались ли с такими задачами и как решали? По поводу написанного - набор слов и только. Вы даже непытались вникнуть в суть. Когда поймете хоть 20% того что нужно будете переделывать все заново. Когда поймете еще больше - снова переделывать. Ну и т.д. Тема конечно же интересная. Но невостребована в основной массе. Поэтому думаю это направление пока и гуляет в вольном плавании. Один раз предлагали больничку поставить в цифру, но я отказался. Во первых незнаю специфики. Во вторых объем реально не на год пилить. В третьих пилить когда заказчик сам толком неможет сформулировать что и как - это затея для студентов. У вас полный писец. Подумайте - оно вам нада?.. Хотя с другой стороны, вазелином вас обеспечат даже бесплатно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 09:06 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Злой Бобр, зачем такой обидный слова говоришь? ) Во что именно я не вникнул? Это маленький фрагмент большой вполне работающей системы. Задачи, которые перед ней стоят, она решает. На счет связи осознания с переписыванием, Вы совершенно правы. Но переписывается она уже в 4 раз, так что степень осознания больше, чем Вы думаете. И вообще, медицина только для примера. Меня в принципе интересуют правила выбора сущностей для учета. По сути, тут 4 типа пользователей, которые работают с сущностями на 3 уровнях детализации. Мне интересно, какие есть варианты организации такой схемы, какие у них преимущества/недостатки и какой лучше в моем случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 09:21 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Злой БобрУ вас полный писец.Очень хочется узнать, почему Вы так думаете. Я считаю, что полный писец в здравоохранении. И я пытаюсь найти там какой-то здравый смысл. Под теми же посещениями могут пониматься совершенно разные вещи: 1) любой (с кучей оговорок) контакт врача с пациентом 2) некая абстрактная (в отличие от 1) сущность, определенная набором правил: такие-то контакты с таким-то врачом в рамках такого-то временного периода считаются посещениями, такие-то - нет 3) форма оказания помощи или разновидность случая оказания помощи Сейчас мы остановились на том, что 2 - это посещение, а 1 - работы (или услуги), выполняемые врачом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 11:30 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbВопрос: что вы думаете по поводу всего этого? Талантливо создаются трудности для героического их преодоления, которое громоздит следующие уровни трудностей. Решение, как мне видится по описанию - дать каждому заниматься своим делом и не требовать от него посторонней фигни. Регистратор вносит посещения, причём крайне желательно сделать этот процесс неявным, без кнопки "создать посещение". Лучше привязать этот процесс к выдаче карты, отметке "пациент пришёл" для врача или чему-то подобному. Оператор вносит работы. Ни о каких посещениях он не думает. Если кому-то и где-то нужна их связь - она генерится (например, в ETL) на основании даты/времени. Врач имеет список необработанных работ, выбирает и работает (создаёт протокол), тот автоматом привязывается к работе. И никаких костылей, фейков и гениальных схем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 12:30 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
> И вообще, медицина только для примера. Меня в принципе интересуют правила выбора > сущностей для учета. По сути, тут 4 типа пользователей, которые работают с Правил нет. Есть ТЗ, и искусство проектировщика. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 13:09 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb Меня в принципе интересуют правила выбора сущностей для учета. Сущности (условно постоянные) События - влияют на состояния сущностей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 15:03 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
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 из книги "Шаблоны проектирования баз данных"" ))) _мод, ну, фиг знает... вот, прием врача вроде событие, но не понятно можно ли считать это изменением состояния пациента или чего-то ещё... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 20:27 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, Для начала давайте проясним на примере, сколько посещений будет с точки зрения статистиков, если я пришел к гастроэнтерологу, который направил меня на УЗИ и к хирургу; хирург посмотрел и послал на рентген; потом они вместе поставили диагноз; а я попутно профилактически зашел еще к офтальмологу и стоматологу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 20:59 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ы, статистик ответил бы, что это 3 посещения (гастроэнтеролог, хирург и офтальмолог). Это "полноценные" врачебные посещения. Стоматологов они считают отдельно. Рентгенологов и УЗИ тоже. Для них какие-то свои отчетные формы. У стоматологов учет по манипуляциям. У диагностов по диагностическим процедурам. Но с нашими статистиками мы договорились, что всё это будут посещения (6 штук). Статистики группируют их по отделениям, в которых работают врачи (поликлиника, стоматология, лучевая диагностика, функциональная диагностика). Поликлинические посещения они используют в отчетах, а остальные смотрят просто для информации. Тут диагноз не имеет значения, важна специальность врача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 21:29 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ы, не важно сколько раз в течение дня пациент был у врача, это будет одним посещением. Не важно то, что к хирургу он пришел по направлению гастроэнтеролога. Всё-равно это полноценное посещение. В стационаре всё несколько сложнее. Консультации лечащего врача не считаются посещениями. А, вот, консультация врача из другого отделения или зав. отделением - это уже посещение. Хотя, с другой стороны, статистики говорят, что не важно какое отделение, а важно входит ли эта консультация в стандарт лечения. Если да, то это не посещение, если не входит, то посещение )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2012, 21:42 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, В таком случае я не вижу принципиальной разницы между «посещением» и «работой», изображенными на вашей схеме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 01:41 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, Без обид, но у вас в команде китайский фейерверк, там-же волной бегут цветные драконы на палочках и организованная группа любителей у-шу в центре. Не удивительно, что переделывали 4 раза. Я так и не понял, что вы делаете, хотя смутно догадываюсь о чём речь. В проектировании явные огрехи, вытекающие из незнания предметной области. Вашей команде наверняка не известно, что на МИС (медицинская информ. система для непосвящённых) есть ГОСТ. (см. ГОСТ Р 52636-2006). В этом ГОСТе чётко прописано, что мы должны в МИС однозначно идентифицировать пациента, помимо этого, должны чётко однозначно идентифицировать историю болезни (амбулаторную карту). Только из этих двух постулатов вся ваша схема улетает на свалку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 07:28 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb_мод, ну, фиг знает... вот, прием врача вроде событие, но не понятно можно ли считать это изменением состояния пациента или чего-то ещё... Ессно это событие, может изменится диагноз, например ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 10:48 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ы, схема рисовалась дома в текстовом редакторе , слишком буквально её воспринимать не надо, это просто визуализация идеи, чтобы не перечислять атрибуты и связи словами. Отчасти, и посещения, и работы, и протоколы - одно и тоже. Они описывают один и тот же факт с разной степенью детализации. Есть факт выполнения врачом работы, детали этого факта подробно описаны в протоколе, а некая выжимка из этого факта, обобщение описаны в посещении. Приведу примеры, поясняющие разницу между посещениями и работами. 1) Допустим, стоматолог Иванов И.И. удалил пациенту зуб (и оплачиваться это будет из средств ТФОМС). Так же этот врач предложил пациенту сделать в этот же день платно массаж десен у стоматолога Петрова П.П. Очевидно, что выполнено две работы, причем, разными врачами и с разными видами оплаты. Но это будет одно посещение. Дата посещения очевидна, она совпадает с датами работ. Диагноз тоже должен совпадать, иначе будет 2 разных посещения. Как определить врача, которому мы припишем это посещение, и какой у посещения будет вид оплаты уже менее очевидно. Ну, мы можем принять правило, что эти атрибуты посещения будут определяться на основе первой работы. Ещё менее понятно откуда брать код услуги, цель обращения. У работ нет таких атрибутов. Видимо, посещения всё-таки придется оставить, но убрать из них все атрибуты, которые можно взять из работ. Если врач захочет подать свои работы как посещение, он их укажет. 2) Врач делает пациенту операцию в стационаре. Это будет работой, но не будет посещением. Однако, если этот же врач делает эту же операцию амбулаторно, то это будет уже посещение. Работы могут выполняться средним мед. персоналом, но это не посещения. Т.е. посещение - это одна или совокупность (!) работ, удовлетворяющих определенным условиям. Можно, в принципе, добавить работам атрибуты: 1) первая/не первая работа в течение дня 2) работа сделана в поликлинике/стационаре 3) работа сделана в рамках стандарта/выходит за рамки стандарта 4) работа сделана врачом / сред. мед. персоналом А статистики (в BI-системе) будут отбирать нужные работы, которые они считают посещениями. Но это немного вынос мозга... безумная схема для элементарнейшего показателя... Ещё проблема с 5-ым типом пользователей - регистраторы ТФОМС. Им нужны уже пофамильные списки посещений, а не просто количество как статистикам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 14:08 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
zeon11, у нас есть и пациенты, и карты, и идентификаторы. Картинка выше - это просто картинка, а не точная схема всей БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 14:17 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
_мод, а где-нибудь написано подробней про идею сущностей и событий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 14:19 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbОтчасти, и посещения, и работы, и протоколы - одно и тоже. Они описывают один и тот же факт с разной степенью детализации. Есть факт выполнения врачом работы, детали этого факта подробно описаны в протоколе, а некая выжимка из этого факта, обобщение описаны в посещении.По моему, лучьше писать первичку, то есть те факты, которые имели место в реальности. А потом уже запросами по нужным вам правилам вынимать оттуда работы, посещения и прочее. А то получается какой то абсурдный монстр, который нельзя будет написать и отладить, вам придётся в реальном времени делать вычисления и не записывать реальные факты (их можно будет потом узнавать, бегая по кабинетам и пытая персонал). Мне кажется, 4 переписывания системы (после которых вы задаёте вопросы, как студент, впервые увидивший ЭВМ) - это ненормально и вызвано таким принципиально неверным подходом к проектированию архитектуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 19:23 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvg, в том и проблема, что всё это первичка, только для разных специалистов. Спроси любого медика или даже ИТшника от медицины являются ли посещения первичкой, фактами существующими в реальности, они однозначно ответят "да" ( тут же есть люди, занимающиеся разработкой МИС? как вы ответите на этот вопрос? ). Потому, что во многих поликлиниках учет ведется по посещениям, а не работам (им достаточного такого уровня детализации). В той же самой поликлинике, у тех же самых врачей, но в рамках платных услуг первичка - это работы (у которых есть стоимость), посещения тут уже мало кого волнуют. Врачу же вообще нет дела ни до посещений, ни до работ, для него первичка - протокол. Это подтверждают и сами медицинские документы: в ТАП учитываются посещения, в договорах, калькуляциях - работы, в медицинской карте - протоколы. Обычно делается очень просто. Под каждую службу создается отдельная МИС: регистратура, платная регистратура, АРМ врача, стоматология, косметология, физиотерапия, функциональная диагностика, лаборатория и т.п. - 100500 систем. Мы же считаем, что между всеми этими системами гораздо больше общего, чем все думают, хотим сделать что-то универсальное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 21:47 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbalexeyvg, в том и проблема, что всё это первичка, только для разных специалистов. Спроси любого медика или даже ИТшника от медицины являются ли посещения первичкой, фактами существующими в реальности, они однозначно ответят "да" ( тут же есть люди, занимающиеся разработкой МИС? как вы ответите на этот вопрос? ). Потому, что во многих поликлиниках учет ведется по посещениям, а не работам (им достаточного такого уровня детализации). В той же самой поликлинике, у тех же самых врачей, но в рамках платных услуг первичка - это работы (у которых есть стоимость), посещения тут уже мало кого волнуют. Врачу же вообще нет дела ни до посещений, ни до работ, для него первичка - протокол.Вы меня не поняли. То, про что вы говорите - это не первичка, это соответствующая законодательству (или, например, правилам клиники) отчётность. А первичка - это то, что происходит в реальном, физическом мире. То есть зашёл человек к врачу, постоял, помолчал - это факт реального мира: к врачу зашёл человек. Вышел человек, так ничего и не сказав - второй факт реального мира: он не остался жить в кабинете навсегда, а вышел из него. Вот это и есть первичка (конечно, несколько утрирую, но не так уж сильно). А вот как будут учитываться эти факты и будут ли вообще учитываться - уже другое дело. При этом такой подход правильный и с точки зрения законов и инструкций, поскольку интерпретация фактов часто зависит от других фактов, которые произойдут в будущем (о чём вы уже писали выше как про одну из трудностей ведения статистики). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2012, 23:37 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvg, согласен, но это очень маленькая доля интересующей первички. После того как пациент зашел в кабинет, врач начинает задавать ему вопросы. Пациент отвечает. Врач читает предыдущие медицинские записи, выполняет диагностические, лечебные процедуры. И самое сложное и важное (для учета) - принимает решения. Чтобы зафиксировать всю это первичку, нужно поставить в кабинете видеокамеру или диктофон. А врача нужно заставить озвучивать все свои мысли. Сделать это достаточно сложно, поэтому мы задаем врачу правила обработки первички. Для разных врачей они разные, например, психологу может быть важно выражение лица пациента, какие-то движения, неврологу - частота моргания. Врач обобщает все эти реальные наблюдения, действия, решения, и фиксирует их не как первичку, а уже в отчетной форме - медицинской записи. Т.е. то, что там записано, это не реальные факты, а их интерпретация, обобщение. Если у врача много времени, он может сделать очень подробные записи, приближенные к реальным фактам. Может просто перечислить работы: выполнен первичный прием, сделано узи, наложен гипс. А может вообще написать: было первичное посещение, диагноз - такой-то. В реальности ведутся параллельно все 3 вида учета, причем разными людьми. Проблема в том, как сделать, чтобы эти данные не были противоречивыми, не велся двойной учет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 05:12 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb..." ( тут же есть люди, занимающиеся разработкой МИС? как вы ответите на этот вопрос? ). .... Да, есть тут по крайней мере один. Что могу сказать? Наконец-то понял, что вам нужно. У меня этот блок называется "Автоматизация платных услуг". Тема на самом деле сложная, готовьтесь на 2-3 года, как минимум. Основная ваша проблема - не выстроена медицинская логистика и похоже, пока не знаете, какова она должна быть. Если хотите, можем по-сотрудничать. Есть программа по вашей теме, работает в десятке медучреждений, в некоторых с 2000г, есть практически всё, в том числе такие плюшки, как работа без кассового аппарата по бланкам строгой отчётности, работа по-ролям, анонимизация пациентов, печать разных договоров с пациентом на различные виды услуг, вся отчётность для врачей, экономистов, бухгалтеров (у них тоже стоят эти клиенты), эстеты могут покрутить кубы OLAP, персонализация зарплаты исполнителей услуг и т.д. К той-же БД при желании прикручивается история болезни (весь цикл от приёмного отделения до медстатистики и терфонда ОМС), поликлиника, экономический и ресурсный отдел, пищеблок с его лечебным питанием, аптека, персонифицированный учёт лекарственных средств и т.п. В общем, нет только бухгалтерии (но есть связь с 1С (OLE) и Парус (ADO)) и кадров. Но кадры сейчас дописываю. В качестве помощи, может вам поможет, прикладываю скрин списка услуг по платным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 08:57 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbalexeyvg, согласен, но это очень маленькая доля интересующей первички. После того как пациент зашел в кабинет, врач начинает задавать ему вопросы. Пациент отвечает. Врач читает предыдущие медицинские записи, выполняет диагностические, лечебные процедуры. И самое сложное и важное (для учета) - принимает решения. Чтобы зафиксировать всю это первичку, нужно поставить в кабинете видеокамеру или диктофон. А врача нужно заставить озвучивать все свои мысли. Сделать это достаточно сложно, поэтому мы задаем врачу правила обработки первички. Для разных врачей они разные, например, психологу может быть важно выражение лица пациента, какие-то движения, неврологу - частота моргания. Врач обобщает все эти реальные наблюдения, действия, решения, и фиксирует их не как первичку, а уже в отчетной форме - медицинской записи. Т.е. то, что там записано, это не реальные факты, а их интерпретация, обобщение.Да, разумеется, не нужно записывать абсолютно все (я же писал, что немного утрирую :-) ) Я просто говорю о том, что нужно разделять данные отчётности и факты. То есть для каждой преджметной области придумывается такой набор первички, который позволяет сохранить все значимые факты. В данном случае нужно записывать, допустим, факты посещения пациентом врача (но это не посещения, которые учитываются в отчётности, так что не нужно сразу их фильтровать по критериям учитывается/не учитывается!), и факты о разного рода (типа) действиях врача (но это тоже не "работы", которые учитываются в отчётности, их тоже не нужно сразу фильтровать по критериям учитывается/не учитывается!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 09:05 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
zeon11Наконец-то понял, что вам нужно. У меня этот блок называется "Автоматизация платных услуг".Как я понял, им нужно понять, как хранить и обрабатывать данные для "всего". И в принципе такое желание правильно, тем более что граница платные/бесплатные достаточно размыта, бесплатные - это платные, которые оплачиваются другим способом, да и вообще вся эта отрасль сечас непрерывно меняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 09:10 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgzeon11Наконец-то понял, что вам нужно. У меня этот блок называется "Автоматизация платных услуг".Как я понял, им нужно понять, как хранить и обрабатывать данные для "всего". И в принципе такое желание правильно, тем более что граница платные/бесплатные достаточно размыта, бесплатные - это платные, которые оплачиваются другим способом, да и вообще вся эта отрасль сечас непрерывно меняется. А тут рецепт один - мы должны чётко зафиксировать в БД самый мельчайший факт, который с точки зрения наблюдателя из предметной области представляет интерес. Иными словами, если для врача важно, сколько раз пациент пукнул за приём, то мы должны в БД зафиксировать каждый пук, с указанием времени, длительности и громкости события. Тогда имея такие данные, мы всегда сможем их обобщить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 09:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
zeon11alexeyvgпропущено... Как я понял, им нужно понять, как хранить и обрабатывать данные для "всего". И в принципе такое желание правильно, тем более что граница платные/бесплатные достаточно размыта, бесплатные - это платные, которые оплачиваются другим способом, да и вообще вся эта отрасль сечас непрерывно меняется. А тут рецепт один - мы должны чётко зафиксировать в БД самый мельчайший факт, который с точки зрения наблюдателя из предметной области представляет интерес. Иными словами, если для врача важно, сколько раз пациент пукнул за приём, то мы должны в БД зафиксировать каждый пук, с указанием времени, длительности и громкости события. Тогда имея такие данные, мы всегда сможем их обобщить.Ну да, я про это и говорю ТС. Ну конечно, нужно выбирать, что записывать, находить компромисс между "слишком трудоёмко для пользователей записать всё, что произошло" и "не записаны факты, которые необходимы для дальнейшего анализа" Но главное - неправильно на этом этапе обрабатывать факты и писать вместо них результат анализа. Просто с таким подходом сложнее разрабатывать и модифицировать систему, при любом изменении требований нужно будет "переписывать всё" с последующей мучительной отладкой и внедрением. Пропадают инвестиции. И чем система в целом сложнее и универсальнее, тем важнее это правило. Допустим, если лаборатория наймёт программиста для написания собственной не связанной ни с чем системы учёта, то можно сущности тупо срисовать с инструкций по отчётности, всё будет просто и надёжно. Но при усложнении, чем больше учитывается, тем больше нужно идти в сторону многофазных обработок от фиксации фактов до формирования данных для конечного учёта. Это как сравнить простенький интернет-магазин и полноценную учётную систему торговой фирмы. В первом случае можно делать записи ближе к конечному бизнес-процессу, во втором система раскладывается на учёт фактов (допустим, движение по складу) и какие то фазы постобработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 10:35 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbа где-нибудь написано подробней про идею сущностей и событий? Не думаю, просто best practics ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 11:36 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
zeon11, спасибо за предложение о сотрудничестве! Нам очень нужны партнеры, но пока не знаю чем именно мы сможем друг другу помочь. Мы осознаем, что систему с таким охватом автоматизируемой деятельности как у вас нам разрабатывать ещё лет 5. Поэтому основной акцент делаем на вещах, которых нет или которые очень слабо развиты в других МИС. Это более универсальная схема данных, которая позволит упростить поддержку и развитие системы. Это анализ процессов, классификаторы, поддержка принятия решений. У нас относительно крупное мед.учреждение, многие врачи занимаются научной работой, у них полно идей для воплощения в ИТ. Словом, мы не занимаемся чисто автоматизацией деятельности, проект в значительной степени исследовательский. По поводу платных услуг. А в этом списке у вас есть операции (стационарные) или манипуляции стоматолога? Операции, которые заводятся в стационаре хранятся в той же таблице, что и платные услуги врача поликлиники? А манипуляции стоматолога? А в регистратуре у вас ведется учет посещений? Талоны амбулаторного пациента заносятся в базу? Если да, то вы ведете учет на двух уровнях детализации (посещения и услуги). А что если статистикам понадобится посчитать количество платных посещений (а не услуг, их будет больше, чем посещений)? А если врачи в "бесплатной" поликлинике захотят учитывать не только посещения, но и услуги, которые они оказывали в рамках этих посещений? Как платные услуги завязаны с ЭИБ? Услуги отмечаются отдельно, медицинские записи - отдельно? Или они связаны между собой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 14:15 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbпроект в значительной степени исследовательский. Посему бесплатный совет: купите готовый движок и на нем делайте свой проект. Будете тупо кодить - ничего не выйдет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 14:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgТо есть для каждой преджметной области придумывается такой набор первички, который позволяет сохранить все значимые факты.Проблема в том, что у нас 2 предметных области: "бесплатная" и хозрасчетная поликлиники. В первой минимальным фактом является посещение. А во второй - услуга. Нужно эти области как-то объединить: либо заставить регистраторов бесплатной поликлиники заносить услуги вместо посещений (а все посещения будут генириться на основе услуг), либо регистраторов платной поликлиники заставить дополнительно к услугам отмечать ещё и посещения. В принципе, первый вариант вполне реализуемый, но придется делать 2 варианта формы ввода услуги (одна приближенная талону амбулаторного пациента, другая - к договору). Второй вариант - это как сделано сейчас, одна форма, но удобная только для бесплатной регистратуры и то, не очень. alexeyvgВ первом случае можно делать записи ближе к конечному бизнес-процессу, во втором система раскладывается на учёт фактов (допустим, движение по складу) и какие то фазы постобработки.Ага, по-моему в этом и проблема. Пользовательский интерфейс должен быть максимально приближен к бизнес-процессу. В нашем случае идет разрыв между интерфейсом и схемой данных, что не очень хорошо. Но, видимо, это необходимая жертва. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 14:55 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
_мод, спасибо за совет! В принципе, с этим и связан 4-ый этап переписывания системы. Изначально было несколько ужасных систем Delphi, Access, FoxPro. Потом один товарищ решил переписать всё на C#, MS SQL - технологии другие, код такой же. Потом я попытался сделать хоть какой-то адекватный движок. Он, конечно, позволил избавиться от 80% кода, но сейчас требования изменились, дорабатывать движок нет никаких ресурсов. С переходом на готовый фреймвок, мы выкинем ещё 80% кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 15:02 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbПроблема в том, что у нас 2 предметных области: "бесплатная" и хозрасчетная поликлиники. В первой минимальным фактом является посещение. А во второй - услуга. Нужно эти области как-то объединить: либо заставить регистраторов бесплатной поликлиники заносить услуги вместо посещений (а все посещения будут генириться на основе услуг), либо регистраторов платной поликлиники заставить дополнительно к услугам отмечать ещё и посещения.Печально, вы даже поверхностно не прочитали, что я написал :-( Ares_ekbВ нашем случае идет разрыв между интерфейсом и схемой данных, что не очень хорошо. Но, видимо, это необходимая жертва.Какой у вас критерий "хорошо"? Это красивое, испольуемое ещё за сотни лет до появления ЭВМ, и единственное из работающих (при хоть какой-то сложности процессов) архитектурное решение, а не "жертва". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 16:20 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbВ принципе, с этим и связан 4-ый этап переписывания системы. Изначально было несколько ужасных систем Delphi, Access, FoxPro. Потом один товарищ решил переписать всё на C#, MS SQL - технологии другиеО да, вот в чём дело - язык программирования был выбран не такой :-) Можно ещё ввести журнал опозданий, после этого уж точно будет сделан проект. Архитектора бы вам надо хорошего, или руководителя проекта :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 16:23 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbПроблема в том, что у нас 2 предметных области: "бесплатная" и хозрасчетная поликлиники. В первой минимальным фактом является посещение. А во второй - услуга. Нужно эти области как-то объединить: либо заставить регистраторов бесплатной поликлиники заносить услуги вместо посещений (а все посещения будут генириться на основе услуг), либо регистраторов платной поликлиники заставить дополнительно к услугам отмечать ещё и посещения. Вменяемый пользователь пошлёт Вас {очень далеко} при попытке заставить его делать что-то ему нафиг не нужное, и будет абсолютно прав. Таким путём и появляются "формально внедрённые" монстры, в которых систему вроде как купили, а конечные пользователи её сливают. А "нужно" сделать то, что реально нужно клиентам. Если в поликлинике А не нужны услуги - вот нет у них в бизнес-процессе такого понятия - значит, не нужно показывать им услуги и что-то от них требовать. Если вашему движку эти услуги нужны - прячьте внутрь и генерите автоматом. Со второй поликлиникой соответственно. Ares_ekbПользовательский интерфейс должен быть максимально приближен к бизнес-процессу. Не всегда. Ares_ekbВ нашем случае идет разрыв между интерфейсом и схемой данных, что не очень хорошо. Но, видимо, это необходимая жертва. Схема данных и бизнес-процесс - вовсе разные вещи. Разрыв между интерфейсом и схемой данных - это совершенно нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 16:28 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgПечально, вы даже поверхностно не прочитали, что я написал :-( Прочитал, но, видимо, не понял, намекните, пожалуйста... Ares_ekbКакой у вас критерий "хорошо"? Это красивое, испольуемое ещё за сотни лет до появления ЭВМ, и единственное из работающих (при хоть какой-то сложности процессов) архитектурное решение, а не "жертва".Хорошо - просто и дешево, когда интерфейс генерится автоматически под предметную область, описал её и всё. А тут приходится затрачивать дополнительные усилия. Ну, хотя, да, так, действительно, не бывает. Предметная область должна быть как минимум 2-х уровневой. Например, у нас есть факт "стационарное оказание помощи пациенту". Сам этот факт напрямую практически не редактируется, и, вообще, мало понятен пользователю. Но с этим фактом связан десяток документов. В каждом документе описано какие атрибуты каких сущностей регистратор должен заполнить, т.е. фактически это набор ссылок на атрибуты реальных фактов, такой своеобразный виртуальный факт. Интерфейс для документов генерится автоматически. По сути мы изобрели аналог OpenEHR или HL7 CDA, убогий, но зато простой и понятный. Ares_ekbО да, вот в чём дело - язык программирования был выбран не такой :-)Ну, во-первых то, что там было сделано на Access и FoxPro вообще не поддается никакой критике, это просто ужас, сами технологии конечно не виноваты, но и они не айс. Чел, который переписывал всё на C# по крайней мере понимал, что вместо 20 баз нужна одна, и, что в БД должны быть хотя бы ключи (и первичные, и внешние) и хоть какая-то валидация данных, что посещение врача и посещение психолога - это одна сущность, а пациент и амбулаторная карта - разные, что база стационара должна использоваться не только для распечатки документов, но и облегчать жизнь статистикам - это можно перечислять бесконечно. Но он был слишком самоуверен, считая, что напишет всё сам с нуля без использования готового движка. Ещё он заблуждался в том, что такая система вообще кому-то нужна. В общем, дело не в ЯП ) Ares_ekbАрхитектора бы вам надо хорошего, или руководителя проекта :-)Всё несколько хуже. Туманна необходимость этого проекта в принципе. МИС полно. Зачем делать ещё одну? Мы ищем ответ, и вместе с ним, я надеюсь, найдём и деньги, и архитектора, и руководителя, и программистов. Кстати к вопросу о сотрудничестве, мы со своей стороны готовы принять деньги и помощь в разработке )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 18:17 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
softwarerВменяемый пользователь пошлёт Вас {очень далеко} при попытке заставить его делать что-то ему нафиг не нужное, и будет абсолютно прав.Да, но всё-равно у меня в подсознании сидит мысль, что пользователи работают неправильно А почему интерфейс не всегда должен быть приближен к бизнес-процессу? Я вообще думаю, что все учетные системы должны быть заменены на системы управления процессами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 18:27 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbДа, но всё-равно у меня в подсознании сидит мысль, что пользователи работают неправильно Понимаю. Но с одной стороны, пользователя очень сложно в этом убедить. С другой - чем больше вникаешь в его работу, тем чаще понимаешь, что зря сидит эта мысль. Ares_ekbА почему интерфейс не всегда должен быть приближен к бизнес-процессу? Я вообще думаю, что все учетные системы должны быть заменены на системы управления процессами. Софт должен удачно интегрироваться в бизнес-процесс. Для этого часто полезно, чтобы интерфейс был к нему приближен, но тем не менее. Скажем, возьмите эксель - про его интерфейс никто такое не скажет, но софтина очень полезная. Другой пример: время от времени у моей жены на работе случаются завалы, и руководство собирается и планирует, как распорядиться людьми-оборудованием-транспортом, чтобы всё успеть. Вопрос, нужно ли автоматизировать решение таких завалов? Ответ: да нет, они случаются нечасто, автоматизация не окупится. Следующий вопрос: нужно ли приблизить интерфейс к бизнес-процессу и описать в ИС процесс этого совещания со всеми его предложениями, дёрганьями итдитп? Ответ: да нет, тем более не нужно. Вполне хватит и устраивает просто решения по итогам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 18:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgzeon11А тут рецепт один - мы должны чётко зафиксировать в БД самый мельчайший факт, который с точки зрения наблюдателя из предметной области представляет интерес.Ну да, я про это и говорю ТС.Наблюдателей несколько, один видит услуги, другой - посещения. Причем, оба являются учетчиками. alexeyvgНо главное - неправильно на этом этапе обрабатывать факты и писать вместо них результат анализа.Обработка фактов происходит всегда. В действительности нет ни посещений, ни услуг, ни движения товара на складе. Есть только физические, мыслительные, ... процессы (хотя, и их наверное тоже нет), которые наблюдатель идентифицирует, например, как поступление товара на склад. В реальности произошло огромное количество событий, которые были проанализированы/обработаны и внесены в базу как приход товара. Затем начальник склада аналогично обрабатывает факты движения товара и получает какие-то новые факты. А что если у этого начальника есть в подчинении склад (где-нибудь в Китае), где ведется не учет движения товара, а какой-то другой учет? Например, у них первичка - остатки. Или, например, в первом складе учет ведется по номенклатуре товаров, а во втором - по группам. Словом, вернулись к началу темы, тут всего 2 варианта: либо переучивать один из складов, либо программно реализовать приведение одного вида первички в другой. Можно ли тут придумать какой-то 3-ий вид первички, на который будет раскладываться и первая, и вторая не понятно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 21:32 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, словесный понос все это есть 8 лимонов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 21:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
ViPRos, сделаю скидку на специфику форума и всё-таки спрошу: что именно? почему 8? и зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 04:45 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, словесный понос - попытка подвести тухлую философию по обычные задач мне нужен как раз 8 лимнов срочно избавить вас от этой работы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 13:43 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
ViPRos, Спасибо, я в ваших услугах не нуждаюсь ) Задача наверное обычная... приведите хотя бы одну МИС, в которой она решена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 14:38 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbalexeyvgНу да, я про это и говорю ТС.Наблюдателей несколько, один видит услуги, другой - посещения. Причем, оба являются учетчиками.А вы предметной областью считайте медицину, а не потребителей статистики. Тогда никакой двусмысленности - будут только факты контакта больного с врачём и факты каких либо действий врача и пациента (пациент тоже делает какие то действия в этом процессе). Это близко к реальной жизни, и это позволит получить нужную всем статистику без потерь какой либо информации. Про интерфейсы - понятно, что нужно их делать подходящими для каждого конкретного случая. Но это будет проще (как и должно быть для интерфейсов) - сейчас из за выбранной вами архитектуры относитесь к интерфейсам как к чему то священному, они у вас трудоёмкие в изгоитовлении, завязаны на постоянно и сильно меняющуюся модель данных. А с новой схемой будет проще - инерфейсы будут, как и положено, шелухой, нанятые кодеры будут их быстренько лабать (на разных языках и платформах) под разные подразделения и меняющиеся требования пачками. Модель данных не бдет меняться, интерфейсы соответственно не нужно будет переделывать под эти изменения - только под изменения бизнес-требований к интерфейсам, за часик, за день. Ares_ekbВ реальности произошло огромное количество событий, которые были проанализированы/обработаны и внесены в базу как приход товара. Затем начальник склада аналогично обрабатывает факты движения товара и получает какие-то новые факты. А что если у этого начальника есть в подчинении склад (где-нибудь в Китае), где ведется не учет движения товара, а какой-то другой учет? Например, у них первичка - остатки.Издревле первичка для складов - это "приход товара" и "уход товара". Всё. Где бы как бы не велась отчётность и учёт - первичка не меняется. Это тысячи лет так, и сомневаюсь, что какой то склад где-нибудь в Китае делает по другому. Вот и ищите в вашей предметной области такую правильную первичку, которая была тысячи лет и не изменится ещё столько же (то есть для медицины: приём врача-действия врача, только не те, которые подразумевает статистика, а те, которые подразумевают участники действа - пациент и врач, причём врач, не работающий в какой либо системе зравохранения :-) ). Не внедряйте новую первичку, которой не было хотя бы сотню лет назад. А уже из этой "правильной" первичке легко получите любую информацию - для работ, которые на самом деле приёмы, для приёмов, которые работы и т.д. Ares_ekbИли, например, в первом складе учет ведется по номенклатуре товаров, а во втором - по группам.А вот это уже детали учёта. Конечно, при подборе хранимых атрибутов нужно учитывать и потребености статистики, и т.п. Но при правильной модели будет несложно добавить атрибут при необходимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 17:31 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbViPRos,Спасибо, я в ваших услугах не нуждаюсь )зря отказываешься, он мог бы решить, имхо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2012, 00:13 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbzeon11, спасибо за предложение о сотрудничестве! Нам очень нужны партнеры, но пока не знаю чем именно мы сможем друг другу помочь. Мы осознаем, что систему с таким охватом автоматизируемой деятельности как у вас нам разрабатывать ещё лет 5. Поэтому основной акцент делаем на вещах, которых нет или которые очень слабо развиты в других МИС. Это более универсальная схема данных, которая позволит упростить поддержку и развитие системы. Это анализ процессов, классификаторы, поддержка принятия решений. У нас относительно крупное мед.учреждение, многие врачи занимаются научной работой, у них полно идей для воплощения в ИТ. Словом, мы не занимаемся чисто автоматизацией деятельности, проект в значительной степени исследовательский. По поводу платных услуг. А в этом списке у вас есть операции (стационарные) или манипуляции стоматолога? Операции, которые заводятся в стационаре хранятся в той же таблице, что и платные услуги врача поликлиники? А манипуляции стоматолога? А в регистратуре у вас ведется учет посещений? Талоны амбулаторного пациента заносятся в базу? Если да, то вы ведете учет на двух уровнях детализации (посещения и услуги). А что если статистикам понадобится посчитать количество платных посещений (а не услуг, их будет больше, чем посещений)? А если врачи в "бесплатной" поликлинике захотят учитывать не только посещения, но и услуги, которые они оказывали в рамках этих посещений? Как платные услуги завязаны с ЭИБ? Услуги отмечаются отдельно, медицинские записи - отдельно? Или они связаны между собой? В этом списке, скрин фрагмента которого я привёл находится всё: услуги поликлиники, стоматолога, стационара, платные палаты и т.д. Т.е. всё то, что учреждение может дать (продать) пациенту, а пациент согласен принять. Этот список как видно на скрине, называется обобщённо - "услуги". Поскольку в некоторых учреждениях, где работает программа таких услуг может быть достаточно много (например, в одной городской больнице 40 отделений, более 1800 "живых" услуг) структура списка достаточно сложна. Как видно, на скрине, она иерархическая, количество вложений не ограничено, но в реале, более чем на 5 колен экономисты не делали. Поскольку оформление услуг в реале должно быть быстрым (никто не позволит держать толпу пациентов перед регистратурой), на список накладываются доп. ограничения, например, отношениями "Многие-ко-многим" связываются услуги и отделения. Тогда оператор выбрав отделение получает небольшой список услуг, оказываемых именно этим отделением. Благодаря этому, скорость оформления такая-же, как в супермаркете. Некоторые услуги могут требовать и как-бы и опосредованной продажи каких-либо материальных ценностей (расходных материалов), например, импланты, линзы, реактивы, рентгеновская плёнка и т.п. Если в учреждении установлен модуль для ресурсного отдела, то программа может предложить и список имеющегося на складе (в отделении) мат. обеспечения этой услуги. Т.о. мы имеем актуальный склад и персонифицированный учёт мат.активов. Это в принципе должно быть в каждом мед.учреждении, поскольку, не дай бог, если придёт какая-либо "гнилая" партия имплантов, то мы отзовём не пол-города, а только несколько человек, у которых импланты из этой партии. А помимо этого, есть и хороший экономический эффект, если подключить ресурсный отдел. Уменьшаются запасы на складе, нет проблемы просроченного товара (те, кто работает в медицине знают, что это очень серьёзно), исчезает бардак. Далее, в некоторых учреждениях ведут персонифицированный учёт исполнителей услуг. В этом случае на каждую услугу "навешивается" гроздь должностей-исполнителей. На скрине можно видеть закладку "Услуга - Должности", где прописано должностное обеспечение выполнения услуги и тариф должности за выполнение услуги. Если будет интерес, выложу скрин. Далее, по факту выполнения услуги, специальный человек распределяет конкретных людей на исполнение услуги. Заранее, до исполнения это сделать можно только в единичных учреждениях, где железная дисциплина. В большинстве-же, кто дорос до этой схемы, по-факту. Тут тоже для исключения ошибок, учитывается, находится-ли человек в отпуске, какая у него квалификация, должность. В целом, БД построена так, что учёт выполнения услуг может работать как самостоятельное раб. место, сидит один кассир, выписывает квитанции и всё. Если-же в учреждении ввели электронную историю или электронную амбулаторну карту, то учёт услуг можно прицепить к этим документам. Фундаментального различия между платными-бесплатными нет. Просто есть поток услуг с признаками "Платный", "ДМС", "ОМС", "РОФСС" и т.д. Врачу на самом деле по-барабану, кто заплатит. А бухгалтерии плюшки ввиде учёта наличных, автоматическое формирование счетов, напр. для страховых компаний по ДМС и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2012, 09:48 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1541673]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
145ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 420ms |

| 0 / 0 |
