RU2686032C1 - Способ формирования документа openEHR - Google Patents
Способ формирования документа openEHR Download PDFInfo
- Publication number
- RU2686032C1 RU2686032C1 RU2018119779A RU2018119779A RU2686032C1 RU 2686032 C1 RU2686032 C1 RU 2686032C1 RU 2018119779 A RU2018119779 A RU 2018119779A RU 2018119779 A RU2018119779 A RU 2018119779A RU 2686032 C1 RU2686032 C1 RU 2686032C1
- Authority
- RU
- Russia
- Prior art keywords
- json
- openehr
- template
- document
- data
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 230000015572 biosynthetic process Effects 0.000 claims description 11
- 238000012986 modification Methods 0.000 claims description 7
- 230000004048 modification Effects 0.000 claims description 7
- 238000013502 data validation Methods 0.000 claims description 4
- 238000005516 engineering process Methods 0.000 abstract description 7
- 230000000694 effects Effects 0.000 abstract description 2
- 239000000126 substance Substances 0.000 abstract 1
- 238000005755 formation reaction Methods 0.000 description 9
- 239000002131 composite material Substances 0.000 description 7
- 238000010200 validation analysis Methods 0.000 description 7
- 238000007726 management method Methods 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 6
- 238000012360 testing method Methods 0.000 description 5
- 230000036541 health Effects 0.000 description 4
- 239000000203 mixture Substances 0.000 description 4
- 101100521345 Mus musculus Prop1 gene Proteins 0.000 description 3
- 108700017836 Prophet of Pit-1 Proteins 0.000 description 3
- 238000013480 data collection Methods 0.000 description 3
- 230000036772 blood pressure Effects 0.000 description 2
- 239000003814 drug Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000007630 basic procedure Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000035487 diastolic blood pressure Effects 0.000 description 1
- 201000010099 disease Diseases 0.000 description 1
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000000691 measurement method Methods 0.000 description 1
- 238000000968 medical method and process Methods 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000035488 systolic blood pressure Effects 0.000 description 1
- 238000002604 ultrasonography Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
Landscapes
- Health & Medical Sciences (AREA)
- Engineering & Computer Science (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Изобретение относится к способу формирования документа открытого стандарта управления, хранения и обмена электронными историями болезни (openEHR). Технический результат заключается в автоматизации формирования документа openEHR. В способе собирают на основании выбранного шаблона openEHR данные, которые должны быть записаны в документ openEHR; формируют на основании выбранного шаблона openEHR представление в текстовом формате обмена данными, основанное на JavaScript (JSON), упомянутого шаблона openEHR (далее JSON-шаблон); предоставляют на основании сформированного JSON-шаблона программный интерфейс для работы с JSON представлением документа openEHR (далее JSON-документом); формируют с помощью предоставленного программного интерфейса на основании собранных данных JSON-документ; формируют на основании сформированного JSON-документа документ openEHR. 10 з.п. ф-лы, 5 ил.
Description
Область техники
Техническое решение относится к системам и способам формирования документа 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. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В заключение следует отметить, что приведённые в описании сведения являются примерами, которые не ограничивают объём настоящего изобретения, определённого формулой.
Claims (23)
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-шаблон таким образом, чтобы по меньшей мере:
8. Способ по п. 1, по которому программный интерфейс для работы с JSON-документом представляет совокупность методов, позволяющих осуществлять на основании пути к полю данных JSON-шаблона в упомянутом JSON-документе по меньшей мере:
9. Способ по п. 8, по которому программный интерфейс для работы с JSON-шаблоном воспроизводит объектную модель классов, которая соответствует иерархии архетипов, описанных в исходном шаблоне openEHR, и предоставляет доступ к данным, которые представляют собой объект, класс которого соответствует типам эталонной модели openEHR и у которого определен набор методов для работы с указанными данными.
10. Способ по п. 8, по которому программный интерфейс для работы с JSON-шаблоном предоставляет доступ к данным на основании по меньшей мере:
11. Способ по п. 10, по которому в случае, если название поля данных одного архетипа в разных шаблонах openEHR различается, и способ работы с упомянутым архетипом не является уникальным, то доступ к данным предоставляется на основании AQL пути.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2018119779A RU2686032C1 (ru) | 2018-05-29 | 2018-05-29 | Способ формирования документа openEHR |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2018119779A RU2686032C1 (ru) | 2018-05-29 | 2018-05-29 | Способ формирования документа openEHR |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| RU2686032C1 true RU2686032C1 (ru) | 2019-04-23 |
Family
ID=66314881
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2018119779A RU2686032C1 (ru) | 2018-05-29 | 2018-05-29 | Способ формирования документа openEHR |
Country Status (1)
| Country | Link |
|---|---|
| RU (1) | RU2686032C1 (ru) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2413987C2 (ru) * | 2005-03-04 | 2011-03-10 | Майкрософт Корпорейшн | Шаблон электронной формы |
| EP2478456A2 (en) * | 2009-09-14 | 2012-07-25 | II4SM - International Institute For The Safety Of Medicines Ltd. | Semantic interoperability system for medicinal information |
| CN105512985A (zh) * | 2015-12-29 | 2016-04-20 | 杭州邦泰科技有限公司 | 基于openEHR标准的糖尿病电子病历数据存储方法 |
| US20170039330A1 (en) * | 2015-08-03 | 2017-02-09 | PokitDok, Inc. | System and method for decentralized autonomous healthcare economy platform |
| RU2613026C1 (ru) * | 2015-09-30 | 2017-03-14 | Общество с ограниченной ответственностью "Интерсофт" | Способ подготовки документов на языках разметки при реализации пользовательского интерфейса для работы с данными информационной системы |
| CN106991276A (zh) * | 2017-03-17 | 2017-07-28 | 浙江大学 | 一种基于openEHR模板的数据接口动态生成方法 |
| US9961156B2 (en) * | 2007-09-20 | 2018-05-01 | Intel Corporation | Healthcare semantic interoperability platform |
-
2018
- 2018-05-29 RU RU2018119779A patent/RU2686032C1/ru active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2413987C2 (ru) * | 2005-03-04 | 2011-03-10 | Майкрософт Корпорейшн | Шаблон электронной формы |
| US9961156B2 (en) * | 2007-09-20 | 2018-05-01 | Intel Corporation | Healthcare semantic interoperability platform |
| EP2478456A2 (en) * | 2009-09-14 | 2012-07-25 | II4SM - International Institute For The Safety Of Medicines Ltd. | Semantic interoperability system for medicinal information |
| US20170039330A1 (en) * | 2015-08-03 | 2017-02-09 | PokitDok, Inc. | System and method for decentralized autonomous healthcare economy platform |
| RU2613026C1 (ru) * | 2015-09-30 | 2017-03-14 | Общество с ограниченной ответственностью "Интерсофт" | Способ подготовки документов на языках разметки при реализации пользовательского интерфейса для работы с данными информационной системы |
| CN105512985A (zh) * | 2015-12-29 | 2016-04-20 | 杭州邦泰科技有限公司 | 基于openEHR标准的糖尿病电子病历数据存储方法 |
| CN106991276A (zh) * | 2017-03-17 | 2017-07-28 | 浙江大学 | 一种基于openEHR模板的数据接口动态生成方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Kumar et al. | Big data analytics for healthcare industry: impact, applications, and tools | |
| JP6907831B2 (ja) | コンテキストベースの患者類似性の方法及び装置 | |
| US6263330B1 (en) | Method and apparatus for the management of data files | |
| US10176541B2 (en) | Medical information navigation engine (MINE) system | |
| TWI649762B (zh) | 用於雲端臨床資料庫管理的方法及系統 | |
| Laleci et al. | Providing semantic interoperability between clinical care and clinical research domains | |
| Mantri et al. | DICOM integration libraries for medical image interoperability: a technical review | |
| EP1057133A1 (en) | Method and apparatus for the management of data files | |
| JP2015533437A (ja) | 識別不能化および再識別を用いた医療情報解析のためのシステムおよび方法 | |
| Carvalho et al. | Standardizing clinical trials workflow representation in UML for international site comparison | |
| Sarkar et al. | A conceptual distributed framework for improved and secured healthcare system | |
| JP2021536636A (ja) | 医療記録を分類する方法 | |
| Bona et al. | Enhancing clinical data and clinical research data with biomedical ontologies-insights from the knowledge representation perspective | |
| Kock-Schoppenhauer et al. | Medical Data Engineering–Theory and Practice | |
| Leslie et al. | Archetypes 101 | |
| Amendolia et al. | Grid databases for shared image analysis in the mammogrid project | |
| RU2686032C1 (ru) | Способ формирования документа openEHR | |
| Anbarasi et al. | Ontology based medical diagnosis decision support system | |
| Patange et al. | Semantic interoperability for development of future health care: a systematic review of different technologies | |
| EP3654339A1 (en) | Method of classifying medical records | |
| Ramírez et al. | Big data in healthcare | |
| Schindler et al. | An annotation scheme for references to research artefacts in scientific publications | |
| Shah et al. | Comparative analysis of semantic frameworks in healthcare | |
| Jahan et al. | How Healthcare Industry can Leverage Big Data Analytics Technology and Tools for Efficient Management | |
| Bharaj et al. | AsthmaCheck: multi-level modeling based health information system |