element for indicated who or what changes the status

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU2
    • Orders & Observations
    • STU
    • Observation
    • Hide

      Deferred

      Not Persuasive Eric Haas/Riki Merrick: 8-3-1 Feb 02 201

      (Negative ballot items will need to be voted as not persuasive if you want to defer them for R3 publishing-make the status "Deferred")

      --------------------------------------------------------------------------------

      Use the Provenance resource here to indicate the actors involved in updates.

      Add the extension `event.eventHistory` to allow referencing past event history for all OO event resources: Observation, DiagnosticReport, Task, SupplyDelivery, DocumentUseStatement. This extension will be defined by this request pattern element: http://build.fhir.org/request-definitions.html#Request.relevantHistory and Pharmacy's: http://build.fhir.org/medicationadministration-definitions.html#MedicationAdministration.eventHistory

      document: that is does not replace work-flow management but but for documentation of past events that lead to status

      Show
      Deferred Not Persuasive Eric Haas/Riki Merrick: 8-3-1 Feb 02 201 (Negative ballot items will need to be voted as not persuasive if you want to defer them for R3 publishing-make the status "Deferred") -------------------------------------------------------------------------------- Use the Provenance resource here to indicate the actors involved in updates. Add the extension `event.eventHistory` to allow referencing past event history for all OO event resources: Observation, DiagnosticReport, Task, SupplyDelivery, DocumentUseStatement. This extension will be defined by this request pattern element: http://build.fhir.org/request-definitions.html#Request.relevantHistory and Pharmacy's: http://build.fhir.org/medicationadministration-definitions.html#MedicationAdministration.eventHistory document: that is does not replace work-flow management but but for documentation of past events that lead to status
    • Jose Costa-Teixeira/Eric Haas: 13-0-2
    • Enhancement
    • Non-substantive
    • DSTU2

      This comment was triggered by #9675 resolution Either a person or machine could initiate the change to a final status. However, it is unclear whether the existing performer and device attributes are sufficient to infer who did it. Perhaps that requires another attribute to indicate which of the two, or perhaps it needs even an attribute with the status to indicate who finalized the status.

            Assignee:
            Unassigned
            Reporter:
            Hans Buitendijk
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: