Подойдут ли web-технологии для нагруженной медицинской системы?

Question

[Arman]

Есть приличная медицинская система с несколькими медцентрами, огромное кол-во записей каждый день и подозреваю около 1-2к онлайн.
Сейчас кажется используют нативное приложение (windows?) с Oracle Database (?).

Жалобы: система устарела, сложная, лагает и толком не маштабируется.

Хотят: поднять некое онлайн приложение (интранет), которое постепенно полностью заменит текущее решение.

Проблемные места: Запись на прием (регистратура) - скорость поиска пациента и записи в очередь, записи в карточках пациента - цена ошибки велика, формирование отчетов - скорость, большое кол-во данных

Может у кого был опыт с подобным или со схожей задачей? Какие-то советы? может такое вообще не формат?

Пока план: ларавел, постгрес, sphinx/elastic

Гугл как-то в другую степь посылает...

Comments

[Антон Р.]

Мне кажется тут должно быть что-то более сложное чем просто "веб-проект". Смесь десктопных клиентов, серверов и интранета, одним php тут не обойдешься (работать только через браузер?).

[Melkij]

Большое количество данных - это сколько в террабайтах?

[Сергей Сергей]

Гугл пытается отговорить пихать веб в медицину.

[Arman]

Антон Р., вот и у меня такое подозрение и хочется отговорить вовремя)

[Иван Шумов]

Сергей Сергей, HIPAA не согласны)

[Антон Р.]

Arman, тут надо очень подробно расписать все пожелания, технические возможности и еще пару сотен факторов, это точно за пол часа не решается.

[Сергей Сергей]

Иван Шумов, ну то там, а тут здесь.

Не, я лично не против веба как такового, просто медицинская информационная система не должна базироваться на вебе.
Банально, у нас (в России) ведь ещё много бумаги требуется, и здесь лучше через файлики или прямой доступ к принтеру (матричному, ленточному) печатать.
Потом всякие ключи безопасности и подписи к документам (для главврачей и ответственных за склад) — через плагины к браузеру делать? Туда же контроль доступа в помещения прилепить, обязательно с адаптивным интерфейсом.

Веб может и не понадобиться вовсе, когда Госуслуги©®™ возьмут на себя функцию записи пациентов, единственно важную для внешнего мира.

Но, опять же, если тех-задание будет натягиваться на веб, то ладно.

[Иван Шумов]

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

[Сергей Сергей]

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

А распечатку талона с компьютера может запустить посетитель, просунувшись в окошко.

Answer 1

[Максим Шевченко]

Несомненно подойдут

У некоторых сайтов посещаемость и онлайн за 100 тысяч переваливают. Все зависит от хостинга и разработчика приложения.

Comments

[Arman]

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

[Максим Шевченко]

Если у вас система для внутреннего использования, без выхода в сеть, то её кто ломать будет. Запустите её на сервере в учреждении и она вытянет все. Если же все через сеть идет, то тоже можно защитить. Я не профи по взлому и защите веб ресурсов, однако они такие же защищенные как любые другие. Взломать и поломать можно все. Просто обращайтесь к профи которые и гарантию дадут и в контракте пропиши условия безопасности. Да такое будет не дешево, я бы сказал дорого. Однако вам нужен качественный продукт.

[Сергей Егоров]

MarsianinM,

Просто обращайтесь к профи которые и гарантию дадут и в контракте пропиши условия безопасности

И где их найти таких профи?

[Максим Шевченко]

Сергей Егоров, Ну где то же есть.

[Сергей Егоров]

MarsianinM,

Ну где то же есть.

Эххх... знать бы еще где...

Answer 2

[Иван Шумов]

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

Comments

[Arman]

не уверен что общая БД между медцентрами, подозреваю в каждом стоит свой сервак локально

[Иван Шумов]

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

[Arman]

Иван Шумов,

все у вас вообще плохо с сервисом

с этим все согласны и с этой проблемой и пришли)
если не ошибаюсь, то там чтоб работать с другим медцентром запускают это приложение отдельно чуть ли не в тимвивере‍

[Иван Шумов]

Arman, ну вот и пришли мы к выводу что как минимум надо все выносить на единый внешний сервер. Это ещё и дешевле же получится. Обратная сторона в том что надо в клиниках будет ставить резервный канал интернета (не обязательно чтобы мощный, но всё-таки чтоб работал)

[Иван Шумов]

Arman, в общем, надо что спроектировать - пиши, обмозгуем

[Сергей Егоров]

...в общем архитектурных вопросов больше чем самой работы напрогать...

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

[Иван Шумов]

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

[Сергей Егоров]

Иван Шумов,

...продумать архитектуру до мелочей это большой и объемный процесс...

Это методология разработки 80-ых годов. Не очень дешевая... я бы даже сказал очень недешевая... и с очень негарантированным результатом...

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

[Иван Шумов]

Сергей Егоров, этот виток сейчас возвращается, просто его научились готовить, появились всякие MVP, agile, поэтапная разработка и всякие вещи вроде 10000ft architecture landscape. И занимается этим архитектор. Если нужен качественный продукт не для гаража или дворника то программистам такие вопросы доверять нельзя. Даже многим сеньорам нельзя, увы

[Сергей Егоров]

Иван Шумов, ух ты! А кто такой архитектор? Он откуда берется? Я правильно понимаю что это такой специально выращенный гриб, который никогда не программировал, но при этом способен спроектировать внутренности программного продукта?

[Сергей Егоров]

Иван Шумов, MVP и agile как раз не подразумевают исчерпывающего проектирования всего и вся...

[Иван Шумов]

Сергей Егоров, нет, неправильно. Он вырастает в определенных условиях. Чаще всего бывший программист, появившийся в условиях недостатка ресурсов компании или под присмотром других архитекторов) но да, этот человек, который рассматривает программирования как один из многих инструментов, но не ставит его во главу угла.

[Сергей Егоров]

Иван Шумов,

...рассматривает программирования как один из многих инструментов, но не ставит его во главу угла...

А как он проектирует программную систему? Как без программирования спроектировать программный продукт?

[Иван Шумов]

Сергей Егоров, прекрасно можно. Язык наносит не такое большое число ограничений про проектирование идет на уровне интерфейсов взаимодействия и типа трафика. И то и другое довольно абстрактная вещь. Вообще ты не думаешь же что эту тему можно раскрыть даже за полчаса?)

[Сергей Егоров]

Иван Шумов,

Вообще ты не думаешь же что эту тему можно раскрыть даже за полчаса?

Да я не тороплюсь никуда. Мне всего то на один вопрос хочется ответа. Как спроектировать объемный, корпоративный программный продукт без программирования?

...Язык наносит не такое большое число ограничений...

Язык привносит хренову тучу ограничений на использование возможных шаблонов проектирования. Если к примеру программировать на `Javascript`, и пытаться использовать шаблоны GoF, то поимеешь много боли...

[Иван Шумов]

Сергей Егоров, если хочешь можем созвониться вечером и я тебе постараюсь донести)

[Сергей Егоров]

Иван Шумов, нет, не хочу. Я предпочитаю печатный текст. Он удобен и дешев с точки зрения хранения, индексации и поиска...

[Иван Шумов]

Сергей Егоров, твое право) но излагать такие темы в печатном виде надо на Хабре)

Answer 3

[Adamos]

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

Answer 4

[Сергей Егоров]

Подойдут веб технологии.

Comments

[Антон Р.]

Ок, есть кабинет доктора у которого на ПК программа в которой все истории болезней, графики записи пациентов + связь с руководством + заявки на закупку материалов + еще 100500 задач и всё это крутится онлайн с общим сервером.
Сайт на php подойдет?

[Сергей Егоров]

Антон Р., а в чем противоречие? Какая вообще разница на каком языке программирования написан бэкенд?

[Антон Р.]

Сергей Егоров, а потом сшивать это с десктопным приложением, сайтом, приложением для смартфонов и планшетов? Мне кажется здесь надо что-то более универсальное.

[Сергей Егоров]

Антон Р., зачем сшивать с десктопным приложением и смартфонами и планшетами? Кто просил сшивать?

[Adamos]

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

Answer 5

[Сергей Горностаев]

Web-технологии тоже разные бывают. Знаю как минимум пару крупных медицинских учреждений в Иркутске, использующих web-технологии на базе Java EE.

Comments

[Сергей Егоров]

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

[Сергей Горностаев]

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

[Сергей Егоров]

Сергей Горностаев, а что именно в продукте, написанном на PHP дает в долгосрочной перспективе такое жуткое удорожание эксплуатации?

[Сергей Горностаев]

Сергей Егоров, отсутствие статической типизации как минимум.

[Сергей Егоров]

Сергей Горностаев, как наличие или отсутствие статической типизации влияет на снижение стоимости эксплуатации?

[Сергей Горностаев]

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

Кроме того, как сам язык Java, так и каждый стандарт, входящий в Java EE, были разработаны с учётом многолетнего опыта разработки и эксплуатации высококритичных для бизнеса систем в огромных корпорациях, типа IBM. Никакой другой язык, кроме C++ разве что, и никакая другая платформа не прошли такой закалки.

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

Не спроста вся финансовая отрасль, включающая банки, страховые компании, биржи и т.п., используют именно Java.

[Сергей Егоров]

Сергей Горностаев, ну то есть если мы возьмем двух одинаковых джуниоров и один напишет код на Java, а второй на Pyhon, то это гарантирует нам что код на Java будет в разы дешевле в эксплуатации, только за счет одной статической типизации?

[Сергей Горностаев]

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

[Сергей Егоров]

Сергей Горностаев, хм... а если неправильная программа Java джуниора соберется? И будет работать несколько месяцев, прежде чем мы заметим что она портит каждую тысячную транзакцию?

[Сергей Горностаев]

Сергей Егоров, шанс этого существенно ниже со статической типизацией и развитой системой типов.

[Максим Федоров]

Сергей Егоров, хочу отметить, что хоть PHP и динамической типизации, но последние версии поддерживают режим строгой типизации, последние 2 месьа работы -- требование строгой типизации обязательные... Да, по сравнкнию с Java все проще, но уже нет тех проблем.... (уже несколько лет)

Правда по стоимости он уже не так уж и дешевле, хотя в скорости разработки все еще сильно выигрывает

Это уже очень взрослый язык и очень популярный, на рынке много (очень) квалифицированных инженеров

[Сергей Егоров]

Максим Федоров, да я же не возражаю... никакие языковые средства не гарантируют чистой и изменяемой архитектуры... можно на Java написать так, что и работать не будет и исправить нельзя будет, а можно на PHP написать красиво и эффективно.

[DevMan]

Максим Федоров,

последние версии поддерживают режим строгой типизации

весьма условно в сравнении с изначально строгими языками.