Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-39424

We need a new OperationDefinition for patient-export-pdex.

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci PDex (FHIR)
    • current
    • Financial Mgmt
    • Payer-to-Payer Exchange [deprecated]
    • 5.2.6
    • Hide

      Insert a new section to Payer-to-Payer Page

      Section 5.2.5 Constraining Data based upon Permissions of the Requestor

      The FHIR Server *SHALL* constrain the data returned from the server to a requestor based upon the access permissions of the requestor.

      For example, if a requestor queries for ExplanationOfBenefit resources but they are only allowed to see Prior Authorization records, and not EOB Claims, the FHIR Server shall filter the data accordingly.

      This Constraining condition may be required in implementations where multiple types of data are being served up by a single FHIR Server. The condition is particularly relevant when implementing Operations such as $everything or $export.

      The Patient/{id}/$everything-pdex operation will be removed from the IG and the section will reference the Constraints section above and the standard $everything operation.

      The Bulk FHIR Asynchronous Protocols section will be updated to reference the Constraints section above. 

      Show
      Insert a new section to Payer-to-Payer Page Section 5.2.5 Constraining Data based upon Permissions of the Requestor The FHIR Server * SHALL * constrain the data returned from the server to a requestor based upon the access permissions of the requestor. For example, if a requestor queries for ExplanationOfBenefit resources but they are only allowed to see Prior Authorization records, and not EOB Claims, the FHIR Server shall filter the data accordingly. This Constraining condition may be required in implementations where multiple types of data are being served up by a single FHIR Server. The condition is particularly relevant when implementing Operations such as $everything or $export. The Patient/{id}/$everything-pdex operation will be removed from the IG and the section will reference the Constraints section above and the standard $everything operation. The Bulk FHIR Asynchronous Protocols section will be updated to reference the Constraints section above. 
    • Bob Dieterle / MaryKay McDaniel: 8-0-0
    • Clarification
    • Non-compatible
    • 2.0.0-ballot

    Description

      Hi.

      This was raised during the workgroup conference call on November 11, 2022.

      PDex defines a discrete patient-everything-pdex OperationDefinition with its own canonical URL, which allows clients to distinguish between it and the base specification's Patient-everything operation.

      We need to do the same for the FHIR Bulk Data Access Patient Level Export operation. Presently, PDex simply refers to the existing definition. Since PDex expects $export to behave differently (e.g. constraining the payload to certain profiles), there's justification for a discrete OperationDefinition with its own canonical URL (e.g. patient-export-pdex).

      Additionally, if the intent is that patient-export-pdex will only ever be scoped to a single Patient, a discrete OperationDefinition can support this. Either include a required input parameter identifying the member (i.e. the Member ID) or make this an instance-level operation that includes the Patient resource ID in the request URL.

      Note we previously corrected the request URL pattern in FHIR-38650. All signs point to the need for a discrete OperationDefinition.

      Thanks!

      Attachments

        Activity

          People

            Unassigned Unassigned
            dmuylwyk Diederik Muylwyk
            Diederik Muylwyk
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: