あなたの一人がそれをダウンロードするために走る前に、ちょっと注意してください。 この標準は、プログラマーやビジネスアナリストを対象としておらず、少し高いレベルを対象としているため、理解するのがやや困難です。 次の図は、他のすべての公開されたHL7の中でこの標準の場所を条件付きで示しています。
つまり、機能モデルに精通する前に、選択した医療分野のHL7V3ドメイン分析モデル、たとえばHL7バージョン3ドメイン分析モデル：救急医療サービスを確認しておくとよいでしょう。 HL7ドメイン分析モデル標準には、医療サービスの特定の領域（この場合は救急医療）の多数のユースケース、アクティビティ、およびその他のタイプのUML図が含まれており、おそらくこの領域の多数の専門家によって収集されたベストプラクティスを反映しています。 この規格は、再び救急医療サービスに関連して、救急医療および患者の輸送の場合に、誰が、どのように、誰に医療情報を伝えているかを把握するのに役立ちます。 他の領域にも同様のモデルが存在します。
システムの主要なコンポーネントを実装する必要があることがわかったので、この記事で説明する次の標準を使用して、これらのシステムコンポーネントが理想的な場合に実行する機能を見つけることができます。
まず、HL7 EHR-S FM規格のコンパイラーに従って使用できる典型的な（仮説的な）シナリオを検討してください。 （ 予想される使用基準の第5章）与えられたスクリプトは、もちろん、海外の現実を反映しています。
したがって、最初のシナリオ：プライベートクリニックを所有する医師のグループは、特定の医療システムを金融業務に使用します：請求、計画など。ただし、患者のEMCは保存しません。 何らかの理由で、このシステムは今後2年間で更新または交換する必要があります。 医師グループがHL7 EHR-S FM規格を採用し、広範な実務経験があるため、「 治療プロセス機能」セクションのどの機能が理想的なEHRシステムに最も適しているかを調べ始めます。 この時点で、診療所の管理スタッフは、 サポート機能セクションの機能リストと、情報インフラストラクチャの技術スタッフを調べます。 次に、これらの要件をすべて組み合わせた機能プロファイルを作成します。
シナリオ2：いくつかの主要な病院の医療情報システムは、HIPAA要件を満たすために最近更新されました。 ただし、この更新には、臨床決定、システムパフォーマンスの監視、レポートなどのサポートは含まれていません。 病院の情報技術部長は、医師グループに治療プロセスの機能と治療プロセスを保証する機能を検討するよう依頼します。 現時点では、ITグループは情報サポートの機能を研究しています。 リストは統合され、必要な機能を追加するために病院情報システムプロバイダーに送信されました。
シナリオ3：特定の供給医療システムは、大規模病院や類似の組織を対象としたEMCをサポートするためのさまざまなシステムを開発中です。 同時に、会社は個人診療や小規模クリニック向けのシステム市場に参入したいと考えていますが、この場合、メディケアの要件を満たす必要があります。 メディケアの要件に加えて、同社はこの市場の既存システムとの競争に成功するために多くの機能を追加したいと考えています。 HL7 EHR-S FM規格のさまざまなセクションの機能のリストを検討した結果、企業の代表者は、競争を成功させるために既存のシステムにごくわずかな変更を加える必要があるという結論に達しました。
ご覧のとおり、3つのケースすべてで、全員が研究している特定の機能のリストについて説明しています。 そして、本当にそうです。 標準の最初のバージョンには3つのセクション（またはグループ）があり、2番目のバージョンにはすでに7がありました。したがって、一般的な医療システムに推奨される機能の数も140から322に増加し、それらをチェックする基準は972から2310に増加しました。これらのセクション（機能のグループ）を整理しました。
各セクションは一連の関数で構成され、各関数はさらに、このサブ関数に対応する改良サブ関数と検証基準を持つことができます。 第4章「機能モデルの概要と定義」では、標準での機能の表現方法について説明します。
したがって、たとえば、Overarching（Generalセクション）には、このセクションの検証基準がすべてのEHRシステムに適用されるため、すべての機能プロファイルに含まれる必要があることを示すOV.1関数のみが含まれます。
ケア提供セクションにはいくつかの機能があり、そのうちの1 つにはCP.1.1.2などのCP.1.1患者履歴の管理に 14のサブ機能があります-システムは、患者履歴に関与する臨床医のIDを管理する機能を提供するものとします実践の範囲、組織の方針、および/または司法管轄区域に応じた要素 。
などなど。 明らかに、すべての関数をリストすることはまったく意味がありません。 IT部門にとって興味深いセクションと機能は、いつものように、地下室、つまりRecord InfrastructureとTrust Infrastructureにあります。 たぶん誰かが彼らをもっとよく知りたいと思うでしょう。
上記のシナリオで説明したように、標準は、リストされているすべての機能が典型的なEHRシステムでの実装に必須であることを意味するものではないため、標準のユーザーは、特定の蜂蜜システムを使用するコンテキストで必要なものだけを選択することにより、独自の機能プロファイルを作成できます。 次の図は、7つのセクションすべてをカバーするこのようなプロファイルを条件付きで示しています。
一般に、標準のコンパイラによると、実際のEHRシステムは複数の機能プロファイルに対応できます（どのように、それらが結合されないのかはよくわかりません）。 標準の最大の章である適合条項の第6章では、プロファイルの作成方法、プロファイルの構造、機能の追加方法、テスト条件の選択方法、英語での正しい記述方法などについて説明しています。
ゼロから始めないように、ウェブサイトHL7.orgのStandards > EHR Profilesセクションで、標準自体に加えて、 HL7 EHR Pharmacist / Pharmacy Provider Functional ProfileやHL7 EHR Child Health Functional Profileなど、さまざまな分野の既製のプロファイルをダウンロードすることもできます。
規格自体は、単にセクションと機能をリストするよりもいくぶん広範ですが、その一部は英語圏の国にのみ適用可能です。 たとえば、前述のように、検証要件の説明に関する要件。 使用できる単語、使用できない単語、意味するものなど。 したがって、 調整は推奨されませんが、前者は非常に一般的であり、後者は情報システムのドキュメントで記憶されることはほとんどありませんが、 調和 （調整）できます。
この記事の最初の図に戻ります。 システムの機能が定義された後、残りの2つの右の列であるメッセージとドキュメントには、他のシステムとの相互作用（データ転送）および医療データの表示に関するHL7技術標準があります。
私は意図的に標準の章をレビューしませんでした。これはほとんど意味がありません。 私の意見では、最も興味深いのは、機能を調べて、お使いのシステムがHL7の要件をどのように満たしているかを確認することです。 これは、蜂蜜システムのサプライヤーである場合です。 また、消費者が医療システムである場合、この同じ機能セットがおそらく入札の準備に役立ちます。
宿題
英語の文献には、 EHR 、 EMR 、およびPHRという 3種類の医療システムがあり、EMCとしてロシア語に翻訳できます。 このため、システムの意味と機能は失われます。 一部の英語圏の同僚でさえ、これらの用語で混同されることがあります。 それらの類似点と相違点を検索して把握することをお勧めします。