Раздел V. Сериализация и работа сервиса
Сериализация является процессом, при котором объект преобразуется в байтовый поток, чтобы объект можно было хранить в базе данных, файле или памяти. Основная суть сериализации – это сохранение состояния объекта, который может быть воспроизведен, когда это потребуется. В потоке, созданным из объекта при сериализации, хранится информация не только об объектном типе, версии и подобные характеристики, но и имена сборок.
Десериализация – это процесс, который, напротив, преобразует структурированный байтовый поток в объект.
( общая схема сериализации)
Сериализация используется для передачи объектов при обмене данными. Именно данный метод является оптимальным для отправки того или иного объекта с помощью веб-сервисов, чтобы передать объект между доменами, передать объект в виде XML-строки в брэндмауер и хранить данные для использования несколькими приложениями.
XML-сеариализация так же называется двоичной. Особенность данного типа сериализации заключается в том, что сериализации подвергаются даже те элементы, которые имеют статус «только для чтения», в связи с этим увеличивается эффективность работы. Более того двоичная сериализация имеет удобный читабельный вид и приемлемость для грамотной и легкой интеграции систем.
Сериализация имеет ключевую роль в веб-сервисе, так как сообщение между двумя системами (1C.Bitrix и МИС) должно происходить по протоколу MedML. В связи с этим для начала производится описание классов, объекты для которых подвергнутся сериализации. Так как выгрузка на сайт состоит из нескольких списков: выгрузка списка услуг, списка организаций, списка врачей, расписания, изменений, то описывается каждый из классов по отдельности.
Одним из родительских классов является «ИнформацияДляЗаписиНаПрием», которая передает информацию о записи. С помощью System.Xml.Serialization.XmlElementAttribute описываются все элементы данного класса, каждый из которых является самостоятельным классом, на что указывает тип typeof() каждого атрибута.
public partial class ИнформацияДляЗаписиНаПрием {
private object itemField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute("Документ", typeof(Документ))]
[System.Xml.Serialization.XmlElementAttribute("КлассификаторУслуг", typeof(КлассификаторУслуг))]
[System.Xml.Serialization.XmlElementAttribute("Организации", typeof(Организации))]
[System.Xml.Serialization.XmlElementAttribute("ПакетПредложений", typeof(ПакетПредложений))]
[System.Xml.Serialization.XmlElementAttribute("Расписание", typeof(Расписание))]
[System.Xml.Serialization.XmlElementAttribute("Услуги", typeof(Услуги))]
public object Item {
get {
return this.itemField;
}
set {
this.itemField = value;
}
}
}
Изначально система 1С.Bitrix запрашивает общее расписание у МИС, которое в последствии хранится в базе данных сайта. После того как пациент заходит на сайт, он просматривает расписание на необходимые даты. После чего он делает свой выбор, заполняет необходимые данные и отправляет запрос на запись. 1С.Bitrix с помощью своего веб-сервиса отправляет запрос в МИС на подтверждение записи, формируя талон на запись. Данный талон содержит всю необходимую информацию о пациенте, поэтому после получения веб-сервисом данного талона, происходит десериализация и отправка информации в МИС.
Талон имеет следующую структуру:
<?xml version="1.0" encoding="UTF-8"?>
<ИнформацияДляЗаписиНаПрием xmlns="http://medml.ru/standard/MedML.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Документ>
<Ид>2396909670</Ид>
<Дата>2013-04-16T11:50:45</Дата>
<Операция>Заказ услуг</Операция>
<Пациент>
<Фамилия>Фамилия</Фамилия>
<Имя>Имя</Имя>
<Отчество>Отчество</Отчество>
</Пациент>
<Услуги>
<Услуга>
<ИдСотрудника>dfc34639-0628-11e0-87ee-001c2387a941</ИдСотрудника>
<ИдУслуги>dfc3462c-0628-11e0-87ee-001c2387a941</ИдУслуги>
<ПериодВремени>
<НачалоПериода>2013-04-17T10:35:00</НачалоПериода>
<КонецПериода>2013-04-17T11:00:00</КонецПериода>
</ПериодВремени>
<Статус>Подтверждено</Статус>
</Услуга>
</Услуги>
</Документ>
</ИнформацияДляЗаписиНаПрием>
После того как МИС e-Anamnesis принимает необходимую информацию, она проверят доступность свободного периода, на который происходит попытка записи. Это требуется для того, чтобы исключить ошибку актуальности информации: во время обновления расписания на сайте мог произойти обрыв связи между МИС и сайтом, и на сайте отобразилось расписание, не соответствующее действительности, либо другой пациент отправил запрос на запись раньше, и поэтому данное время уже является занятым.
Именно для таких случаев MedML предусматривает специальное поле подтверждения под названием «Статус». Оно может принимать два значения: «Подтверждено», если запись на данное время произведена успешно и «Отклонено», если запись не может быть сделана. Таким образом после обработки талона медицинской информационной системой, формируется обратный ответ сайту, в котором вся переданная информация остается неизменной кроме поля «Статус». Стоит отметить, что если данный параметр имеет отрицательное значение, то добавляется еще одно поля, которое описывает причину отказа. Пользователю приходит сообщение о статусе записи и по необходимости предлагается выбрать альтернативный вариант.
Изначально 1C.Bitrix запрашивает общее расписание, для заполнения своей внутренней базы.
В базе МИС информация о расписании хранится в виде правил, по которым осуществляется прием. Когда доктор №1 оказывает услугу №1 по вторникам и четвергам с 9:00 до 13:00, нет смысла хранить каждый день по отдельности. Задается правило, которое распространяется на все время, если иное не будет задано.
Стандарт MedML не позволяет в полной мере воспользоваться данным решением правил, так как возможно установка правила только в рамках одного дня. Таким образом выгрузка общего расписания на один день будет иметь следующий вид:
<ИдСотрудника>001</ИдСотрудника>
<ИдПомещения>204</ИдПомещения>
<ПериодРаботы>
<НачалоПериода>2011-03-01T9:00:00Z</НачалоПериода>
<КонецПериода>2011-03-01T13:00:00Z</КонецПериода>
<СвободноеВремяВМинутах>30</СвободноеВремяВМинутах>
</ПериодыРаботы>
<ДоступныеУслуги>
<ИдУслуги>00.000.01</ИдУслуги>
</ДоступныеУслуги>
Это означает, что врач с идентификационным номером 001 осуществляет прием с 9:00 до 13:00 1 марта 2011 года с интервалом 30 минут на каждого пациента по услуге 00.000.01.
После выгрузки общего расписания производится запись на прием и здесь есть два варианта возможности передачи данных.
С одной стороны, можно разбить дневное правило на несколько временных промежутков, каждый из которых будет соответствовать занятому или свободному времени:
<ИдСотрудника>001</ИдСотрудника>
<ИдПомещения>204</ИдПомещения>
<ПериодРаботы>
<НачалоПериода>2011-03-01T9:00:00Z</НачалоПериода>
<КонецПериода>2011-03-01T11:00:00Z</КонецПериода>
<СвободноеВремяВМинутах>30</СвободноеВремяВМинутах>
</ПериодыРаботы>
<ПериодРаботы>
<НачалоПериода>2011-03-01T11:00:00Z</НачалоПериода>
<КонецПериода>2011-03-01T11:30:00Z</КонецПериода>
<СвободноеВремяВМинутах>0</СвободноеВремяВМинутах>
</ПериодыРаботы>
<ПериодРаботы>
<НачалоПериода>2011-03-01T11:30:00Z</НачалоПериода>
<КонецПериода>2011-03-01T13:00:00Z</КонецПериода>
<СвободноеВремяВМинутах>30</СвободноеВремяВМинутах>
</ПериодыРаботы>
<ДоступныеУслуги>
<ИдУслуги>00.000.01</ИдУслуги>
</ДоступныеУслуги>
Данный код показывает, что период с 11:00 до 11:30 является занятым. Однако, если таких промежутков будет достаточное количество, то тогда объем передаваемых данных может увеличиться в разы для полного расписания, и передача буду занимать существенное время и ресурсы. Поэтому наиболее оптимальным решением, которое поддерживается протоколом MedML, является передача талонов записи, в котором отображается занятое время. Если запись происходит в регистратуре медицинского учреждения, то происходит одностороннее оповещение веб-сервиса сайта о записи со статусом «Подтверждено», после чего запись на данное время на сайте становится недоступным.
Если говорить об отображении расписания на нескольких сайтах, так как это имеет место быть, так как помимо собственного сайта организации, может потребоваться возможность записи через портал государственных услуг, а так же через сайты компаний-партнеров, то способ выгрузки расписания в едином формате через веб-сервис является наиболее эффективным, так как один и тот же пакет данных рассылается по всем необходимым направлениям, и дело встает только за пропускной способности канала для передачи такого объема данных. Следует отметить, раз код передается в формате xml, размер даже нескольких записей достаточно внушительный, и запись о 100 услугах может достигать объема в 800-900 КБ.