始めましょう。 何らかの理由で、医療システムの作成に関しては、これは必然的に患者の電子医療記録であり、おそらく何か他のものであると考えられていますが、ごくわずかです。 ただし、患者EMCは医療システムの唯一のカテゴリではありません。
次の3つを区別できます。
電子患者記録中心 -これには、特定の患者に適用されるものが含まれます。 アプリケーションは、患者とその病歴の人口統計データの保存に限定されません。 このカテゴリには、遠隔医療、医療ポータルなどを含めることができます。
公衆衛生情報ネットワーク -このレベルのシステムは、個人から抽出され、さまざまな患者指向システムからの定量的データを集約して、流行、生物テロリズムなどのイベントの発生を予測します。
臨床研究支援 -意思決定、薬物モデリングなどのシステムのこのグループで
カテゴリ間に明確な境界線はなく、データフローは処理され、補足され、返されます。 特定の領域またはカテゴリでの経験がない場合、使用できるデータを推測することは非常に困難です。その場合、HL7参照情報モデル（RIM）は、クラスの構造と関係を日夜夜間に積み重ねてきた多くの専門家の経験を提供する貴重な支援を提供します。
この点で、FHIRがまだ地平線上にないとき、トピックが生じました-HL7標準が非常にクールで、ハニーデータの交換に必要なすべてを記述している場合、データベース構造としてそれを使用しないのはなぜですか？他のシステムからのメッセージでは、何らかの方法で保存することができます。 目的のドメインに関連するすべてのRIM、またはRMIMまたはDMIMを取得し、開発されたシステムに必要なクラスのみを使用してデータベースを設計します。 さて、HL7 RIMの栄光をすべて見てください。
以下は色分けされています：他のアクション（赤）の一部（ピンク）であるアクション（赤）に参加する（黄色）として機能するエンティティ（緑） それだけです、RIMにはそのようなものはありません！ 一見したところ、これは何らかの形でEMCの既製モデルとはあまり思えません。
次に、「2番目の」外観で何があるかを見てみましょう。 また、一見すると、HL7データ型は、ほとんどの場合、「通常の」データ型とは異なります。 標準のUML図形式のデータ型は、次のように表示されます。
たとえば、HL7 Point-In-TimeはデータベースのTimestamp型に似ていますが、最初の型は抽象型ANYから継承されるため、必要なNullFalvorプロパティは全体像を台無しにします。
より複雑な例は、概念記述子（CD）タイプです。これは、属性によって記述されます：code、codeSystem、codeSystemName、codeSystemVersion、displayName、originalText、qualifier、translation。 さらに、最後の2つはリストです。 Equivalents（CE）、Coded Value（CV）、Coded Ordinal（CO）、およびCoded Simple Value（CS）タイプでコード化されたタイプは、CDタイプから継承されます。 CSタイプには、コードとNullFalvorのみが含まれます。 問題は、CD用に別のテーブルを作成するかどうか、および継承されたすべてのタイプをそこに保存するかどうかです。 または、作成するテーブル内にCSフィールドを作成し、タイプCDのデータを別のテーブルに転送しますか？
次に、いくつかの単純なエンティティを取り上げます。たとえば、ADデータ型のADDRフィールドを配置して見てください。
•タイプDSETの使用。
•タイプGTSのuseablePeriod。これはQSETです。
•タイプBLのisNotOrdered。
•フォーマットされたタイプST.NT。
データベースの論理構造の観点から見ると、use属性とusefulPeriod属性は1対多の関係です。
isNotOrdered属性は、データベースに関しては単なるブール値ではなく、3番目のnull状態を持つ場合があります。
タイプST.NT（StringNoTranslations）のフォーマットされた属性には、次のコンポーネントが含まれます。
•タイプBINのデータ。
•mediaTypeタイプCS。
•文字セットタイプCS。
•言語タイプCS。
•headCharacterタイプST.NT。
•タイプST.NTのtailString。
上記のCSデータ型の各要素は、次のもので構成されます。
•タイプST.SIMPLEのコード。
•タイプUIDのcodeSystem。
•タイプST.NTのcodeSystemName。
•タイプST.SIMPLEのcodeSystemVersion。
そして、HL7 RIMクラスのほぼすべてのフィールドを備えたこのようなロシアの人形（場合によってはループが見やすいため）。
これは、RIMに基づいてではなくデータベーススキームを実装する2つの極端な方法と、それらの派生を意味します。
•テーブル内の各データタイプ。 この場合、最も単純なAck（MCCI_IN000002）を形成する場合でも、リクエストがどのようなものになるかを簡単に想像できます。
•テーブル内のすべてのデータ型。 また、可能なアプローチですが、データベースが異常になります。
•極端な要素を取り除いて混合アプローチを使用するのは非常に論理的です。特定の領域に対してRMIMを使用し、一部のデータ型を別のテーブルに、一部のテーブルを内部に配置します。
•RIMを振り返ることなく、アプリケーションの必要に応じてゼロから基本構造を作成します。
最初のタイプの実装の例は、Abdul-Malik Shakirによって提示されました。Abdul - MalikShakirは、一度にRIMのクラスのクラスターを現在の形式に「 コーミング」しました-www.slideshare.net/AShakir/rim-based-relational-database-design-tutorial- 2008年9月
私の意見では、これはRIMに基づいてデータベース構造を作成することがまだ可能であることを示すための学術的なアプローチです。 実際には、このようなシステムのパフォーマンスは大きな問題になります。 ちなみに、私が知っているこのような実装の少なくとも1つは、非常に「遅く」なりました。
内部構造があまり情報を持たない別の商用実装は、Oracle Healthcare Transaction Base（Oracle HTB）です。 通信から知る限り、エンティティ名（EN）、アドレス部分（ADXP）、通信アドレス（TEL）などの一部のデータ型のみが別のテーブルにリストされています。 HTBのパフォーマンステストでは、優れたハードウェアではベースが非常に高速に回転することが示されています。 （ リンクは停止しています。）
InterSystemsCachéまたは1Cまたはその他の実装の内部構造については、何も知りません。必要に応じてそれら自体が記述します。
そのため、医療システムの基地建設事業には、十分な機動性があります。
=====
RMIM-洗練されたメッセージ情報モデル
DMIM-ドメインメッセージ情報モデル
FHIR-Fast Healthcare Interoperability Resources