この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
導入
この文書は、ウィーン協定を通じて CEN と ISO が共同で発行した 5 部構成の標準シリーズの一部です。このドキュメントでは、このシリーズの他の部分への依存関係が該当するwhere は明示的に記載されています。
包括的で複数の企業にまたがる長期的な電子医療記録は、多くの場合、個々の症状、専門分野、または企業のニーズに合わせて調整された複数の臨床アプリケーション、データベース (およびますます多くのデバイス) を結合することによって実際に実現されます。
これには、さまざまなシステムからの電子医療記録 (EHR) データを、EHR システムとサービスの分散ネットワーク (フェデレーション) 内のインターフェイスとメッセージを支えるために使用される単一の包括的な表現に、または単一の包括的な表現からマッピングできる必要があります。この共通表現は、通信される EHR (または EHR のセット) の一部またはすべてを構成する、考えられる健康記録データを表すのに十分かつ豊富でなければなりません。
EHR に関する国際的な研究に裏付けられた ISO 13606 標準シリーズで採用されたアプローチは、EHR 内のあらゆる種類のデータとデータ構造に適しており、すべてのラベルとコンテキストが含まれる厳密で汎用的な参照モデルを定義することでした。情報は各構成要素の不可欠な部分です。 EHR 抽出 (ISO 13606-1 で定義) には、たとえその構成や臨床内容の性質が事前に「合意」されていない場合でも、受信時に忠実に解釈されるために必要な名前、構造、およびコンテキストがすべて含まれます。 。
ただし、医療記録を大規模に共有し、分散サイト間でその有意義な分析を行うには、参照モデルを介して伝達される臨床 (セマンティック) データ構造に一貫したアプローチを使用して、同等の臨床情報が提供されることも必要です。一貫して表現されています。これは、臨床アプリケーションや分析ツールが異種ソースからの EHR データを安全に処理するために必要です。
0.1 アーキタイプ
したがって、EHR の相互運用性の課題は、考えられるあらゆる種類の健康記録データ構造を一貫した方法で表現するための一般化されたアプローチを考案することです。これは、さまざまな医療分野で必要とされる臨床データセット、値セット、テンプレートなどが多様で複雑であり、臨床実践や医療知識に応じて頻繁に変化することを認識しながら、あらゆる職業、専門分野、またはサービスから生じる記録に対応する必要があります。前進。この要件は、セマンティックな相互運用性という広く認識されている医療情報学の課題の一部です。
この標準シリーズで採用されているアプローチは、医療記録情報の一般的なプロパティを表すために使用される参照モデルと、臨床データの特定の特性のパターンを定義するために使用されるメタデータであるアーキタイプ (アーキタイプ モデルに準拠) を区別します。それぞれの特定の職業、専門分野、またはサービスの要件を表します。
参照モデルは 、オープン分散処理 (ODP) 情報ビューポイント モデルとして指定され、医療記録コンポーネントのグローバルな特性、それらの集約方法、倫理的、法的、出所の要件を満たすために必要なコンテキスト情報を表します。 13606 標準シリーズでは、参照モデルがPart 1 で定義されています。このモデルは、EHR の一般的な構成要素を形成するクラスのセットを定義します。これは電子医療記録の安定した特性を反映しており、分散 (連合) EHR 環境に特定のメッセージまたはインターフェイスとして埋め込まれます (この標準シリーズのPart 5 で指定されているように)
アーキタイプは 、セマンティックな相互運用性、データの一貫性、およびデータ品質を確保するためにコミュニティ内で合意された、名前付きの RECORD_COMPONENT 階層の事前調整された組み合わせです。
EHR_EXTRACT の場合、ISO 13606-1 で定義されているように、アーキタイプは RECORD_COMPONENT サブクラスの特定の階層を指定 (および効果的に制約) し、その名前およびその他の関連する属性値、階層内の任意の点でのオプション性および多重性を定義または制約します。 ELEMENT データ値が取り得るデータ型と値の範囲。また、他の依存関係の制約が含まれる場合もあります。 Archetype インスタンス自体は、Archetype Model として知られる正式なモデルに準拠しています (これは制約モデルであり、ODP Information Viewpoint Model としても指定されます)アーキタイプ モデルは安定していますが、臨床実践が進化するにつれて、個々のアーキタイプ インスタンスが改訂されたり、他のアーキタイプ インスタンスが引き継がれたりする可能性があります。バージョン管理により、新しいリビジョンが以前のリビジョンで作成されたデータが無効にならないことが保証されます。
EHR システム内でアーキタイプを使用して、リポジトリにコミットされた EHR データを管理できます。ただし、この相互運用性標準シリーズの目的では、この標準シリーズが EHR 通信に使用される場合は常に、EHR プロバイダー システム内でのアーキタイプの使用については想定されていません。元の EHR データは、まだアーキタイプ化されていない場合、EHR_EXTRACT を生成するときに、必要に応じて一連のアーキタイプにマッピングできると想定されます。
ISO 13606-1 で定義された参照モデルには、EHR_EXTRACT 内の任意の RECORD_COMPONENT が準拠するアーキタイプを指定するために使用できるプロパティがあります。クラス RECORD_COMPONENT には、その RECORD_COMPONENT が準拠するアーキタイプとノードを識別するための属性Archetype_idが含まれています。
この標準シリーズのPart 3 には、参照アーキタイプのセットが含まれています。これらは、使用前にさらに特殊化される可能性が高い基本アーキタイプです。これらのアーキタイプは、このアーキタイプ モデルのインスタンス例です。
この文書で指定されているアーキタイプ モデルは、もともと openEHR 財団によって開発され、付属書 A で参照されているこのアーキタイプ モデルに準拠したアーキタイプ定義言語を使用してアーキタイプを公開しています。アーキタイプ モデルは、要件と要件を組み込むために共同で更新されてきました。 Clinical Information Modeling Initiative (CIMI) からのモデリング入力。 CIMI は、モデリング言語 (Archetype Modeling Language, AML) をオブジェクト管理グループに提出する作業を行っています。 AML もこの原型モデルに準拠しています。
0.2 アーキタイプのデータ型
ISO 13606-1 と ISO 13606-2 では、異なる目的でデータ型を使用することに注意してください。
Part 1 では、5.3 の ISO 21090 のプロファイルとして、参照モデルのプロパティを表すデータ型を定義します。 ISO 21090 のサブセットでもある Element の値となり得るデータ型は、第 7 条で個別に定義されています。これらのデータ型はすべて、最終的にいわゆる「プリミティブ」データ型 (整数、実数、文字列、ブール値、日付/時刻/日時)
Part 2 では、同じプリミティブ データ型のセットを使用して、アーキタイプ オブジェクト モデルのプロパティを表します。さらに、 Part 2 では、 Part 1 のプリミティブ データ型に対する制約を定義できるクラスのセットを定義します。これらの制約クラスは、C_PRIMITIVE_OBJECT クラスの子孫としてPart 2 の図 9 に示されています。
単一のPart 1 複合データ型 (PHYSICAL_QUANTITY など) は、アーキタイプ オブジェクト モデルの制約クラスの組み合わせによって制約され、それに含まれる複合データ型とプリミティブ データ型の両方に対する制約を定義できます。したがって、 Part 2 で制約を定義する場合、 Part 1 の複合データ型はクラスとして扱われますが、 Part 1 のプリミティブ データ型は C_PRIMITIVE_OBJECT 階層によって制約されます。
PHYSICAL_QUANTITY アーキタイプの例を以下の例に示します。この例では、PHYSICAL_QUANTITY の値は 0.0 から 1000.0 の間であり、その単位は UCUM 'mm[Hg]' コードである必要があります。
| PHYSICAL_QUANTITY は{ と一致します |
| 値は{|0.0..<1000.0|} と一致します |
| 単位は{ と一致します |
| CODED_SIMPLE は{ と一致します |
| 値は{"mm[Hg]"} と一致します |
| } |
| } |
| } |
このアーキタイプの例は、アーキタイプ オブジェクト モデルの観点から表現すると、表 1 に示す構造になります。
表1物理量を表す構造例
| 参照モデルのクラス、属性、またはプリミティブ値 | アーキタイプモデル制約クラス |
|---|---|
| PHYSICAL_QUANTITY | C_COMPLEX_OBJECT |
| 価値 | C_属性 |
| 本物 | C_REAL |
| 単位.単位 | C_属性 |
| CODED_SIMPLE | C_COMPLEX_OBJECT |
| 価値 | C_属性 |
| 弦 | C_STRING |
アーキタイプ オブジェクト モデルは、openEHR 参照モデルなどの他の参照モデルを制約するためにも使用されるため、openEHR アーキタイプを ISO 13606 アーキタイプに、またはその逆に変換する必要があります。 openEHR 参照モデルも同じプリミティブ データ型を使用しますが、 DV_ORDINAL や DV_TEXT 1などの異なる複雑なデータ型のセットが含まれています。 openEHR アーキタイプ制約を ISO 13606 アーキタイプに変換する場合、同等の openEHR サブコンポーネントを ELEMENT として表す追加の CLUSTER 構造を導入することが必要になる場合があります。
たとえば、ISO 13606 での openEHR DV_ORDINAL の表現は、表 2 に示す構造になります。
表 2 —順序データ値を表す構造の例
| オープンEHR | ISO13606 |
|---|---|
| DV_ORDINAL | CLUSTER は{ -- DV_ORDINAL と一致します |
| 部分が一致する{ | |
| シンボル | ELEMENT は{ -- 記号と一致します |
| 値は{ と一致します | |
| DV_CODED_TEXT | CODED_VALUE は{*} と一致します |
| } | |
| } | |
| 価値 | ELEMENT は{ -- 値と一致します |
| 値は{ と一致します | |
| 整数 | INTEGER は{*} に一致します |
| } | |
| } | |
| } | |
| } |
この標準シリーズのPart 1 で定義された LINK クラスを、この文書で定義されたアーキタイプ オブジェクト モデルを使用してどのように表現できるかの例を付録 B に示します。
0.3 アーキタイプ リポジトリ
共有される EHR コミュニティ内で必要とされる原型の範囲は、その臨床活動の範囲によって異なります。国家ベースで必要なセットの合計は現時点では不明ですが、最終的には世界中で数千のアーキタイプが存在する可能性があります。このような原型の定義を作成するための理想的な知識源は、臨床ガイドライン、ケア経路、科学出版物、およびその他のベストプラクティスの実施形態です。ただし、合意された臨床データ構造の「事実上の」ソースには、次のものも含まれる場合があります。
- 既存の臨床システムのデータ スキーマ (モデル)
- これらのシステムがデータ入力や実行された分析の表示に使用するコンピュータ画面フォームのレイアウト。
- これらのシステムで使用されるデータ入力テンプレート、ポップアップ リスト、ルックアップ テーブル。
- 地域および全国で使用される共有ケアデータセット、メッセージ、レポート。
- 紙の記録内の臨床相談または要約の文書化に使用されるフォームの構造。
- 二次データ収集で使用される健康情報。
- 用語システムにおける事前に調整された用語。
臨床データ構造が現在表現されている事実上の方法のこのリストにもかかわらず、これらの形式が多大な費用をかけずに相互運用できることはほとんどありません。標準化されたアーキタイプの使用により、これらの仕様を表現および共有するための相互運用可能な方法が提供され、一貫した (高品質の) 医療記録管理と共有 EHR のセマンティックな相互運用性がサポートされます。
国家医療サービス、学術団体、専門機関がアーキタイプの開発に関与することで、このアプローチが科学的根拠に基づいた質の高い臨床実践の追求に貢献できるようになります。次の重要な課題は、アーキタイプのライブラリを構築するコミュニティを育成することです。この研究がどのように進められるべきかを主張することはこの文書の範囲を超えていますが、これまでのところいくつかの国では、国の eHealth プログラムが臨床情報学ベンダーのチームを組織し、臨床情報学ベンダーのチームを組織し、要求を満たすための一連の原型を開発および運用し始めているようです。特定のヘルスケア領域のニーズ。将来的には、アーキタイプ定義の地域または国のパブリック ドメイン ライブラリがインターネット経由でアクセスされ、EHR システム内でローカルに使用するためにダウンロードされる可能性があります。このような使用には、共有アーキタイプの品質を検証および認証するプロセスも必要になります。これもこの文書の範囲を超えていますが、オープン EHR 財団 ( www.openehr.org )、 Clinical Information Modeling Initiativ, EN13606 Associatio, および European Institute for Innovation through Health Data ( www.i-hd.eu )
0.4 原型の伝達
この文書は、第 6 項で包括的で相互運用可能なアーキタイプ表現の要件を指定し、第 7 項でアーキタイプ オブジェクト モデルの ODP 情報ビューポイント表現を定義します。
このドキュメントは、EHR サービスと連携してアーキタイプを作成、保存、またはデプロイするために使用されるアーキタイプ リポジトリ、サービス、またはコンポーネントの内部アーキテクチャとして特定のモデルを採用することを要求しません。 EHR 共有コミュニティ内で EHR 通信と相互運用性をサポートするには、これらのアーキタイプがこの文書で定義されているアーキタイプ オブジェクト モデルにマッピングできる必要があります。
アーキタイプのより詳細な概要は、ここで見つけることができます。
http://www.openehr.org/releases/AM/latest/docs/Overview/Overview.html
Introduction
This document is part of a five-part standard series, published jointly by CEN and ISO through the Vienna Agreement. In this document dependency upon any of the other parts of this series is explicitly stated where it applies.
Comprehensive, multi-enterprise and longitudinal electronic health records will often in practice be achieved through the joining up of multiple clinical applications, databases (and increasingly devices) that are each tailored to the needs of individual conditions, specialties or enterprises.
This requires that Electronic Health Record (EHR) data from diverse systems be capable of being mapped to and from a single comprehensive representation, which is used to underpin interfaces and messages within a distributed network (federation) of EHR systems and services. This common representation has to be sufficiently generic and rich to represent any conceivable health record data, comprising part or all of an EHR (or a set of EHRs) being communicated.
The approach adopted in the ISO 13606 standards series, underpinned by international research on the EHR, has been to define a rigorous and generic Reference Model that is suitable for all kinds of data and data structures within an EHR, and in which all labelling and context information is an integral part of each construct. An EHR Extract (as defined in ISO 13606-1) will contain all of the names, structure and context required for it to be interpreted faithfully on receipt even if its organisation and the nature of the clinical content have not been “agreed” in advance.
However, the wide-scale sharing of health records, and their meaningful analysis across distributed sites, also requires that a consistent approach is used for the clinical (semantic) data structures that will be communicated via the Reference Model, so that equivalent clinical information is represented consistently. This is necessary in order for clinical applications and analysis tools safely to process EHR data that have come from heterogeneous sources.
0.1 Archetypes
The challenge for EHR interoperability is therefore to devise a generalised approach to representing every conceivable kind of health record data structure in a consistent way. This needs to cater for records arising from any profession, speciality or service, whilst recognising that the clinical data sets, value sets, templates etc. required by different health care domains will be diverse, complex and will change frequently as clinical practice and medical knowledge advance. This requirement is part of the widely acknowledged health informatics challenge of semantic interoperability.
The approach adopted by this standard series distinguishes a Reference Model, used to represent the generic properties of health record information, and Archetypes (conforming to an Archetype Model), which are meta-data used to define patterns for the specific characteristics of the clinical data that represent the requirements of each particular profession, speciality or service.
The Reference Model is specified as an Open Distributed Processing (ODP) Information Viewpoint model, representing the global characteristics of health record components, how they are aggregated, and the context information required to meet ethical, legal and provenance requirements. In the 13606 standards series, the Reference Model is defined in Part 1. This model defines the set of classes that form the generic building blocks of the EHR. It reflects the stable characteristics of an electronic health record, and would be embedded in a distributed (federated) EHR environment as specific messages or interfaces (as specified in Part 5 of this standard series).
Archetypes are effectively pre-coordinated combinations of named RECORD_COMPONENT hierarchies that are agreed within a community in order to ensure semantic interoperability, data consistency and data quality.
For an EHR_EXTRACT, as defined in ISO 13606-1, an archetype specifies (and effectively constrains) a particular hierarchy of RECORD_COMPONENT sub-classes, defining or constraining their names and other relevant attribute values, optionality and multiplicity at any point in the hierarchy, the datatypes and value ranges that ELEMENT data values can take, and might include other dependency constraints. Archetype instances themselves conform to a formal model, known as an Archetype Model (which is a constraint model, also specified as an ODP Information Viewpoint Model). Although the Archetype Model is stable, individual archetype instances can be revised or succeeded by others as clinical practice evolves. Version control ensures that new revisions do not invalidate data created with previous revisions.
Archetypes can be used within EHR systems to govern the EHR data committed to a repository. However, for the purposes of this interoperability standard series, no assumption is made about the use of archetypes within the EHR Provider system whenever this standard series is used for EHR communication. It is assumed that the original EHR data, if not already archetyped, can be mapped to a set of archetypes, if desired, when generating the EHR_EXTRACT.
The reference model defined in ISO 13606-1 has a property that can be used to specify the archetype to which any RECORD_COMPONENT within an EHR_EXTRACT conforms. The class RECORD_COMPONENT includes an attribute archetype_id to identify the archetype and node to which that RECORD_COMPONENT conforms.
Part 3 of this standard series includes a set of Reference Archetypes: which are base archetypes that are likely to be specialised further before they are used. Those archetypes are example instances of this Archetype Model.
The Archetype Model specified in this document was originally developed by the openEHR Foundation, which publishes its archetypes using Archetype Definition Language, conforming to this Archetype Model, referenced within Annex A. The Archetype Model has been the subject of collaborative updating to incorporate the requirements and modelling inputs from the Clinical Information Modeling Initiative (CIMI). CIMI is in the process of submitting a modelling language (Archetype Modeling Language, AML) to the Object Management Group. AML also aligns to this Archetype Model.
0.2 Archetype datatypes
It should be noted that ISO 13606-1 and ISO 13606-2 use datatypes for different purposes.
Part 1 defines datatypes to represent the properties of the Reference Model, as a profile of ISO 21090, in 5.3. It separately defines in Clause 7 the data types that can be the values of Element, also a subset of ISO 21090. All these datatypes are finally expressed in terms of the so-called “primitive” datatypes (Integer, Real, String, Boolean, Date/Time/Datetime).
Part 2 uses the same set of primitive datatypes to represent the properties of the Archetype Object Model. Additionally, Part 2 defines a set of classes that allow defining constraints over primitive datatypes of Part 1. These constraining classes are shown in Figure 9 of Part 2, as descendants of the C_PRIMITIVE_OBJECT class.
A single Part 1 complex datatype (e.g. PHYSICAL_QUANTITY) can be constrained by a combination of the constraining classes of the Archetype Object Model, defining constraints on both the complex and primitive datatypes it contains. Thus, Part 1 complex datatypes are treated as classes when defining constraints with Part 2, while Part 1 primitive data types are constrained by the C_PRIMITIVE_OBJECT hierarchy.
An example of a PHYSICAL_QUANTITY archetype can be seen in the example below. In this example, the value on a PHYSICAL_QUANTITY shall be between 0.0 and 1000.0 and their units shall be UCUM ‘mm[Hg]’ code.
| PHYSICAL_QUANTITY matches{ |
| value matches{|0.0..<1000.0|} |
| units matches{ |
| CODED_SIMPLE matches{ |
| value matches{"mm[Hg]"} |
| } |
| } |
| } |
This example archetype, expressed in terms of the Archetype Object Model, would have the structure shown in Table 1.
Table 1 — Example structure for representing physical quantity
| Reference Model class, attribute or primitive value | Archetype Model constraining class |
|---|---|
| PHYSICAL_QUANTITY | C_COMPLEX_OBJECT |
| value | C_ATTRIBUTE |
| Real | C_REAL |
| units | C_ATTRIBUTE |
| CODED_SIMPLE | C_COMPLEX_OBJECT |
| value | C_ATTRIBUTE |
| String | C_STRING |
Since the Archetype Object Model is also used to constrain other reference models, as for example the openEHR Reference Model, there will be a need to transform openEHR archetypes to ISO 13606 archetypes, and vice versa. The openEHR Reference Model also uses the same primitive datatypes, but includes a different set of complex datatypes, such as DV_ORDINAL, or DV_TEXT 1 . When transforming an openEHR archetype constraint to an ISO 13606 archetype, it might be necessary to introduce an additional CLUSTER structure to represent the equivalent openEHR sub-components as ELEMENTs.
For example, a representation of an openEHR DV_ORDINAL in ISO 13606 would have the structure shown in Table 2.
Table 2 — Example structure for representing an ordinal data value
| openEHR | ISO 13606 |
|---|---|
| DV_ORDINAL | CLUSTER matches{ -- DV_ORDINAL |
| parts matches{ | |
| symbol | ELEMENT matches{ -- symbol |
| value matches{ | |
| DV_CODED_TEXT | CODED_VALUE matches{*} |
| } | |
| } | |
| value | ELEMENT matches{ -- value |
| value matches{ | |
| Integer | INTEGER matches{*} |
| } | |
| } | |
| } | |
| } |
An example of how the LINK class defined in Part 1 of this standard series can be represented using the Archetype Object Model defined in this document is given in Annex B.
0.3 Archetype repositories
The range of archetypes required within a shared EHR community will depend upon its range of clinical activities. The total set needed on a national basis is presently unknown, but there might eventually be several thousand archetypes globally. The ideal sources of knowledge for developing such archetype definitions will be clinical guidelines, care pathways, scientific publications and other embodiments of best practice. However, “de facto” sources of agreed clinical data structures might also include:
- the data schemata (models) of existing clinical systems;
- the lay-out of computer screen forms used by these systems for data entry and for the display of analyses performed;
- data-entry templates, pop-up lists and look-up tables used by these systems;
- shared-care data sets, messages and reports used locally and nationally;
- the structure of forms used for the documentation of clinical consultations or summaries within paper records;
- health information used in secondary data collections;
- the pre-coordinated terms in terminology systems.
Despite this list of de facto ways in which clinical data structures are currently represented, these formats are very rarely interoperable without substantial costs. The use of standardised archetypes provides an interoperable way of representing and sharing these specifications, in support of consistent (good quality) health care record-keeping and the semantic interoperability of shared EHRs.
The involvement of national health services, academic organisations and professional bodies in the development of archetypes will enable this approach to contribute to the pursuit of quality evidence-based clinical practice. A key next challenge is to foster communities to build up libraries of archetypes. It is beyond the scope of this document to assert how this work should be advanced, but in several countries so far it would appear that national eHealth programmes are beginning to organise clinical-informatics-vendor teams to develop and operationalise sets of archetypes to meet the needs of specific healthcare domains. In the future regional or national public domain libraries of archetype definitions might be accessed via the Internet, and downloaded for local use within EHR systems. Such usage will also require processes to verify and certify the quality of shared archetypes, which are also beyond the scope of this document but are being taken forward by not for profit organisations such as the open EHR Foundation ( www.openehr.org ), the Clinical Information Modeling Initiative (CIMI, http://www.opencimi.org ) the EN13606 Association ( http://www.en13606.org ) and the European Institute for Innovation through Health Data ( www.i-hd.eu ).
0.4 Communicating archetypes
This document specifies, in Clause 6, the requirements for a comprehensive and interoperable archetype representation and defines, in Clause 7, the ODP Information Viewpoint representation for the Archetype Object Model.
This document does not require that any particular model be adopted as the internal architecture of archetype repositories, services or components used to author, store or deploy archetypes in collaboration with EHR services. It does require that these archetypes are capable of being mapped to the Archetype Object Model defined in this document in order to support EHR communication and interoperability within an EHR-sharing community.
A more detailed overview of archetypes can be found here:
http://www.openehr.org/releases/AM/latest/docs/Overview/Overview.html