この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
導入
0.1 序文
この文書の全体的な目標は、単一の治療対象 (患者) の電子医療記録 (EHR) の一部またはすべてを伝達するため、または情報を伝達する必要がある患者グループのために、厳密で安定した情報アーキテクチャを定義することです。一緒にコミュニケーションします (家族など)これは、システムの相互運用性をサポートするためです (付録 C を参照) EHR データを通信 (アクセス、転送、追加、または変更) する必要があるコンポーネント:
- 著者が意図した本来の臨床的意味を維持する。
- EHR データが取得および構成されたコンテキストについて受信者または受信システムに通知するために必要な来歴メタデータを組み込む。
- 著者および治療対象者が意図したデータの機密性を観察し、伝達すること。
この文書では、EHR は永続的な長期的で潜在的に複数の組織または多国籍の医療およびケア提供の記録であり、ほとんどの場合、単一のケア対象 (患者) に関連し、1 つまたは複数の物理システムに作成および保存されると考えています。各被験者の将来の医療について情報を提供し、提供されたケアの医療法的記録を提供するため。これは、ISO 18308:2011 (電子医療記録アーキテクチャの要件) で提供される定義に対応します。
この文書は、EHR システムやコンポーネントの内部アーキテクチャやデータベース設計を指定することを目的としたものではなく、また、特定の設定、領域、または専門分野で EHR データを要求または提供する可能性のある臨床アプリケーションの種類を規定することを目的としたものでもありません。このため、ここで提案する情報モデルは EHR 抽出と呼ばれ、メッセージ、XML ドキュメントまたはスキーマ、またはオブジェクト インターフェイスの定義に使用される可能性があります。これらは、2 つのリポジトリ間で EHR データを通信したり、集中化された地域または国の EHR リポジトリを更新したり、EHR コンポーネント、システム、サービスの分散ネットワーク内で使用したりすることができます。 EHR サービスまたはシステムは、用語、医学知識、ガイドライン、ワークフロー、セキュリティ、個人登録、請求などを提供する他の多くのサービスまたはシステムと対話する必要がありますが、この文書では、そのような対話の永続的な痕跡が存在する場合にのみ、それらの領域について触れています。 EHR 自体に必要であり、通信を可能にするために参照モデルの特定の機能が必要です。
この文書は、EHR システムの設計に実用的で有用な貢献を提供する可能性がありますが、主に、異種臨床システム上に構築された外部インターフェイスまたはメッセージの共通セットとして実現されます。この文書に準拠したインターフェースをサポートする可能性のあるコンポーネントには、電子医療記録システムだけでなく、セキュリティ コンポーネント、ガイドラインおよびワークフロー システム、アラートおよび意思決定支援サービス、個人の健康システムおよびアプリケーション、センサーおよびウェアラブル デバイスなどの他のミドルウェア サービスも含まれます。 、および医療知識管理サービス。この文書は、電子医療記録システムと人口登録システムの間で個人に関するデータを通信する場合や、電子医療記録を使用して (承認された) 研究を実施する場合にも役立つ可能性があります。
この文書は、ウィーン協定を通じて CEN と ISO が共同で発行した 5 部構成の標準シリーズの一部です。
このドキュメントでは、このシリーズの他の部分への依存関係が該当するwhere は明示的に記載されています。
0.2 技術的アプローチ
この文書は、2007 年に CEN によって発行され、2008 年に ISO によって発行されたオリジナルの規格の第 2 バージョンです。この改訂版では、EHR システム開発者や大規模な eHealth プログラムが元の標準を使用して得た経験が考慮されています。これらは、国際調査、広範な 1 対 1 のインタビュー、学術文献のレビュー、および EHR 関連の研究開発に積極的に取り組んでいる多くの専門家との交流を通じて確認されました。また、ISO 18308:2011 (電子医療記録アーキテクチャの要件) の関連要件も満たしています。この改訂版は考慮されており、この文書も使用される他の CEN および ISO 規格および技術仕様、国際用語規格、および HL7: Fast Healthcare Interoperability Resources (FHIR) からの新たな規格と可能な限り整合しています。 ）。この文書の仕様は、openEHR Foundation によって公開された参照モデル仕様、openEHR Foundation および Clinical Information Modeling Initiative (CIMI) によって公開されたアーキタイプ モデルから引用され、可能な限り一致しています。
この文書の情報モデルは、オープン分散処理のための ISO 参照モデル (ISO/IEC 10746-1:1998 ) の情報ビューポイントです。
導入されている EHR システムの多様性を考慮して、この文書では EHR 通信のほとんどの機能を必須ではなくオプションとしています。ただし、EHR 受信者システムで EHR 抽出を安全に処理できるようにするには、ある程度の処方箋が必要です。これは、このシリーズの第 1 部、第 2 部、および第 4 部のモデル内の必須プロパティと、規範的な用語リスト ( Part で定義されています) を通じて反映されています。このシリーズの 3 つ目)
0.3 デュアルモデルアプローチ
EHR の相互運用性の課題は、考えられるあらゆる種類の健康記録データ構造を一貫した方法で表現するための一般化されたアプローチを考案することです。これは、さまざまな医療分野で必要とされる医療データセット、値セット、テンプレートなどは多様かつ複雑であり、臨床実践や医療知識の進歩に伴って頻繁に変化することを認識しながら、あらゆる職業、専門分野、またはサービスから生じる記録に対応する必要があります。 。この要件は、セマンティックな相互運用性という広く認識されている医療情報学の課題の一部です。
この標準シリーズで採用されているアプローチは、この文書で定義され、医療記録情報の一般的なプロパティを表すために使用される参照モデルと、メタデータであるアーキタイプ (このシリーズのPart 2 部で定義されているアーキタイプ モデルに準拠) を区別します。特定の専門職、専門分野、またはサービスごとの要件を表す医療データの特定の特性のパターンを定義するために使用されるデータ。
参照モデルは、 医療記録コンポーネントのグローバルな特性、それらがどのように集約されるか、倫理的、法的、出所の要件を満たすために必要なコンテキスト情報を表します。このモデルは、EHR の一般的な構成要素を形成するクラスのセットを定義します。これは電子医療記録の安定した特性を反映しており、特定のメッセージまたはインターフェイスとして分散 (フェデレーション) EHR 環境に埋め込まれます (このシリーズの第 5 Part で指定されているように)
この一般的な情報モデルは、特定の臨床状況で作成された記録コンポーネントのセットに対応する EHR フラグメントの事前定義クラスの組織構造を伝達および共有する正式な方法によって補完される必要があります。これらは、相互運用性、データの一貫性、およびデータ品質を確保するためにコミュニティ内で合意された、名前付き RECORD_COMPONENT 階層の事前調整された組み合わせです。
アーキタイプは、 特定の臨床領域または組織の参照モデルで定義された構成要素クラスの規定の組み合わせの正式な定義です。アーキタイプは、インスタンスが参照モデルに準拠するデータに対する制約の形式で表現される、個別のドメイン レベルの概念の正式な表現です。 EHR_EXTRACT の場合、このドキュメントで定義されているように、アーキタイプ インスタンスは RECORD_COMPONENT サブクラスの特定の階層を指定 (および効果的に制約) し、その名前およびその他の関連する属性値、階層内の任意の点でのオプション性および多重性を定義または制約します。 ELEMENT データ値が取り得るデータ型と値の範囲、およびその他の制約。
この文書は、原型 (または同等の臨床モデル) が、電子医療記録システムの現在のアーキテクチャに必ずしも直接組み込まれているわけではないことを認識しています。したがって、この文書はそのようなシステム内でアーキタイプを使用することを義務付けるものではありません。ただし、EHR_EXTRACT の生成に使用された臨床情報モデルまたは同等物 (データ項目、データ項目の集約、データ値の制約、用語の結合、測定単位など) 自体が作成され、伝達または参照されることが必要です。 、各 EHR_EXTRACT 内。これらの伝達または参照されるアーキタイプは、この標準シリーズのPart 2 に準拠する必要があり、この標準シリーズのPart 5 に準拠するインターフェイスを通じて伝達される場合があります。
0.4 EHR_EXTRACT レコード階層の概要
医療記録内の情報は本質的に階層構造になっています。臨床観察、推論、意図は、単純な構造を持つ場合もあれば、より複雑な構造を持つ場合もあります。これらは通常、見出しの下に整理され、相談記録、手紙、報告書などの「文書」に含まれます。これらの文書は通常、フォルダーに保管されており、ヘルスケア企業 (医療、看護、産科など) 内にケア対象ごとに複数のフォルダーがある場合があります。
EHR 通信参照モデルは、元の臨床状況に忠実であり、異種の臨床システム間で記録が通信されるときに意味が確実に保持されるようにするために、この階層構造と組織を反映し、公開されている要件を満たす必要があります。これを行うために、このモデルは EHR 階層を正式に複数の部分に再分割し、異種 EHR システム内で個々の EHR が編成される方法への一貫したマッピングを提供することがわかっています。
これらの部分を以下の表 1 にまとめます。
表 1 — EHR 抽出参照モデルの主な階層コンポーネント
| 名誉階層 成分 | 説明 | 例 |
|---|---|---|
| EHR_EXTRACT | EHR プロバイダー システムと EHR 受信者の間で通信するための、単一のケア対象またはケア対象グループ (家族など) の EHR の一部またはすべてを格納する最上位のコンテナー。 | （適用できない） |
| フォルダ | EHR 内の高レベルの組織。EHR を、単一の症状に対して、臨床チームまたは施設によって、またはケアのエピソードなどの一定期間にわたって、単一のケア対象に提供されるケアに関連する区画に分割します。 | 糖尿病ケア、統合失調症、胆嚢摘出術、小児科、聖マンゴ病院、GP フォルダー、エピソード 2000 ～ 200 |
| 構成 | 1 回の臨床診察または記録文書化セッションの結果として、1 人のエージェントによって 1 つの EHR にコミットされた一連の情報。 | 経過記録、臨床検査結果フォーム、放射線科レポート、紹介状、クリニック訪問、クリニックレター、退院概要、健康機能評価、糖尿病レビュー。 |
| セクション | 1 つの臨床見出しに属する COMPOSITION 内の EHR データ。通常、臨床診療中に収集される情報の流れを反映するか、将来の人間の読者の利益のために構造化されます。 | 発症理由、既往歴、家族歴、アレルギー情報、自覚症状、他覚所見、分析、計画、治療、食事、姿勢、腹部検査、網膜検査。 |
| エントリ | 1 つの臨床行為、1 つの観察、1 つの臨床解釈、または意図の結果として EHR に記録される情報。これは臨床声明とも呼ばれます。 | 症状、所見、1 つの検査結果、処方薬、アレルギー反応、診断、鑑別診断、白血球数の鑑別、血圧測定。 |
| 集まる | 時系列などのネストされた複数部分のデータ構造を編成し、テーブルの列を表す手段。 | 聴力図の結果、脳波の解釈、重み付けされた鑑別診断。 |
| 要素 | EHR 階層のリーフ ノード。単一のデータ値が含まれます。 | 最高血圧、心拍数、薬剤名、症状、体重。 |
EHR_EXTRACT には、FOLDER 階層に編成された EHR データが COMPOSITION として含まれています。
COMPOSITION には ENTRY が含まれており、オプションで SECTION 階層内に含まれます。
ENTRY には ELEMENTS が含まれており、オプションで CLUSTER 階層内に含まれます。
参加の表現: この標準の前のバージョンの参照モデルは、レコード コンポーネント階層の特定の部分に明示的なクラスを提供し、これを通じて医療とその文書に貢献するアクターが果たすアイデンティティと役割を表現することができました。このバージョンの参照モデルでは、LINK クラスは人口統計エンティティを参照するために使用されることを目的としています。これらのエンティティが果たす役割は、この標準シリーズの第 3 Part で定義されている拡張用語リストを使用してラベル付けできます。この更新されたメカニズムは、そのような民主的なエンティティへの参照をレコード コンポーネント階層内で表すことができるwhere で、以前のバージョンよりも優れた柔軟性を提供します。
コンテキストの表現 : すべての EHR_EXTRACT は、たとえば RECORD_COMPONENT 階層や LINK ターゲットを介して、通信されたコンテンツに接続されている他の RECORD_COMPONENTS を参照します。 EHR 交換サービス ( Part 5 で指定されているものなど) が参照コンポーネントへのアクセスを許可する場合、どのユーザーも、元々含まれていなかったコンテンツの追加領域にアクセスしてレビューできるようになります。 (アーキタイプは、直接のドキュメントのコンテキストの主要な要素をまとめます。)
信頼性の表現 : すべての EHR_EXTRACT には、証明されたビューが含まれる場合があります。これらは、元の作成者によって表示および保持されたものの本物のビューである PDF, HTML, またはその他のレンダリングである可能性があります。オプションで、デジタル署名の証拠である証明も含めることができます。
EHR_EXTRACTS は特定の目的のために作成されており、これらが他の目的に適合することを自動的に保証するものではありません。
0.5 この版の規格で行われた変更の概要
すべての部分の範囲は同じままです。
この改訂の目的は次のとおりです。
- 13606 標準シリーズの公開バージョンの採用経験に関する実装者のフィードバックを得る。
- 実装者にとって役に立たないプロパティを削除して参照モデルを簡素化します。
- 人口統計モデルを改善して、人口統計の原型の使用をサポートする。
- ISO 13940 ケアの継続性をサポートするための概念体系 (Contsys) との連携を改善します。
- データ型を情報交換用の ISO 21090 調和データ型と一致させる (付録 A を参照)
- HL7 FHIR との位置合わせのための地面を準備します。
- openEHR アーキタイプ オブジェクト モデル 2.0 に合わせてアーキタイプ モデルを更新します。
- 一般に必要な情報 (人口統計など) の参照アーキタイプを含めます。
- 電子医療記録の ISO 27789 監査証跡、および ISO 22600 シリーズの特権管理とアクセス制御に合わせて監査ログ モデルを更新します。
参照モデルの変更
ベースコンポーネント
ベース コンポーネント クラスは、レコード コンポーネントよりも継承階層の上位に導入されており、一意の識別子、バージョン履歴情報、および構成証明情報を持っています。
これにより、LINK や人口統計情報、レコード コンポーネントの元のファミリーなど、EHR 抽出内のすべての構造をバージョン管理および証明できるようになります。
レコードコンポーネント
役に立たなかったいくつかのプロパティがレコード コンポーネントから削除されました。
重要なのは、このモデルでは、アーキタイプ ID を通じてレコード コンポーネントに意味的なラベルを付けるようになり、名前や意味などの意味的なラベルの重複や競合する可能性が回避されるようになりました。
経験的には、これらの異なるプロパティが適切に使い分けられず、一貫性のない慣行が生じていました。
アーキタイプを使用する予定のないベンダーやプロバイダーとの協議により、この標準シリーズの採用を選択した場合、データ構造をマッピングするアーキタイプのライブラリを作成できることが確認されました。
機密性とポリシー ID に関連するプロパティは、混合ポリシーのデータを含むコンポジションのリスクを回避するためにコンポジションに移動され、その結果、異なる当事者による一貫性のない完全なアクセスが行われます。
構造コンポーネント
汎用親クラス Structure Component は、すべての Record Component および人口統計クラスの汎用親クラスになりました。
このようなクラスはすべてアーキタイプ ID を継承します。これにより、重要な点として、人気のある変更リクエストであったアーキタイプを通じて人口統計構造を定義できるようになります。
EHR_抽出
抽出基準は、実装者が役に立たないと判断したため、削除されました。
EHR_EXTRACT には、抽出された EHR コンポーネントのセットが含まれるため、複数の治療対象に関するデータが含まれる可能性があります。
フォルダー
フォルダーにはケアの対象というプロパティがあり、これにより EHR 抽出には、家族などの複数のケアの対象に関する情報が含まれる可能性があり、これは私たちが受け取った重要な変更リクエストでした。
EHR 抽出は、抽出生成に関する特定のメタデータを含む一種のフォルダーです。
構成、エントリー、クラスター
いくつかの未使用のプロパティが構成、エントリ、およびクラスターから削除されました。
これには、session_time, obs_time が含まれます。このような日付と時刻は、より正確に指定された名前と役割とともに、関連するアーキタイプ内に含める方が適切です。
要素
Element クラスとそれに対応する Demographic Element は、以前よりも継承されるプロパティと継承される関連付けが少ない、より純粋なリーフ ノードです。
これは、元の Element が資産が豊富すぎて、一貫性のない導入慣行を招いていると指摘した多くの ICT ベンダーへの対応です。
Null フレーバーは明示的な参照モデル プロパティではなくなりました。代わりに、 Part 3 で参照アーキタイプが定義され、エレメント レベルだけでなく、より上位の階層 (たとえば、クラスターまたはエントリが存在しない) で null をアサートできるようになりました。
データ値
データ値はすべて、ISO 21090 のプロファイリングのメカニズムに準拠して、データ型の制約されたサブセットとして表現されるようになりました (付録 A を参照)
人口統計
人口統計エンティティは、別個のパッケージではなく、レコード コンポーネントと同じ仕組みの多くを継承するクラスを使用して表現され、導入が簡素化されます。
これは、人口統計抽出内の人口統計エントリを一意に識別し、バージョン管理し、証明できることも意味します。
俳優が複数の役割を果たし、時間の経過とともに異なる介護現場で働くwhere 、これは比較的一般的ですが、介護現場で役割内の俳優を具体的に指すことがはるかに簡単になりました。
リンク
Link クラスは簡素化されていますが、リンクが一意の識別子を持ち、バージョン管理と証明ができるように強化されています。
リンクは、人口統計上のエンティティを含む、識別されたコンポーネントを接続できます。これは、現在、ほとんどの参加を表す方法です。これは、以前の標準のモデル化があまり成功していない部分を修正するための、重要かつ十分にサポートされた変更リクエストでした。
LINK の語彙はPart 3 内で大幅に拡張され、必要に応じwhere Contsys と調整されています。
LINK は、レコードの部分間の臨床的に関連する接続、ポイントツーポイント、またはリンク スレッドとして表すために引き続き使用できます。
以前のクラス FUNCTIONAL_ROLE および RELATED_PARTY は、LINK 経由で関連する RECORD_COMPONENT に接続されたアーキタイプ化された DEMOGRAPHIC ENTITY インスタンスを通じて人口統計エンティティへの接続を確立できるため、削除されました。
新しいクラス EXTERNAL_LINK を使用すると、治療プロトコル、安全性レポート、学術出版物などの非 EHR データへの参照を含めることができます。
監査情報
監査情報クラスは、この標準シリーズのPart 4 の対応する監査モデルと同様に、ISO 27789 に準拠するようになりました。
0.6 この規格と他の関連規格との関係
- この文書で使用されるデータ型は、ISO 21090 医療情報学 - 情報交換のための調和されたデータ型のプロファイルです。
- 特に、ISO 13940 医療情報学 - ケアの継続性をサポートするための概念体系 (Contsys) との調整が行われています。標準シリーズ内の用語と定義はすべて、5 つのパートにわたって調和されており、ほとんどの用語はPart 1 に含まれています。それらはすべて Contsys に準拠しています。
- 重要な 13606 FHIR プロファイル プロジェクトが HL7 内で進行中です (付録 B を参照)このようなプロファイルを作成する上での課題は見つかっていません。ただし、ISO 13606 と HL7 の間でさらなる作業が必要なマッピング調整の領域がいくつかあります。
- Part 1 と 4 は、ISO 27789 医療情報学 - 電子医療記録の監査証跡に準拠しています。 Part 4 の整合性は、ISO 22600 医療情報学 - 特権管理およびアクセス制御と維持されています。
Introduction
0.1 Preface
The overall goal of this document is to define a rigorous and stable information architecture for communicating part or all of the Electronic Health Record (EHR) of a single subject of care (patient), or for a group of patients whose information might need to be communicated together (for example, a family). This is to support the interoperability of systems (see Annex C). and components that need to communicate (access, transfer, add or modify) EHR data:
- preserving the original clinical meaning intended by the author;
- incorporating the necessary provenance metadata to inform the recipient or receiving system about the context in which the EHR data were obtained and composed;
- observing and communicating the confidentiality of that data as intended by the author and subject of care.
This document considers the EHR to be the persistent longitudinal and potentially multi-organisation or multi-national record of health and care provision, most often relating to a single subject of care (the patient), created and stored in one or more physical systems in order to inform each subject’s future healthcare and to provide a medico-legal record of care that has been provided. This corresponds to the definition provided in ISO 18308:2011 (Requirements for an Electronic Health Record Architecture).
This document is not intended to specify the internal architecture or database design of EHR systems or components, nor is it intended to prescribe the kinds of clinical applications that might request or contribute EHR data in particular settings, domains or specialities. For this reason, the information model proposed here is called the EHR Extract, and might be used to define a message, an XML document or schema, or an object interface. These might be used to communicate EHR data between two repositories, to update a centralised regional or national EHR repository, or within a distributed network of EHR components, systems and services. Whilst an EHR service or system will need to interact with many other services or systems providing terminology, medical knowledge, guidelines, workflow, security, persons registries, billing etc. this document has only touched on those areas if some persistent trace of such interactions is required in the EHR itself, and requires specific features in the reference model to allow their communication.
This document may offer a practical and useful contribution to the design of EHR systems but will primarily be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical systems. The components that might support an interface conforming to this document will be not only electronic health record systems but also other middleware services such as security components, guideline and workflow systems, alerting and decision support services, personal health systems and applications, sensors and wearable devices, and medical knowledge management services. This document might also prove useful for communicating data about individuals between electronic health record systems and population registries, and also for conducting (approved) research using electronic health records.
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.
0.2 Technical approach
This document is the second version of an original standard which was published in 2007 by CEN, and in 2008 by ISO. This revision has taken into account the experiences gained by EHR system developers and by large scale eHealth programmes from using the original standard. These were ascertained through an international survey, a wide range of 1:1 interviews, a review of the academic literature, and interactions with many experts active in R&D relating to the EHR. It also meets the relevant requirements in ISO 18308:2011 (Requirements for an Electronic Health Record Architecture). The revision has taken into account, and aligns as far as possible, with other CEN and ISO Standards and Technical Specifications with which this document might also be used, with international terminology standards and with emerging standards from HL7: Fast Healthcare Interoperability Resources (FHIR). The specifications in this document have drawn from, and align as far as possible with, the reference model specifications published by the openEHR Foundation, and with the archetype models published by the openEHR Foundation and by the Clinical Information Modeling Initiative (CIMI).
The information model in this document is an Information Viewpoint of the ISO Reference Model for Open Distributed Processing (ISO/IEC 10746-1:1998 ) .
Given the diversity of deployed EHR systems, this document has made most features of EHR communication optional rather than mandatory. However, some degree of prescription is required to make EHR Extracts safely processable by an EHR recipient system, which is reflected through mandatory properties within the models in Parts 1, 2, and 4 of this series, and through normative term lists (defined in Part 3 of this series).
0.3 The Dual Model approach
The challenge for EHR interoperability is 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 healthcare data sets, value sets, templates etc. required by different healthcare 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, defined in this document and used to represent the generic properties of health record information, and Archetypes (conforming to an Archetype Model, defined in Part 2 of this series), which are meta-data used to define patterns for the specific characteristics of the healthcare data that represents the requirements of each particular profession, speciality or service.
The Reference Model represents the global characteristics of health record components, how they are aggregated, and the context information required to meet ethical, legal and provenance requirements. 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 series).
This generic information model needs to be complemented by a formal method of communicating and sharing the organisational structure of predefined classes of EHR fragment corresponding to sets of record components made in particular clinical situations. These are effectively pre-coordinated combinations of named RECORD_COMPONENT hierarchies that are agreed within a community in order to ensure interoperability, data consistency and data quality.
An Archetype is the formal definition of prescribed combinations of the building-block classes defined in the Reference Model for particular clinical domains or organisations. An archetype is a formal expression of a distinct, domain-level concept, expressed in the form of constraints on data whose instances conform to the reference model. For an EHR_EXTRACT, as defined in this document, an archetype instance 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 data types and value ranges that ELEMENT data values may take, and other constraints.
This document recognises that archetypes (or equivalent clinical models) are not always directly incorporated within the present-day architectures of electronic health record systems. This document therefore does not mandate that archetypes are used within such systems. It does, however, require that the clinical information models or equivalents (data items, data item aggregations, data value constraints, terminology bindings, units of measure etc.) that have been used to generate an EHR_EXTRACT are themselves created and communicated, or referenced, within each EHR_EXTRACT. These communicated or referenced archetypes have to conform to Part 2 of this standard series, and maybe communicated through an interface conforming to part 5 of this Standard series.
0.4 Overview of the EHR_EXTRACT record hierarchy
The information in a health record is inherently hierarchical. Clinical observations, reasoning and intentions can have a simple or a more complex structure. They are generally organised under headings, and contained in “documents” such as consultation notes, letters and reports. These documents are usually filed in folders, and a subject of care may have more than one folder within a healthcare enterprise (e.g. medical, nursing, and obstetric).
The EHR Communications Reference Model needs to reflect this hierarchical structure and organisation, meeting published requirements in order to be faithful to the original clinical context and to ensure meaning is preserved when records are communicated between heterogeneous clinical systems. To do this, the model formally sub-divides the EHR hierarchy into parts that have been found to provide a consistent mapping to the ways which individual EHRs are organised within heterogeneous EHR systems.
These parts are summarised in Table 1 below.
Table 1 — Main hierarchy components of the EHR Extract Reference Model
| EHR HIERARCHY COMPONENT | DESCRIPTION | EXAMPLES |
|---|---|---|
| EHR_EXTRACT | The top-level container of part or all of the EHR of a single subject of care or for a group of subjects of care (such as a family), for communication between an EHR Provider system and an EHR Recipient. | (Not applicable) |
| FOLDER | The high level organisation within an EHR, dividing it into compartments relating to care provided to a single subject of care, for a single condition, by a clinical team or institution, or over a fixed time period such as an episode of care. | Diabetes care, Schizophrenia, Cholecystectomy, Paediatrics, St Mungo’s Hospital, GP Folder, Episodes 2000-2001. |
| COMPOSITION | The set of information committed to one EHR by one agent, as a result of a single clinical encounter or record documentation session. | Progress note, Laboratory test result form, Radiology report, Referral letter, Clinic visit, Clinic letter, Discharge summary, Functional health assessment, Diabetes review. |
| SECTION | EHR data within a COMPOSITION that belongs under one clinical heading, usually reflecting the flow of information gathering during a clinical encounter, or structured for the benefit of future human readership. | Reason for encounter, Past history, Family history, Allergy information, Subjective symptoms, Objective findings, Analysis, Plan, Treatment, Diet, Posture, Abdominal examination, Retinal examination. |
| ENTRY | The information recorded in an EHR as a result of one clinical action, one observation, one clinical interpretation, or an intention. This is also known as a clinical statement. | A symptom, an observation, one test result, a prescribed drug, an allergy reaction, a diagnosis, a differential diagnosis, a differential white cell count, blood pressure measurement. |
| CLUSTER | The means of organising nested multi-part data structures such as time series, and to represent the columns of a table. | Audiogram results, electro-encephalogram interpretation, weighted differential diagnoses. |
| ELEMENT | The leaf node of the EHR hierarchy, containing a single data value. | Systolic blood pressure, heart rate, drug name, symptom, body weight. |
An EHR_EXTRACT contains EHR data as COMPOSITIONs, organised in a FOLDER hierarchy.
COMPOSITIONs contain ENTRYs, optionally contained within a SECTION hierarchy.
ENTRYs contain ELEMENTS, optionally contained within a CLUSTER hierarchy.
Representing participation: The Reference Model in the previous version of this standard provided explicit classes at certain parts of the Record Component hierarchy through which it was possible to represent the identity and roles played by actors contributing to healthcare and to its documentation. In this version of the Reference Model the LINK class is intended to be used to reference demographic entities. The roles played by these entities can be labelled using extended term lists defined in Part 3 of this standard series. This updated mechanism offers greater flexibility than the previous version in where the references to such democratic entities may be represented within the Record Component hierarchy.
Representing context : Any EHR_EXTRACT references any other RECORD_COMPONENTS that are connected to the communicated content, for example via the RECORD_COMPONENT hierarchy and via LINK targets. If the EHR exchange service (e.g. as specified in Part 5) permits access to referenced components, any user would be able to access and review any additional areas of content that were not originally included. (Archetypes bring together the key elements of immediate documentation context.)
Representing authenticity : Every EHR_EXTRACT may contain attested views: these might be PDF or html or other renderings that are the authentic view of what was seen and persisted by the original author. The proof may also optionally be included, which is the evidence of a digital signature.
EHR_EXTRACTS are created for specific purposes, and will not automatically guarantee that these will be fit for other purposes.
0.5 Summary of changes made in this edition of the standard
The scope of all parts remains the same.
The objective of this revision was to:
- obtain implementer feedback on adoption experiences with the published version of the 13606 standard series;
- simplify the reference model by removing properties that have not proved useful to implementers;
- improve the demographics model to support the use of demographic archetypes;
- improve alignment with ISO 13940 System of concepts to support continuity of care (Contsys);
- align the data types with ISO 21090 Harmonized data types for information interchange (see Annex A);
- prepare the ground for alignment with HL7 FHIR;
- update the archetype model to align with the openEHR Archetype Object Model 2.0;
- include reference archetypes for commonly needed information (e.g. demographics);
- update the audit log model to align with ISO 27789 Audit trails for electronic health records, and the ISO 22600 series, Privilege management and access control.
Reference Model changes
Base Component
A class Base Component has been introduced higher in the inheritance hierarchy than Record Component, which has a unique identifier, version history information and attestation information.
This allows all of the structures within an EHR Extract to be version managed and attested, including LINK and demographic information, as well as the original family of Record Components.
Record Component
Several properties that had not proved useful have been removed from Record Component.
Importantly, the model now semantically labels Record Components through archetype ID, avoiding duplicating and possibly conflicting semantic labels such as name and meaning.
Experience is that these different properties were not differentially well used, and resulted in inconsistent practices.
Consultation with vendors and providers who do not intend to use archetypes has confirmed that they could create a library of archetypes mapping their data structures, should they choose to adopt this standard series.
Properties relating to sensitivity and policy ID have been moved to Composition, to avoid the risk of a Composition containing data of mixed policies and therefore inconsistently complete access by different parties.
Structure Component
A generic parent class Structure Component is now the universal parent class of all Record Components and demographic classes.
All such classes inherit an archetype ID, which now also importantly allows demographic structures to be defined through archetypes, which was a popular change request.
EHR_Extract
Extract Criteria has been removed as implementers did not find it useful.
EHR_EXTRACT may now contain a set of extracted EHR components, and so may contain data on multiple subjects of care.
Folder
The Folder has the property subject of care, which allows an EHR extract potentially to contain information about more than one subject of care, such as a family, which was an important change request we received.
The EHR Extract is a kind of folder, with specific meta data about the extract generation.
Composition, Entry and Cluster
Some unused properties have been removed from Composition, Entry and Cluster.
This includes session_time, obs_time. Such dates and times are better included within relevant archetypes with more precisely specified names and roles.
Element
The Element class, and its counterpart Demographic Element, are more genuinely leaf nodes with fewer inherited properties and fewer inherited associations than in the past.
This is a response to a number of ICT vendors who indicated that the original Element was too property rich, inviting inconsistent adoption practice.
Null flavour is no longer an explicit Reference Model property. Instead a Reference Archetype has been defined in Part 3, to allow null to be asserted not only at Element level but higher up the hierarchy (e.g. that a Cluster or Entry is not present).
Data Value
The data values are now all represented as a constrained subset of the data types in ISO 21090, conforming to its mechanism for profiling (see Annex A).
Demographics
Rather than being a separate package, demographic entities are represented using classes that inherit many of the same mechanics as Record Components, simplifying adoption.
This is now also means that demographic entries in a demographic extract can be uniquely identified, version managed and attested.
It is now much easier to refer specifically to actors within roles at care settings, in cases where actors play multiple roles and work within different care settings over time, which is relatively common.
Link
The Link class has been simplified, but enriched so that Links have a unique identifier, and can be versioned and attested.
Links can connect any identified components including demographic entities, which is now the way that most participations are represented. This was an important and well supported change request, to correct a less successfully modelled part of the previous standard.
The vocabulary for LINK has been greatly extended within part 3, and where appropriate aligned with Contsys.
LINKS can continue to be used to represent clinically relevant connections between parts of a record, point to point or as a linkage thread.
The former class FUNCTIONAL_ROLE and RELATED_PARTY have been removed, as the connection to demographic entities can now be made through archetyped DEMOGRAPHIC ENTITY instances connected to the relevant RECORD_COMPONENT via LINK.
A new class EXTERNAL_LINK enables references to be included to non-EHR data such as care protocols, safety reports or academic publications.
Audit information
The audit info class now aligns with ISO 27789, as does the corresponding audit model in Part 4 of this standard series.
0.6 Relationship of this standard to other relevant standards
- The data types used in this document are a profile of ISO 21090 Health informatics - Harmonized data types for information interchange.
- Alignment has especially been undertaken with ISO 13940 Health informatics - System of concepts to support continuity of care (Contsys). All of the terms and definitions within the standard series have been harmonised across the five parts, with most of the terms being in Part 1. All of them have been aligned with Contsys.
- An important 13606 FHIR profile project is in progress within HL7 (see Annex B). No challenges have been identified with being able to create such a profile. However there are a few areas of mapping alignment which need further work between ISO 13606 and HL7.
- Parts 1 and 4 align with ISO 27789 Health informatics - Audit trails for electronic health records. Alignment in Part 4 has been maintained with ISO 22600 Health informatics - Privilege management and access control.