Рис. 1

После авторизации нашему взору появляется основное рабочее окно с «направляющим» интерфейсом (рис.2). Сразу подгружаются общие данные о человеке (ФИО, № полиса и последнего лечащего врача), если данные отсутствуют в базе, то их можно ввести и при первом же бронировании талона они запишутся в базу.

Рис.2

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

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

Рис.3

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

На рис.4 мы видим результат нажатия кнопки «Печатать талон», которая выводит шаблон распечатки с веденными пользователем данными. Шаблон сделан так, чтобы пользователь точно знал, к какому врачу он записался, на какое время, к какому кабинету подойти и какие дополнительные данные он указал. После печати данные в базе обновятся, а именно: ФИО, если пользователь внес свои коррективы, и история посещений.

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

Рис.4

Интерфейс врача

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

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

Первый этап: авторизация врача по логину и паролю на защищенном сервере с шифрованием (рис.5). Переход на основную страницу.

Рис.5

Второй этап: первым отображается строка поиска пациента по его уникальному идентификатору - страховому полису. При удачном поиске сразу же отобразится история болезни пациента по профессиональной деятельности врача (рис.6). Рядом отображается список с возможностью отображения истории врачей других специальностей. Медицинская карта коллег врачей специально представлено для дифференциальной диагностики заболевания - третий этап нашего интерфейса. Именно медицинские карты занимают основное рабочее место в окне, так как этот элемент несет основную информацию для специалиста (принцип акцентирования внимания). Размер медкарт подобран таким образом, чтобы ровно две карты смогло уместиться на стандартном разрешении монитора, это сделано для удобства чтения и сравнительного анализа. Отображение двух медкарт одновременно визуально похоже на чтении книги или тетради, более привычный образ для среднестатистического врача (Принцип использования привычных ассоциаций и стереотипов).

Рис. 6

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

Под основной медкартой пациента отображаются самые важные изображения анализов, рентгенов, кардиограмм и т. п. Нажав на изображение, мы увидим его в полном масштабе для детального просмотра (рис.7). Рядом есть список дополнительных вложений к карте абонента, который может содержать любую информацию. Любой файл из списка можно открыть, нажав кнопку «Просмотреть файл». Данный список может дополнять любой врач. В идеале, анализы должны автоматически поступать в медкарту пациента с аппаратуры, но это уже касается инфраструктурной части создания массового интерфейса, решением который мы не занимаемся в ходе этого проекта.

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

Рис.7

Четвертый этап: назначение лечения, зная противопоказания. Была создана мини рабочая область ввода лечения, а так же редактирования противопоказаний при их изменении. Для привлечения внимания к противопоказаниям, они были выделены томатным цветом, который привлекает внимание, но не раздражает (рис. 8).

Рис.8

Пятый этап: посвящен окончанию приема пациента. На форме присутствует единственная управляющая кнопка «Закончить прием», по ее нажатию происходит запись новых данных в медицинскую карту. Эту запись может предотвратить только встроенная функция проверки назначенного лечения с противопоказаниями. Если проверка не пройдена, то появится крупная надпись: «Ваше лечение противопоказано пациенту».

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

Рис.9

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

Решение проблем программной инженерии

Хранение данных

Во время создания любого веб-сервиса разработчик сталкивается с проблемой размещения, хранения данных, равно как предоставления доступа к ним и вывод конечному пользователю. Исходя из выбранной платформы логичней всего использование MS SQL баз, которые имеют ряд преимуществ в среде :

1)  Интеграция с другими продуктами Microsoft

2)  Масштабируемость

3)  Превосходная производительность

4)  Простота использования

5)  Готовность к использованию в Интернете, интрасетях и для электронной коммерции

6)  Хранилища данных

Стоит особенно отметить важность второго пункта о масштабируемости, которая в совокупности с гибкостью очень важна в процессе хранения, записи и вывода данных. Для нашего веб-сервиса требуется быстрый вывод данных о пациенте (ФИО, истории приемов и т. д.) в интерфейсе получения талона. Так же требуется гибкая система хранения расписания работы врачей, которая успешно решена при помощи инструментария MS SQL и его возможности структурировать данные и связи между таблицами. В итоге мы получили возможность динамически управлять списком врачей, их графиком работы в любой день.

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

Безопасность

Важную роль в веб-сервисах и в любых системах, содержащих персональные данные, играет безопасность. Есть ряд государственных законов, защищающих персональные данные граждан России.

В прототипе реализована многоуровневая система безопасности.

Во-первых, создана система авторизации. Доступ к данным получит пользователь, знающий логин и пароль. Во-вторых, чтобы данные не смогли перехватить со злым умыслом, введена на сервере система шифрования методами IIS (Internet Information Server) и соединения по защищенному каналу 443 порту.

Вопросы безопасности, с которыми имеет дело разработчик веб-приложения, — это лишь часть общего комплекса проблем безопасности. Вероятно, более актуальными, особенно в контексте веб-безопасности, являются те проблемы, которые связаны с обеспечением безопасности приложения после развертывания — во время его выполнения.

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

·  Защитить собственные ресурсы разработчика от несанкционированного доступа.

·  Ограничить уровни доступа по пользователям или ролям.

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5