Предложение по реализации

проекта МИС

Основные цели документа

Предложить  архитектуру системы по проекту  МИС для лечебно-профилактического учреждения (ЛПУ). Описать используемые принципы, технологии и методики.

Первоочередная  задача документа:

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

План  работ

1. Автоматизация оперативного учета ЛПУ 
2. Сопряжение с существующими системами автоматизации
3. Получение данных для принятия управленческих решений уровня ЛПУ

 

Основные принципы

1. Архитектура с тремя основными слоями:

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

• Предметная логика, бизнес-логика  (Domain) – описывает основные функции приложения. К таким функциям относятся обработка и вычисления на основе вводимых и хранимых данных, проверка вводимых данных и обработка команд,  поступающих от слоя представления, а также сохранение информации слою источника данных.
• Источники данных (Data source) – это подмножество функций для работы с базой данных и другими источниками данных. Этот код несет ответственность за управление транзакциями, хранение, поиск, вставку и обновление хранимых данных.

 

 
 
 
 

 

2. Организация бизнес-логики

Для реализации логики предметной области: можно использовать три разных способа распределения функций: сценарий транзакции, модель предметной области и модуль таблицы.

• Сценарий транзакции получает на вход информацию от слоя  представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных. Затем процедура возвращает слою представления требуемые данные в нужном формате. Такой подход является простым в понимании, определяет четкие границы транзакции. Однако с повышением сложности бизнес-логики, требуется реализовывать схожие функции, что приводит к дублированию кода. С этим можно бороться с помощью процедур, но даже это не позволяет справиться со всеми проблемами. В итоге приложение может выглядеть беспорядочной мешаниной кода без отчетливой структуры. Более удачным решением  является  использование объектов или переход к модели предметной области.
• Модель предметной области - это реализация на основе объектно-ориентированного варианта решения проблемы. Это подход связан с выделением сущностей, атрибутов и методов, определения видов связей между ними.
• Модуль таблицы – опирается на организацию бизнес логики вокруг таблиц. Этот подход является промежуточным вариантом, компромиссным по отношении к сценарию транзакции и модели предметной области. Однако решение модуль таблицы не позволяет использовать многие технологии: наследование, стратегии и другие типовые объектно-ориентированные решения.

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

Если логика приложения проста, модель предметной области менее соблазнительна , потому как затраты на ее реализацию выше чем у сценария транзакции. Когда сложность решаемой задачи возрастает, альтернативные пути становятся все менее приемлемыми: трудоемкость пополнения новыми функциями резко возрастает. Все эти три типа не являются взаимоисключающими, желательно заранее предвидеть насколько сложной является решаемая задача.

Для уменьшения стоимости реализации проекта МИС  будем использовать модель предметной области.

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

Отображение объектов на реляционную модель

Объектно-реляционное  отображение это решение вопросов взаимно однозначного соответствия между объектами в памяти и табличными структурами базы данных на диске. Для повышения производительности имеет смысл кэшировать уже считанные объекты в памяти, добавляя ссылку на объект в коллекцию.

Для облегчения работы с объектами наиболее гибким и удобным является подход, основанный на метаданных. Наличие метаданных позволяет избежать написания кода для операций CRUD (Create, Read, Update, Delete) создания, выборки, обновления и сохранения данных объектов в базе данных.  

Выделение OLTP и OLAP обработки

В базах данных традиционно разделяет обработку, связанную с модификацией данных (добавление, изменение и удаление записей) основанных на транзакциях OLTP (Online Transaction Processing), от операций связанных с анализом больших объемов обрабатываемых данных (создание отчетов) OLAP (Online Analyzing Processing).

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

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

Взаимодействия  между модулями основано на WEB сервисах.

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

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

На городском  уровне требуется централизованная система НСИ (Нормативно Справочная Информация). Данная служба обеспечивает единую базу показателей и справочников, Типовая система НСИ содержит функции по контролю изменений справочников, развитую службу управления заявками для изменения данных справочников, обеспечивает публикацию изменений для всех ЛПУ и т.д.

Взаимодействие  между модулями системы

Для организации  взаимодействия между модулями системы  можно использовать WEB сервисы. Это позволит четко детализировать интерфейсы взаимодействия между модулями. Выделение модулей позволит: распараллелить разработку, проводить модификацию системы за счет замены одного модуля другим. В случае необходимости можно увеличить количество поддерживаемых функций системы.

Другие преимущества WEB сервисов это простота интеграции модулей системы и их доступность для всех участников в соответствии с их правами.

Использование метаданных для реализации интерфейса пользователя

Можно добавить в набор метаданных дополнительную информацию такую как:

• русское наименование полей;
• прикладной тип данных;
• значение по умолчанию;
• является ли поле обязательным для заполнения;
• дополнительные проверки;
• список полей для просмотра/поиска в виде списка

Эта информация может быть использована для автоматического  создания форм редактирования данных. Автоматически создаваемая форма содержит набор атрибутов: наименование и поле для редактирования значение атрибутов объекта. Возможность указать прикладной тип данных позволяет реализовать специализированные редакторы атрибутов объектов. Например, можно ввести тип цвет - для редактирования этого типа можно реализовать поле в виде цветной полоски с кнопкой вызова диалога - Выбор цвета или тип: ссылка на некоторый объект  в поле отображает наименование объекта по умолчанию, и диалог с возможностью выбора из списка/поиска/добавления нового объекта. 

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

Полезно для  каждого объекта привязать форму  по умолчанию. Это облегчит реализацию пользовательского интерфейса.

В процессе проектирования интерфейса пользователя, следует ориентироваться на объектный подход. Как это можно реализовать? Для каждого АРМ отобразить несколько иерархий связанных объектов. При выборе объекта пользователем, отобразить все доступные пользователю методы этого объекта.

Обеспечение прав доступа

Количество АРМ  должно соответствовать количеству ролей. Роль описывается набором  доступных пользователю функций  системы. Функции системы следует описывать на достаточно высоком уровне детализации, в терминах предметной области, на основании существующих на предприятии бизнес-процессов. Набор ролевых функций образует матрицу функций для некоторой роли. Выделение ролей в существующих бизнес-процессах образует матрицу ролей.

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

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

• Пользователь входит в группы
• Группа создается для каждой роли
• Группа определяет набор: доступных функций, коллекций и объектов.

Общие требования к безопасности:

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

Реализация  системы отчетности

Количество АРМ  должно соответствовать количеству ролей. Роль описывается набором доступных пользователю функций системы. Функции системы следует описывать на достаточно высоком уровне детализации, в терминах предметной области, на основании существующих на предприятии бизнес-процессов. Набор ролевых функций образует матрицу функций для некоторой роли. Выделение ролей в существующих бизнес-процессах образует матрицу ролей.