Stream: workflow
Topic: Patient Care Exemption Requests
Michelle (Moseman) Miller (Mar 02 2018 at 00:28):
@Lloyd McKenzie Patient Care would like exemptions for all of these, which sounds like we needed to clear with workflow first?
1-The element CarePlan.intent has a fixed binding to code system(s) http://hl7.org/fhir/request-intent while the element uses the code system(s) http://hl7.org/fhir/care-plan-intent. Confirm this is necessary and, if so, discuss with the workflow project. (We're trying to use a consistent code system across all of FHIR when we can.)
2-The element CarePlan.careTeam has increased the maximum cardinality from 1 to *. Is it in the 80% for this element to repeat? Is there a need to change the workflow pattern? Please discuss with the workflow project.
3-The element CarePlan.activity.detail.performer has increased the maximum cardinality from 1 to *. Is it in the 80% for this element to repeat? Is there a need to change the workflow pattern? Please discuss with the workflow project.
4-The element CarePlan.author has increased the maximum cardinality from 1 to *. Is it in the 80% for this element to repeat? Is there a need to change the workflow pattern? Please discuss with the workflow project.
5-The element CarePlan.status has a fixed binding to code system(s) http://hl7.org/fhir/request-status while the element uses the code system(s) http://hl7.org/fhir/care-plan-status. Confirm this is necessary and, if so, discuss with the workflow project. (We're trying to use a consistent code system across all of FHIR when we can.)
6-The element CarePlan.activity.detail.status has a fixed binding to code system(s) http://hl7.org/fhir/request-status while the element uses the code system(s) http://hl7.org/fhir/care-plan-activity-status. Confirm this is necessary and, if so, discuss with the workflow project. (We're trying to use a consistent code system across all of FHIR when we can.)
7-The element Communication.sender has decreased the minimum cardinality from 1 to 0. Verify that it's acceptable to make this element optional. Is there a safe default? Does the pattern need to be adjusted? Please discuss with the Workflow project.
8-The element Communication.subject has decreased the minimum cardinality from 1 to 0. Verify that it's acceptable to make this element optional. Is there a safe default? Does the pattern need to be adjusted? Please discuss with the Workflow project.
9-The element CommunicationRequest.payload.content[x] has multiple workflow mappings () for the same workflow pattern. Discuss with the workflow group why this is done.
10-The element CommunicationRequest.recipient has increased the maximum cardinality from 1 to *. Is it in the 80% for this element to repeat? Is there a need to change the workflow pattern? Please discuss with the workflow project.
11-The element CommunicationRequest.subject has decreased the minimum cardinality from 1 to 0. Verify that it's acceptable to make this element optional. Is there a safe default? Does the pattern need to be adjusted? Please discuss with the Workflow project.
12-The element Condition.asserter has a w5 mapping of 'who.source' which disagrees with the Event pattern mapping of 'who.actor'. Either the element has the wrong workflow mapping, the element has the wrong w5 mapping or there's a problem with the pattern's w5 mapping. If you're not sure what to fix, please discuss with the Workflow project.
13-The element Condition.clinicalStatus has decreased the minimum cardinality from 1 to 0. Verify that it's acceptable to make this element optional. Is there a safe default? Does the pattern need to be adjusted? Please discuss with the Workflow project.
14-The element Condition.clinicalStatus has a fixed binding to code system(s) http://hl7.org/fhir/event-status while the element uses the code system(s) http://hl7.org/fhir/condition-clinical. Confirm this is necessary and, if so, discuss with the workflow project. (We're trying to use a consistent code system across all of FHIR when we can.)
15-The element Condition.verificationStatus has decreased the minimum cardinality from 1 to 0. Verify that it's acceptable to make this element optional. Is there a safe default? Does the pattern need to be adjusted? Please discuss with the Workflow project.
16-The element Condition.verificationStatus has a fixed binding to code system(s) http://hl7.org/fhir/event-status while the element uses the code system(s) http://hl7.org/fhir/condition-ver-status. Confirm this is necessary and, if so, discuss with the workflow project. (We're trying to use a consistent code system across all of FHIR when we can.)
17-The element FamilyMemberHistory.status has a fixed binding to code system(s) http://hl7.org/fhir/event-status while the element uses the code system(s) http://hl7.org/fhir/history-status. Confirm this is necessary and, if so, discuss with the workflow project. (We're trying to use a consistent code system across all of FHIR when we can.)
Michelle (Moseman) Miller (Mar 02 2018 at 00:29):
Let me know how best to proceed. I'm hoping these are all obvious, but if any of them warrant discussion, let me know and I can elaborate on our thought process.
Lloyd McKenzie (Mar 02 2018 at 00:48):
1. Why aren't you using the CarePlan code system? It's fine for you to have a value set that uses a subset of the codes, but it's not clear why you'd need a new code system.
4. Multiple authors are a bit problematic - 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
5, 6. Is there a reason you can't leverage the existing code system and define your own value set?
12 should be fixed - there's no reason for these to be inconsistent
Rest are ok
Michelle (Moseman) Miller (Mar 02 2018 at 00:56):
1. ok
4. I'll put it on the next PC agenda to discuss
5,6. our value set has elements (like stopped) that aren't in the existing code system....it sounds like you are saying, we could define our own value set which pulls from the existing request code system + our own code system for the additional codes we want included.
12. asserter is the actor when it's a Practitioner, but asserter isn't the actor (diagnosing the condition) when the asserter is the patient.
Lloyd McKenzie (Mar 02 2018 at 01:52):
5,6 - yes. Pharmacy has already got a code system that defines "stopped". Though I'm surprised it's relevant in the CarePlan space.
Lloyd McKenzie (Mar 02 2018 at 01:54):
12 - the w5 mapping should cover both. And it's a bit suspect that you're using one element to cover both informer and who actually made the diagnosis.
Michelle (Moseman) Miller (Mar 02 2018 at 02:09):
6 - status is at the CarePlan.activity.detail level, and the activity could be a medication, so stopped would apply here as well.
12 - we can revisit in PC, but are you saying that we can map a single element to multiple w5 elements (if we want to)? What is the delimiter?
For the others that you agree to exempt, I assume we treat those like the other exemptions by adding to suppressed-workflow-warnings.
Lloyd McKenzie (Mar 02 2018 at 02:21):
6 - then bind to the pharmacy value set.
Lloyd McKenzie (Mar 02 2018 at 02:22):
12 - comma should work.
Lloyd McKenzie (Mar 02 2018 at 02:22):
But hopefully you won't need to :)
Michelle (Moseman) Miller (Mar 15 2018 at 23:11):
@Lloyd McKenzie After discussing #4 with Patient Care last week, Patient Care would still like to ask for an exemption. 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 meant to be all contributors
Lloyd McKenzie (Mar 15 2018 at 23:19):
I would suggest renaming it to "contributor" then if the individual isn't deemed to be responsible for the full content of the current instance - because that's the meaning of the word "author" everywhere else. It might also be best to not map that to Request.author if the resource isn't capturing the notion of "author".
Last updated: Apr 12 2022 at 19:14 UTC
