VOTE on Feb 22: Stephen/Eric: 13-0-0 – rename from CarePlan.activity.detail.prohibited to doNotPerform VOTE on March 1: Stephen/Russ: 10-0-0 – see spreadsheet for rows marked with this vote (mainly mapping updates and exemptions) VOTE on March 8: Rob/Emma: 5-0-0 1. Condition.asserter (Person who asserts this condition; Individual who is making the condition statement) - Is this who.source or who.actor? Recorder (author) - existing Reporter (source) - Who provided the information in this resource - Emma and Rob believe asserter is more like who.source - TO DO: unmap Condition.asserter from workflow's Event.performer.actor Who diagnosed it? (actor?) - Who did the work described the resource (or will do) 2. Review instantiates changes across all PC workflow-related resources - TO DO: update all resources accordingly 3. CarePlan.author cardinality – do all of the authors accept responsibility for the whole plan as it is? There's a difference between authorship (who has responsibility for the current version) and contribution For example, version 1 of a CarePlan will have a single author, but version 2 of a CarePlan will have two authors. Not one author is responsible for the entire CarePlan. The author isn't the author of a single instance or version, but rather CarePlan.author is all contributors. TO DO: Talk to workflow about exemption again. 4. CarePlan.activity.detail.statusReason data type – change string to CodeableConcept? TO DO: Agree to switch to CodeableConcept 5. Exempt FamilyMemberHistory from having an Event.occurrence (when.done) TO DO: Exempt because when.recorded is good enough proxy for when.done FamilyMemberHistory.date is defined "When history was recorded or last updated" 6. Remove CommunicationRequest.category mapping to Request.code (like we did for Communication) TO DO: Exempt since category is more like class, not what 7. Exempt CommunicationRequest from having a Request.doNotPerform TO DO: Add doNotPerform resource element Example: Do not call physician for abnormal result. Should that be managed as a Flag or a CommunicationRequest? Not a Flag. 8. CommunicationRequest.recipient – either remove workflow mapping (like Communication) or map to Request.subject to be aligned with w5 who.focus TO DO: Replace Communication and CommunicationRequest.recipient mappings to who.actor (not who.subject) TO DO: Map Communication.recipient to Event.performer.actor 9. Add CommunicationRequest.statusReason (Communication has it) TO DO: Add element to resource 10. Unmap CommunicationRequest.content workflow mapping to Request.supportingInfo TO DO: unmap because content IS the information, it isn't supporting information 11. Add *ClinicalImpression.statusReason *TO DO: Add element 12. map ClinicalImpression.effective (when.done) to Event.occurrence (when.done) TO DO: agree to add mapping to Event.occurrence 13. Value Set review for *CarePlan.intent * TO DO: to have value set with a subset of request's code system VOTE on March 22: Russ/Rob H.: 8-0-0 1) aligning CarePlan.status with Request.status 2) CarePlan.activity.detail.status exemption, 3) ClinicalImpression.status aligns with a subset of Event.status - specifically entered-in-error, completed, in-progress VOTE on June 28, 2018:Rob H/Eric: 9-0-0 1. Update mapping CommunicationRequest.recipient to Request.performer 2. Add suppressed-workflow-warnings for the following: * The resource CommunicationRequest does not have an element with a mapping to the Request pattern element Request.code, nor is it listed as a context in the corresponding extesnsion. Possibilities: mapping was missed; element is in the 80% and should be added and mapped; element is outside the 80% but should be supported by the standard pattern extension; element is not relevant and this warning should be added to the 'suppressed-workflow-warnings' file * The resource CarePlan has multiple elements that map to pattern element Request.instantiatesCanonical: . If this is because different elements are used for different types or because the resource embeds the concept of multiple Requests, then add to the 'suppressed-workflow-warnings' file. Otherwise, determine which element should actually be mapped * The resource CarePlan has multiple elements that map to pattern element Request.instantiatesUri: . If this is because different elements are used for different types or because the resource embeds the concept of multiple Requests, then add to the 'suppressed-workflow-warnings' file. Otherwise, determine which element should actually be mapped 3. Switch workflow resource-specific extensions to common workflow extensions 4. CarePlan.instantiatesCanonical should additionally reference Measure | ActivityDefinition | OperationDefinition 5. CarePlan.activity.detail.instantiatesCanonical should additionall reference Measure | OperationDefinition 6. CarePlan.author 0..1 (change cardinality, update definition) Who is the designated responsible party When populated, the author is responsible for the care plan. The care plan is attributed to the author. The author may also be a contributor. For example, an organization can be an author, but not listed as a contributor. Workflow mapping to Request.requestor 7. Add CarePlan.contributor 0..* Who provided the content of the care plan Identifies the individual(s) or organization who provided the contents of the care plan Collaborative care plans may have multiple contributors. No workflow mapping. 8. Communication.instantiatesCanonical should additionally reference Measure | OperationDefinition | Questionnaire 9. FamilyMemberHistory.instantiatesCanonical should additionally reference ActivityDefinition | Measure | OperationDefinition 10. Procedure.instantiatesCanonical should additionally reference Measure | OperationDefinition | Questionnaire 11. Procedure.instantiatesCanonical should NOT reference HealthcareService 12. Rename Procedure.performer.role to Procedure.performer.function