電子カルテ（EHR）について研究しています。OpenEHR は広く採用されているため、この分野では非常に拡張され、高く評価されているようです。しかし、私はそれがどのように使用されているかを見つけることができません。つまり、アーキタイプのすべての定義と、それらの定義が ADL または XML でどのように記述されているかを確認できます。しかし、特定のデータ モデルの定義であるアーキタイプを取得したら、それをどのように使用すればよいでしょうか。ADL や XML など、別のタイプの表現はありますか? 患者の実際の健康記録の例はありますか? 性別、年齢、血圧などの情報を含む John Doe の健康記録の例を探すのに何時間も費やしましたが、見つけることができる例はすべて、これらの用語の定義に関するものです。
誰かが私を正しい軌道に乗せることができれば、私はそれを感謝します. 前もって感謝します！
臨床記録 (構造、制約、用語) を指定する原型のセットを取得したら、Ocean Template Designer を使用して運用テンプレート (OPT) を作成することをお勧めします。これは、参照されるすべてのアーキタイプ セマンティクスを 1 つのファイルにまとめた大きな XML です (扱いやすい)。
その後、いくつかの設計上の選択を行う必要があります。
リレーショナル、オブジェクト ベース、またはドキュメント ベースのテクノロジを選択できます。私の好みは、リレーショナル + いくつかの XML サポートの組み合わせです。現在、ほとんどのリレーショナル DBMS は、ネイティブ データ型として xml をサポートしています。
a) RM 1-1 を DB モデルにマップする、b) キー/値アプローチを使用する、2 つの極端なモデルがあります。階層を照会する必要がある要件については、a) の方が優れていますが、リレーショナル DBMS では多くの結合が必要になります。プレーンデータに基づくクエリの場合、b) の方が優れていますが、k/v セットから階層を構築したい場合は、いくつかのロジックが必要になります。
なぜ階層について言及したのですか？お気づきかもしれませんが、openEHR 情報モデルにはツリー構造があり、デフォルトで階層化されています。これは、臨床情報が本質的に階層化されているためです。
私が EHRServer で行ったことは、リレーショナル DBMS で構造化インデックスを作成することでした。このアプローチは、a) と b) の中間にあります。また、ORM ツール ( http://grails.org/doc/latest/guide/GORM.html ) を使用して、オブジェクト インスタンスをテーブルに自動的にマップします。
データ モデルの重要な側面の 1 つは、すべてのデータ ポイントを定義するアーキタイプへの参照を保存することです。これは、DB 自体で行うか、メタデータを使用してアーキタイプ パスをテーブル/列にマップすることができます。
UI を手動で作成することも、アーキタイプとテンプレートから生成することもできます。いずれにせよ、UI のフィールドをアーキタイプのフィールドにバインドするには、メタデータが必要です。このために、フィールド ID と archetypeId + パスを使用します。
これは、医師からの入力データを openEHR 情報モデルにバインドするのに役立ちます。適切なメタデータがあれば、これを一般的な方法で行うことができます。
アーキタイプ ID とパスがわからない場合は、http: //openehr.org/releases/1.0.2/architecture/am/archetype_principles.pdfを参照してください。
アーキテクチャの概要もお勧めします: http://openehr.org/releases/1.0.2/architecture/overview.pdf
データをデータ モデルにバインドすることは、ビジネス ロジックの一部であり、そのデータも検証します。検証には、アーキタイプと運用テンプレートに表示される制約を使用します。アーキタイプ ID + パスがあれば、アーキタイプから制約を取得し、入力データに対してその制約を評価できます。
すべてのものを一緒に接着すると、次のようになります: UI <-> ロジック <-> DB
それが役立つことを願っています。
openEHR 仕様では、このデュアル レイヤー アプローチに基づいてシステムを作成する方法が説明されています。現在、世界中の多くの企業がこのアーキテクチャをシステムの基盤として使用しています。あなたのフラストレーションは新しいものではありません。しかしその結果、医療記録をシステムで共有できるようになり、正式な意味が事後的に発見されます。モデルは任意の言語で記述でき、必要に応じて言語を追加できます...言語の優位性はありません。
openehr.orgテクニカル メーリング リストに登録して、同じ質問をすることをお勧めします。
乾杯 Sam Heard OpenEHR Foundation
openEHR の世界へようこそ :)
また、オープン ソースの例も参考になるかもしれません。永続化から自動化された GUI まで、openEHR を使用して内視鏡レポート アプリケーションを実装しました。この場合、.Net winforms アプリケーションですが、MVC を使用しているため、Web またはモバイル フロントエンドを使用することはそれほど難しくないと思います。現時点で openEHR にはないのは、「UI」をデータとともにモデル化する手段です。そのため、「ハック」と悪用された注釈機能を使用して、臨床モデルに埋め込まれたいくつかの「GUI ディレクティブ」を作成しました。
見てください：http://gastros.codeplex.com
また、openEHR の実装に関するいくつかの「論文」も書いています。
アタラグ K、ヤン HY、テンペロ E、ウォーレン JR。openEHR によるソフトウェア保守性の評価 - アーキテクチャの比較。International Journal of Medical Informatics
Atalag K、Yang HY、Tempero E、Warren J. openEHR を使用した臨床情報システムのモデル駆動型開発。スタッドヘルステックインフォーム。2011;169:849–53。
アタラグ K、ヤン HY。openEHR ドメイン モデルから高度なユーザー インターフェイスまで: 内視鏡検査のケース スタディ。ウェリントン; 2010. から入手可能: http://www.hinz.org.nz/uploads/file/2010conference/P17_Atalag.pdf
幸運を！最後に 1 つ - HL7 は、他の人が指摘しているように、「システムの外部」または健康情報交換のためのものです。RIM を使用してアプリケーションを構築しようとした人もいます。openEHR はこの目的のために存在するため、EHR システムを構築するための仕様です。HL7 から新たに登場した FHIR 標準は、臨床データ モデルの定義という点で類似点があります。また、そのスペースを監視することをお勧めします。そう遠くない将来に何らかの収束が起こることを願っています ;)
あなたも見たいかもしれません
基礎となる openEHR バックエンドに基づく dev.ehrscape.com と
GET コンポジション呼び出しを見てください
JSON 化された openEHR データの例が表示されます。これは「標準的な」openEHR データの簡略版ですが、一般的な構造を理解するのに役立ちます
他の例はhttp://www.medvision360.com/medcloud/?lang=enにあり、openEHR ベースのデータ モデルと同様です。
これはjson形式のバイタルサインのスニペットです...
{
"ctx":{
"language":"en",
"territory":"GB",
"composer_name":"Sr. Kristen George"
},
"nursing_vital_signs_observations":{
"vital_signs":[
{
"respirations":[
{
"any_event":[
{
"rate":[
{
"|magnitude":16,
"|unit":"/min"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"blood_pressure":[
{
"any_event":[
{
"systolic":[
{
"|magnitude":123,
"|unit":"mm[Hg]"
}
],
"diastolic":[
{
"|magnitude":102,
"|unit":"mm[Hg]"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"pulse":[
{
"any_event":[
{
"heart_rate":[
{
"|magnitude":93,
"|unit":"/min"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"indirect_oximetry":[
{
"any_event":[
{
"spo2":[
{
"|numerator":94,
"|denominator":100
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
}
],
"context":[
{
"setting":[
{
"|code":"233",
"|value":"secondary nursing care",
"|terminology":"openehr"
}
],
"start_time":[
"2014-05-22T15:18:07.339+01:00"
]
}
]
}
}
GitHub https://github.com/ppazos?tab=repositoriesでこの作業を見ることで、いくつかの助けが得られるかもしれません。その多くは、openEHR の概念に基づいています。
ヘルスケアにおけるマルチレベル知識モデリングの世界には、MLHIM もあります。MLHIM は、openEHR の経験から成長し、XML 標準に直接基づいています。www.mlhim.org およびhttps://github.com/mlhim
レコードはコンパイルされ、XML で他のベンダーや組織に送信されます。HL7 は、特定の OBR および OBX を使用してラボ ベンダーとの間でラボ オーダーなどのメッセージを送信するために使用されます。
調査で何をしようとしているのかわかりません。独自のアプリやサイトを構築している場合は、青いボタン プラスをお勧めします。これは ONC によるイニシアチブであり、js はほとんどの CCDA (EHR からの患者情報を含む XML ドキュメント) ドキュメントを解析します。GitHub のライブラリを確認してください - https://github.com/blue-button/bluebutton.js
最も重要なことは、背景 (HITECH Act) を調査し、課題 (EHR の相互運用性) を理解することです。HHS.gov にアクセスして、そこにある情報を確認してください。また、世界中のすべてのデータを取得できるため、医療用語とコード (ICD、CPT、SNOMED など) を知っている人や臨床アドバイザーが必要になりますが、表示しない場合は適切または意味のある方法で、それは本質的に役に立たない.
REST+openEHR (または CIMI や ISO 13606 などの他の原型ベースの EHR アプローチ) の組み合わせに興味がある場合は、http://www.biomedcentral.com/1472-6947/13/57 で説明されているアプローチが興味深いと思うかもしれません。に対応する Java のオープン ソース コードは、https://github.com/LiU-IMT/EEEで入手できます。
openEHR REST API の指定/標準化に関する最近の議論は、https: //openehr.atlassian.net/wiki/display/spec/openEHR+REST+APIs にあります。
openEHR 用の標準化された REST API を使用すると、エンド ユーザー アプリケーションが複数の異なるベンダー/プロジェクトの openEHR バックエンドに接続できるようになるため、ストレージとクエリに多くの時間を費やす必要がなくなります。