Personal tools
 

Intake Management

History of Development

 

Intake A, B, C

Two intake forms and two intake reports

  • Intake A (Seaton House)
  • Intake C (used everywhere else)


The problems with this implementation were:

  • Completely separate models. Ideally all intakes should have a 'common' section.
  • Separate struts actions for both intakes which have the same workflow. No reuse of code. Easy for one process to be missing a new component.
  • No validation of form values. This is especially problematic for key identifiable data such as health card numbers.
  • No simple extension/customization model in place.


Some ideas developed for restructuring Intake A, B, C:

  • Redesign from the ground up.
  • All data should be saved to a single table consisting of key/value pairs and a type attribute (which form this represents). Demographic information should only be persisted to the demographic table, and no copy should be maintained. The rest of the validated values should be stored as (form id, key, value) triplets. The disadvantage to this approach is that it's harder to query data out, but the advantages outweigh this. The key advantage being that we can add fields without a database update.
  • Define the "Intake" workflow, and implement it into a single abstract action with callbacks to the child class for any "custom" processing at key points of the flow.
  • Need to search bugzilla for the list of bugs/feature requests pertaining to intakes.

 

In Intake A, B, C a staff member administers an intake questionnaire to a client when:

  • admitting a new client (Intake A or C)
  • or, at an arbitrary time after admission, by updating a client's intake questionnaire (Intake A, B or C) while viewing a client's record in the PMM.


The following changes to this process are proposed:

  • a new cross agency quick intake questionnaire (based on Intake A)
  • a new cross agency in-depth intake questionnaire (based on Intake B and C)
  • the ability to dynamically create per-program intake questionnaires
  • the ability to configure whether or not questionnaires are administered concurrently
  • the ability to configure how long after admission the in-depth questionnaire is scheduled
  • the ability to customize any questionnaire by adding supplemental questions

 

Intake Process Described

Registration Intake (formerly intake A)

The aim of the Registration intake questionnaire is to gather the least amount of information and be minimally intrusive to the client that will allow staff:

  • to uniquely identify a client (to support inter-agency integration),
  • to gather community wide information about a client's (to support generating population statistics e.g. access to health care).
  • to refer to an appropriate set of programs
  • to collect emergency information should the client get into trouble
  • to administer the admission of the client into the agency
  • to facilitate rapid return to housing

 

In-Depth Intake (formerly intake B)

The aim of the in-depth intake is to allow agency staff to collect more detailed information on a client that will allow them to understand the underlying issues that are preventing the client from being housed. This intake has the following characteristics:

  • it is asked within a prescribed period of time, so that if a client is still living in shelter or otherwise in trouble and using the agency's services after e.g. 3 months then this more detailed information is collected
  • all clients who are chronically homeless have the registration and in-depth information collected so that population level information can be collected for the chronically homeless population - this tool may therefore contain tools or instruments that are useful for burden of illness or other ongoing needs assessment type work
  • this data may be further used to help refer a client to more appropriate services

Program Specific Intake (Formerly intake C)

The aim of the program specific intake is that once detailed data is collected for a client there is still information that may need to be gathered to admit a client to a specific program e.g. spousal assault shelter, harm reduction drinking program etc.

Overall Intake Principles

The following principles apply to the intake forms:

  • as much as possible if two or more agencies ask questions that are collecting the same underlying information these questions will be asked using the same question and wording between these agencies
  • agencies will be allowed to maintain the uniqueness of their programming by organizing their intake forms in a way that allows them to have unique questions and unique organization of questions in all three levels of forms
  • agencies can combine the three intake forms so that all three levels are asked as one form
  • all clients must be asked a minimal set of CAISI registration information that will allow for registration and identification of the client in CAISI and allow for population level care of clients

Map of Intake Process Sections

The following schematic and definitions describe the sections of the intake process:

Image:Intake Forms Schematic.PNG

 

Registration Intake

ID Common

This section gets the minimal set of information needed to identify a client in the CAISI system

Registration Common

This is the minimal set of questions that all CAISI agencies will have in their registration intake form that they will ask of all clients who they enter into CAISI

Registration Survey Module Common

This is the set of survey questions that all agencies participating in the survey will include in their intake of all clients they enter into CAISI

 

 Registration/In-Depth Common

This is the set of questions that some agencies ask in the registration intake and some agencies ask in the in-depth intake, however all agencies ask once a client has both registration and in-depth questions

Agency Specific Registration

These are questions that only certain agencies (at least one agency but not all agencies) ask as part of their registration process

 

In-Depth Intake

In-Depth Common

This is the minimal set of questions that all CAISI agencies will have in their In-Depth intake form that they will ask of all clients who they perform an In-Depth intake in CAISI

In-Depth Survey Module Common

This is the set of survey questions that all agencies participating in the survey will include in their In-Depth intake for all clients that they enter In-Depth intakes into CAISI

Registration/In-Depth Common

This is the set of questions that some agencies ask in the registration intake and some agencies ask in the in-depth intake, however all agencies ask once a client has both registration and in-depth questions

Agency Specific In-Depth

 

These are questions that only certain agencies (at least one agency but not all agencies) ask as part of their In-Depth process

Program Specific Intake

This is the intake filled out to admit a client into a specific program and includes questions not in the other intakes and that are unique for that program

 

Technical Architecture

As a whole, these changes should allow the CAISI system to be configured (through a combination of installation and run time modifications) to match the variety of intake processes which different implementors follow. The following processes will be supported:

  • combined Registration/in-depth/program intake questionnaire
  • combined Registration/in-depth intake questionnaire
  • combined Registration/in-depth intake questionnaire and per-program questionnaire(s)
  • separate Registration intake and in-depth questionnaires
  • separate Registration intake, in-depth and per-program questionnaire(s)

 

INTAKE ROADMAP

I

A. Intake Editor

Ability for the user/admin to create/edit intake forms. Functions would include:

  1. create sections
  2. create different types of questions [select (radio, multiple select, combo box); text; date]
  3. format question selection types into vertical or horizontal orientation of lists
  4. format question multiple select to include text box next to select item (e.g. for other value or ID # value etc.)
  5. format question to new line or continuous (ie series of text boxes along same line vs go to new line for the next text box or drop down)
  6. format question to include indent for e.g. following "if yes" type questions
  7. be able to designate a question as a mandatory field
  8. read select question values from the CAISI list editor
  9. identify the intake as a) registration intake b) in depth intake c) program specific intake
  10. publish / launch the intake with date time stamp and user signature
  11. items that cannot be edited include: a) the tombstone ID data
  12. after publishing an intake be able to re-open it and re-edit
  13. be able to insert questions between questions
  14. once questions are published they cannot be deleted, however they can be inactivated, or the wording of the question can be changed
  15. launched versions of the intake are stored with launch dates

 

B. Intake link to other database elements

The editor should allow the function of selecting elements from other sections of OSCAR/CAISI e.g.

  1. issues list (e.g. multiple select, combo box, radio of a list of issue codes from the CAISI Issue list editor - this could be done as a simple list e.g. CTCMM1000, CTCMM2000 or subset containing a string e.g. "CTCMM" or a range of issue code values e.g. CTCMM1000 - CTCMM28000) the  values would  then populate the clients list of issues table - you could then have a question like Do you have []  Type 1 diabetes mellitus without (mention of) complication? (ie ICD-10 code = E109) (or additionally you could optionally fill in your own value for the text...)
  2. measurements - e.g. the question asks for your weight and you can enter the value and it would get entered into the clients weight measurement etc.
  3. prevention items
  4. documenting medications from prescription editor
  5. etc.

If an intake element populates another part of the database in this way, it should be reciprocal, in other words if in the example above at initial intake diabetes is not check off, but later an issue of E109 is given to the client, then this item appears checked when a new registration is opened for updating.

This neccessitates having two views of an intake, the print preview showing what was last saved vs the one that can be updated as the latter might have the new diabetes value whereas the former would not, the former would show the values as they were last saved including e.g. a different version of the clients name etc.

 

C. Intake Triggers

Intake questions can trigger actions in the database e.g.

  1. ticklers
  2. others...

 

Document Actions

« June 2020 »
June
MoTuWeThFrSaSu
1234567
891011121314
15161718192021
22232425262728
2930