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

$everything now includes Provenance and AuditEvent

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • FHIR Core (FHIR)
    • R5
    • Patient Administration
    • Operations List
    • $everything
    • Hide

      We will cleanup a few items in the $everything page:

       

      This narrative will be updated from:

      "In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned."

      to:

      "Implementation guides may make additional rules about how much information that is returned."

       

      This section will be updated from:

      This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment.

      to:

      This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. 

       

      We will update this from:

      When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so.

      to:

      When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for Searching, using the _count parameter, and Bundle links. There is no defined order for the results of $everything. Servers MAY consider sorting the returned resources in descending order of last record update.

      Show
      We will cleanup a few items in the $everything page:   This narrative will be updated from: "In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide. Other applicable implementation guides may make additional rules about how much information that is returned." to: "Implementation guides may make additional rules about how much information that is returned."   This section will be updated from: This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment. to: This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources.     We will update this from: When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made  asynchronously , and associated with  bulk data formats . Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for  Searching , using the  _count  parameter, and Bundle links. Implementers should note that paging will be slower than simply returning all the results at once (more network traffic, multiple latency delays) but may be required in order not to exhaust available memory reading or writing the whole response in a single package. Unlike searching, there is no inherent user-display order for the $everything operation. Servers might consider sorting the returned resources in descending order of last record update, but are not required to do so. to: When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made  asynchronously , and associated with  bulk data formats . Alternatively, clients may choose to page through the result set (or servers may require this). Paging through the results is done the same as for  Searching , using the  _count parameter, and Bundle links. There is no defined order for the results of $everything. Servers MAY consider sorting the returned resources in descending order of last record update.
    • Sonja Ziegler / Cooper Thompson: 12-0-0
    • Clarification
    • Non-substantive

    Description

      The Patient compartment now does include Provenace and AuditEvent. So the text in the operation 

      "This frees the client from needing to determine what it could or should ask for, particularly with regard to included resources. Servers should consider returning appropriate Provenance and AuditTrail on the returned resources, even though these are not directly part of the patient compartment."

       

      Should be modified. There is some concern that including AuditEvent is undesirable. So the warning might simply need to be inverted to indicate that they are included in the Patient compartment, but a server may chose to NOT return them.

       

      also "AuditTrail" is not a resource, it is "AuditEvent"

       

      https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.24everything.20and.20auditEvent

      Attachments

        Activity

          People

            Unassigned Unassigned
            john_moehrke John Moehrke
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: