32
Также выполнено требование наличия операционной системы Windows Server 2003
Standart Edition, ведь сервер HP ProLiant SL165z G6 функционирует под
управлением именно этой операционной системы.
На рабочих местах сотрудников уже присутствует операционная система
Windows XP или Windows 7 под управлением которых работают используемые
сотрудниками приложения.
Требование наличия платформы «1С:Предприятие 8.3» также выполнено, так
как именно на этой платформе работает система «1С:Бухгалтерия 3.0».
Таким образом, для разработки системы учета предоставленных
медицинским учреждением услуг нет необходимости приобретать никакие
программные продукты и системы. Требуется лишь разработать прикладное
решение для платформы «1С:Предприятие 8.3».
1.4
Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному
обеспечению
Опишем входные и выходные документы проектируемой системы.
Как уже было сказано выше, система автоматизации лечебно-
диагностического учреждения делится на две подсистемы: работы с пациентами и
работы отдела материально-технического обеспечения.
Для первой подсистемы входными данными являются сведения о пациенте и
данные, о проводимых с ними лечебно-диагностических мероприятиях. Данные о
пациенте вносятся в систему на основании документов, предъявляемых пациентом.
Для контроля личности пациента предназначены документы удостоверения
личности. Данные документы унифицированы, а их всевозможные виды
перечислены в общероссийском классификаторе видов документов,
удостоверяющих личность. Кроме документа (документов) удостоверяющих
личность, для пациента вводятся данные страхового полиса. При этом виды
страхования и виды страховых полисов являются общероссийскими
классификаторами.
Данные о проводимых с пациентами мероприятиях, назначенном лечении,
поставленном диагнозе, реализованных ему препаратах, лекарствах, любых других
33
ТМЦ также являются входными данными системы. Ранее при использовании
бумажной системы документооборота эти данные вносились в медицинскую
амбулаторную карту пациента. В проектируемой системе, врач проводящий
лечение пациента, будет вносить все эти данные в базу данных системы через
форму документа «Посещение». Таким образом, входными данными для этого
документа являются объективные данные обследований, лабораторных
исследований, осмотров. Все эти данные стандартизированы внутренними
стандартами центра.
В случае оказания пациенту услуг ненадлежащего качества или реализации
ему ТМЦ, неудовлетворяющих пациента, в системе оформляется документ
«Претензия». Документ факт оказания услуг ненадлежащего качества, а также
возврат реализованных ТМЦ.
Выходными данными подсистемы работы с пациентами является журнал
документов работы с пациентами. Кроме того, по каждому пациенту можно
просмотреть электронную медицинскую карту, в которой будут отображены все
данные пациента и проведенных с ним лечебно-диагностических мероприятиях,
поставленные диагнозы, история болезни и проведенные лечения.
Выходными данными подсистемы работы с пациентами является также
отчет об оказанных услугах и реализованных препаратах и материалах. Отчет
позволит проанализировать номенклатуру оказываемых услуг и реализуемых ТМЦ
в различных разрезах, с наложением любых условий и их сочетаний, настройкой
состава выводимых данных и внешнего вида.
Вторая подсистема, фактически представляет из себя, подсистему
складского учета, характерную для любого предприятия. Деятельность отдела
материально-технического обеспечения учреждения мало отличается от работы
склада любого предприятия.
Входными документами подсистемы автоматизации учета материальных
ценностей являются, прежде всего, входящие документы, поступающие от
поставщиков. Формы некоторых из этих документов стандартизированы
законодательством РФ. Например, накладные на поступление материалов и
препаратов от поставщиков оформляются стандартными формами, например
Унифицированная форма Торг-12, утвержденная постановлением Госкомстата
34
России, или Типовая межотраслевая форма № 1-Т, утвержденная постановлением
Госкомстата России.
Все документы, поступающие в медицинское учреждение, движущиеся
внутри него и выходящие из учреждения преобразуются в электронный вид
системы учета. Любой документ отображается записью в базе данных с указанием
всех его параметров.
Кроме документов входными данными является условно-постоянная
информация по структуре учреждения, данные по пациентам, данные по
контрагентам и данные по номенклатуре услуг и материалов, используемых в
учреждении.
Вся эта входная информация в разрабатываемой системе должна храниться в
справочниках, наиболее подходящих для хранения условно-постоянной
информации. Подсистема ведения справочников должна позволять вести все
основные и дополнительные справочники системы, хранящие ее объектные данные
[2].
Система должна позволять вести данные о номенклатуре предоставляемых
услуг, а также хранящихся на складах препаратах и материалах, включая все
основные и дополнительные данные.
Для каждой записи справочника номенклатуры должен вестись список
единиц измерения, в которых может учитываться товар при складских операциях.
Одна из единиц измерения является базовой, а остальные – производные от нее.
Учет номенклатуры должен вестись в разрезе партий. Каждая партия должна
характеризоваться набором свойств. Состав свойств и их возможных значений не
известны на момент разработки системы и задаются конечным пользователем в
процессе ее эксплуатации. При любом движении номенклатуры должна быть
предоставлена возможность выбора ее партии. Остатки номенклатуры на складах
должны вестись также в разрезе партий.
Система должна давать возможность ведения цен на номенклатуру услуг и
ТМЦ в разрезе типов цен. Это касается как цен, по которым ТМЦ поступают от
поставщиков, так и учетных цен по которым ТМЦ хранятся на складах и числится
за подразделениями и сотрудниками. Заданная ответственным пользователем цена
35
должна автоматически подставляться во все документы движения ТМЦ, ведущие
суммовой учет ТМЦ.
Система должна давать возможность прикреплять к номенклатуре любое
количество внешних файлов, дополнительно характеризующих ТМЦ или услугу.
Это могут быть графические изображения, видеоматериалы, документы – файлы
любых форматы могут быть присоединены к номенклатуре, сохранены в
информационной базе и открыты из нее при помощи внешнего приложения,
связанного с данным типом файлов.
Система должна позволять вести данные о контрагентах - пациентах
учреждения включая все основные и дополнительные данные, которые могут
понадобиться в процессе эксплуатации системы. В этом же справочнике хранятся
данные о поставщиках ТМЦ.
Ведение контактных данных контрагентов должно представлять из себя
список контактов контрагентов с разделением по видам контактов (почта, телефон,
скайп и т.д.), а также по видам коннекта (телефония, электронная почта, средства
мгновенных сообщений).
Ведение свойств контрагентов, дополнительно характеризующих
контрагента, значения которых неизвестны на момент разработки конфигурации,
но которые могут участвовать в отборе списка контрагентов, заданий условий и
группировок отчетов также является задачей подсистемы ведения справочников.
Ведение договоров контрагентов, главное назначение которых –
автоматическое образование цен на товары в документах поступления ТМЦ от
поставщиков, а также в документах оказания услуг и реализации товаров
пациентам.
Ведение банковских счетов (и банков) контрагентов для автоматического
заполнения соответствующих реквизитов в документах работы с поставщиками.
Система должна давать возможность вести список внешних файлов
контрагентов, дополнительно характеризующих контрагента. Это могут быть
графические изображения, видеоматериалы, документы – файлы любых форматы
могут быть присоединены к контрагенту, сохранены в информационной базе и
открыты из нее при помощи внешнего приложения, связанного с данным типом
файлов.
36
Система должна позволять вести данные, связанные с собственной
организацией.
Учет должен вестись в разрезе нескольких организаций, если у конченого
пользователя системы есть такая необходимость. Во всех документах учета должна
быть предусмотрена возможность выбора организации, от имени которой
оформляется хозяйственная операция. Регистры учета также должны быть
построены в разрезе организаций.
Должен вестись список сотрудников. Сотрудники характеризуются
должностью и принадлежностью к подразделению, список которых также должен
вестись системой.
Система должна вести список складов – мест хранения номенклатуры ТМЦ.
Склад также выступает разрезом учета остатков и движения ТМЦ в том случае,
когда ТМЦ хранятся на складах, а не выданы в подразделения или сотрудникам.
Подсистема учета движений ТМЦ должна позволять вводить документы
перемещения ТМЦ внутри организации.
Учет наличия и движения ТМЦ должен вестись в следующих разрезах
(
Рисунок
1
.
10).
Учет наличия и движений ТМЦ
Организация
Подразделение
Сотрудник
Склад
Если несколько организаций
ТМЦ выдано для эксплуатации в
подразделение
ТМЦ выдано для эксплуатации
конкретному сотруднику на руки
ТМЦ хранится на складе
Рисунок 1.10. Разрезы учета наличия и движений ТМЦ
Учет ТМЦ должен вестись не только в количественном но и в суммовом
выражении для возможности оценить запасы ТМЦ на складах или находящихся в
подразделениях в денежном выражении.
37
Подсистема складского учета должна позволять вводить документы
складского учета для фиксации фактов совершения операций по взаимодействию с
поставщиками ТМЦ и движения ТМЦ в учреждении:
- Заявка подразделения на приобретение ТМЦ;
- Заказ поставщику для фиксации предварительного желания заказать у
поставщика ТМЦ;
- Поступление от поставщика для фиксации факта прихода ТМЦ от
поставщика на склад;
- Возврат поставщику в случае возврата некачественных или бракованных
ТМЦ;
- Перемещение для фиксации перемещения ТМЦ между разрезами учета;
- Списание для фиксации списания ТМЦ со склада и других разрезов
учета.
При проведении каждого документа должны соответствующим образом
меняться остатки ТМЦ на разрезах учета и должен проводиться контроль наличия
требуемого количества ТМЦ. Форма каждого документа должна предоставлять
пользователю максимально удобный интерфейс по вводу данных: все данные,
которые можно заполнить автоматически, должны заполняться. Также должен
автоматически производиться расчет цен и сумм на основании типа цен договора
поставки и автоматический их пересчет при изменении параметров. Документы
могут вводиться на основании друг друга, образуя цепочки документов и позволяя
заполнять все реквизиты шапки и табличной части автоматически.
В системе должен быть реализован отчет «Остатки», который позволяет
анализировать остатки и движения ТМЦ на любых разрезах учета в
количественном и суммовом выражении в различных разрезах с наложением
различных условий, в том числе в разрезе партий.
Отчет должен быть настраиваемым, т.е. позволять пользователю на этапе
эксплуатации системы настраивать любые параметры отчета, задавать условия,
отборы, группировки, состав и порядок выводимых полей, порядок сортировки и
оформления. Должна предоставляться возможность сохранить и в последствии
быстро загрузить вариант настроек отчета, создавая таким образом «много отчетов
в одном».
38
1.4.2 Обоснование проектных решений по программному
обеспечению
Сегодня на рынке программного обеспечения, позволяющего создавать
системы собственной разработки, существует огромное количество предложений.
Среди них особо следует выделить систему «1С: Предприятие 8.3» [18,19] как
наиболее популярной на российском рынке.
«1С: Предприятие 8.3» является гибкой и настраиваемой средой разработки,
с помощью которой можно создавать прикладные решения для широкого круга
задач в области автоматизации деятельности предприятий любой формы
собственности и сферы деятельности.
Выбор в пользу системы «1С:Предприятие 8.3» сделан в силу ряда факторов.
В системе разработчики реализовали целый ряд важных преимуществ,
позволяющих создавать прикладные решения, гораздо более эффективные, чем при
помощи других систем [18] (Рисунок 1.11).
39
Отличительные особенности платформы 1С: Предприятие 8
Четкое разделение на
платформу и
прикладное решение.
Ориентация на
построение
прикладного решения
на основе
определенной модели
В основе прикладного
решения лежат
метаданные
Стандартные
прототипы
прикладных объектов
Согласованность
технологий и
инструментов
Многозвенная
архитектура работы
Отказоустойчивый
кластер с
балансировкой
нагрузки
Высокоуровневая
модель интерфейса
Веб-клиент и тонкий
клиент
Мобильная платформа
Интеллектуальные
механизмы
подготовки отчетов
Построение
распределенных и
интегрированных
информационных
систем
Рисунок 1.11. Преимущества платформы «1С:Предприятие 8»
Технологическую платформу «1С: Предприятие 8.3» нельзя назвать
программным обеспечением (ПО), предназначенным к эксплуатации конечными
пользователями: для работы необходимы также прикладные решения — так
называемые конфигурации, разработанные на основе платформы.
Данный подход позволяет компаниям абсолютно различных форм
собственности и направления деятельности автоматизировать свои специфические
бизнес-процессы с применением единой технологической платформы «1С:
Предприятие 8.3».
40
Технологическая платформа «1С: Предприятие 8.3» обладает большой
функциональностью и гибкостью, что позволяет применять ее в самых различных
областях, представленных на Рисунок 1.12.
Области применения 1С: Предприятие 8
Автоматизация
производственных и
торговых
предприятий,
бюджетных и
финансовых
организаций,
предприятий сферы
обслуживания и т.д.
Поддержка
оперативного
управления
предприятием
Автоматизация
организационной и
хозяйственной
деятельности
Ведение
бухгалтерского учета
с несколькими
планами счетов и
произвольными
измерениями учета,
регламентированная
отчетность
Широкие
возможности для
управленческого учета
и построения
аналитической
отчетности,
поддержка
многовалютного учета
Решение задач
планирования,
бюджетирования и
финансового анализа
Расчет зарплаты и
управление
персоналом
Рисунок 1.12. Области применения платформы «1С:Предприятие 8.3»
Программные продукты платформы «1С:Предприятие 8.3» поставляются с
типовыми решениями, реализующими схемы учета, которые приняты в
большинстве организаций той сферы деятельности, для которой написан
программный продукт. В случае необходимости типовые решения могут быть
подстроены к любым особенностям функционирования конкретной организации.
Прикладное решение может быть создано и совсем с нуля, если особенности
ведения учета в конкретной организации требуют этого. В состав платформы
входит программный модуль «Конфигуратор», который обеспечивает функции,
представленные на
Рисунок
1
.
13.
41
Возможности модуля «Конфигуратор»
Настройку системы на
различные виды учета
Реализацию
произвольной
методологии учета
Организацию
справочников и
документов
произвольной
структуры
Настройку внешнего
вида форм ввода
информации
Настройку поведения
и алгоритмов работы
системы в различных
ситуациях
Возможность создания
печатных форм
документов и отчетов
Возможность
представления
информации в виде
диаграмм
Быстрое изменение
конфигурации с
помощью
«конструкторов»
Рисунок 1.13. Возможности модуля «Конфигуратор»
Именно наличие единой технологической платформы, а также общей
методологии позволяет создавать такие решения на базе выпускаемых фирмой
«1С» тиражных прикладных решений, добавляя в них только необходимые
функциональные отличия, учитывающие специфику отрасли или области
деятельности конкретного предприятия.
1.4.3 Обоснование проектных решений по техническому
обеспечению
Разрабатываемая система учета пациентов является конфигурацией для
системы «1С:Предприятие 8.3», и данная система становится центром комплекса
автоматизации работы медицинского учреждения и определяет требования к
составу и структуре технического обеспечения системы [7].
Система учета разрабатывается для клиент-серверного варианта работы,
работающего в локальной сети учреждения. Выделение в локальной сети сервера
становится обязательным. На этом сервере должна быть обязательно установлена