たとえば、私たち（クライアントアプリケーションとして）が1つの連絡先配列を持つ患者を検索して、今では連絡先の情報の一部を変更するPATCH要求をfhirサーバーに送信します...私たちが見せた唯一の方法その位置を使用しています。例：Patient.contact [1] .gender。 1つの例にすぎません。配列インデックスに基づいてPATCHを使用するのは本当に安全ですか？
サービスはステートフルではないし、常に同じ配列を同じ順序で返しているわけではないので（配列位置を使用した）アプローチは安全ではないと思います（連絡先リストを受け取っているとは思わないサーバーが間違った連絡先を変更する可能性があります（この場合、または臨床リソースを使用する場合、より危険な/危険な状況になることがあります）。
私は間違っていますか？パフォーマンスにペナルティを課すことなくPATCHを使用するもう1つの安全対策がありますか？
サーバはとし、注文を保持するとします。すべてのサーバーがそうするわけではありませんが、おそらくPATCHをサポートできないサーバーはありません。ご希望の場合は、変更依頼を送信してください。仕様書でその変更を強調表示することができます。
ご清聴ありがとうございます。確かに、私たちは少なくともこの要件をハイライトするためのドキュメント（サーバーは注文をする必要があります）で変更を要求します。
「注文」とはどういう意味ですか？例えば、appclient1は3人の連絡先（Andrew、Bob、Dukhan）のPatientを取得し、[2]（Dukhan）のパッチを送信しましたが、この間他のシステム（appclient2）が新しい連絡先（Carl）を追加しました。 （サーバー側の）リストは、Andrew（0）、Bob（1）、Carl（2）、Dukhan（3）となります。ポジション[2]はちょうど今ではありません、カフです。だから私たちは同じ安全でない状況を続けます。
JSONパッチの場合、信頼できる配列内に値がある場合は、「テスト」操作を使用できます。テストが失敗した場合、パッチ操作全体が失敗する必要があります。http://jsonpatch.com/#test
XMLパッチについては、セレクタと同様の操作を実行できると思いますか？ https://tools.ietf.org/html/rfc5261#section-4.1 - 更新する内容によって異なります。
また、バージョンが一致した場合にのみパッチを適用するようにしてください。バージョン・ブラインドで臨床データを更新する必要はほとんどありません。
はい。それは危険です。バージョン固有の書き込みをパッチと混ぜて安全にするか、あるいはこれが起こらないように他の方法を使うか、XMLパッチを使うことはできません。これらの制限はXMLパッチに内在しています。これらの制限がないFHIRPathベースのパッチを使用することはできませんが、複数の書き込みに関連する問題は回避されません。 –
私は問題がXMLまたはJSONを使用することによるとは思わない、実際には私たちはjsonパッチとfhirパッチで作業しています。リソースのバージョンを使用して、正しいリソースを変更していることを確認しますが、バージョンIDが同じであることがわかっても、サーバの想定する順序と同じ順序で配列の位置を確認することはできません。 FHIR臨床プロトコルAPIは安全性が高く、文書化された標準的な方法であり、クライアント側がどのようにデータを準備して送信するか、サーバーが配列をどのように配列するかに依存しないでください。 –
私はそれがかなり明白であったことに基づいてこれを文書化しなかったと思います。注文を維持できないサーバーはインデックスベースのパッチをサポートしません。しかし、私たちは見ることができないサーバーは見ていません –