2. Уровень клиентского ПО системы

— приложения системы, с которыми осуществляет свою работу пользователь. Здесь мы разделяем все клиентское ПО на две группы: основное и вспомогательное. При этом для функционирования вспомогательного ПО добавляется новая прослойка — программный интерфейс системы, т.е.

Целями такого разделения стали следующие причины.

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

> Увеличение производительности работы основного ПО. Это требование совершенно логично. Самые востребованные функции клиент должен выполнять с самой высокой производительностью. За счет этого происходит экономия времени работы с компьютером, повышение эффективности использования системы и т.д. Только с этой целью основное клиентское ПО может обращаться к серверу БД напрямую.

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

> Уменьшение трудозатрат программиста на создание нового ПО или на внесение изменений в существующие приложения.

Рис. 6.12. Архитектура медицинской информационной системы

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

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

К программному интерфейсу системы мы относим специальное ПО, инкапсулирующее в себе возможности клиента базы данных и взаимодействующее уже не с сервером базы данных, а с системой. Например, в случае распределенной БД поиск имеющихся в системе архивных историй болезни является нетривиальной задачей. Конечно, можно встроить этот алгоритм в саму программу. А что если ядро системы или архитектура ее будут изменены? Вносить изменения во все имеющиеся программы медицинской информационной системы? А если таких приложений десятки, а их инсталляций сотни? Именно поэтому целесообразнее переносить все прямые запросы к БД в промежуточное ПО. В случае надобности только в программный интерфейс вносятся изменения, а готовые и установленные приложения не потребуют переделки и переустановки. Кроме этого, при использовании такого ПО значительно увеличивается скорость разработки новых программ. Не секрет, что значительное число функций даже нового приложения содержит однотипные действия: подключиться к серверу, осуществить поиск, обработать ответ и т.д.

3. Уровень клиента БД. Клиент БД осуществляет диалог с основным и дополнительным ПО, выполняет проверку пароля пользователя и, самое главное, формирует запросы к серверу БД, осуществляя с ним диалог. Работа основного ПО у некоторых БД осуществляется прямо в клиенте (Lotus Notes), обеспечивая интерфейс пользователя, справку, дополнительные возможности типа электронной почты и т.д. Работа других клиентов (InterBase) состоит только в обеспечении программной возможности доступа к серверу БД.

4. Сеть и сетевой протокол. Клиент БД, обращаясь с запросом к серверу, должен передать его по сети. При этом он должен поддерживать хотя бы один сетевой протокол. На этом уровне учитывается список поддерживаемых сетевых протоколов клиентов и сервера и решается вопрос об использовании конкретного или нескольких протоколов. Это решение влияет на производительность системы в целом, на возможности ее масштабирования, на простоту и надежность в работе и управлении. Наиболее распространенным на сегодня является протокол TCP/IP, используемый в сегментированных сетях и Интернете. Мы также считаем его предпочтительным при выборе. Кроме того, этот уровень является еще и разделительным — все последующие уровни относятся к серверу БД.

5. Уровень серверного ПО системы. Здесь мы не разделяем уровень на ПО сервера БД и прикладное ПО, расширяющее возможности сервера для обеспечения задач ИС. На этом уровне осуществляется принятие запросов от клиентов БД, выполнение и отправка ответов. В случае программно распределенной БД возможен вариант, когда не клиент определяет, к какой конкретно БД обратиться, а центральный сервер системы.

6. Уровень текущих документов. Небольшие по объему БД, которые содержат только текущие документы, позволяют осуществлять максимально производительную работу системы.

7. Уровень архивов. На этом уровне находятся архивные БД, производительность работы с которыми может быть низкой, однако потребность в документах этого уровня не такая высокая, как с текущими документами. Как правило, в архивах осуществляется только поиск документов или расчет статистики. Необходимое условие — отсутствие прав на запись или удаление документов с целью сохранности информации. Этот уровень может быть физически расположен на отдельном компьютере для разгрузки сервера текущих документов.

6.5.1.