Crisis Line/Safe House Case Management System Martin Zhao Mercer University

Summary of Data Needs  This system is designed for CL/SH to keep track of case data and to run reports for various purposes  Currently the case data set is collected by filling word files. Reports have to be generated by counting paper-based records manually.  The new system will use MS Access or another database management system to store data in electronic format. User interfaces for data entry and reporting purposes will also be provided.

Conceptual Data Model  An initial analysis based on the form template used for case data intake leads to the following conceptual data model.  Data items listed in the intake form can be categorized into the following groups (entities) Case: identified by a unique number and described by data items (or attributes) such as type, referral, etc. Each case has a caller and an abuser if type is DV. Caller: Abuser: Dependent ( known as child in the intake form ) Advocate ( and Advocator, though not explicitly defined ) Additional Case Note Entry: needed for complex cases

Relationship Diagram

Notes on Data Model  Dividing the data set into a number of groups (also known as tables) assures any fact is store only once in one place in the database (such as information about a particular Caller)  Relationships between data groups (or tables) are also tracked, such as a Case has a Caller and an Abuser; a Caller may have one or more Children  The order in which information may be entered is as follows: a Child record may only be entered after the corresponding Caller is entered; a Case may be entered only after its Caller and Abuser.

Data Entry Sequence  To keep the relationship between various facts (or records) to be entered into the database, the following ordering is essential Facts about Caller, Abuser, and Advocate may be entered any time with no dependency on other data Child records may only be entered after their Caller Case records depend on both Caller and Abuser AdditionalCaseNoteEntry may be entered after a Case record is available AdvocateSession records depend on both Case and Advocate

Data Entry Tips  Relationships are defined in the database and have been implemented with lookup features (i.e., dropdown lists in data entry forms)  For a certain Case Enter Caller, Abuser, and Advocate records first Enter Child records, if any, using the ChildEntry form: select Caller from the dropdown list to hook it up Enter a Case record using the CaseEntry form, and select Caller and Abuser from the lists Enter AdditionalCaseNotes and/or AdvocateSession when needed, selecting the corresponding Case record (identified by Case#) from the dropdown

Further Development  The current stage is for proof-of-concept purpose and focuses on Understanding the logics about data (for developers) Showing the way (Access) databases work (for users)  Forms better fit real data entry flow will be designed and implemented based on mutual agreements between users and developers  Reporting mechanisms that can organize facts to answer business questions will be developed based on a solid data model