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

Consider improving description of docref for clarity

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • US Core (FHIR)
    • 5.0.1
    • Cross-Group Projects
    • US Core Fetch DocumentReference
    • Hide

      See comment proposal below.  We will align with IPA and FHIR R5 $docref OperationDefinion and extend/constrain where appropriate for US Core.

      Show
      See comment proposal below.  We will align with IPA and FHIR R5 $docref OperationDefinion and extend/constrain where appropriate for US Core.
    • Eric Haas/Floyd Eisenberg: 14-0-0
    • Clarification
    • Non-substantive

    Description

      Ipa has gotten feedback requesting common sense wording improvements to the description of the docref operation. Specifically--

      New in bold.

      ~~~

      This operation is used to return all the requested references to documents related to a patient.

      The operation requires a patient id and takes the optional input parameters:

      start date
      end date
      document type
      on-demand
      profile
      and returns a Bundle of type "searchset" containing DocumentReference resources for the patient. If the server has or can create documents that are related to the patient, and that are available for the given user, the server returns the DocumentReference resources needed to support the records satisfy the operation parameters provided. The principal intended use for this operation is to provide a patient with access to their available document information.

      This operation is different differs from a search by patient and type and date range because:

      It is used to request from a server generate one or more document based on the specified parameters.
      If no optional parameters are specified, the server SHALL return a DocumentReference to the patient's most current summary document*.* (depending on jurisdiction) The type of such summary document will depend on jurisdiction, for example, it may be an IPS document, or a C-CDA CCD. It is expected that such a summary document will always exist, or can be dynamically generated, however a jurisdiction may define the outcome of the operation when such document is missing.
      If the server cannot generate a document based on the specified*,* optional parameters, the operation will return an empty search bundle.
      This operation is the same executes the same way as a FHIR RESTful search by patient, type and date range when there are existing documents the meet the requirements of the the request, because:

      References for existing documents that meet the requirements of the request SHOULD also be returned unless the client indicates they are only interested in 'on-demand' documents using the on-demand parameter.

      Attachments

        Activity

          People

            Unassigned Unassigned
            Isaac.Vetter Isaac Vetter
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: