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

Add clarification to use of $everything operation

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • US Da Vinci PDex (FHIR)
    • 1.0.0
    • Financial Mgmt
    • PDex Implementation, Actors, Interactions, Data Payloads and Methods
    • 4.0.3
    • Hide

      Add additional guidance in the use of $everything. 

      Use _type to identify resourceTypes to return, including Provenance.

      The following has been added to section 4.0.3  Patient $everything via alternate secure transport:

       

      The FHIR Specification provides for a Patient-everything operation. The supported format is:

      • URL: [base]/Patient/[id]/$everything

      Health Plans SHOULD enable support for a Patient-everything bundle to be created. Exchange of this bundle SHOULD be accomplished using SMART or SMART Backend services. The bundle may alternatively be exchanged via a transport method that supports the secure exchange of PHI.

      This operation is intended to simplify requests from a client application when requesting records for a patient.

      $everything is an operation. Operations do not support the full range of query parameters available to a regular search request. PDex recommends the use of _revInclude in search operations to retrieve associated Provenance resources. In cases where Provenance is being requested as part of the $everythng operation this is accomplished by specifying Provenance as one of a list of resources included in the _type parameter of the $everything operation.

      Example of _type parameter:
       _type=Condition,Device,Encounter,Immunization,Observation,Procedure,Provenance
      A Health Plan’s FHIR API SHOULD support the Patient-everything operation as defined in the FHIR R4 specification here: https://www.hl7.org/fhir/operation-patient-everything.html

       

       

      Show
      Add additional guidance in the use of $everything.  Use _type to identify resourceTypes to return, including Provenance. The following has been added to section 4.0.3  Patient $everything via alternate secure transport:   The FHIR Specification provides for a Patient-everything operation . The supported format is: URL: [base] /Patient/ [id] /$everything Health Plans SHOULD enable support for a Patient-everything bundle to be created. Exchange of this bundle SHOULD be accomplished using SMART or SMART Backend services. The bundle may alternatively be exchanged via a transport method that supports the secure exchange of PHI. This operation is intended to simplify requests from a client application when requesting records for a patient. $everything is an operation. Operations do not support the full range of query parameters available to a regular search request. PDex recommends the use of _revInclude in search operations to retrieve associated Provenance resources. In cases where Provenance is being requested as part of the $everythng operation this is accomplished by specifying Provenance as one of a list of resources included in the _type parameter of the $everything operation. Example of _type parameter:   _type=Condition,Device,Encounter,Immunization,Observation,Procedure,Provenance A Health Plan’s FHIR API SHOULD support the Patient-everything operation as defined in the FHIR R4 specification here: https://www.hl7.org/fhir/operation-patient-everything.html    
    • Bob Dieterle / Chris Johnson: 12-0-1
    • Clarification
    • Non-substantive
    • Yes
    • 1.0.0

    Description

      It is unclear whether Patient $everything returns Provenance records. 

      The proposed resolution is to provide additional guidance in the Guide to provide a list of Resources to be returned in the $everything parameters using the _type parameter. (https://www.hl7.org/fhir/operation-patient-everything.html)

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            ekivemark Mark Scrimshire
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: