2

HL7 V2 メッセージを FHIR リソースに変換し、サーバーに POST することに成功しました。しかし、私が頭を悩ませているのは、更新中または偶発的な再投稿中に重複を作成することをどのように回避できるかという問題です。

例: PID.#3 = 12345 の V2 ADT_A01 メッセージを受け取ったので、識別子を持つ患者リソースを作成します

  <identifier>
    <use value="usual"/>
    <label value="MRN"/>
    <system value="urn:oid:0.1.2.3.4.5.6.7"/>
    <value value="12345"/>
  </identifier>

そしてそれをサーバーに投稿します。システムと値によって識別される患者は、サーバーに患者を供給するシステムが複数ある場合でも、どのような環境でも一意である必要があります。

次に、ADT_A08 メッセージを受け取り、患者を更新したいので、上記と同じ識別子で別のリソースを作成しますが、それをサーバーに POST すると、更新された患者が 1 人ではなく 2 人になります。PUT では、処理しようとしている V2 メッセージからはわからない患者の URL を提供する必要があるため、POST の代わりに PUT を使用することはできません。

Ewout は親切にも DSTU2 トランザクションと条件付き処理を紹介してくれました。これにより、患者リソースをバンドルに入れ、検索プロパティとのステータス「一致」を追加することができます。例えば

<Bundle xmlns="http://hl7.org/fhir" xmlns:xhtml="http://www.w3.org/1999/xhtml">
    <id value="20141213205602" />
    <type value="transaction" />
    <base value="base" />
    <entry>
        <status value="match" />
        <search value="Patient?identifier=urn:oid:0.1.2.3.4.5.6.7|12345" />
        <resource>
            <Patient>
                <id value="myTempIDforInternalReferencingWithinTheBundle"/>
                <identifier>
                    <use value="usual" />
                    <label value="MRN" />
                    <system value="urn:oid:0.1.2.3.4.5.6.7" />
                    <value value="12345" />
                </identifier>...

サーバー側の動作の仕様には次のように記載されています。したがって、これにより、誤って同じ患者を 2 回作成することを防ぐことができます。しかし、一致が正の場合、サーバーは提供されたデータを無視するため、患者を更新する方法はまだありません。

もちろん、最初に識別子でクエリを実行してから、返されたリソースをその ID で更新することもできます。しかし、サーバーは識別子を一意の制約として扱わないことは明らかであるため、検索結果が 1 つだけになるとは限りません。そのため、サーバーが複数の結果を返すたびに人間の操作が必要になります。

簡単に言うと、システムが患者を識別し、URL ではなく、更新を fhir サーバーに送信するための推奨される手順は何ですか?

よろしくお願いします、

シモーネ

4

1 に答える 1

2

これは、トランザクションを必要とせずに機能するはずです。サーバーは、識別子に一意性を適用する必要があります。あなたが言ったように、A08 で ID を照会することができ、応答で常に 0 または 1 を返す必要があります。そうしないと、実装が不十分なサーバーと通信していることになります。

また、特定のサーバーのコンシューマーは、作成 (POST) するか更新 (PUT) するかを決定する前に、これを確認することさえできない可能性があることも考慮する必要があります。すべての A01 と A08 を create として扱うことができます。私の経験では、登録システムからのストリームが順不同で到着するのを見てきました。ID に一致するものが見つからない場合、クライアントは合理的に A08 の作成を送信できますが、行儀の良いクライアントは、A01 を取得したときにも既存のリソースをチェックする必要があります。

いずれにせよ、REST トランザクションはステートレスであり、サーバーはクライアントが送信するものは何でも処理できる必要があります。

説明したシナリオでは、同じ ID で新しい患者リソースを作成しようとすると、サーバーはリソースが既に存在することを検出する必要があります。また、このようなリクエストは競合応答 (HTTP ステータス 409) で失敗し、OperationOutcome には、その ID を持つ患者リソースが既に存在することを示す理由と、そのリソースへの URL が含まれている必要があります。これは、参照されている患者リソースを A08 のデータで更新して、再試行する必要があることを示しています。

于 2014-12-14T15:25:09.263 に答える