DraftTaskProfilesForPatientCorrections

	A	B	C	D	E	F
1	Name	Flags	Card	Type	Description and Constraints	Notes

2	identifier	Must Support	0..*	Identifier	A business identifier for the correction process. It could be assigned by requester or fulfiller
3	instantiatesCanonical		0..1
4	instantiatesUri		0..1
5	basedOn		0..*
6	groupIdentifier		0..1
7	partOf		0..*		Could potentically be used on child tasks on a request for correction task if part is accepted and part in denied
8	status	M	1..1	code	Value Set - certain values recommended. Some must be supported.
9	statusReason	M	0..1		Reason for rejection, for example
10	businessStatus	M	0..1	code	Provide further detail on status. Examples include Extended to represent that the consideration of an amendment request has been extended.
11	intent		1..1	code	"Order"
12	priority		0..1	code
13	code	M	1..1	code	Code and code.text to represent patient correction. Code and code.text to represent a disagreement.
14	description	M	1..1	string - use full markdown extension	Human readable description of what is to be performed. For example: "Please correct the Progress Note dated 2/10/20 in which you state that I am a smoke cigarettes. I do not smoke cigarettes but do smoke cigars".
15	focus	M	0..1
16	for	M	1..1	Reference(Patient)	The patient whose record this correction references	Can this be just a display string? Or should it be an actual resource reference?
17	encounter		0..1		This is to indicate that this specific task originated in a specific encounter. Correction requests from patients are expected to usually originate outside of an encounter. An exception might be requests for correction sent from the inpatient bedside by patient or caregiver.
18	executionPeriod	M	0..1		If the requester needs the correction to be done by a specific date, this is specified in ExecutionPeriod.end
19	authoredOn	M	1..1	dateTime	Constrained to 1..1. Date/Time original request was authored
20	lastModified	M	0..1	dataTime
21	requester	M	1..1	Reference(Device \| Organization \| Patient \| Practitioner \| PractitionerRole \| RelatedPerson)	The entity that requests the correction. Examples - Patient, CareGiver, Clinician.	Can this be just a display string? Or should it be an actual resource reference?
22	performerType		0..*
23	owner	M	0..1	Reference(Practitioner \| PractitionerRole \| Organization \| CareTeam \| HealthcareService \| Patient \| Device \| RelatedPerson)	The entity that is responsibility for fulfilling the request. Especially important to indicate owner on Fulfiller side
24	location		0..1
25	reasonCode		0..1
26	reasonReference		0..1
27	insurance		0..*
28	note		0..*		Notes from those that are working on the correction task about that work.
29	relevantHistory		0..*	Reference(Provenance)
30	restriction		0..0
31	repetitions
32	period
33	recipient
34	input		0..*		Provides details about the specific correction being requested	This would be 'Must support' then?
35	type		1..1		Possible types: 1) Encounter in which error was made, 2) supporting image, 3) Resource in dispute, 4) Suggested Correction resource, 5) Who to notify and how, 6) Supporting information, 7) Associated document
36	valueReference, valueAttachment, valueString		1..1		1) Reference (Encounter), 2) Attachment, 3) Reference (Backbone), 4) Reference (Backbone), 5) Reference (CommunicationRequest), 6) String 7) DocumentReference
37	output		0..*		Documentation about the Correction from the Fulfiller. For example, an explanation about request is extended 60 days, that patient can ask to have correction sent to third parties, or an explanation of denial and a patient's right to disagree,
38	type		1..1		Type indicating "Additional Information"
39	valueString		1..1
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100