E-mail
Case types: all
The following activity types are needed in all types of cases.
Activity Type:Open case
Auto: No
Offset:
MaxInstances:
This is the final activity prior to the assignment of a case type. There may be other activities with a contact that happen before the start of this one, but this one should result in the assignment of a case type, and the creation of an actual case. We may work to optimize later some of the activity flow that happens prior to this one.
Custom Fields:
As per the Alberta intake form. The Alberta intake form has a section called "Service Provided". This is actually to me very close to the assignment of a case type, except that it might be the assignment of multiple case types. So for example, they indicate "referral to therapist" and "referral to family doctor". We might actually want to do BOTH of those things in a substantial number of cases.
Activity Type:Follow up
Auto: No
Offset:
MaxInstances:
This activity type is present in all case types. It's a generic follow up activity that essentially just says "we had a conversation". It will have the follow-up fields which make it easy to schedule a follow-up activity from within this one.
Analogous to the "generic file memo" activity in Safety Net.
Activity Type:Close case
Auto: no
Offset:
MaxInstances:
This sub-process includes things like requesting extensions above two sessions for assessment, and doing the final satisfaction survey.
Activity Type:Assign principal classification - [vocabname][vocabindex]
Auto: no
Offset:
MaxInstances: 1
This is an example of the work-around we've come up with to build in support for any CPHN indicators that we want to implement in phase 1. We anticipate that we'll improve support for this when we see how the better import features planned for CiviCRM 2.3+ will support integration with multiple external classification schemes.
This particular activity has a max-instances of 1 because it's referring to the "principal" classification.
Custom Fields:
Assigned code:
Assigned description:
Classification version:
Classification dilemma:
Examples:
Let's say that we decide to do a study where we want to record the problem drugs involved in all cases at the time of intake. CPHN indicator 13 involves Problem Drugs. A person might use many different Problem Drugs, but only one would be considered the "drug of choice".
We would have to create an activity type called "Assign principal classification - CPHN13" or better still "Assign principal classification - Problem drugs".
Whatever code we place in the code field would indicate the drug of choice for this person. If we wanted to add the description to make it easier, we could. So, we could assign code 5 for Cocaine/Crack, indicating that cocaine was this person's drug of choice. In the text field, we'd put the string "cocaine/crack". In the version field, we'd put "1.1" indicating that this is version 1.1 of the CPHN classification scheme.
Let's say that the person's drug of choice is actually not cocaine, but is a combination of cocaine and heroin, taken together (a.k.a "speedball"). Our classification system doesn't explicitly support this, so we signal that by setting the "classification dilemma" flag to "yes".
As I said, there are lots better ways to do this, but this one at least lets us add whatever classifications we think are really important while we're puzzling over a better way to handle it.
Activity Type: Assign classification - [vocabname][vocabindex]
Auto:
Offset:
MaxInstances:
See above. This is like the case of wanting to assign the problem drugs, except instead of wanting to assign the drug of choice, we're now interesting in assigning ALL the problem drugs. So maxinstances<>1. We can create a new activity of this type for each problem drug we want to record.
Custom Fields:
The custom fields are the same as the related "principal" activity.
Assigned code:
Assigned description:
Classification version:
Classification dilemma:
Activity Type: Assign classification - Presenting Problem
Auto: Yes
Offset: 3
MaxInstances:
See above. This is like the case of wanting to assign the problem drugs, except instead of wanting to assign the drug of choice, we're now interesting in assigning ALL the problem drugs. So maxinstances<>1. We can create a new activity of this type for each problem drug we want to record.
Custom Fields:
The custom fields are the same as the related "principal" activity.
Assigned code:
Assigned description:
Classification version:
Classification dilemma:
Case Type: Inpatient treatment
The following activity types are needed in cases where inpatient treatment is being contemplated.
Activity Type:Plan inpatient admission
Auto:Yes
Offset:0
MaxInstances:
This activity records that consideration is being given to an inpatient admission. It might include such things as determining the right facility, whether admission was going to be voluntary, etc. When completed it indicates that a decision has been made about admission.
Custom Fields:
I guess if we're using this as a way to develop a plan (or not) about admission, then it should record when completed that the decision is to admit or not, and whether the admission is voluntary or not.
Admit?: y/n
Voluntary: y/n
Facility: (reference to contact record) ([DD] As of 2009-01-13 probably the best way to do this would be to put this in the "assigned to" field.)
In the way that we're thinking about these activities now, the system would autocreate this activity when the case type "inpatient treatment" was chosen. The activity would be there with an offset of 0 to indicate that some form of action on it is due immediately. The user might edit the activity (of course retaining and audit trail) and change the due date to be when they actually plan to complete it, and describe how they're going to make the decision, etc.
If the decision is made to admit, then it might be helpful to track the place where admission is planned. This would be a reference to a contact record for the inpatient treatment facility. This would be helpful, in that we could pull a report of all the people we planned to admit to any given facility.
Activity Type: Confirm expected admission date
Auto: No
Offset:
MaxInstances:
Once the decision to admit is confirmed, a date when the admission is expected to start should be obtained. This is an example of where I can't figure out how to describe the offsets. One way to look at this is that we wouldn't even create this activity until the activity "plan admission" is completed. That's simple enough, just set the "auto" switch to "off" in the config file. But if we wanted to give the user some sort of guidance about the key milestones in the case it might be better to have it autopopulate.
Ok, no, I'm thinking that it's simpler not to.
Custom Fields:
I don't think we need any custom fields. Or maybe it's better to put the reference to the contact record of the facility in this activity, vs. the "plan admission" activity?
Activity Type:Confirm actual admission
Auto: NO
Offset:
MaxInstances:
This activity could result in confirmation, or a no-show at the facility where admission was planned.
Custom Fields:
Did the person show up?: Yes / No (maybe also "Yes but late")
Activity Type:Confirm expected discharge date
Auto: NO
Offset:
MaxInstances:
I think this is self-explanatory.
Custom Fields:
The only relevant thing here is the date, so probably no custom fields. I guess the only question is whether we store this as the due date, or the actual date. The semantics get a bit hairy.
Activity Type:Confirm actual discharge date
Auto: No
Offset:
MaxInstances:
This activity records the date that the problem person was discharged from the treatment facility.
I guess potentially this could be just one activity type, called "discharge date" and we'd use the due date and actual date to record the difference.
Custom Fields:
Activity Type:Receive report of early withdrawal from treatment
Auto: No
Offset:
MaxInstances:
Notes:
activity type to record the early termination of inpatient treatment by the patient, against medical advice.
Custom Fields:
Don't think there's really anything we know about this at this point. It will mostly be a narrative account about the circumstances leading up to the withdrawal from treatment, with the date being the date the person actually walked out.
Case Type: Intervention
The following activity types are needed in cases of the "intervention" type. I'm now realizing that this includes almost any type of call where a caller is calling with a concern about another person, not themselves.
Activity Type: Plan intervention
Auto:Yes
Offset:4
MaxInstances:
Custom Fields:
intervention type: surprise or invitational; planned attendees and roles
Activity Type: Rehearse intervention
Auto:
Offset:
MaxInstances:
Custom Fields:
Activity Type:Conduct intervention
Auto:
Offset:
MaxInstances:
did PHP representatives attend? - some cases might be coaching for a simple approach to the problem/vulnerable person
Custom Fields:
Activity Type:Debrief intervention
Auto:
Offset:
MaxInstances:
record what the result was - did the problem person obtain help?
Custom Fields:
Case Type: Referral to counselor
The following activity types are required in cases where the service provided is referral to a counselor.
Activity Type:Survey client satisfaction
Auto: Yes
Offset: 21
MaxInstances: 1?
after two counseling sessions, the intake physician calls the client to make sure that the therapeutic relationship is ok
Custom Fields:
copy from a survey form. a bunch of likert type items.
Case Type: Referral to family doctor
The following activity types are required in cases where the service provided involves referral to a family doctor.
Activity Type:Determine needs and preferences
Auto:Yes
Offset:0
MaxInstances: 1
Do you have one, where are you, is there someone you'd prefer not to see?
Custom Fields:
Activity Type: Notify selected referral target
Auto: Yes
Offset: 1
MaxInstances: 1
Call family doc to let MOA know that name has been given out, and call might come in, remind MOA of code word. Want to track contact name of referral target
Custom Fields:
Activity Type:Facilitate first appointment
Auto: Yes
Offset: 2
MaxInstances: 1
do not give names in writing (AB)
Custom Fields:
Activity Type: Survey client satisfaction
Auto:Yes
Offset:30
MaxInstances:
Confirm which family doc was selected (to keep stats on how many successful referrals generated, etc) and if satisfied.
Custom Fields:
Case Type: Referral to specialist
The following activity types are required in cases where the service provided involves referral to a specialist (most often a psychiatrist).
Activity Type: Determine needs and preferences
Auto: Yes
Offset: 0
MaxInstances:
what's the need, where are you, and is there someone you'd prefer not to see
Custom Fields:
Activity Type:Prescreen referral target
Auto: Yes
Offset: 1
MaxInstances:
don't give client's name until it has been determined that the referral will be accepted. If not accepted, then repeat consult list activity
Custom Fields:
Activity Type: Facilitate first appointment
Auto: Yes
Offset: 2
MaxInstances:
Notes:
Custom Fields:
Activity Type: Survey client satisfaction
Auto:Yes
Offset:30
MaxInstances:
AB doesn't do this - we might consider calling both the client and the psychiatrist after one or two sessions, to determine if the relationship is satisfactory to both.
Custom Fields:
Case Type: Relapse prevention
The following activity types are required in cases where the service provided involves relapse prevention. This is commonly for a diagnosis of an addictive disorder, but could also be for another chronic disease. When it is for another chronic disease, the most likely diagnosis is a mental disorder that might impair the person's judgment.
Activity Type: Sign case coordination agreement
Auto:Yes
Offset: 7
MaxInstances:
This activity can include a variety of other subsidiary agreements, such as voluntary withdrawals, consents, etc.
Custom Fields:
Activity Type:Receive comphrensive plan for assessment and treatment
Auto:Yes
Offset:14
MaxInstances:
Notes:
This service set requires a comprehensive treatment plan as input
Custom Fields:
Activity Type:Engage workplace supervisor
Auto:Yes
Offset:30
MaxInstances:
Notes:
This will involve confirming that a case role has been filled (is not null). There may be more than one workplace supervisor
Custom Fields:
Activity Type:Engage community mentor
Auto:Yes
Offset:30
MaxInstances:
Notes:
This will involve confirming that a case role has been filled (is not null). There is generally only one of these.
Custom Fields:
Activity Type:Develop biological monitoring plan
Auto:No
Offset:
MaxInstances:
Notes:
This might involve random drug screens, lithium levels, or any other lab test that might be required periodically to attest to ongoing recovery in a particular disease state.
Custom Fields:
Activity Type:Receive community mentor report
Auto:No
Offset:
MaxInstances:
Notes:
These activities are all of the form "Receive report from [role]". Not sure if there's more analysis to do that might simplify things. For now, I'm leaving the known separate role types as separate activity types.
Custom Fields:
Activity Type:Receive treating physician report
Auto:No
Offset:
MaxInstances:
Notes:
There might be several different treating physicians. We could record the contact from which the report was received, but it might also be helpful to record the type of physician (Family, Psychiatrist, Addictionologist)
Custom Fields:
Activity Type:Receive workplace supervisor report
Auto:No
Offset:
MaxInstances:
Notes:
There might be several different workplace supervisors on the case. Might want to indicate which contact the report was received from.
Custom Fields:
Activity Type:Record biological monitoring results
Auto:No
Offset:
MaxInstances:
Notes:
This involves receiving and interpreting a biological monitoring result.
Custom Fields:
Activity Type:Review prescribing privileges
Auto:No
Offset:
MaxInstances:
Notes:
This activity indicates that the licensing authority has reviewed the client's prescribing privileges. Indicator: increase/decrease/no change.
Custom Fields:
Activity Type:Review hospital privileges
Auto:No
Offset:
MaxInstances:
Notes:
This activity indicates that the relevant institutional authority has reviewed the problem person's hospital privileges, and the result of that review: increase / decrease / no change.
Custom Fields:
Activity Type:Summarize case for discharge
Auto:No
Offset:
MaxInstances:
Notes:
This activity is recorded when the decision is made not to do any further follow-up (i.e. the case coordination agreement is completed). Custom fields might include some kind of checklist for ensuring that things are tidy for reporting.
Custom Fields:
Case Type: Return to work
The following activity types are required in cases where the service of return-to-work coordination / facilitation is provided.
Activity Type: Sign case coordination agreement
Auto:Yes
Offset: 7
MaxInstances:
This activity can include a variety of other subsidiary agreements, such as voluntary withdrawals, consents, etc.
Custom Fields:
Activity Type: Record beginning of earliest total absence
Auto:Yes
Offset:0
MaxInstances:1
Notes:
This milestone records the beginning of earliest period totally absent from work, that is the first day where work was scheduled, but none was performed.
Custom Fields:
Activity Type: Record earliest return work activity
Auto:Yes
Offset:30
MaxInstances:1
Notes:
This activity is used to record the earliest return to any work activities. These may be tightly supervised, and may not represent the full range of activities. The number of days between this and the first day off work is considered to be the duration of the disability.
Custom Fields:
Activity Type: Record beginning of period of restricted duties
Auto:Yes
Offset:30
MaxInstances:
Notes:
Records a transition to restricted duties. This is usually thought to happen from a status of total absence, but can also happen if an attempt to return to full duties is not successful. Because there can be considerable interest in showing progress tow
Custom Fields:
Activity Type: Record beginning of period of attempted full duties
Auto:Yes
Offset:30
MaxInstances:
Notes:
Records a return to full pre-illness work. This can often happen multiple times in a case.
Custom Fields:
Activity Type: Record beginning of period total absence
Auto:No
Offset:99
MaxInstances:
Notes:
This activity type is used to record a transition to total absence from work AFTER a trial of restricted duty, or full duty. It indicates a type of relapse.
4 Comments
Hide/Show CommentsNov 14, 2008
D D
Some minor comments:
For labelling, while the New Activity selection field limits the options to those defined for the case type, there are other administrative functions that don't, so having some with the same label could be confusing, e.g. if you see three Survey Client Satisfaction choices in the list there's no way to know which one. So we just may need to label them with a more specific label. My reading is that those three client satisfaction surveys would actually be different things, since the custom fields on them would be different?
For using "follow up" as THE generic activity, I think it can just be left as a training issue for new users, but the term "follow up" implies only activities initiated by the user themselves. I can't think of a better term though. Maybe "Follow up / Other". Or just train them.
With this shortened list, it also occurs to me I can't think of a use case for the report/audit feature for anything other than "case timeline". So at the moment the xml config files only have that option for generating the report. It's a relatively easy thing to add if we discover one during system usage.
Dec 17, 2008
D D
I think I misinterpreted the classifications part the first couple reads. This is my current thinking about the classifications part:
1) The text under "Assign classification - Presenting Problem" is a copy-paste typo from the previous activity above it.
2) There exist "CPHN indicators", and "Presenting Problem" is one of them. It's an (the?) important one to collect during the case intake process.
Good docs to look at are http://wiki.civicrm.org/confluence/display/CRM/CiviCase+-+Mapping+to+CPHN+Common+Indicators and http://wiki.civicrm.org/confluence/display/CRM/Presenting+Problem.
3) Some of the indicators, like Presenting Problem, can have more than one value, e.g. the person has multiple health problems. Under the guidelines though, one and only one of them must be designated as the principal one. So you need a way to record the principal one, and then also all the others.
The discussion about dilemma is then sort of a *separate* thing, talking about how to record the principal one when there isn't an existing code for it.
4) There are classifications other than CPHN, and they might work similarly, e.g. ICD codes, or even internal classifications within an organization.
Dec 17, 2008
D D
Just making a note that we're thinking about the tradeoffs involved in the way the classifications would get implemented: Ease of use vs. Flexibility.
The way it's described above with the principal classification as its own activity, and then you make multiple instances of another activity is the most flexible, but is also the hardest to use, and can't be easily fit into a "questionnaire" structure (unless wizards or something also get implemented).
So at the moment we're leaning towards ease of use. With the available widgets, we're thinking you'd create an option group with the list of values, then you'd only create one activity, and on the form you'd have a single select list where you choose the principal classification, and then a (potentially big) group of checkboxes sharing the same option list where you choose as many of the others as needed. The dilemma and version can also be there as described above.
As of this writing we've partially implemented this for the intake questionnaire where it asks about presenting problem.
Dec 17, 2008
D D
Some of the CPHN indicators in sections 3 and 4 on that page might be best handled by a custom field on the contact form rather than a classification activity, e.g. their year of graduation from medical school, and then there's some obvious ones like birthdate and gender. Some aren't obvious whether they should be activities or not because they're relatively simple and might best be handled all at once by a single form with some fields, like number of children, their ages, work hours per week, etc...
Note that anything that can change between two cases though should NOT be on the contact form, because when we run historical reports we'll want to know what it was at the time of the case.