С ручной корректировкой все забьют на это :( Тут надо что то что переносит опыт одной «истории болезни»-«операции» на другой случай по возможности автоматически.

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

Иначе зачем мониторить кучу всего этого автоматом? Если просто учет унд контроль, то пос-терминалов ресторанных на постах и ординаторских хватит.

С ручной корректировкой все забьют на это :(

Не, не забьют, эта ручная корректировка злобно включена в форму сдачи/приема дежурства. Так что как в том анекдоте - добровольно и с песней.

Тут надо что то что переносит опыт одной «истории болезни»-«операции» на другой случай по возможности автоматически.

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

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

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

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

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

Я же писал, что паузы в пару секунд не критичны, а на большее время gc систему не поставит колом. Про большое количество данных - думал. Оттуда и архитектура с очередью взялась.

Ну и да, вопрос на засыпку, тебе не стремно доверяться реанимации, когда одна сестра на все отделение и по писку прикроватного монитора она банально несколько минут будет идти до тебя? Или лечь на операцию, когда анестезиолог на параметры аппаратов дай бог раз в 5 минут лениво глянет?

Насколько оправдано использование именно кафки, а не другого MQ в данном случае - фиг знает

Ну в таком случае я бы порекомендовал просто снять показания по загрузке за день, посмотреть пиковые и на них погонять варианты. Писать напрямую в БД конечно можно, я даже думаю, что на таком объёме может вполне хватить вебсервиса с прямой заливкой в БД, но я бы всё равно держал в загашнике возможность поставить посередине жмс. Хотя при правильном подходе клиент подмены всё равно не заметит, какая ему разница кто сидит за сервисом.

Конечно стремно, но ты правильно сделал, что поставил эти две стороны одного вопроса в ряд ;)

Так в том-то и дело, что гц зависит от количества _живых_ объектов, а в описанной системе параметров, а следовательно - и объектов - чуть менее чем дохрена, по-моему. Если пруф концепта работает - пусть себе работает, плтесть его нащот нагрузок да и все.

Причем желательно не по одной больнице.

скорее по одной, в каждом монастыре свои порядки. несколько больниц больше для науки нужны, что бы отделить фактор «больница и её порядки» от «объективной реальности».

монга плоха отсутствием транзакций. нельзя атомарно изменить два документа. в последней версии говорят какие-то транзакции появились?

Ну, в принципе довольно давно можно было вот это использовать http://www.tokutek.com/tokumx-for-mongodb/

Хотя вроде в третьей из коробки добавили $isolated. Если честно, я пока не особо разбирался.

скорее по одной, в каждом монастыре свои порядки. несколько больниц больше для науки нужны, что бы отделить фактор «больница и её порядки» от «объективной реальности».

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

Решение о внедрении системы принимает не врач. А начальство врача. От врача могут зависеть только цвет кнопки и шрифты в окошке. Да и то не факт.
Дальше. Система, которую пишет ТС - это не банальный хеллоуворд ниачом, это серьёзная система, от которой может зависеть исход лечения. Следовательно, приёмка в эксплуатацию должна происходить соответственно ГОСТам, как минимум. С комиссией, актами по приёмке etc
А что такое комиссия? Это группа профильных специалистов, представителей заказчика, исполнителя и лицо, ставящее подпись последним и берущее всю ответственность на себя. Но и это лицо не бывает самодостаточным, за ним стоят отдельные люди, чьи выводы влияют на решение ставить подпись или нет.
С учётом того, что с ответственностью у нас дело обстоит плохо, все стремятся с себя эту ответственность снять, произошло саморазрушение отраслевых экспертных групп.
Кстати, это невосполнимая потеря по целому ряду направлений.
В том числе ещё и потому, что экспертам нужно платить. А у нас ведь как, там где начинают мельтешить какие-то мало-мальски денежки, сразу вырисовываются полчища экспертов =)
Предположим, я выбился в начальники. И передо мной встала проблема принять в эксплуатацию нечто, в чём я не совсем разбираюсь, но за что отвечаю в рамках своих обязанностей. Естественно, если за мной нет людей, чьи выводы для меня были бы абсолютными, я из чувства самосохранения буду стремиться всячески снизить свою меру ответственности.
Поэтому такие комиссии обычно состоят из групп каких-то начальников.
Ты много видел начальников, хорошо разбирающихся в широком спектре вопросов? Лично я - от силы двоих-троих. Как следствие - решения таких комиссий в большинстве случаев осторожно-половинчатые.
Дальше. По причине обилия нечётких связей медицина в числе прочих слабо поддаётся глобальной автоматизации. Как в масштабах отрасли, так и на уровне предприятия. Автоматизировать можно что-то типа регистратур, каких-то функций по учёту.
Дальше. Какие-то решения по комплексной автоматизации медучреждений существуют, но они дорогие и потребуют изменений гораздо больших, нежели простая установка ПО, и автоматизируются только такие, у которых есть для этого ресурсы. Поэтому медучреждениям сказали: «Братцы,решайте свои вопросы исходя из ваших возможностей». Чем они и занимаются, нанимая за 3 рубля конторки и шабашников.
Это я так подробно не в защиту ТС, а чтобы показать масштаб трагедии. ТС зарабатывает тем ремеслом, каким владеет и решает задачу так, как она поставлена.

И, да, с тех пор как врачи стали оценивать пациента по состоянию его кошелька, смысл доверять медицине практически теряется. Хороший врач и без систем всё определит. Но сколько их осталось? Один на миллион? Сегодня врачи, даже хорошие, - это участники бюрократической гонки на выживание. Им тоже нужно кушать, оплачивать ЖКХ, одеваться и давать образование детям.

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

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

По причине обилия нечётких связей медицина в числе прочих слабо поддаётся глобальной автоматизации. Как в масштабах отрасли, так и на уровне предприятия. Автоматизировать можно что-то типа регистратур, каких-то функций по учёту.

Поддерживаю. В остальных случаях автоматизацию делать чревато.

Централизованная, экстенсивная структура.

Это понятно. Я старался не залезать в дебри.

это обычная доказательная медицина вроде как...

тут просто понимаешь в чем дело --- все формулы очень просты, но что в каждом случае знать куда подставлять в эту формулу (ну и критерий выбора формулы) нужен целый ибмватсонТМ :)

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

ну а так, логинг это просто куча сообщений и ничего больше. их можно просто в лог писать. всё интересное начинается когда эти сообщения начинают дополнять друг друга и априорно заданные сведения. именно поэтому нормальный подход jena + sesame и т.д.

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

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

Задача поставлена как поставлена. Есть данные от устройств, есть действия, выполняемые мед персоналом. Надо свести это воедино и выстроить это в некоторое количество вариантов отображения: динамика за последние N минут, статика за период, где видно какие действия какие сдвиги в показателях вызвали, некоторое количество отчетов для снижения бюрократической нагрузки на врачей.

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

тут просто понимаешь в чем дело --- все формулы очень просты, но что в каждом случае знать куда подставлять в эту формулу (ну и критерий выбора формулы) нужен целый ибмватсонТМ :)

Угу, примерно в курсе.

ну а так, логинг это просто куча сообщений и ничего больше. их можно просто в лог писать. всё интересное начинается когда эти сообщения начинают дополнять друг друга и априорно заданные сведения. именно поэтому нормальный подход jena + sesame и т.д.

Насчет jena & sesane спасибо, постараюсь поковырять их. Но еще раз повторяю - пока что задача сформулирована гораздо проще.

Медицина советского типа (система Семашко) — это вообще удивительный пример бюрократической организации труда. Централизованная, экстенсивная структура. А автоматизация таких систем выливается в оцифровку бюрократии.

Ну да, вопрос только в том, что с этим делать. Можно разогнать конечно к черту весь минздрав и подождать лет 100 пока сформируется нормальный рынок частных страховых компаний и клиник. Только вот сколько народу за этот период перемрет?

Да я понимаю. Это я не тебе отвечал, а другому товарищу. Позднее набросаю свои мысли по теме, пока занят. Если не против.

Позднее набросаю свои мысли по теме, пока занят. Если не против.

Да, спасибо, буду рад любым мыслям по теме. Ради этого топик и создавал собственно ;)

прочел не все комменты и буду дофига цитировать

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

Пример события 1 - пришли от прибора данные по текущему давлению

это называется ЛИС

Пример события 2 - пациенту поставили капельницу

это уже МИС

отметить использование расходников

это уже складская программа (модуль)

возможно что в дальнейшем - приложения под андроид/иос/винду

это может не пройти по 152-ФЗ
1) я не понял почему вы решили не следовать практике, а объединить две совершенно разные информационные системы в одну 2) я совершенно не понял зачем вам NoSQL
допустим среднестатистическая лаборатория делает около 1к тестов в день, скажем это 200-500 исследований
вопрос - сколько json будет через два года в монге и как она с этим справится? а если лабораторий 6-7?
где-то в комментариях было о приборах которые шлют данные потоком в течении нескольких часов (может плохо прочел) - это удобно хранить в nosql?

некоторые из которых надо просто сохранить в базе и показать на клиенте, а некоторые из которых приводят к куче пересчетов текущих показателей

зачем пересчитывать текущие показатели?
у нас есть результат (с прибора/вбит вручную), пришел второй результат который рассчитывается из первого - рассчитали сохранили.
я незнаком со спецификой (хирургов, анестезиологов, реаниматологов) но скажем в лабораториях самые страшные расчеты только в микробиологии (с экспертной системой) и серологии. и главное как эти расчеты ложатся на монгу?
если я например знаю что тест с id 1234 нужно умножить на тест id 4321 и показать только второй, как это в json выглядит?

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

мелкие вопросы:
3) как вы в веб интерфейсе будете печатать штрихкоды к пробиркам?
4) как вы будете обрабатывать ситуации, когда в больнице уже стоит ЛИС, и регистрация заявок полным ходом? обмен с ней? возьмете на себя задачу МИС? нафига тогда драйверы к приборам?
5) как вы собираетесь проводить учет предоставленных услуг и отправлять его например в ППО ОМС?
6) учет реагентов? по сути он сейчас не нужен, достаточно предоставлять список выполненных исследований (включая те, что были повторно+контроли)

о! оказывается тут всё можно пилить по шаблону, профессионально :)

не уверен что это сарказм, да я считаю что лучше пилить в рамках уже принятых практик.
придумывать свои методики - только делу вредить.
те ЛПУ что уже работали с информационными системами не должны перестраивать стандартные процессы лишь потому, что с наших налогов купили новый софт. те же, что вообще компутеры ближе трёх метров не видели, им вообще без разницы - лишь бы поставщик подстроился
это правда мало относится к вопросу ТС «На чем и как вы бы делали систему?»
тут правильный ответ один - Cache+Java, но дорого. я не хочу свои налоги тратить на такое, когда SQL+Java/.NET на 1000% дешевле и работают не хуже.
скатил бы дискуссию в сторону именно процессов, а не софта, т.к. софта очень много и половины желаю никому не видеть - будут кошмары по ночам беспокоить и всем пофиг. в этом году мед персонал стерпит любые издевательства, главное чтоб не уволили.

Как говорил мой профессор «Если автоматизировать бардак - ничего, кроме автоматизированного бардака, не получится по определению».(С) Нестандартный KDE (комментарий)

Ох, попытаюсь ответить более-менее по пунктам, но ИМХО ты слишком зациклился на ЛИСе. Там своя специфика и он по отношению к нашей системе является внешней.

Пример события 1 - пришли от прибора данные по текущему давлению

это называется ЛИС

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

Пример события 2 - пациенту поставили капельницу

это уже МИС

В существующих МИС можно отметить факт назначения. Но например ни одна из знакомых мне не умеет по факту этого назначения (а так же куче других) раз в минуту (или чаще или реже - без разницы) автоматом пересчитывать баланс жидкости и выводить его врачу на экран. А при операциях это часто необходимо.

это может не пройти по 152-ФЗ

А может и пройти ;)

1) я не понял почему вы решили не следовать практике, а объединить две совершенно разные информационные системы в одну

Потому что это не ЛИС (функции другие) и не МИС (это ее очень специфический кусок для узкого круга процессов)

2) я совершенно не понял зачем вам NoSQL

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

допустим среднестатистическая лаборатория делает около 1к тестов в день, скажем это 200-500 исследований

У меня 1000 сообщений прилетает примерно секунд за 5 и это не пиковая нагрузка.

где-то в комментариях было о приборах которые шлют данные потоком в течении нескольких часов (может плохо прочел) - это удобно хранить в nosql?

Да, удобнее чем в реляционке. Проблема в том что я пока не вижу смысла разносить данные с приборов и все остальное по разным базам. А вот с тем самым всем остальным - проще работать с рсубд.

зачем пересчитывать текущие показатели?

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

но скажем в лабораториях самые страшные расчеты только в микробиологии (с экспертной системой) и серологии. и главное как эти расчеты ложатся на монгу?

Я с лабораторными системами последний раз работал году в 2007-2008, т.е. уже не помню что и как считается в микробиологии, но скорее всего ложатся. Вопрос в удобстве.

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

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

3) как вы в веб интерфейсе будете печатать штрихкоды к пробиркам?

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

4) как вы будете обрабатывать ситуации, когда в больнице уже стоит ЛИС, и регистрация заявок полным ходом? обмен с ней? возьмете на себя задачу МИС? нафига тогда драйверы к приборам?

В больнице и должна стоять ЛИС. Наша система - это совсем не про лаборатории. Взаимодействие с ней - на уровне интеграции. На вход дается спец. заявка для экспресс лаборатории со списком исследований/тестов. Лабораторка нам потом скидывает результаты. Как уж это будет осуществляться в каждом конкретном случае - от системы зависит.

И еще раз - система не лабораторная, приборы к ней подключены совершенно другие: прикроватные мониторы, инфузоматы, аппараты ИВЛ итд.

5) как вы собираетесь проводить учет предоставленных услуг и отправлять его например в ППО ОМС?

Зависит от конкретного внедрения и того, что уже есть у клиента. Но вообще предусмотрена интеграция с историей болезни.

6) учет реагентов? по сути он сейчас не нужен, достаточно предоставлять список выполненных исследований (включая те, что были повторно+контроли)

Ну, как наверное уже понятно - у нас нет реагентов. И нет лаборатории ;) Расходники - в принципе могут быть привязаны к определенным событиям системы (т.е. по возникновению производится списание с условного минисклада).

но есть же скорее всего готовый модуль в 1C? наверное типа «поликлиника», «больница»... о нашел! «медицина» :)

почему вы навязываете не стандарт? :)

тред не читал.

одно слово: dwh. есть готовые решения от microsoft, oracle, ibm и других, в которых надо реализовать только свою бизнес-логику: «просто сохранить в базе и показать на клиенте», «приводят к куче пересчетов текущих показателей процесса»...

или смысл именно повелосипедить?

Итак, рассказываю про свои бодания. Не совсем твой случай, но надеюсь, что будет полезно. Однажды мне поставили задачу выпилить некую систему сбора и обработки информации. Вкратце: это должно было выглядеть как нечто, куда вводится информация из бумажного носителя, систематизируется и хранится до запроса заказчиком-потребителем информации. Задача была поставлена очень общо, без сроков. Вскользь было озвучено что-то по типу разработки под Эксель или создание дополнительной БД в существующих на тот момент информационных системах.
Жутко не люблю формализм, поэтому идею насчёт Экселя отмёл сразу. Да и озвучивалась она человеком, весьма далёким от темы. Делать в Экселе — это значит заранее обрекать продукт на скорую гибель. Эксель не обеспечит гибкость.
Вклиниться в существующие базы данных не позволяли полномочия, поэтому проектировать всю концепцию стал с нуля.
В качестве СУБД выбрал Постгрес.
Первое, что выдумал от начала и до конца, был тот самый носитель-анкета, с которого впоследствии должна была вводиться инфа. То есть очертил круг информации, которая должна вводиться в систему для её эффективного функционирования согласно задаче. В процессе размышления выяснилось, что система должна быть многопользовательской, с детализацией пользовательских функций, с гибкой подсистемой генерации отчётов, в том числе в графическом виде, с ведением архивов.
В общем, проект достаточно быстро распух.
Начал реализацию на Си. Эффективность и скорость разработки на Си были низкими, поэтому пришлось сесть и выучить эту вашу Джаву.
После реализации основных функций я её протестировал и определил критичные места.
1. Недостаточная детализация входных параметров.
2. Необходимость внедрения дополнительной логики для проверки целостности и адекватности введённых данных.
3. Необходимость внедрения дополнительных систем защиты информации и от оч.умелых действий пользователя.

это уже почти «тонко» :)

Увы, но это быль.