Patient Request for Corrections Implementation Guide
1.0.0-ballot - STU 1 Ballot

This page is part of the Patient Request for Corrections Implementation Guide (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Resource Profile: Patient Correction Task

Defining URL:http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-task
Version:1.0.0-ballot
Name:PatientCorrectionTask
Title:Patient Correction Task
Status:Active as of 2022-03-29 04:29:26+0000
Definition:

Represents the process of reviewing the patient’s request for correction or the patient’s request to log a disagreement to a prior request for correction decision. This Task is spawned by the Fulfiller as a result of a post of a Communication resource that indicates a new request for correction or a new logging of a disagreement.

Publisher:HL7 International - Patient Empowerment Workgroup
Source Resource:XML / JSON / Turtle

The official URL for this profile is: 

http://hl7.org/fhir/uv/patient-corrections/StructureDefinition/patient-correction-task

This is the profile for the Patient Correction Task, which is used to summarize the Fulfiller process to support either a patient’s request for correction to their medical record or their logging of a disagreement to a correction denial. A Requester can query the Patient Correction Task (or request notifications) to understand the current state and history of the process for carrying out the request on the Fulfiller side. It can determine the type of process (Request for Correction or Log Disagreement), the current state of the process, timing information about the process (when did it start, when did it move through states, when did it complete), who made the original request on behalf of the Patient, and who owns the process on the Fulfiller side. This profile sets minimum expectations for the Task resource to support this workflow. It is expected to be used in conjunction with the Patient Correction Communication profile.

Mandatory and Must Support data elements

The following data-elements must always be present (Mandatory) definition]) or must be supported if the data is present (Must Support) definition). They are presented below in a simple human-readable explanation. Profile specific guidance is provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements. Refer to the Examples section of the guide for example resources provided in the context of an example workflow.

Each implementation of PatientCorrectionTask must provide:

  1. id: An id
  2. status: status combined with businessStatus provide the state of the process
  3. businessStatus: status combined with businessStatus provide the state of the process
  4. intent: fixed to “order”
  5. code: indicates whether it’s a “Request Correction” or “Log Disagreement” process
  6. for: the patient whose record is to be corrected
  7. requestor: the person who asked for the correction on behalf of the patient in Task.for.
  8. authoredOn: date/time when the request was received on the Fulfiller side
  9. lastModified: date/time of last update to the process.
  10. input: points to the Communication resource containing the original patient correction or log disagreement request.
  11. output: points to the Communication resource containing the resolution of the request (for example, the completed amendment report)
  12. reasonReference: if the Task represents a disagreement, points to the Task containing the original request for correction process.

Profile-specific implementation guidance

  • The Task is spawned by the Fulfiller as a result of receipt of a Request for a Correction or a Request to Log a Disagreement. It is expected that in most cases, these requests will be coming through a Communication resource. However, this specification does not preclude the use of Task when requests are received via alternative means such as paper forms in the mail.
  • When a request for correction or logging of a disagreement is received via a Request for Correction or Log Disagreement Communication resource posting, a Task is spawned and then several fields in the Task must be populated by copying from the Communication resource that contains the original request. In specific, code, for, requester, input, and authoredOn must be pulled from fields in the original Communication resource (see details on these fields below).
  • When the Task is posted on the Fulfiller as a result of an originating Communication resource, the Fulfiller must update the Communication resource to reference the Task in the Communication.about field.

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from Task

This structure is derived from Task

NameFlagsCard.TypeDescription & Constraintsdoco
.. Task 0..*TaskA task to be performed
... identifier S0..*IdentifierA business identifier for the correction process.
... basedOn 0..0
... partOf 0..0
... statusReason 0..1CodeableConceptThe reason for the correction request status. Codes to identify the reason for current status. These will typically be specific to a particular workflow.
... businessStatus S0..1CodeableConceptThe business status of the request for correction process or the log disagreement process. The domain-specific business-contextual sub-state of the task. For example: Waiting on additional information from requester, waiting on additional information from fulfiller (could be a specific party on the fulfiller side), more time needed to review request, an amendment will be made to the record, an amendment has been made to the record, current record determined accurate and will not be amended, a partial amendment will be made to the record, a partial amendment has been made to the record, disagreement has been reviewed and attached to the record, disagreement has been rebutted.
Binding: PatientCorrectionBusinessStatusVS (required)
... intent 1..1codeunknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option
Fixed Value: order
... code S1..1CodeableConceptCode and code.text to represent patient correction, or Code and code.text to represent a disagreement.
Binding: PatientCorrectionTaskTypesVS (required)
... for S1..1Reference(Patient)The patient whose record this correction references. If request received through Communication resource, must be populated with the value of Communication.subject from the original request for correction Communication resource or log disagreement Communication resource.
... encounter 0..0
... executionPeriod 0..1PeriodExecutionPeriod.end can be used by the Fulfiller to represent when the request is completed.
... authoredOn S1..1dateTimeThe date/time that the original request was received by the Fulfiller, kicking off the request for correction or log disagreement process. If the request was received within the payload of a Communication resource, it should match Communication.sent from the original request Communication resource.
... lastModified S0..1dateTimeIndicates the most recent modification date/time on the correction process – usually would change in conjunction with a status or businessStatus change. Useful when doing historical version searches as well. lastModified when status = completed gives the process completion date/time.
... requester S0..1Reference(Patient | RelatedPerson)The entity that is requesting the correction or logging the disagreement such as the patient themselves or their caregiver.
... owner S0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService)The entity that is responsibility for fulfilling the request. Initially, this could be populated from Communication.recipient on the Communication resource of the initial request. TheFulfiller can then refine to a specific individual, group, role, or department. For example, a medical records staff person.
... reasonCode 0..1CodeableConceptWhy task is needed. E.g. Need record correct prior to upcoming surgery.
... reasonReference I0..1Reference(Patient Correction Task)Used on Log Disagreement Task to point to the original Request for Correction Task.
task-reasonreference: If Task.code indicates this is a Disagreement Task, this field SHALL reference the original Request for Correction Communication.
... note 0..*AnnotationComments made about the task
... restriction 0..0
... input I0..*BackboneElementInformation used to perform task
task-input: Task.input SHALL only be populated or updated by the CorrectionRequestor.
.... id 0..0
.... extension 0..0
.... modifierExtension 0..0
.... type 1..1CodeableConceptLabel for input
Binding: PatientCorrectionCommunicationTypesVS (required)
.... value[x] 1..1Content to use in performing the task
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)
... output I0..*BackboneElementFormal Response from Fulfiller to the Correction Request or to the Disagreement to Correction Denial.
task-output1: Task.output SHALL only be populated or updated by the CorrectionFulfiller.
task-output2: If Task.code indicates this is a Request for Correction Task, this field SHALL contain the formal response to the request (acceptance, denial, partial acceptance/denial).
task-output3: If Task.code indicates this is a Disagreement Task, this field SHALL contain the formal response to the disagreement and optionally a rebuttal.
.... id 0..0
.... extension 0..0
.... modifierExtension 0..0
.... type 1..1CodeableConceptLabel for output
Binding: PatientCorrectionOutputTypesVS (required)
.... value[x] 1..1Result of output
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. Task I0..*TaskA task to be performed
... id Σ0..1stringLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages: A human language.

... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... identifier S0..*IdentifierA business identifier for the correction process.
... instantiatesCanonical Σ0..1canonical(ActivityDefinition)Formal definition of task
... instantiatesUri Σ0..1uriFormal definition of task
... groupIdentifier Σ0..1IdentifierRequisition or grouper id
... status ?!SΣ1..1codeThe current status of the Correction Request or Log Disagreement process. The status, in conjunction with the business status, can be used to determine the state of the process.
Binding: TaskStatus (required)
... statusReason Σ0..1CodeableConceptThe reason for the correction request status. Codes to identify the reason for current status. These will typically be specific to a particular workflow.
Binding: (unbound) (example): Codes to identify the reason for current status. These will typically be specific to a particular workflow.

... businessStatus SΣ0..1CodeableConceptThe business status of the request for correction process or the log disagreement process. The domain-specific business-contextual sub-state of the task. For example: Waiting on additional information from requester, waiting on additional information from fulfiller (could be a specific party on the fulfiller side), more time needed to review request, an amendment will be made to the record, an amendment has been made to the record, current record determined accurate and will not be amended, a partial amendment will be made to the record, a partial amendment has been made to the record, disagreement has been reviewed and attached to the record, disagreement has been rebutted.
Binding: PatientCorrectionBusinessStatusVS (required)
... intent Σ1..1codeunknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option
Binding: TaskIntent (required): Distinguishes whether the task is a proposal, plan or full order.


Fixed Value: order
... priority 0..1coderoutine | urgent | asap | stat
Binding: RequestPriority (required): The task's priority.

... code SΣ1..1CodeableConceptCode and code.text to represent patient correction, or Code and code.text to represent a disagreement.
Binding: PatientCorrectionTaskTypesVS (required)
... description Σ0..1stringHuman-readable explanation of task
... focus Σ0..1Reference(Resource)What task is acting on
... for SΣ1..1Reference(Patient)The patient whose record this correction references. If request received through Communication resource, must be populated with the value of Communication.subject from the original request for correction Communication resource or log disagreement Communication resource.
... executionPeriod Σ0..1PeriodExecutionPeriod.end can be used by the Fulfiller to represent when the request is completed.
... authoredOn SI1..1dateTimeThe date/time that the original request was received by the Fulfiller, kicking off the request for correction or log disagreement process. If the request was received within the payload of a Communication resource, it should match Communication.sent from the original request Communication resource.
... lastModified SΣI0..1dateTimeIndicates the most recent modification date/time on the correction process – usually would change in conjunction with a status or businessStatus change. Useful when doing historical version searches as well. lastModified when status = completed gives the process completion date/time.
... requester SΣ0..1Reference(Patient | RelatedPerson)The entity that is requesting the correction or logging the disagreement such as the patient themselves or their caregiver.
... performerType 0..*CodeableConceptRequested performer
Binding: ProcedurePerformerRoleCodes (preferred): The type(s) of task performers allowed.


... owner SΣ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService)The entity that is responsibility for fulfilling the request. Initially, this could be populated from Communication.recipient on the Communication resource of the initial request. TheFulfiller can then refine to a specific individual, group, role, or department. For example, a medical records staff person.
... location Σ0..1Reference(Location)Where task occurs
... reasonCode 0..1CodeableConceptWhy task is needed. E.g. Need record correct prior to upcoming surgery.
Binding: (unbound) (example): Indicates why the task is needed. E.g. Suspended because patient admitted to hospital.

... reasonReference I0..1Reference(Patient Correction Task)Used on Log Disagreement Task to point to the original Request for Correction Task.
task-reasonreference: If Task.code indicates this is a Disagreement Task, this field SHALL reference the original Request for Correction Communication.
... insurance 0..*Reference(Coverage | ClaimResponse)Associated insurance coverage
... note 0..*AnnotationComments made about the task
... relevantHistory 0..*Reference(Provenance)Key events in history of the Task
... input I0..*BackboneElementInformation used to perform task
task-input: Task.input SHALL only be populated or updated by the CorrectionRequestor.
.... type 1..1CodeableConceptLabel for input
Binding: PatientCorrectionCommunicationTypesVS (required)
.... value[x] 1..1Content to use in performing the task
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)
... output I0..*BackboneElementFormal Response from Fulfiller to the Correction Request or to the Disagreement to Correction Denial.
task-output1: Task.output SHALL only be populated or updated by the CorrectionFulfiller.
task-output2: If Task.code indicates this is a Request for Correction Task, this field SHALL contain the formal response to the request (acceptance, denial, partial acceptance/denial).
task-output3: If Task.code indicates this is a Disagreement Task, this field SHALL contain the formal response to the disagreement and optionally a rebuttal.
.... type 1..1CodeableConceptLabel for output
Binding: PatientCorrectionOutputTypesVS (required)
.... value[x] 1..1Result of output
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. Task I0..*TaskA task to be performed
... identifier 0..*IdentifierA business identifier for the correction process.
... status ?!Σ1..1codeThe current status of the Correction Request or Log Disagreement process. The status, in conjunction with the business status, can be used to determine the state of the process.
Binding: TaskStatus (required)
... businessStatus Σ0..1CodeableConceptThe business status of the request for correction process or the log disagreement process. The domain-specific business-contextual sub-state of the task. For example: Waiting on additional information from requester, waiting on additional information from fulfiller (could be a specific party on the fulfiller side), more time needed to review request, an amendment will be made to the record, an amendment has been made to the record, current record determined accurate and will not be amended, a partial amendment will be made to the record, a partial amendment has been made to the record, disagreement has been reviewed and attached to the record, disagreement has been rebutted.
Binding: PatientCorrectionBusinessStatusVS (required)
... for Σ1..1Reference(Patient)The patient whose record this correction references. If request received through Communication resource, must be populated with the value of Communication.subject from the original request for correction Communication resource or log disagreement Communication resource.
... authoredOn I1..1dateTimeThe date/time that the original request was received by the Fulfiller, kicking off the request for correction or log disagreement process. If the request was received within the payload of a Communication resource, it should match Communication.sent from the original request Communication resource.
... lastModified ΣI0..1dateTimeIndicates the most recent modification date/time on the correction process – usually would change in conjunction with a status or businessStatus change. Useful when doing historical version searches as well. lastModified when status = completed gives the process completion date/time.
... requester Σ0..1Reference(Patient | RelatedPerson)The entity that is requesting the correction or logging the disagreement such as the patient themselves or their caregiver.
... owner Σ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService)The entity that is responsibility for fulfilling the request. Initially, this could be populated from Communication.recipient on the Communication resource of the initial request. TheFulfiller can then refine to a specific individual, group, role, or department. For example, a medical records staff person.

doco Documentation for this format

This structure is derived from Task

Summary

Mandatory: 3 elements
Must-Support: 9 elements
Fixed Value: 1 element
Prohibited: 10 elements

Structures

This structure refers to these other structures:

Differential View

This structure is derived from Task

NameFlagsCard.TypeDescription & Constraintsdoco
.. Task 0..*TaskA task to be performed
... identifier S0..*IdentifierA business identifier for the correction process.
... basedOn 0..0
... partOf 0..0
... statusReason 0..1CodeableConceptThe reason for the correction request status. Codes to identify the reason for current status. These will typically be specific to a particular workflow.
... businessStatus S0..1CodeableConceptThe business status of the request for correction process or the log disagreement process. The domain-specific business-contextual sub-state of the task. For example: Waiting on additional information from requester, waiting on additional information from fulfiller (could be a specific party on the fulfiller side), more time needed to review request, an amendment will be made to the record, an amendment has been made to the record, current record determined accurate and will not be amended, a partial amendment will be made to the record, a partial amendment has been made to the record, disagreement has been reviewed and attached to the record, disagreement has been rebutted.
Binding: PatientCorrectionBusinessStatusVS (required)
... intent 1..1codeunknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option
Fixed Value: order
... code S1..1CodeableConceptCode and code.text to represent patient correction, or Code and code.text to represent a disagreement.
Binding: PatientCorrectionTaskTypesVS (required)
... for S1..1Reference(Patient)The patient whose record this correction references. If request received through Communication resource, must be populated with the value of Communication.subject from the original request for correction Communication resource or log disagreement Communication resource.
... encounter 0..0
... executionPeriod 0..1PeriodExecutionPeriod.end can be used by the Fulfiller to represent when the request is completed.
... authoredOn S1..1dateTimeThe date/time that the original request was received by the Fulfiller, kicking off the request for correction or log disagreement process. If the request was received within the payload of a Communication resource, it should match Communication.sent from the original request Communication resource.
... lastModified S0..1dateTimeIndicates the most recent modification date/time on the correction process – usually would change in conjunction with a status or businessStatus change. Useful when doing historical version searches as well. lastModified when status = completed gives the process completion date/time.
... requester S0..1Reference(Patient | RelatedPerson)The entity that is requesting the correction or logging the disagreement such as the patient themselves or their caregiver.
... owner S0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService)The entity that is responsibility for fulfilling the request. Initially, this could be populated from Communication.recipient on the Communication resource of the initial request. TheFulfiller can then refine to a specific individual, group, role, or department. For example, a medical records staff person.
... reasonCode 0..1CodeableConceptWhy task is needed. E.g. Need record correct prior to upcoming surgery.
... reasonReference I0..1Reference(Patient Correction Task)Used on Log Disagreement Task to point to the original Request for Correction Task.
task-reasonreference: If Task.code indicates this is a Disagreement Task, this field SHALL reference the original Request for Correction Communication.
... note 0..*AnnotationComments made about the task
... restriction 0..0
... input I0..*BackboneElementInformation used to perform task
task-input: Task.input SHALL only be populated or updated by the CorrectionRequestor.
.... id 0..0
.... extension 0..0
.... modifierExtension 0..0
.... type 1..1CodeableConceptLabel for input
Binding: PatientCorrectionCommunicationTypesVS (required)
.... value[x] 1..1Content to use in performing the task
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)
... output I0..*BackboneElementFormal Response from Fulfiller to the Correction Request or to the Disagreement to Correction Denial.
task-output1: Task.output SHALL only be populated or updated by the CorrectionFulfiller.
task-output2: If Task.code indicates this is a Request for Correction Task, this field SHALL contain the formal response to the request (acceptance, denial, partial acceptance/denial).
task-output3: If Task.code indicates this is a Disagreement Task, this field SHALL contain the formal response to the disagreement and optionally a rebuttal.
.... id 0..0
.... extension 0..0
.... modifierExtension 0..0
.... type 1..1CodeableConceptLabel for output
Binding: PatientCorrectionOutputTypesVS (required)
.... value[x] 1..1Result of output
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)

doco Documentation for this format

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Task I0..*TaskA task to be performed
... id Σ0..1stringLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages: A human language.

... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... identifier S0..*IdentifierA business identifier for the correction process.
... instantiatesCanonical Σ0..1canonical(ActivityDefinition)Formal definition of task
... instantiatesUri Σ0..1uriFormal definition of task
... groupIdentifier Σ0..1IdentifierRequisition or grouper id
... status ?!SΣ1..1codeThe current status of the Correction Request or Log Disagreement process. The status, in conjunction with the business status, can be used to determine the state of the process.
Binding: TaskStatus (required)
... statusReason Σ0..1CodeableConceptThe reason for the correction request status. Codes to identify the reason for current status. These will typically be specific to a particular workflow.
Binding: (unbound) (example): Codes to identify the reason for current status. These will typically be specific to a particular workflow.

... businessStatus SΣ0..1CodeableConceptThe business status of the request for correction process or the log disagreement process. The domain-specific business-contextual sub-state of the task. For example: Waiting on additional information from requester, waiting on additional information from fulfiller (could be a specific party on the fulfiller side), more time needed to review request, an amendment will be made to the record, an amendment has been made to the record, current record determined accurate and will not be amended, a partial amendment will be made to the record, a partial amendment has been made to the record, disagreement has been reviewed and attached to the record, disagreement has been rebutted.
Binding: PatientCorrectionBusinessStatusVS (required)
... intent Σ1..1codeunknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option
Binding: TaskIntent (required): Distinguishes whether the task is a proposal, plan or full order.


Fixed Value: order
... priority 0..1coderoutine | urgent | asap | stat
Binding: RequestPriority (required): The task's priority.

... code SΣ1..1CodeableConceptCode and code.text to represent patient correction, or Code and code.text to represent a disagreement.
Binding: PatientCorrectionTaskTypesVS (required)
... description Σ0..1stringHuman-readable explanation of task
... focus Σ0..1Reference(Resource)What task is acting on
... for SΣ1..1Reference(Patient)The patient whose record this correction references. If request received through Communication resource, must be populated with the value of Communication.subject from the original request for correction Communication resource or log disagreement Communication resource.
... executionPeriod Σ0..1PeriodExecutionPeriod.end can be used by the Fulfiller to represent when the request is completed.
... authoredOn SI1..1dateTimeThe date/time that the original request was received by the Fulfiller, kicking off the request for correction or log disagreement process. If the request was received within the payload of a Communication resource, it should match Communication.sent from the original request Communication resource.
... lastModified SΣI0..1dateTimeIndicates the most recent modification date/time on the correction process – usually would change in conjunction with a status or businessStatus change. Useful when doing historical version searches as well. lastModified when status = completed gives the process completion date/time.
... requester SΣ0..1Reference(Patient | RelatedPerson)The entity that is requesting the correction or logging the disagreement such as the patient themselves or their caregiver.
... performerType 0..*CodeableConceptRequested performer
Binding: ProcedurePerformerRoleCodes (preferred): The type(s) of task performers allowed.


... owner SΣ0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService)The entity that is responsibility for fulfilling the request. Initially, this could be populated from Communication.recipient on the Communication resource of the initial request. TheFulfiller can then refine to a specific individual, group, role, or department. For example, a medical records staff person.
... location Σ0..1Reference(Location)Where task occurs
... reasonCode 0..1CodeableConceptWhy task is needed. E.g. Need record correct prior to upcoming surgery.
Binding: (unbound) (example): Indicates why the task is needed. E.g. Suspended because patient admitted to hospital.

... reasonReference I0..1Reference(Patient Correction Task)Used on Log Disagreement Task to point to the original Request for Correction Task.
task-reasonreference: If Task.code indicates this is a Disagreement Task, this field SHALL reference the original Request for Correction Communication.
... insurance 0..*Reference(Coverage | ClaimResponse)Associated insurance coverage
... note 0..*AnnotationComments made about the task
... relevantHistory 0..*Reference(Provenance)Key events in history of the Task
... input I0..*BackboneElementInformation used to perform task
task-input: Task.input SHALL only be populated or updated by the CorrectionRequestor.
.... type 1..1CodeableConceptLabel for input
Binding: PatientCorrectionCommunicationTypesVS (required)
.... value[x] 1..1Content to use in performing the task
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)
... output I0..*BackboneElementFormal Response from Fulfiller to the Correction Request or to the Disagreement to Correction Denial.
task-output1: Task.output SHALL only be populated or updated by the CorrectionFulfiller.
task-output2: If Task.code indicates this is a Request for Correction Task, this field SHALL contain the formal response to the request (acceptance, denial, partial acceptance/denial).
task-output3: If Task.code indicates this is a Disagreement Task, this field SHALL contain the formal response to the disagreement and optionally a rebuttal.
.... type 1..1CodeableConceptLabel for output
Binding: PatientCorrectionOutputTypesVS (required)
.... value[x] 1..1Result of output
..... valueStringstring
..... valueAttachmentAttachment
..... valueReferenceReference(Patient Correction Communication)

doco Documentation for this format

 

Other representations of profile: CSV, Excel, Schematron

Terminology Bindings

PathConformanceValueSet / Code
Task.languagepreferredCommonLanguages
Max Binding: AllLanguages
Task.statusrequiredTaskStatus
Task.statusReasonexample
Task.businessStatusrequiredPatientCorrectionBusinessStatusVS
Task.intentrequiredFixed Value: order
Task.priorityrequiredRequestPriority
Task.coderequiredPatientCorrectionTaskTypesVS
Task.performerTypepreferredProcedurePerformerRoleCodes
Task.reasonCodeexample
Task.input.typerequiredPatientCorrectionCommunicationTypesVS
Task.output.typerequiredPatientCorrectionOutputTypesVS

Constraints

IdGradePathDetailsRequirements
task-reasonreferenceerrorTask.reasonReferenceIf Task.code indicates this is a Disagreement Task, this field SHALL reference the original Request for Correction Communication.
: true
task-inputerrorTask.inputTask.input SHALL only be populated or updated by the CorrectionRequestor.
: true
task-output1errorTask.outputTask.output SHALL only be populated or updated by the CorrectionFulfiller.
: true
task-output2errorTask.outputIf Task.code indicates this is a Request for Correction Task, this field SHALL contain the formal response to the request (acceptance, denial, partial acceptance/denial).
: true
task-output3errorTask.outputIf Task.code indicates this is a Disagreement Task, this field SHALL contain the formal response to the disagreement and optionally a rebuttal.
: true