PicoMed Home page
PicoMed - All you needs for your clinic
Медицинская
информационная система
  ГЛАВНАЯ   |  О КОМПАНИИ   |  МЕДИЦИНСКАЯ ПРОГРАММА   |  ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ   |  ПОДДЕРЖКА   |   15-11-2019 00:49

Наши преимущества

Можно перечислять состав модулей программы и рассказывать, чем они лучше, но это есть у всех уважающих себя разработчиков.
Мы хотим обратить Ваше внимание на то, чем мы отличаемся от других.
1. Стоимость владения
Чаще всего, покупая программу, вы покупаете задешево кота в мешке – это называется «лицензия»
Потом вам, за значительно большие деньги этого кота достают из мешка – это называется «внедрение»,
Когда вы его увидите, скорее всего придется его перекрасить или украсить бантиком – это называется «доработки», и это самое дорогое – намного дороже самого кота.
И когда вы, наконец, станете счастливым обладателем любимого кота, вы поймете, что его надо кормить – и это называется «сопровождение».
Что получится в итоге – большой жирный ленивый кот, который много ест – все это – цена владения.

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

2. Процессный подход, гибкая настройка на бизнес процессы заказчика
В отличие от «функционального подхода» мы не автоматизируем АРМ Регистратуры, АРМ Кассы, АРМ Врача и т.д., чтобы потом не искать ответ на вопрос – «а что мы со всем этим будем делать?»

Мы подходим к автоматизации процессов – «источник» - «ресурс» - «метод» - «контроль» - «результат». В таком подходе задействованы сразу несколько АРМов и внедрятся он должен комплексно, целостно.

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

  • 4. Стабильная работа как в малых, так и в больших лечебных учреждениях;
    быстрая работа с большими объемами данных
    С малыми объемами данных и пользователей все программы работают хорошо. Проблемы начинаются, когда размер базы переползает через примерно 1 миллион записей (примерно 3 года работы клиники на 30 мест). Когда это случается, начинаются проблемы со «скоростью отклика» - это реакция программы на действие пользователя. И это очень раздражает, когда программа думает по 5-10 секунд на каждый твой шаг.

    Объяснение этому очень простое – при проектировании архитектуры базы ее можно оптимизировать под добавление новых данных или под чтение старых. В первом случае программа будет быстро добавлять новые записи но подтормаживать на отчетах, во втором случае отчеты будут быстрыми, а добавление данных тормозить. Создать архитектуру второго типа НАМОНОГО проще.

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

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

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

    При проектировании нашей системы мы строили модель оптимизированную на скорость отклика при большом количестве одновременно работающих пользователей (в несколько сотен).

    Проектная скорость отклика на поиске оперативных данных (расписание врача, карта пациента, услуга и т.п.) не должна быть более 500 мс (реально укладываемся в 0,3 секунды), а на добавление записи (кроме протокола) менее 100 мс (для протоколов – 500 мс) при базе данных в 20 миллионов записей и количестве одновременно работающих пользователей - 1000.

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


    ЗАО "Ингрус". 117342, г. Москва, ул. Введенского д.8, офис 1003 ИПК Тел/факс. (495) 660 3818 (многоканальный), E-mail: admin@picomed.ru
    Copyright © 1996-2019 ZAO Engrus, Moscow, Russia (ЗАО "Ингрус", Москва)