← На главную

При автоматизации медицинских учреждений часто возникает ситуация, когда приобретенный программный продукт 1С:Медицина. Больничные не оправдывает ожиданий в части масштабируемости. Рассмотрим подробнее, почему попытки установить эту конфигурацию на сервер или организовать работу нескольких врачей одновременно заканчиваются неудачей, и какие законные пути решения существуют для крупных организаций.

Лицензионные и технические ограничения базовой версии

Проанализируем правовой и технический статус продукта. Программный продукт 1С:Медицина. Больничные выпускается правообладателем исключительно в формате базовой версии. Это накладывает ряд жестких ограничений, которые невозможно обойти штатными средствами платформы 1С:Предприятие:

1. Однопользовательский режим: С одной информационной базой в конкретный момент времени может работать только один пользователь. Попытки организовать совместный доступ к файлу 1Cv8.1CD приведут к блокировкам или повреждению данных.
2. Запрет на клиент-сервер: Работа в варианте клиент-сервер (с использованием SQL-сервера) не поддерживается на программном уровне. Базовая лицензия попросту не увидит сервер 1С.
3. Невозможность расширения: Использование дополнительных клиентских лицензий для увеличения количества рабочих мест технически заблокировано.
4. Отсутствие возможности конфигурирования: Вы не можете вносить изменения в код, добавлять свои справочники или отчеты. Любая попытка снять конфигурацию с поддержки лишает программу лицензионного статуса.

Выясним причину такого позиционирования. Фирма 1С специально создала этот продукт как максимально дешевое решение (порядка 3000 рублей) для небольших медицинских кабинетов, где один сотрудник (например, старшая медсестра) централизованно выписывает листки нетрудоспособности.

Анализ ситуации: работа 150 врачей и более

Разберем ситуацию, когда в организации работают 150 врачей на нескольких объектах. Использование базовой версии в таких условиях превращается в «узкое горлышко». Если каждый врач должен самостоятельно подписывать ЭЛН своей электронной цифровой подписью (ЭЦП), использование одной базы становится невозможным. Рассмотрим, к чему это приведет:

Во-первых, врачам придется заходить в базу по очереди, что парализует работу при большом потоке пациентов. Во-вторых, возникает проблема с хранением и использованием личных сертификатов ЭЦП на одном рабочем месте. Проанализируем способы решения этой задачи.

Решение 1: Переход на полнофункциональные медицинские системы

Если ваша организация выросла из рамок «одного кабинета», единственным правильным решением с точки зрения методологии 1С является переход на многопользовательские конфигурации. Разберем основные варианты:

• 1С:Медицина. Поликлиника — включает в себя полноценный блок работы с листками нетрудоспособности, поддерживает работу в сети, клиент-серверный вариант и позволяет автоматизировать любое количество рабочих мест.
• 1С:Медицина. Больница — комплексное решение для стационаров, где блок ЛН интегрирован в общую цепочку лечебного процесса.

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

Решение 2: Использование бесплатного ПО от СФР (бывший ФСС)

Разберем альтернативный вариант, который часто выбирают системные администраторы для экономии бюджета. Социальный фонд России предоставляет бесплатное программное обеспечение для работы с ЭЛН.

Посмотрим на преимущества этого подхода:

1. Поддержка сетевого режима работы (база данных может располагаться на PostgreSQL).
2. Прямая интеграция с сервисами СФР для отправки и получения данных.
3. Бесплатность и легальность для любого количества рабочих мест.

Однако здесь кроется и минус: отсутствие интеграции с вашей текущей медицинской информационной системой (МИС). Данные о пациентах придется вводить вручную или настраивать сложные механизмы обмена через XML или прямые запросы к БД.

Решение 3: Собственная разработка в рамках текущей МИС

Проанализируем предложение о «заимствовании» кода из купленной базовой версии. С юридической точки зрения, использование фрагментов кода 1С:Медицина. Больничные в сторонних разработках является нарушением лицензионного соглашения. Право на использование предоставляется только для программы в целом.

Если у вас уже есть самописная МИС на платформе 1С:Предприятие (версии ПРОФ), правильным путем будет самостоятельная реализация функционала обмена с СФР. Для этого рекомендуем использовать Библиотеку стандартных подсистем (БСП) и специализированные модули обмена, которые 1С предоставляет для разработчиков. Рассмотрим шаги для реализации:

1. Изучение спецификаций обмена СЭДО (Система электронного документооборота) СФР.
2. Настройка криптографии на сервере или рабочих местах врачей.
3. Создание объектов Документ.ЭлектронныйЛистокНетрудоспособности в вашей системе.
4. Реализация HTTP-запросов к сервисам фонда для получения номеров ЛН и отправки заполненных форм.

Проблема консолидации данных и отчета 16-ВН

Выясним, почему работа в нескольких разрозненных базовых версиях — плохая идея. Главная проблема возникнет в конце отчетного периода, когда потребуется собрать отчет по форме 16-ВН. Базовая версия не умеет объединять данные из других информационных баз. Вам придется:

1. Выгружать данные из 150 баз в формат XML или Excel.
2. Создавать отдельную обработку для объединения этих данных.
3. Вручную устранять дубли и ошибки сопоставления.

Именно поэтому для организаций со штатом более 5-10 врачей использование базовой версии 1С:Медицина. Больничные экономически нецелесообразно из-за высоких трудозатрат на сопровождение и сбор отчетности.

Итоги и рекомендации

Мы проанализировали ситуацию и пришли к выводу, что ограничение «только файловая версия и один пользователь» — это не техническая ошибка, а архитектурное решение продукта. Если вам требуется автоматизация 150 рабочих мест, рассмотрите следующие шаги:

Шаг 1: Оцените бюджет. Если есть возможность, перейдите на 1С:Медицина. Поликлиника. Это закроет все вопросы с лицензированием и обеспечит бесшовную работу всех подразделений.

Шаг 2: Если бюджет ограничен, используйте АРМ от СФР. Это позволит врачам подписывать документы на своих местах, а системному администратору — хранить данные в единой базе PostgreSQL.

Шаг 3: Для разработчиков МИС наиболее перспективным является путь интеграции прямого взаимодействия с СЭДО СФР внутри основной программы, минуя использование промежуточных «базовых» конфигураций.

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