Данный документ дает общее представление об архитектуре openehr в терминах краткого обзора модели, ключевой глобальной семантики, применения и интеграции
|
Скачать 1.29 Mb.
|
1 Introduction 1.1 Назначение 1.1 Purpose Данный документ дает общее представление об архитектуре openEHR в терминах краткого обзора модели, ключевой глобальной семантики, применения и интеграции архитектур, отношения с изданными стандартами, и, в конечном счете, подход к построению Спецификаций Технологии Реализации (Implementation Technology Specifications). Семантики специфичные для каждой из моделей: информационной, архетипа и сервиса – описаны в модели с соответствующим названием (information model, archetype, service model). This document provides an overview of the openEHR architecture in terms of a model overview, key global semantics, deployment and integration architectures, relationship to published standards, and finally the approach to building Implementation Technology Specifications (ITSs). Semantics specific to each information, archetype and service model are described in the relevant model. Предполагаемая аудитория: The intended audience includes:
Данный документ является ключевым техническим обзором openEHR и должен быть прочитан перед чтением другой технической документации This document is the key technical overview of openEHR, and should be read before all other technical documents. 1.2 Статус(положение) 1.2 Status Этот документ находится в разработке и опубликован как введение в процессы стандартизации и реализации. This document is under development, and is published as a proposal for input to standards processes and implementation works. Данный документ доступен на http://svn.openehr.org/specification/TAGS/Release1.0/publishing/architecture/overview.pdf. Последнюю версию документа можно найти на http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf. Новые версии публикуются на openehr-announce@openehr.org. Места в тексте выделенные голубым цветом находятся в разработке. This document is available at http://svn.openehr.org/specification/TAGS/Release1.0/publishing/architecture/overview.pdf. The latest version of this document can be found at http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf. New versions are announced on openehr-announce@openehr.org. Blue text indicates sections under active development.
1.3 Peer review Области, которые требуют более подробного анализа или объяснения отмечены метками «to be continued »,как например: Areas where more analysis or explanation is required are indicated with “to be continued” paragraphs like the following: To Be Continued: требуется дополнительная работа Поощряется комментарии и/или советы рецензентов относительно таких пометок, а также относительно основного содержимого. Пожалуйста, отправляйте ваши запросы на информацию на info@openEHR.org. Обратная связь обеспечивается через списки рассылки openehr-technical@openehr.org, или частной электронной почтой. Reviewers are encouraged to comment on and/or advise on these paragraphs as well as the main content. Please send requests for information to info@openEHR.org. Feedback should preferably be provided on the mailing list openehr-technical@openehr.org, or by private email. 2 Краткий обзор 2 Overview Данный документ дает общие представления об архитектуре openEHR. Он начинается с описания спецификации проекта, заканчивается кратким обзором структуры и пакетов эталонной модели. Основная глобальная семантика, включая безопасность, версию идентификацию, интерпретацию (version) и пути(paths) описаны далее. Обозначена связь с уже опубликованными стандартами, и в завершении, даны контуры подхода к построению Спецификаций Технологии Реализации (Implementation Technology Specifications-ITSs). This document provides an overview of the openEHR architecture. It commences with a description of the specification project, followed by an overview of the reference model structure and packages. Key global semantics including security, archetyping, identification, version and paths are then described. The relationship to published standards is indicated, and finally, the approach to building Implementation Technology Specifications (ITSs) is outlined.
2.1 The openEHR Specification Project Рисунок 1 иллюстрирует Проект по спецификации openEHR. Этот проект ответственен за развитие спецификаций, на которых основана Здравоохранительная Компьютерная Платформа. Взаимоотношения между частями вычислительной платформы и спецификаций показаны на диаграмме. Проектные составные части включают в себя: абстрактные спецификации, спецификации технологии реализации (ITSs), исчислимые выражения и критерии соответствия. FIGURE 1 illustrates the openEHR Specification Project. This project is responsible for developing the specifications on which the openEHR Health Computing Platform is based. The relationships between the parts of the computing platform and the specifications are indicated on the diagram. The project deliverables include requirements, abstract specifications, implementation technology specifications (ITSs), computable expressions and conformance criteria.  Абстрактная спецификация содержит эталонную модель (RM), сервисную модель (SM) и модель архетипов (АМ). Первые две согласуются с моделью ISO RM/ODP с информационной и вычислительной точек зрения. Последняя приводит в соответствие с формальными требованиями связь между информационными моделями и ресурсами знаний. The abstract specifications consist of the Reference Model (RM), the Service Model (SM) and Archetype Model (AM). The first two correspond to the ISO RM/ODP information and computational viewpoints respectively. The latter formalises the bridge between information models and knowledge resources. Абстрактные спецификации, опубликованные openEHR, описаны с использованием терминологии UML и формальных текстовых спецификаций классов. Эта модель содержит основную эталон для всей семантики openEHR. Представленный вид абстрактной спецификации предназначен специально для понятности и семантической близости к сообщаемым идеям. Таким образом, спецификация не следует идиомам или ограничениям специфики языков программирования, языкам описания схем(в базах данных) или другим формализмам. The abstract specifications published by openEHR are defined using the UML notation and formal textual class specifications. These models constitute the primary references for all openEHR semantics. The presentation style of these abstract specifications is deliberately intended to be clear and semantically close to the ideas being communicated. Accordingly, the specifications do not follow idioms or limitations of particular programming languages, schema languages or other formalisms. Абстрактная спецификация так же доступна в инструментально-ориентированном вычислимом UML- формате для того, чтобы дать возможность развиваться программному обеспечению и системам. Вычислимые выражения для всех практических целей могут рассматриваться, как наиболее точная интерпретация опубликованных абстрактных спецификаций. The abstract specifications are also available in a tool-oriented computable UML format in order to enable development of software and systems. The computable expressions for all practical purposes can be assumed as being a lossless rendition of the published abstract specifications. ITSs, с другой стороны соответствует выражению абстрактных спецификаций различных программных языков и языков описания схем, каждая из которых представляет несовершенную и обычно неполную трансформацию спецификационных моделей. Многочисленные реализации технологий, изменяющихся от языком программирования, последовательных форм представления, каких как XML , до баз данных и распределенных объектных интерфейсов. Каждая из них имеет свои собственные ограничения и достоинства. Реализация любой из абстрактных моделей OpenEHR в заданной реализации технологии – это, в первую очередь, описать ITS для специфической технологии, для его дальнейшего официального использования, затем отобразить абстрактную модель в выражениях этой технологии. The implementation technology specifications on the other hand correspond to the expression of abstract specifications in various programming and schema languages, each of which represents an imperfect and usually partial transformation from the specification models. There are numerous implementation technologies, ranging from programming languages, serial formalisms such as XML, to database and distributed object interfaces. Each of these has its own limits and strengths. The approach to implementing any of the openEHR abstract models in a given implementation technology is to firstly define an ITS for the particular technology, then to use it to formally map the abstract models into expressions in that technology. 3. Цели архитектуры openEHR 3 Aims of the openEHR Architecture
3.1 Overview Этот раздел дает краткое общее представление о требованиях, подкрепляющих архитектуру openEHR. Архитектура openEHR воплощает в себе результаты пятнадцатилетних исследований многочисленных проектов и стандартов во всем мире. Она проектировалась, основываясь на требованиях, которые фиксировались многие годы. This section provides a brief overview of the requirements underpinning the openEHR architecture. The openEHR architecture embodies 15 years of research from numerous projects and standards from around the world. It has been designed based on requirements captured over many years. Так как архитектура достаточно общая, и особенно благодаря управляемости прототипом, она удовлетворяет многим требованиям, выходящим за пределы оригинального понятия “Клинической EHR”. Например, схожая эталонная архитектура может быть использована для ветеринарного здравоохранения, или планомерного контроля общественных инфраструктур, или внесенных в список зданиями. Это возможно благодаря тому факту, что эталонная (базовая) модель объединяет только общие понятия, связанные с обслуживанием и административными мероприятиями, относящихся к объекту охраны (заботы); в архетипах и образцах (шаблонах) описаны особенности разновидностей мероприятий по уходу и объектов наблюдения. С другой стороны, не смотря на то, что одно из требований к OpenEHR EHR являлось «пациенто-центролизованность, продольная (longitudinal), разделенное обслуживание EHR»; Оно не ограничивается этим и возможно использование в особенных случаях, например как система записи рентгенологического отделения. Требования к различным особенностям здравоохранительных записей могут быть классифицированы согласно двум аспектам, областью действия и видом(родом) объекта, как показано на рисунке 2. Because the architecture is highly generic, and particularly due to being archetype-driven, it satisfies many requirements outside the original concept of the “clinical EHR”. For example, the same reference architecture can be used for veterinary health or even “care” of public infrastructure or listed buildings. This is due to the fact that the reference model embodies only concepts relating to “service and administrative events relating to a subject of care”; it is in archetypes and templates that specifics of the kinds of care events and subjects of care are defined. In another dimension, although one of the requirements for the openEHR EHR was a “patient-centric, longitudinal, shared care EHR”, it is not limited to this, and can be used in purely episodic, specialist situations, e.g. as a radiology department record system. Requirements for various flavours of “health care record” can be categorised according to the two dimensions, scope, and kind of subject, as shown in FIGURE 2.  На этом рисунке каждое из отделений представляет собой множество требований, являющееся суперпозицией всех требований, содержащихся внутри отделений. Требования к общим записям по уходу(лечению,здоровью) для любых типов объектов локального использования в верхнем левом отделении. Следующее добавление, соответствующие живым и человеческием субъектам, представлены в отделениях внизу левой части диаграммы. Требования, представленные в самом большом отделении с левой стороны, представляет «локальную систему записей человеческой защиты», так же как рентгенологические записи, клиническая искусственная вентиляция легких и т.д. Дополнительные наборы требований, охваченные квадратами (овалами) большего размера, соответствуют расширенному масштабу содержимого медицинской записи, начиная от целого субъекта (что в результате приводит к продольной медицинской записи (термин под вопросом ), ориентированной на пациента), и вплоть до популяций или групп субъектов, как это делается в медицине популяций (населения) и исследованиях. С точки зрения здравоохранения, важные наборы требований полностью занимают нижний ряд диаграммы.In this figure, each bubble represents a set of requirements, being a superset of all requirements of bubbles contained within it. Requirements for a generic record of care for any kind of subject in a local deployment are represented by the top left bubble. The subsequent addition of requirements corresponding to living subjects and then human subjects is represented by the bubbles down the left side of the diagram. The requirements represented by the largest bubble on the left hand side correspond to “local health records for human care”, such as radiology records, hospital EPRs and so on. Additional sets of requirements represented by wider bubbles going across the diagram correspond to extending the scope of the content of the care record first to a whole subject (resulting in a patient-centric, longitudinal health record) and then to populations or cohorts of subjects, as done in population health and research. From the (human) healthcare point of view, the important requirements groups extend all the way to the bottom row of the diagram. Спускаясь вниз по диаграмме, требования, соответствующие расширяющимся спецификациям субъекта охраны здоровья(от чего угодно да человека) по большей части реализуются с использованием я архитектуры openEHR. Пересекая диаграмму (Going across the diagram), требования соответствующие расширенным границам содержимого записей (от эпизодических (редких) до постоянных) главным образом, изображенные в различных применениях, в общем случае переход от стандартных к распределенным формам, имеющим возможность к взаимодействию. Одной из основных целей OpenEHR сегодня - «Объединение медицинских записей», собранных (найденных) многими полномочными органами на нынешний момент, которые обеспечивают информационную структуру для единой совместной заботы (охраны). Going down the diagram, requirements corresponding to increasing specificity of subject of care (from “any” to “human”) are mostly implemented in openEHR by the use of archetypes. Going across the diagram, the requirements corresponding to increasing scope of record content (from episodic to population) are mainly expressed in different deployments, generally going from standalone to a shared interoperable form. One of the key aspirations for EHRs today is the “integrated care record” sought by many health authorities today1, which provides an informational framework for integrated shared care. В результате подхода, используемого OpenEHR, компоненты и приложения строятся для удовлетворения требований объединения медицинских записей могут также быть использованы, на пример, эпизодическая система записей рентгенологии. As a result of the approach taken by openEHR, components and applications built to satisfy the requirements of an integrated shared care record can also be deployed as (for example) an episodic radiology record system. Некоторые из ключевых требований, появившиеся в период развития от GEHR до openEHR, внесены в список следующей секции, соответствуя некоторым из основных наборов требований, указанных на рисунке 2. Some of the key requirements developed during the evolution of GEHR to openEHR are listed in the following sections, corresponding to some of the major requirements groups of FIGURE 2. |
Похожие:
 |
Servers Данный документ содержит инструкцию по применению системы автоматического тестирования и интеграции системного и прикладного по |
|
Система автоматического тестирования и непрерывной интеграции по руководство пользователя Данный документ содержит руководство пользователя cистемы автоматического тестирования и интеграции системного и прикладного по |
 |
Общество с ограниченной ответственностью Медицинская страховая компания «Медика-Восток» Примечания, состоящие из краткого обзора основных положений учетной политики и прочей пояснительной информации |
|
Концепции и архитектура Данный документ является описанием архитектуры сервера приложений at application Server. Подразумевается, что читатель знаком с принципами... |
|
Ирцв. Подсистема «судебное делопроизводство и статистика» гас «правосудие» Настоящий документ является описанием применения модуля интеграции с участками мировых судей |
|
Контрольная работа по модулю 15 1 Список рекомендуемой литературы. 17 Сформировать у студентов представление об основных понятиях и терминах дисциплины |
|
«изучение электронной системы хронометража tag heueur» 05 июля 2017 Общее представление о системе. Цели изучения. Область применения в конном спорте |
|
Инструкция по экспорту моделей из 3 dsmax в Unity 3 D Разумееться инструкция применима только к уже смоделированной и затекстуренной модели. Инструкций по моделированию и текстурингу,... |
|
§ 3 Программные модели формирования импульсной последовательности При построении мпс необходимо бывает создавать программные модели одной или нескольких микросхем малой или средней степени интеграции... |
|
Руководство по эксплуатации дизеля 1Д12-400; техническое описание... Настоящий эксплуатационный документ предназ начен для обслуживающего и технического персонала, и дает представление об устройстве... |
|
Руководство по установке и эксплуатации внимательно прочтите и сохраните для справки в будущем Перед установкой и началом эксплуатации теплового насоса просим внимательно прочесть данный документ. Здесь содержатся важные рекомендации... |
|
Методическое пособие «Формирование инновационного потенциала педагогов... Формирование инновационного потенциала педагогов и обучающихся в современной школе. Часть Общее представление об одаренности: Методическое... |
|
Инструкция о порядке применения Списка производств, цехов профессий... Постановление Госкомтруда СССР и Президиума вцспс от 21. 11. 75 №273/П-20 «Об утверждении Инструкции о порядке применения Списка... |
|
Статья I. Область применения 90 Закупочной документации на проведение открытой тендерной закупки на право заключения договора на выполнение комплекса мероприятий... |
|
Данный документ вступает в силу по истечении 10 дней после дня его официального опубликования Данный документ вступает в силу по истечении 10 дней после дня его официального опубликования (п. 12 Указа Президента РФ от 23. 05.... |
|
Лекция 1 Археология как историческая Переднем Востоке, юге Средней Азии и в Закавказье. Это дает представление о зонах первоначального земледелия и скотоводства, позволяет... |