Способ формирования документа openEHR Российский патент 2019 года по МПК G16H10/00 G16H10/60 

Область техники

Техническое решение относится к системам и способам формирования документа openEHR, а более конкретно к формированию документа openEHR с помощью использования JSON представления шаблона openEHR.

Уровень техники

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

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

В последнее время всё большую популярность набирают системы управления, хранения и предоставления доступа к электронным историям болезни (англ. EHR, electronic health record). Такие системы позволяют длительное время хранить информацию о пациентах, обрабатывать и анализировать эту информацию и предоставлять пользователям (например, лечащим врачам) в удобном виде.

Таким образом, на первый план выходит задача разработки эффективных программных интерфейсов (англ. API, application programming interface), которые позволили бы упростить и ускорить создание программного обеспечения и сервисов для работы с электронными историями болезни. К примеру, одним из таких технологий является openEHR (англ. open electronic health records – открытый стандарт управления, хранения и обмена электронными историями болезни), однако большое количество полей данных, правил и вложений в openEHR документах может вызывать сложности при работе с упомянутыми openEHR документами. Для решения подобных проблем создают дополнительные интерфейсы (в том числе представляющие собой «надстройки» над интерфейсом openEHR), обеспечивающие более простое создание и редактирование EHR документов.

В публикации CN106991276A описывается способ динамической генерации интерфейса данных на основе шаблона openEHR, для чего разбирают шаблон openEHR, получают структуру медицинской базы данных, соответствующей атрибутам шаблона openEHR, перехватывают HTTP запросы клиента и формируют SQL запросы к упомянутой базе данных.

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

Описанные выше технологии хорошо справляются с управлением данными в EHR системах, тем не менее они не лишены некоторых недостатков, исправить которые направлена описываема ниже технология формирования документов openEHR.

Настоящее изобретение позволяет решать задачу формирования документа openEHR.

Раскрытие технического решения

Техническое решение предназначено для формирования документа openEHR.

Технический результат настоящего технического решения заключается в формировании документа openEHR с помощью использования JSON представления шаблона openEHR и документа openEHR.

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

В другом частном случае реализации способа шаблон openEHR представляет собой совокупность правил формирования документа openEHR.

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

В другом частном случае реализации способа JSON-шаблон представляет собой совокупность правил формирования JSON-документа.

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

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

Дополнительно в одном частном случае реализации способа формируют JSON-шаблон таким образом, чтобы по меньшей мере: физический размер JSON-шаблона был меньше физического размера шаблона openEHR, на основании которого формируется упомянутый JSON-шаблон; количество полей данных в JSON-шаблоне было меньше количества полей данных в шаблоне openEHR, на основании которого формируется упомянутый JSON-шаблон.

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

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

В другом частном случае реализации способа программный интерфейс для работы с JSON-шаблоном предоставляет доступ к данным на основании по меньшей мере: JSON пути; AQL пути.

Дополнительно в одном частном случае реализации способа в случае, если название поля данных одного архетипа в разных шаблонах openEHR различается, и способ работы с упомянутым архетипом не является уникальным, то доступ к данным предоставляется на основании AQL пути.

Краткое описание чертежей

Фиг. 1 представляет пример системы формирования документа openEHR.

Фиг. 2 представляет пример способа формирования документа openEHR.

Фиг. 3 представляет пример архетипа openEHR.

Фиг. 4 представляет пример шаблона openEHR.

Фиг. 5 представляет пример компьютерной системы общего назначения.

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

Описание вариантов осуществления технического решения

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

Введём ряд определений и понятий, которые будут использоваться при описании вариантов осуществления изобретения.

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript.

openEHR — открытый стандарт управления, хранения и обмена электронными историями болезни (ЭИБ).

В openEHR, все клинические данные о пациенте:

• хранятся в течение всей его жизни;

• формат данных не должен зависеть от организации, разместившей эту информацию;

• размещённая информация ориентирована на человека.

Спецификация openEHR также может включать информационную модель и специализированные службы:

• для электронной истории болезни,

• для хранения данных о демографии (пациентах и лечащего персонала),

• организации лечебного процесса, архетипов.

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

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

Например, архетип для измерения кровяного давления openEHR-EHR-OBSERVATION.blood_pressure.v1 имеет следующую структуру, которая содержит параметры систолического и диастолического давления, метод измерения, положение пациента при измерении и т.д. (см. Фиг. 3).

Архетип представляет собой максимальный набор данных, который описывает клиническое явление. Архетип включает в себя набор полей как простых, так и составных. Архетипы объединяются в шаблон openEHR. В рамках шаблона openEHR архетипы могут быть скорректированы и вложены друг в друга. Таким образом иерархия шаблона openEHR становится сложной.

Например, шаблон может иметь вид, изображённый на Фиг. 4.

Фиг. 1 представляет пример системы формирования документа openEHR.

Система формирования документа openEHR состоит из средства выборки шаблонов openEHR 110, базы шаблонов openEHR 101, средства сбора данных 120, средства формирования JSON-шаблонов 130, средства предоставления интерфейса 140, средства формирования документов openEHR 150, документа openEHR 151.

В одном из вариантов реализации описываемая система представляет собой совокупность методов для работы с документами openEHR, являясь по сути некоторой «оболочкой» над стандартным функционалом работы с документами openEHR. При этом описываемая система предоставляет API для работы с документами openEHR.

Например, описываемая система может быть предоставлена в виде библиотеки (npm библиотеки).

Ещё в одном примере основным назначением описываемой системы может быть предоставление доступа на чтение, запись или удаление к любому элементу документа openEHR 151 (т.е. по сути доступ на модификацию элемента документа openEHR). К примеру, для чтения и редактирования должности медработника из контекстной информации, описанной в контекстном блоке openEHR композиции.

Средство выборки шаблонов openEHR 110 предназначено для:

• выборки шаблона openEHR 111 из базы шаблонов openEHR 101;

• передачи выбранного шаблона openEHR 111 средству сбора данных 120, средству формирования JSON-шаблонов 130.

Например, выборка шаблона openEHR 111 может производиться в зависимости от задачи, к примеру, врач-терапевт перед началом осмотра пациента выбирает соответствующий шаблон openEHR 111 «первичный медицинский осмотр».

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

В одном из вариантов реализации системы шаблон openEHR 111 представляет собой совокупность правил формирования документа openEHR 151.

Ещё в одно варианте реализации системы шаблон openEHR 111 представляет собой XML документ.

Ещё в одном варианте реализации системы шаблоны openEHR 111 из базы шаблонов openEHR 101 созданы заранее любым известным из уровня техники способом (например, на основании анализа созданных ранее документов openEHR и на основании требований, предъявляемых к системам openEHR).

Ещё в одном варианте реализации системы используемый шаблон openEHR (англ. Operational Template) представляет собой XML документ. Особенность такого шаблона заключается в том, что шаблон включает в себя описание всех используемых архетипов. Таким образом каждый шаблон является самодостаточным. В среднем, файл шаблона openEHR имеет размер 400-500 Кб, но может достигать и нескольких мегабайт, в случае сложного шаблона, например, осмотр врача терапевта.

Средство сбора данных 120 предназначено для:

• сбора на основании выбранного шаблона openEHR 111 данных 121, которые должны быть записаны в документ openEHR 151;

• передачи собранных данных средству формирования документов openEHR 150.

Например, в качестве собираемых данных могут выступать:

• клинические данные пациента (например, результаты осмотра пациента врачом, давление, пульс и т.д., назначение исследований, заключения, назначение медикаментов, направление на консультацию и т.д.);

• описание назначенных пациента медицинских процедур.

Средство формирования JSON-шаблонов 130 предназначено для:

• формирования на основании выбранного шаблона openEHR 111 JSON представление упомянутого шаблона openEHR 131 (далее JSON-шаблон);

• передачи сформированного JSON-шаблона 131 средству предоставления интерфейса 140.

В одном из вариантов реализации системы JSON-шаблон 131 представляет собой совокупность правил формирования JSON-документа 151.

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

Например, JSON-объект 131 может иметь вид

Идентификатором для поля «prop1» является «test.instruction.activity1.prop1» или «test.instruction[0].activity1[0].prop1[0]».

Ещё в одно варианте реализации системы путь к полю данных JSON-шаблона 131 представляет собой строку.

Ещё в одно варианте реализации системы формируют JSON-шаблон 131 таким образом, чтобы по меньшей мере:

физический размер JSON-шаблона 131 был меньше физического размера шаблона openEHR 111, на основании которого формируется упомянутый JSON-шаблон 131;

количество полей данных в JSON-шаблоне 131 было меньше количества полей данных в шаблоне openEHR 111, на основании которого формируется упомянутый JSON-шаблон 131.

Средство предоставления интерфейса 140 предназначено для:

предоставления на основании сформированного JSON-шаблона 131 программный интерфейс (англ. API) для работы с JSON представлением документа openEHR 141 (далее JSON-документом); передачи предоставленного интерфейса средству формирования документов openEHR 150.

Например, API для работы с документом openEHR реализует программный интерфейс, который содержит следующие методы для работы с объектным представлением документа:

Метод get предоставляет доступ для работы с элементами документа, каждый элемент представляет собой экземпляр класса, соответствующий типу openEHR Reference Model и содержит вспомогательные методы для работы с ним и реализуют интерфейс DvBase.

Типы элементов DvBase могут быть простыми (или базовыми BasicType) или составными (ComplexType). Базовые типы представляют собой конечные узлы в JSON представлении документа и не могут содержать вложенных элементов. Составные (или сложные или композитные) типы могут содержать вложенные элементы других типов как простых, так и составных. Например, составной тип Composition является корневым для любого документа openEHR.

Базовый интерфейс DvBase содержит следующие методы:

Метод Описание getType():RmType Тип элемента из перечисления RmType, тип из Reference Model getData():any JSON представление элемента validate(save: boolean): Array<ValidationMessage> Валидация элемента (если save = false, происходит проверка корректности заполнения элементов и наличие обязательных элементов, save = true - происходит проверка корректности заполненных / измененных элементов). save():void Сохранение элемента в исходном Composition

Простые типы содержат следующие методы, объявленные в интерфейсе BasicType унаследованный от DvBase:

Метод Описание getPath():string Путь элемента getIsNew() : boolean Признак, новый или существующий элемент checkModified(): boolean Признак, что элемент был изменен assign(other: DvBase) Метод позволяет присвоить значение другого элемента такого же типа setDeleted(deleted: boolean) Пометить элемент как удаленный isDeleted() Признак того, что элемент удаленный

Составные типы наследуют все базовые типы и содержат дополнительные, объявленные в интерфейсе ComplexType унаследованный от BasicType и OpenEHRObject:

Метод Описание getAllProperties(): Array<DvBase> Получить все возможные дочерние элементы getMany<T extends DvBase>(path: string): Array<T> Получить множество элементов по относительному пути find(criteria: FindCriteria): Array<DvBase> Осуществляет поиск дочерних элементов по критерию get<T extends DvBase>(path: string): T Возвращает вложенные элементы по абсолютному или относительному пути set(value: DvBase) Создает или обновляет элемент в исходном объекте Composition getData() : any Позволяет получить ссылку на структуру данных типа

В одном из вариантов реализации системы программный интерфейс для работы с JSON-документом 141 представляет совокупность методов, позволяющих осуществлять на основании пути к полю данных JSON-шаблона 131 в упомянутом JSON-документе 151 по меньшей мере:

поиск данных и доступ к данным;

модификацию данных;

валидацию данных.

Пример создания и редактирования наименования должности автора документа:

Пример поиска элементов заданного типа:

Пример поиска элементов по идентификатору архетипа:

Индексатор элементов в пути является опциональным, путь из примера выше идентичен следующему:

test.context.подробности_контекста.автор_информации.наименование_должности

Для создания новых элементов можно использовать символ '*'. Например, путь:

test.context.подробности_контекста.автор_информации[*].наименование_должности

добавляет нового автора информации в контекст документа.

Пример редактирования контекстной информации, доступ к контекстной информации осуществляется по относительному пути «context»:

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

Для валидации необходимо выполнить метод validate:

validate(save: boolean): Array<ValidationMessage> Валидация элемента (если save = false, происходит проверка корректности заполнения элементов и наличие обязательных элементов, save = true - происходит проверка корректности заполненных / измененных элементов).

Например:

Ещё в одно варианте реализации системы программный интерфейс для работы с JSON-шаблоном 131 воспроизводит объектную модель классов, которая соответствует иерархией архетипов, описанных в исходном шаблоне openEHR 111, и предоставляет доступ к данным, которые представляют собой объект, класс которого соответствует типам эталонной модели (англ. Reference Model) openEHR и у которого определён набор методов для работы с указанными данными.

Следующий пример работает с архетипами Action и Instruction:

Ещё в одно варианте реализации системы программный интерфейс для работы с JSON-шаблоном 131 предоставляет доступ к данным на основании по меньшей мере:

JSON пути;

AQL пути.

Например, AQL путь может иметь следующий вид: «/context/other_context[at0003]/items[openEHR-EHR-CLUSTER.com»).

Пример JSON пути:

Пример AQL пути:

Ещё в одно варианте реализации системы в случае, если название поля данных одного архетипа в разных шаблонах openEHR 111 различается, и способ работы с упомянутым архетипом не является уникальным, то доступ к данным предоставляется на основании AQL пути.

Средство формирования документов openEHR 150 предназначено для:

формирования с помощью программного интерфейса на основании собранных данных 121 JSON-документа 141;

формирования на основании сформированного JSON-документа 141 документ openEHR 151.

Пример JSON-документа:

Фиг. 2 представляет пример способа формирования документа openEHR.

Способ формирования документа openEHR содержит этап 210, на котором выбирают шаблон openEHR, этап 220, на котором собирают данные, этап 230, на котором формируют JSON-шаблон, этап 240, на котором предоставляют интерфейс, этап 250, на котором формируют JSON-документ, этап 260, на котором формируют документ openEHR 151.

На этапе 210 с помощью средства выборки шаблонов openEHR 110 выбирают из базы шаблонов openEHR 101 шаблон openEHR 111.

В одном из вариантов реализации способа шаблон openEHR 111 представляет собой совокупность правил формирования документа openEHR 151.

Ещё в одно варианте реализации способа шаблон openEHR 111 представляет собой XML документ.

На этапе 220 с помощью средства сбора данных 120 собирают на основании выбранного на этапе 210 шаблона openEHR 111 данные 121, которые должны быть записаны в документ openEHR 151.

На этапе 230 с помощью средства формирования JSON-шаблонов 130 формируют на основании выбранного на этапе 210 шаблона openEHR 111 JSON представление упомянутого шаблона openEHR (далее JSON-шаблон).

В одном из вариантов реализации способа JSON-шаблон 131 представляет собой совокупность правил формирования JSON-документа 151.

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

Ещё в одно варианте реализации способа путь к полю данных JSON-шаблона 131 представляет собой строку.

Ещё в одно варианте реализации способа формируют JSON-шаблон 131 таким образом, чтобы по меньшей мере:

физический размер JSON-шаблона 131 был меньше физического размера шаблона openEHR 111, на основании которого формируется упомянутый JSON-шаблон 131;

количество полей данных в JSON-шаблоне 131 было меньше количества полей данных в шаблоне openEHR 111, на основании которого формируется упомянутый JSON-шаблон 131.

На этапе 240 с помощью средства предоставления интерфейса 140 предоставляют на основании сформированного на этапе 230 JSON-шаблона программный интерфейс (англ. API) для работы с JSON представлением документа openEHR (далее JSON-документом).

В одном из вариантов реализации способа программный интерфейс для работы с JSON-документом 141 представляет совокупность методов, позволяющих осуществлять на основании пути к полю данных JSON-шаблона 131 в упомянутом JSON-документе 151 по меньшей мере:

поиск данных и доступ к данным;

модификацию данных;

валидацию данных.

Ещё в одно варианте реализации способа программный интерфейс для работы с JSON-шаблоном 131 воспроизводит объектную модель классов, которая соответствует иерархией архетипов, описанных в исходном шаблоне openEHR 111, и предоставляет доступ к данным, которые представляют собой объект, класс которого соответствует типам эталонной модели (англ. Reference Model) openEHR и у которого определён набор методов для работы с указанными данными.

Ещё в одно варианте реализации способа программный интерфейс для работы с JSON-шаблоном 131 предоставляет доступ к данным на основании по меньшей мере:

JSON пути;

AQL пути.

Ещё в одно варианте реализации способа в случае, если название поля данных одного архетипа в разных шаблонах openEHR 111 различается, и способ работы с упомянутым архетипом не является уникальным, то доступ к данным предоставляется на основании AQL пути.

На этапе 250 с помощью средства формирования документа openEHR 150 формируют с помощью предоставленного на этапе 240 программного интерфейса на основании собранных на этапе 220 данных JSON-документ.

На этапе 260 с помочью средства формирования документа openEHR 150 формируют на основании сформированного на этапе 250 JSON-документа документ openEHR 151.

Например, JSON-шаблон может иметь вид:

Например, JSON-документ может иметь вид:

Ещё в одном примере создание OpenEHRObject:

Ещё в одном примере модификация параметров:

Фиг. 5 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жёсткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жёсткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жёсткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жёсткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединён к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединён к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащён другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удалёнными компьютерами 49. Удалённый компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 5. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключён к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключён к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

Изобретение относится к способу формирования документа открытого стандарта управления, хранения и обмена электронными историями болезни (openEHR). Технический результат заключается в автоматизации формирования документа openEHR. В способе собирают на основании выбранного шаблона openEHR данные, которые должны быть записаны в документ openEHR; формируют на основании выбранного шаблона openEHR представление в текстовом формате обмена данными, основанное на JavaScript (JSON), упомянутого шаблона openEHR (далее JSON-шаблон); предоставляют на основании сформированного JSON-шаблона программный интерфейс для работы с JSON представлением документа openEHR (далее JSON-документом); формируют с помощью предоставленного программного интерфейса на основании собранных данных JSON-документ; формируют на основании сформированного JSON-документа документ openEHR. 10 з.п. ф-лы, 5 ил.

1. Компьютерно-реализуемый способ формирования документа открытого стандарта управления, хранения и обмена электронными историями болезни (openEHR), который содержит этапы, на которых:

а) собирают на основании выбранного шаблона openEHR данные, которые должны быть записаны в документ openEHR;

б) формируют на основании выбранного шаблона openEHR представление в текстовом формате обмена данными, основанное на JavaScript (JSON), упомянутого шаблона openEHR (далее JSON-шаблон);

в) предоставляют на основании сформированного JSON-шаблона программный интерфейс для работы с JSON представлением документа openEHR (далее JSON-документом);

г) формируют с помощью предоставленного программного интерфейса на основании собранных данных JSON-документ;

д) формируют на основании сформированного JSON-документа документ openEHR.

2. Способ по п. 1, по которому шаблон openEHR представляет собой совокупность правил формирования документа openEHR.

3. Способ по п. 2, по которому шаблон openEHR представляет собой документ XML.

4. Способ по п. 1, по которому JSON-шаблон представляет собой совокупность правил формирования JSON-документа.

5. Способ по п. 4, по которому JSON-шаблон представляет собой структуру в формате JSON, которая содержит по меньшей мере одно поле данных, доступ к которому предоставляется на основании пути, однозначно определяющему указанное поле данных.

6. Способ по п. 5, по которому путь к полю данных JSON-шаблона представляет собой строку.

7. Способ по п. 1, по которому формируют JSON-шаблон таким образом, чтобы по меньшей мере:

физический размер JSON-шаблона был меньше физического размера шаблона openEHR, на основании которого формируется упомянутый JSON-шаблон;

количество полей данных в JSON-шаблоне было меньше количества полей данных в шаблоне openEHR, на основании которого формируется упомянутый JSON-шаблон.

8. Способ по п. 1, по которому программный интерфейс для работы с JSON-документом представляет совокупность методов, позволяющих осуществлять на основании пути к полю данных JSON-шаблона в упомянутом JSON-документе по меньшей мере:

поиск данных и доступ к данным;

модификацию данных;

валидацию данных.

9. Способ по п. 8, по которому программный интерфейс для работы с JSON-шаблоном воспроизводит объектную модель классов, которая соответствует иерархии архетипов, описанных в исходном шаблоне openEHR, и предоставляет доступ к данным, которые представляют собой объект, класс которого соответствует типам эталонной модели openEHR и у которого определен набор методов для работы с указанными данными.

10. Способ по п. 8, по которому программный интерфейс для работы с JSON-шаблоном предоставляет доступ к данным на основании по меньшей мере:

JSON пути;

AQL пути.

11. Способ по п. 10, по которому в случае, если название поля данных одного архетипа в разных шаблонах openEHR различается, и способ работы с упомянутым архетипом не является уникальным, то доступ к данным предоставляется на основании AQL пути.