Пояснительная записка

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

Рисунок 4 - Установка и изменение графиков работы специалистов

удаление персональных данных по желанию клиента (исполнитель -

регистратор):

а) формирование печатной формы заявления, подписываемой клиентом;

б) расторжение договора;

в) удаление персональных данных из информационной базы;

оформление пациента без предварительной записи на прием (исполнитель -

регистратор):

а) внесение клиента в справочник, если он обращается впервые;

б) создание документа талон пациента без записи;

прием пациента (исполнитель - врач):

а) проверка актуальности данных медицинской карты;

б) заполнение талона пациента;

в) вывод на печать заполненной формы талона.

2.2.3.3 Основные объекты и их назначение Выбранная среда разработки предоставляет набор проблемно-

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

37

(справочники, документы, регистры сведений и накопления, планы видов характеристик и др.). Язык 1С:Предприятия поддерживает один уровень наследования, и все разработанные объекты являются потомками этих объектов метаданных, определяющих их структуру, стандартные атрибуты и методы [1].

Таким образом, задача первичного проектирования разбивается на два этапа

выделение сущностей с точки зрения поставленной задачи, определение их взаимосвязей (определение отношений ассоциации и агрегации);

выявление соответствия между сущностями и метаобъектами платформы

(определение отношений обобщения).

Результатом выполнения этих этапов является диаграммы, приведенные на рисунках 5 (отражает связи наиболее значимых сущностей предметной области) и 6 (контекстная диаграмма классов) соответственно.

Рисунок 5 - Диаграмма классов

38

На диаграмме, показывающей отношения агрегации, связь между классами

«Специалист», «Регистратор» и «Пользователь» изображена как обобщение, однако это справедливо только на уровне логики (и специалист, и регистратор являются пользователями системы), т.к. среда разработки не поддерживает многоуровневое наследование, и эти связи будут заменены агрегацией. Кроме того, подразумевается связь класса «Регистратор» с классами «Договор», «Заявление на удаление ПД», «Талон пациента», «Талон пациента без записи», «Запись на прием», «Установка графика» и «Корректировка графика» (регистратор является исполнителем или ответственным за все соответствующие им операции).

Рисунок 6 - Контекстная диаграмма классов Справочники – это объекты, хранящиеся в базе данных, и имеющие

уникальные идентификаторы, но не оказывающие влияния на другие сущности.

Предполагается выделить следующие справочники:

клиенты (пациенты);

медицинские карты (подчинены справочнику клиентов);

специалисты (врачи, связаны с пользователями базы данных);

регистраторы (связаны с пользователями базы данных);

часы работы (с указанием времени начала и окончания часа);

специальности врачей;

39

графики приема с указанием периода (представляющие собой таблицу,

устанавливающую соответствие между днем, часом приема и состоянием часа

(свободен, недоступен, занят, забронирован));

причины отмены приема (например, «неявка пациента» или «технические причины»);

виды результатов приема (например, «направление на дополнительные исследования» или «назначение лекарств»);

виды препаратов;

виды анализов;

виды лечения.

Документы – это объекты, хранящиеся в базе данных, имеющие дату создания, номер, изменяющие другие объекты базы данных (а именно регистры сведений или накопления), обладающие признаком «проведение» (показывает,

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

заявка клиента (формируется через веб-клиент самим потенциальным пациентом, где он указывает дату, время приема, выбирает врача и оставляет свои контактные данные);

запись на прием (формируется регистратором либо на основании электронной заявки клиента, либо вручную в случае записи другим способом;

подтверждает факт записи пациента на прием);

талон амбулаторного пациента (отражает факт посещения клиники,

результат приема пациента, фиксирует данные электронной медицинской карты);

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

установка графика специалиста (устанавливает соответствие между врачом

играфиком работы на период);

40

корректировка графика специалиста (позволяет внести изменения в график приема на текущий месяц);

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

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

Документ «Заявка клиента» обладает как формой обычного приложения, так и управляемой формой для отображения в браузере, реализованной в виде

«помощника записи», состоящего из трех шагов:

выбор специалиста (либо только профиля специалиста – для новых клиентов, которым фамилия врача ни о чем не говорит);

выбор даты и времени приема (с отбором только дней и часов, свободных на данный момент у выбранного врача);

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

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

«Отчет по данным регистратуры» формируется по измерениям:

запись на прием;

состоявшийся прием;

врач, ведущий прием;

регистратор;

«Отчет по рабочему времени» формируется по измерениям:

врач, ведущий прием;

часы работы;

период графика (календарный месяц).

41

«Отчет по оказанным услугам» предоставляет сведения о количестве приемов

за указанный период.

Для реализации прочих функций системы используются объекты следующих

типов:

Параметры сеанса (глобальные переменные, значения которых сохраняются в течение сеанса работы):

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

Роли (объект конфигурации, позволяющий описать перечень доступных действий над объектами информационной базы для определенных групп пользователей [1]):

а) полные права (доступ на чтение, редактирование и удаление ко всем объектам информационной базы);

б) регистратор (доступ к заявкам клиента, записи на прием, чтению графиков работы);

а) клиент (доступ к веб-регистратуре);

б) специалист (доступ к талонам пациента);

в) руководитель (доступ на чтение ко всем объектам, формирование отчетов);

г) учет медицинских карт (доступ на чтение и редактирование персональных данных клиентов, чтение медицинских сведений);

д) удаление персональных данных (дополнительное право регистратора,

позволяющее очищать все реквизиты объектов, содержащие персональные данные клиента);

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

Константы (позволяют хранить в информационной базе данные, которые не изменяются во времени, или изменяются очень редко [1]) – используются для хранения сведений о медицинском учреждении:

42

а) краткое и полное наименование организации;

б) должность и ФИО руководителя;

в) сведения о лицензии;

г) контактные данные (адрес, телефон, факс, адрес электронной почты);

д) реквизиты банковского счета.

Перечисления (позволяют хранить в информационной базе наборы значений, которые не изменяются в процессе работы прикладного решения [1]):

а) Пол;

б) Социальный статус;

в) Состояние часа (перечень возможных состояний отдельного часа приема врача: недоступен, свободен, занят, забронирован, прием состоялся);

г) Состояние заявки (позволяет регистратору разделять заявки клиентов на новые, рассмотренные и отклоненные);

д) Типы событий (перечень возможных типов событий в истории взаимодействия клиента с клиникой: заключение договора, запись на прием,

посещение врача).

Журналы документов (предназначены для просмотра документов разных видов в одной форме списка [1]):

а) Журнал посещений по записи;

б) Журнал талонов пациента;

в) Документы установки и изменения графиков.

Обработки (отдельные приложения, функционирующие на платформе

1С:Предприятие, которые могут обладать экранными формами и вносить изменения в информационную базу, но их параметры не в ней не сохраняются):

а) Рабочий стол (обеспечивает удобный доступ к объектам информационной базы в обход главного меню в соответствии с ролью пользователя,

вывод наиболее значимой информации);

б) Удаление персональных данных клиента (для указанного клиента при наличии заявления на удаление персональных данных очищает реквизиты талона

43

пациента, удаляет медицинскую карту, очищает реквизиты договора и помечает его как расторгнутый).

План видов характеристик (структура, подобная справочнику,

предназначенная для хранения элементов – характеристик, тип значения которых может быть неизвестен на момент разработки и впоследствии выбран пользователем; в плане видов характеристик могут существовать предопределенные характеристики, заданные разработчиком)[1]:

а) Типы результатов приема (позволяет занести в информационную базу практически любую информацию – назначенные лекарства, обследования, их результаты, диагнозы и т.д.).

Регистры сведений (табличные структуры, позволяющие хранить произвольные данные в разрезе нескольких измерений)[1]:

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

затем отдельные записи изменяются корректировкой графика, заявками клиентов,

записями на прием, талонами пациента);

б) Фактический прием (хранит сведения о состоявшихся приемах пациентов без предварительной записи);

в) История (хранит историю взаимодействия медицинского учреждения и пациента в виде событий с указанием дат);

г) Медицинские сведения (хранит данные о результатах приемов,

полученные из талонов пациента).

Бизнес-процессы (позволяют описывать, создавать и управлять выполнением бизнес-процессов в прикладных решениях). Выполнение бизнес-

процессов, определяемых предметной областью (были подробно рассмотрены в подпункте 2.2.3.2), может быть реализовано как с помощью специального механизма платформы 1С:Предприятие, так и другими средствами (например,

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

44

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

(порождается в момент проведения заявки клиента, завершается при создании талона пациента).

Задачи (объекты, предназначенные для учета заданий и описывающие способ их распределения по исполнителям, бизнес-процесс, как правило,

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

а) Формирование записи на прием;

б) Создание карты пациента;

в) Создание договора на оказание платных медицинских услуг;

г) Отмена записи на прием.

2.2.3.4 Режимы работы Для реализации указанных выше функций предусматриваются следующие

режимы работы:

веб–регистратура;

приложение.

Режим «веб–регистратура» обеспечивает ограниченный доступ к подсистеме

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

2.2.3.5 Права пользователей Учитывая необходимость реализации бизнес-процессов, рассмотренных в

подпункте 2.2.3.2, предусмотрены следующие роли, определяющие права пользователей (диаграмма вариантов использования приведена на рисунке 7):

«Пациент» (имеет доступ к веб-интерфейсу, обеспечивающему ограниченный доступ к подсистеме «Регистратура»);

45

«Регистратор» (имеет доступ к подсистеме «Регистратура» и ограниченный доступ к подсистеме «Учет электронных медицинских карт»);

«Специалист» (имеет доступ к подсистемам «Ведение электронных медицинских карт» и «Кабинет врача»);

«Руководитель» (имеет доступ к подсистеме «Монитор руководителя» и

право просмотра «Регистратуры»).

Право на установку и изменение графиков работы и право на удаление персональных данных клиентов могут быть назначены как регистратору, так и руководителю.

Рисунок 7 – Диаграмма вариантов использования Такое выделение ролей объясняется необходимостью ограничения доступа к

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

46