問題タブ [hl7-fhir]

Blaze サーバーは、FHIR リソースの削除を完全にはサポートしていないと私は考えています。誰かが次の質問を手伝ってくれませんか:

1. リソースが削除された場合、リソースの新しいバージョンが作成され、最終更新日時が変更されますか?
2. リソース履歴が要求されたとき、特定のバージョンに存在するアトムの削除されたエントリです。
3. リソースはどのように復元され、これによりリソース バージョンが作成されますか。

ところで: Blaze は物理的な削除ではなく、論理的な削除を行っています。物理的な削除を実行する必要があることを何らかの方法で指定できるかどうかをテストするのに適しています。

REST 削除のDSTUは単純な送信ですDELETE [base]\[type]\[id]。

ただし、サーバーがバージョン対応の更新を実装している場合はどうなるでしょうか? Content-LocationHTTP ヘッダーも送信する必要がありますか? 次のように:

または、DELETE はリソースの現在のバージョンに暗黙的に適用されますか?

私たちは、コンポジションで表現された臨床文書用の汎用ブラウザを開発しています。

ポータルおよびモバイル アプリ ウィジェットに表示するために、コンポジションのさまざまなセクションを参照しています。

仕様内の現在のコンポジション サンプルに対する疑問は、Composition.section[].content ResourceReference の正しいリソース タイプを知る方法です。たとえば、

しかし、このような別のサンプルでは、​​URI または URN を使用して、リソース タイプを知る方法がわかりません。

これらの URI/URN リソース参照とリソースのクエリのリソース タイプを知る方法について、助けていただければ幸いです。

よろしくお願いします

私は FHIR リソースを使用してイメージング オーダーをモデリングしており、DICOM / HL7 V2 のイメージング オーダー情報モデルを FHIR とどのように整合させるかという構造上の決定に直面しています。DICOM / HL7 V2 では、画像検査オーダーは 3 つのレベルでモデル化されます。手順ステップ ... 要求された手順の完了に貢献する (スケジュール可能で実行可能な) タスク DICOM / V2 モデルを FHIR に合わせるための私の提案は次のとおりです。要求された手順で計画/スケジュール/実行された手順ステップ 臨床オーダーを満たす過程で、DiagnosticOrder リソースが更新され、より詳細な情報が含まれるようになります。これらの既存のリソース (Order および DiagnosticOrder) には、拡張可能な情報のギャップがあります。私はフィードバックを得るのが本当に好きです。構造マッピングは理にかなっていますか、それとも FHIR モデルの何かを見逃したり誤解したりしましたか? どんな入力でも大歓迎です...ありがとう!!

FHIR パブリッシュ ツールを使用してプロファイル ドキュメントを作成しています。拡張機能を 1 つのプロファイルにまとめ、拡張リソース (拡張機能を使用するリソース) を別のアプリケーション プロファイルにまとめています。リソース内の拡張機能は、Profile 列に「profileIdofextension#extensionName」のような値を持ちます。ただし、これにより、拡張機能が定義されている拡張機能 (すべての拡張機能を含むプロファイル) にハイパーリンクされるわけではありません。ハイパーリンクを機能させるには、Profile 列に「prfoileOfExtensionHtmlFileName#extensionName」を入力する必要があります。ツールが profileId を profileHtmlFileName に解決しないのはなぜですか? プロファイル xml 定義では、html ファイル名ではなく、profileId を参照する必要があると思います。

ResourceFHIRまたはResourceOrFeedオブジェクトを JSON 文字列に変換しようとしています。このための Java 実装で利用可能な API メソッドが見つかりませんでした。

.NET API で使用できるシリアライザーはありますが、Java 実装で同様の API を使用することはできません。

ResourceOrFeedオブジェクトを実際の文字列 JSON 表現に変換する方法についての指針はありますか?

Spring Jackson コンバーターからのデフォルトの変換は機能していますが、正しい JSON を出力しておらず、カスタム オブジェクト マッパーを作成したくありません。

ドキュメント参照リソースを使用して、Atom フィードのクエリ応答を介して返されるドキュメントに関するメタデータを含めています。ドキュメント自体が BLOB であるため、ドキュメント参照リソースで参照されるバイナリ リソースに存在する必要があります。ドキュメント リソースでバイナリ リソースを参照する方法がわかりません。

私の最善の推測は、location 要素を使用して、Atom フィード内のバイナリ オブジェクトへの XPATH を指すことです。

ここで、「28BEE6CC-28F4-11E2-B493-B2916188709B」はドキュメントのマスター識別子です。

メッセージング パラダイムで使用されるバイナリ リソースについて、誰かがもっと光を当ててくれたらお願いします。