Библиотека сайта rus-linux.net
OSCAR
Глава 16 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: OSCAR
Автор: Jennifer Ruttan
Перевод: А.Панин
16.6. Интегратор
АрхитектураДанные для работы интегратора передаются со стороны всех соединенных с ним систем электронных медицинских записей в установленное время и после их доставки другая система электронных медицинских записей может запросить эти данные. При этом никакие из данных не хранятся интегратором на постоянной основе - его база данных может быть очищена и заполнена заново данными от клиентов.
Набор отправляемых данных настраивается индивидуально на стороне каждого из экземпляров системы OSCAR, соединенного с определенным интегратором и, за исключением случаев, когда база пациентов в полном объеме должна быть передана серверу интегратора, ему передаются только те записи пациентов, которые были просмотрены с момента последней отправки данных. Этот процесс не является точной копией процесса наложения патча, но очень похож на него.
Рисунок 16.1: Обмен данными между системами OSCAR и интегратором
Позвольте мне объяснить принцип работы интегратора более подробно с помощью примера: в удаленной клинике хотят посмотреть карту пациента из другой клиники. При желании персонала этой клиники получить доступ к записи пациента, следует первую очередь подключить эти клиники к одному и тому же интегратору. Регистратор может осуществить поиск удаленного пациента с помощью интегратора (по имени и в случае необходимости по дате рождения или полу) и найти запись необходимого пациента, хранимую на сервере. Он инициирует копирование ограниченного набора демографической информации пациента, после чего подтвердит намерения пациента, получив его согласие на извлечение данных путем заполнения формы согласия. После этого сервер интегратора передаст всю информацию, известную интегратору о пациенте - записи, сведения о прописанных препаратах, аллергических реакциях, прививках, дополнительные документы, и.т.д. Эти данные кэшируются локально, поэтому локальной копии системы OSCAR не придется отправлять интегратору запрос каждый раз, когда потребуется обратиться к этим данным, но следует учесть и то, что срок хранения локального кэша ограничивается одним часом.
Рисунок 16.2: Демографическая информация и соответствующие данные отправляются интегратору в процессе передачи данных из домашней клиники. Хранящаяся на интеграторе запись может быть не полным представлением записи из домашней клиники, так как система OSCAR позволяет выбрать вариант отправки данных пациента не в полном объеме.
После начальной настройки записи пациента, выполненной путем копирования его демографических данных в локальную систему OSCAR, запись пациента начинает работать точно так же, как и любая другая запись в рамках системы. Все данные с удаленной системы, принятые от интегратора получают соответствующую метку (также вместе с данными сохраняется информация о клинике, из которой они получены), но они всего лишь временно кэшируются в рамках локальной системы OSCAR. Любые сохраняемые локальные данные записываются абсолютно также, как и любые другие данные пациента в записи пациента, после чего отправляются интегратору, но при этом они не хранятся на удаленной машине на постоянной основе.
Рисунок 16.3: Удаленная система OSCAR запрашивает данные у интегратора, указывая на определенную запись пациента. Сервер интегратора отправляет исключительно демографическую информацию, которая хранится на постоянной основе удаленной системой OSCAR.
Этот процесс имеет очень важное значение, особенно для получения согласия пациента и понимания воздействия описанных факторов на архитектуру интегратора. Представим, что пациент посетил врача из удаленной клиники и согласился на предоставление доступа к своей записи, но только на некоторое время. После визита пациент может аннулировать соглашение о возможности открытия персоналом этой клиники его записи и в следующий раз при открытии карты пациента из этой клиники данные не будут доступны (за исключением тех данных, которые были сохранены локальной системой). В конечном счете этот механизм позволяет пациенту непосредственно контролировать то, как и когда его запись может быть просмотрена аналогично посещению клиники с бумажной копией карты пациента. Персонал клиники сможет ознакомиться с картой только при общении с вами, но вы заберете ее домой тогда, когда покинете клинику.
Рисунок 16.4: Персонал удаленной клиники может просматривать содержимое карты пациента, запрашивая данные; в случае согласия пациента данные передаются. Данные никогда не хранятся на постоянной основе удаленной системой OSCAR.
Другой очень важной для медиков возможностью является возможность принятия решения о том, какие данные они хотели бы передавать другим присоединенным клиникам посредством своего сервера интегратора. Персонал клиники может выбрать передачу всех данных из демографической записи или только частей этой записи, например, записей без документов, информации об аллергических реакциях без предписаний, и.т.д. В конечном счете решение о том, какими типами данных было бы удобно делиться друг с другом принимается группой медиков, настраивающих сервер интегратора.
Как я упоминала ранее, интегратор является исключительно системой временного хранения данных и с помощью него данные никогда не сохраняются на постоянной основе. Это еще одно очень важное решение, которое было принято в ходе разработки; оно позволяет клиникам очень просто отказаться от передачи всех данных с помощью интегратора и, фактически в случае необходимости может быть очищена вся база данных интегратора. В случае очистки базы данных пользователи клиентских систем не заметит этого, так как данные будут аккуратно реконструированы на основе исходных данных, находящихся на различных соединенных с интегратором клиентских системах. Эта возможность влечет за собой требование, согласно которому предоставляющая данные система OSCAR должна доверять получающему данные интегратору, предоставляя возможность очистки базы данных по первому требованию, следовательно, лучшим решением является развертывание интегратора группой медицинских работников из такой зарегистрированной согласно требованиям законодательства организации, как Family Health Organization или Family Health Team; в этом случае сервер интегратора будет эксплуатироваться одной из клиник, в которой работают эти специалисты.
Формат данных
Клиентские библиотеки интегратора созданы с помощью программного компонента wsd2java, который формирует набор классов, представляющих соответствующие типы данных, используемые веб-сервисом в ходе взаимодействия с клиентами. Среди них присутствуют классы для каждого из типов данных наряду с классами, представляющими ключи для каждого из этих типов данных.
Описание способа сборки клиентской библиотеки интегратора выходит за границы данной главы. Единственной важной вещью в данной связи является информация о том, что сразу же после сборки библиотеки она должна быть добавлена в комплект поставки системы OSCAR ко всем остальным JAR-файлам. Этот JAR-файл содержит все необходимое для установления соединения с интегратором и доступа ко всем типам данных, которые сервер интегратора будет передавать системе OSCAR, такими, как CachedDemographic, CachedDemographicNote и CachedProvider наряду с многими другими. В дополнение к типам данных, которые передаются, существуют "WS"-классы, которые используются в первую очередь для получения таких наборов данных, как наиболее часто используемый класс DemographicWs.
Работа с данными интегратора иногда может оказаться немного усложненной. Система OSCAR не имеет каких-либо жестко интегрированных механизмов для работы с типом данных, который обычно используется при получении определенного типа информации о пациенте (например, записей из медицинской карты) в момент, когда клиент интегратора отправляет запрос для получения данных от сервера. После этого данные вручную преобразуются в локальный класс, представляющий эти данные (в случае записей это класс CaseManagementNote). В рамках класса типа данных устанавливается логический флаг, указывающий на то, что это класс содержит данные от удаленной системы и влияющий на то, как данные будут выводиться на экран пользователя. С другой стороны, класс CaisIntegratorUpdateTask обрабатывает выборку локальных данных системой OSCAR, преобразование их в формат данных интегратора и последующую отправку этих данных серверу интегратора.
Эта архитектура может и не является такой эффективной и прозрачной, как могла бы, но она позволяет устаревшим в большей степени частям системы стать "совместимыми" с доставляемыми интегратором данными без значительных модификаций. В дополнение к этому поддержание представления таким простым, как это возможно путем осуществления обращений только к одному типу класса улучшает читаемость JSP-файла и упрощает процесс отладки в случае обнаружения ошибки.
Далее: Выученные уроки