6

私は健康 SaaS アプリを設計しており、初期モデリングの助けをいただければ幸いです。私はこのスレッドから始めて、EAV をまったく使用する必要があることを確認しました。臨床データが少ないため、答えはイエスでした。次に、NoSQL オプションを SQL に適合させる代わりに、NoSQL オプションを使用する可能性を検討し始めました。この2つを組み合わせるとより効果的だと思われます。要件と私のアイデアを説明し、フィードバックをお待ちしています。私は.netを使用しています。

要件 最上位には「患者」がいます。患者が何らかの医療援助を必要とする場合、何かが起こった場合、それを「インシデント」と呼びましょう。「インシデント」ごとに、「訪問」と呼ばれる「患者」を複数回見ることができます。すべての臨床データ (テスト/履歴/その他) は、「訪問」ごとに保存されます。したがって、次のようになります。

患者 1 - ∞ インシデント 1 - ∞ 訪問 1 - 1 臨床データ (多くの潜在的なキー/値ペア)

解決策（フィードバックは素晴らしいでしょう）

SQL テーブル

Patient
- PatientID
- other patient info

Incident
- IncidentID
- PatientID
- Other incident info

Visit
- VisitID
- IncidentID
- Datetime

NoSQL DocumentDB (おそらく RavenDB)

{ // Visit document - id: visits/12345
 "Patient": {
   "PatientId": "patients/54321",
   "Name": "John Smith"
 },
 "Incident": {
   "IncidentId": "incidents/55555",
   "Name": "Cardiac Arrest"
 },
 "VisitData": {
   "BP": "110/70",
   "Hypertension": "True"
   "Cardiac Disease": "Angina"
   "Stroke": "False"
   .... (could be tens or hundreds of key/value pairs)
 },

}

それが私がこれまで持っているものです。一般的な意見 (すべて歓迎) は別として、各患者のすべてのインシデントと訪問を、訪問ごとに 1 つの文書を作成するのではなく、1 つの文書にまとめるべきだと考える人がいるかどうか疑問に思っていました (これは、上記のようになっているはずです)。ドキュメントが「大きすぎる」可能性があり (ドキュメント ベースの DB で大きすぎるとはどういう意味なのかまったくわかりません)、ほとんどの場合、ビューは訪問に基づいています。ただし、訪問全体のトレンド レポートも表示する必要があります。 .

前もって感謝します！！

マイク

4

2 に答える 2

0

これは、指定された要件に従って適切に見えます。

おそらく何か別のことが起こっていると思います。それはおそらく、患者のインシデントの一部ではない「状態」です。たとえば、高血圧症の人は、指の骨折を呈したときに、単にその状態にある可能性があります.

また、インシデントを定義するのは難しい場合があります。それは単一の時点のイベントですか、それとも進行性の劣化期間ですか? おそらくこれは、インシデントが実際には訪問のマーカーにすぎないことを意味するか、訪問が別の訪問のフォローアップであることを宣言して、患者が受けたケアの階層またはネットワークを構築できるビスト関連付けテーブルを持っていることを意味します。

上からのほんのいくつかの考え.. hth

編集 - 後付け: 適切に正規化されたテーブルを持つ SQL データベースをお勧めします...

于 2010-12-08T15:54:58.080 に答える
0

データベースの組み合わせが最適な場合があります。既存のアプローチは EAV を使用しますが、問題はネストされたファクトにあります - 薬物相互作用に関するアラートは SQL テーブルのマスター イベントになる可能性があります

しかし、どの程度重大なアラートが送信され、誰に、どの 2 つの薬が送信されたか - これらの詳細は、ドキュメントベースの noSQL データベースに移動できます。

于 2012-09-21T18:38:44.177 に答える