|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
Посоветуйте, какие таблицы нужны и как связать их. В больнице нужно проводить лечение в зависимости от состояния пациента. Тип лечения определяет, какие процедуры и в какой последовательности нужно выполнить, чтобы лечение считалось завершенным. У разных типов лечения могут быть разное число разных процедур, от одной до М. За лечение отвечает врач. У каждой процедуры есть исполнитель (медсестра). Нужно учитывать продолжительность процедур и лечений в целом. Моё решение. Типы_лечения (cure_id, cure_name, ...); Типы_процедур (proc_id, cure_id, order, proc_name, ...); Лечение (course_id, patient_id, cure_id, start_date, end_date, doctor_id, ...); Процедуры_лечения (imp_id, course_id, proc_id, start_date, end_date, sister_id, ...). Есть внешние ключи. По названию полей, думаю, понятно, какие. Для простоты не привожу здесь таблицы Сотрудники и Пациенты, но они есть. Мне не совсем нравится такая схема, т.к. есть возможность в таблице Процедуры_лечения указать процедуру, которая не соответствует типу лечения в родительской записи в таблице Лечение. И внешние ключи не отловят такую ошибку. Есть ли решение лучше? Уменьшить число таблиц? Или увеличить? Изменить связи? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 23:36 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin, Тип лечения ( Типы_лечения (id, name, ...) ) определяет, какие процедуры ( Типы_процедур (id, cure_id, name, ...) ) и в какой последовательности нужно выполнить ( Типы_лечения_Типы_процедур(id, cure_id, proc_id, order, ...) ), чтобы лечение считалось завершенным. Лечение (id, patient_id, doctor_id, cure_id, date_from, date_to, ...) График_процедур(id, course_id, proc_id, sister_id, datetime_from, datetime_to, order - опционально, ...) Типы_лечения_Типы_процедур - руководство для заполнения графика процедур, date_from, date_to лечения определяется началом и завершением всех процедур по графику. Возможны дополнительные справочники Типы_лечения_Доктора и Типы_процедур_Медсестры, в этом случае возможна замена ссылок doctor_id, cure_id и proc_id, sister_id на идентификаторы из этих справочников. "И внешние ключи не отловят такую ошибку" - внешние ключи обеспечивают контроль целостности только для простейших случаев, в данном случае контроль правильности графика процедур и дат начала и завершения лечения на приложении. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 00:39 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin Есть ли решение лучше? Уменьшить число таблиц? Или увеличить? Изменить связи? Что значит, лучше? Какие задачи вы решаете? На абсолютно любую вашу схему я придумаю вам кейс, где такая организация данных будет г..вно. Если вам кто-то сходу даёт какую-то "правильную" схему, смело плюйте ему в лицо. Решения подбираются под задачи, а не наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 01:01 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin, чтобы улучшить схему БД ее сначала нужно нарисовать хоть какую-то... вы реально думаете что сейчас кто-то будет в голове соединять ваши ключи и сделает это правильно ? aliputin Мне не совсем нравится такая схема а мне совсем не нравится, для вас такая миссия совсем не выполнима ? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 01:07 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin, недавно лежал в больнице - там у них был такой листочек назначений, таблица, я не вглядывался, но вроде как строки - это пациенты, а столбцы конкретные дни, в ячейках какие процедуры/таблетки врач назначает лечение по правилам (антибиотик такой-то, каждый день один раз с утра 20 мл внутримышечно) и лечение в целом не статично, т.е. нет фиксированного срока, когда оно закончится, врач может посередине все поменять (например аллергия на препарат - его отменяют, заливают антигистаминное [это отдельная капельница, отдельный препарат, на один раз] и на след день дают другой препарат). да и нет жесткой привязки к мед сестре. там у них правило - кто ставил капельницу, тот и отвечает за пациента, но снять может другая медсестра, и на следующий день тоже ставить капельницу может другая - потому что вчерашняя была на суточном дежурстве и ушла домой так что я думаю начинать надо вот с этого расписания процедур, это трехмерная таблица на UI, в БД может выглядеть как-то так: таблица расписания (timetable) id patient_id date чтоб алгоритм ее заполнил, нужна таблица назначений таблица назначений (appointments) id patient_id procedure_id start date end date volume доп поля... в ней используется справочник процедур таблица процедур (procedures) id name доп поля (в/в, в/м, мг, мл, таблетки, ампулы и так далее) и наконец таблица связи расписания и назначения (timetable_appointments) - показывается в ячейках на UI id timetable_id appointment_id (возможно все таки procedure_id ?) доп поля (комментарий например или еще что потребуется) ну и следовательно лечение - это вся группа назначений пациенту (select * from appointments where patient_id = ?), если пациент постоянный клиент - то ведется еще учет когда поступил и когда выписался и в условия добавляется период дат ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 09:18 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
в таблицу timetable можно добавить sister_id - мед сестра, которая в этот конкретный день выполнила процедуру ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 09:30 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin, Насколько глубоко собираетесь копать? А то, может, имеет смысл сначала посмотреть, как устроены существующие системы - тот же Cerner. Вот , например. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 10:07 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
hVostt Какие задачи вы решаете? aliputin Нужно учитывать продолжительность процедур и лечений в целом. Меня интересует, можно ли (нужно ли) ловить ошибку назначения неправильной процедуры средствами БД или лучше передать эту ответственность клиентскому приложению. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 10:18 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
Автор. Идеальную БД больница ты все равно не создашь. Поэтому сосредоточимся на БД "назначенные лечебные процедуры". В топике правильно говорят про резкое изменение в лечении. Пойди не от структур данных а от процессов которые происходят в реальной больнице. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 10:23 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
Для публикации диаграмм можешь использовать этот сервис http://www.plantuml.com Пример. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 12:43 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin можно ли (нужно ли) ловить ошибку назначения неправильной процедуры средствами БД Внешними ключами нет, триггерами возможно, зависит от СУБД, триггеры будут содержать сложную логику что очень не хорошо. aliputin или лучше передать эту ответственность клиентскому приложению. Лучше. Рассмотрим простой пример, врач назначает пациенту массаж, стандартный курс - 10 процедур и физиотерапию, также 10 процедур, какая продолжительность? Ответа на этот вопрос без графика нет, поскольку есть выходные и праздничные дни, массажисты также обслуживают других пациентов, т.е. должен быть свободен массажный кабинет и свободное окно у массажиста, то же самое касается медсестры и аппарата для конкретной процедуры физиотерапии. Все это значит что у вас должен быть общий график, навроде учебного плана в учебных заведениях, в котором для пациентов указано время когда они проходят процедуры, процедура, аппарат, человек проводящий процедуру, при этом перед назначением процедуры в конкретный день на конкретное время нужно по этому же графику определить свободные окна у самого пациента, медсестры и аппарата/кабинета. Данные операции естественно должно выполнять клиентское приложение и заботиться о целостности данных тоже должно приложение, для этого существуют инструменты - транзакции и блокировки. Общий вид я вам привел График_процедур(id, course_id, proc_id, sister_id, datetime_from, datetime_to, order - опционально, ...), для удобства можно выделить в отдельный атрибут день, также здесь должен быть кабинет/аппарат. ( Типы_лечения_Типы_процедур(id, cure_id, proc_id, order, ...) является просто шаблоном для заполнения графика, в котором указаны процедуры и их последовательность, сверять реальный график и шаблон также должно клиентское приложение. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 13:04 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
17-77 да и нет жесткой привязки к мед сестре. там у них правило - кто ставил капельницу, тот и отвечает за пациента, но снять может другая медсестра Именно так. Поставил капельницу, зафиксировал в журнале (Процедуры_лечения); снял капельницу, зафиксировал в журнале. Это могут быть разные медсестры. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 13:46 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
graycode нужно по этому же графику определить свободные окна у самого пациента, медсестры и аппарата/кабинета. В этом нет необходимости, т.к. врачей, медсестер, кабинетов и оборудования достаточно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 13:49 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
graycode сверять реальный график и шаблон также должно клиентское приложение. Спасибо за совет. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 13:53 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin Именно так. Поставил капельницу, зафиксировал в журнале (Процедуры_лечения); снял капельницу, зафиксировал в журнале. Это могут быть разные медсестры. Фактическое исполнение назначенного лечения лучше убрать в детейл таблицу, Процедуры_лечения содержит статус - запланировано, успешно, отменено, с замечаниями, добавить пару полей фактическое время начала и окончания, а строки журнала исполнения процедуры убрать в подчиненную таблицу Процедуры_лечения_исполнение, в которой будут строки содержащие например: лаборантка приготовила препараты, дата-время, замечания; одна медсестра поставила аппликацию препаратов, дата-время, замечания; другая медсестра сняла аппликация и выполнила необходимые постпроцедурные операции, дата-время, замечания. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 14:30 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin Меня интересует, можно ли (нужно ли) ловить ошибку назначения неправильной процедуры средствами БД или лучше передать эту ответственность клиентскому приложению. в вашей схеме данных эта миссия не выполнима с любой стороны, лечение назначается конкретному пациенту после установления ему диагноза (диагнозов) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 14:36 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
graycodeа строки журнала исполнения процедуры убрать в подчиненную таблицу Процедуры_лечения_исполнение, в которой будут строки содержащие например: лаборантка приготовила препараты, дата-время, замечания; одна медсестра поставила аппликацию препаратов, дата-время, замечания; другая медсестра сняла аппликация и выполнила необходимые постпроцедурные операции, дата-время, замечания. Так и строки журнала назначений лучше убрать туда же: врач назначил курс, дата-время, замечания; врач отменил курс, дата-время, замечания; врач признал курс успешно завершённым, дата-время, замечания. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 14:48 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
vmag лечение назначается конкретному пациенту после установления ему диагноза (диагнозов) Речь - не о медицинской стороне дела, а о технической. Врач назначил лечение, медсестра после назначения применила схожую по названию, но ошибочную процедуру, в том числе из-за (возможно) неправильной схемы БД. Текущая схема позволяет допустить такую ошибку: выбранная медсестрой процедура не соответствует ни одной процедуре, которая должна быть у данного типа лечения; дочерняя запись (Процедуры_лечения) противоречит записи из родительской таблицы (Лечение) в части типа процедуры. Я пытаюсь понять и найти решение внутри базы данных (check, foreign keys, trigger, stored procedures). Если нет, тогда вынесу такую логику в клиентское приложение. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 14:50 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
Я бы ещё предложил автору другой взгляд на проектирование. Завести таблицу " команды лечащего врача", а все остальное будет просто материализацией этих команд во времени. Это очень похоже на CQRS, но мой поинт в том чтобы не распыляться в мелочах а увидеть главное. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 14:56 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputinмедсестра после назначения применила схожую по названию, но ошибочную процедуру Это неизбежно и никакая схема БД не может этому помешать. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 14:58 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Так и строки журнала назначений лучше убрать туда же: врач назначил курс, дата-время, замечания; врач отменил курс, дата-время, замечания; врач признал курс успешно завершённым, дата-время, замечания. Согласен, правда наверное не туда же, а в самостоятельную таблицу. И как мне думается логика должна быть примерно следующая, врач назначил лечение, например капельницу три раза в день в определенные периоды времени, либо сам врач либо ответственный (старшая медсестра или какой то другой сотрудник отвечающий за ведение графика) должен расписать лечение в конкретный план - График_процедур, далее медперсонал руководствуется графиком, на сегодня такие то процедуры, таким то пациентам, в такое то время. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 15:04 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov aliputinмедсестра после назначения применила схожую по названию, но ошибочную процедуру Это неизбежно и никакая схема БД не может этому помешать. Медсестра использует планшет или другой гаджет, подключенный к БД. Если БД запретит выбор процедур, не относящихся к родительской записи в Лечении, тогда вероятность ошибки значительно снижается. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 15:07 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputin Медсестра использует планшет или другой гаджет, подключенный к БД. Если БД запретит выбор процедур, не относящихся к родительской записи в Лечении, тогда вероятность ошибки значительно снижается. Медсестра на планшете должна видеть график (или план лечения), в котором указана конкретная процедура, она ее не выбирает она тыкает в уже указанную процедуру, там можно сделать подсказку для сестры с купленным дипломом что представляет собой данная процедура. Имплементация лечения ответственным лицом в план должна происходить в режиме сверки с Типы_лечения_Типы_процедур, которую заполнил доктор и здесь жесткую проверку может осуществлять приложение. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 15:13 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
aliputinМедсестра использует планшет или другой гаджет, подключенный к БД. Если БД запретит выбор процедур, не относящихся к родительской записи в Лечении, тогда вероятность ошибки значительно снижается. Не снижается. Сестра посмотрела название процедуры, сестра пошла провести процедуру, сестра ввела данные о проведённой процедуре. Вариант 1: Была проведена правильная процедура, данные введены неправильно. Вариант 2: Была проведена неправильная процедура, данные введены о правильной. Вариант 3: Была проведена неправильная процедура, данные введены неправильно. Твоя БД сможет обработать вариант 1, но при варианте 3 она вынудит сестру пойти на преступление и использовать вариант 2. Это плохая, преступная БД. У современных компьютеров недостаточно средств взаимодействия с окружающим миром. В идеале твоё приложение должно подключиться к камере наблюдения в процедурной, опознать проводимую процедуру и остановить сестру, если та начала отклоняться от плана. Сможешь? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 15:18 |
|
Как улучшить эту схему БД?
|
|||
---|---|---|---|
#18+
graycode в котором указана конкретная процедура, она ее не выбирает она тыкает в уже указанную процедуру Именно это я пытаюсь продумать. Возможно, через хранимую процедуру: хранимка видит последнюю проведенную процедуру; знает по справочной таблице, какая процедура должна быть следующей; и создает запись в дочерней таблице Процедуры_лечения, указав правильную следующую процедуру. Медсестра видит нужную одну процедуру и выполняет ее. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2020, 15:20 |
|
|
start [/forum/topic.php?fid=32&fpage=3&tid=1539835]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
14ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 318ms |
total: | 449ms |
0 / 0 |