the present invention is a method for the tracking and assessment of social services based on defining client barriers to success and then objectively tracking progress of the social worker based on the reduction and / or elimination of those barriers . the invention also comprises an implementation of the foregoing method in software form which facilitates the guided compilation of a knowledge base that quantifies the barriers to success , facilitates objective tracking of progress toward the reduction and / or elimination of those barriers , and which generates tangible results by structured querying of the knowledge base and generation of evaluate progress . all of the foregoing steps are administered to the social worker by a navigable user interface . the basic method of the present system in this context are based on a model involving five specific categories of information regarding : 1 ) the social service provider , 2 ) the client , 3 ) client barriers to success inclusive of severity , 4 ) client outcome , and 4 ) general demographic data . fig1 is flow chart illustrating the general method steps according to the present invention . at step 100 the agency and / or individual case managers enter baseline information for each case worker inclusive of basic identifier information such as lastname , firstname , case worker id #, employment date , position , and other informational fields as desired . at step 200 the individual case manager , once assigned to a client , enters baseline client information regarding each client inclusive of social security number , name address , ethnicity , gender , etc . basic client data is used to populate a relational database table as shown below . “ clients ” table name datatype null option is pk is fk ssn varchar ( 11 ) not null yes no firstname varchar ( 20 ) not null no no middleinitial char ( 1 ) null no no lastname varchar ( 40 ) not null no no otherphone varchar ( 50 ) null no no phonenumber char ( 20 ) null no no address1 varchar ( 50 ) null no no address2 varchar ( 50 ) null no no city varchar ( 30 ) null no no state char ( 2 ) null no no zipcode char ( 5 ) null no no ethnicity smallint null no yes gender varchar ( 50 ) null no yes clientdob smalldatetime null no no maritalstatus smallint null no yes noncustodialparent bit null no no tcaexhaustee bit null no no languagespoken varchar ( 30 ) null no no sourceofincome smallint null no yes i9socialsecuritycard bit null no no i9birthcertificate bit null no no i9driverlicense bit null no no i9licensenumber varchar ( 30 ) null no no i9licensetype smallint null no yes educationgoal varchar ( 50 ) null no no educationhighestgrade smallint null no no attended educationlastyearinschool datetime null no no ged bit null no no educationprojectedged datetime null no no date professionallicenses varchar ( 50 ) null no no militaryserviceentry datetime null no no militaryservicedis - bit null no no charge militaryservicedischarge smallint null no yes type militarybranch smallint null no yes militarydischargedate datetime null no no criminalfelonyconviction bit null no no criminalmisdemeanor bit null no no conviction criminalcivilcase bit null no no criminaldateoflastoffense smalldatetime null no no criminaldispositiontype smallint null no yes criminalprobation bit null no no criminalbackgroundcheck bit null no no employmentfof smallint null no yes employmentshortterm varchar ( 100 ) null no no goal employmenttraining text null no no needed employmenttraining text null no no completed reliablename varchar ( 50 ) null no no reliablenumber varchar ( 50 ) null no no reliablecity varchar ( 50 ) null no no reliablestate varchar ( 2 ) null no no reliablezip varchar ( 5 ) null no no reliablerelationship varchar ( 30 ) null no no socialworkname varchar ( 50 ) null no no socialworknumber varchar ( 30 ) null no no socialworklocation varchar ( 30 ) null no no phonenumber2 char ( 20 ) null no no employeeidoriginal smallint null no no [ 0029 ] fig2 is a screen print of an exemplary “ add participant ” screen by which the caseworker is guided to add a new client and to enter basic details such as name , ssn , phonenumber , and date of birth into the above table . [ 0030 ] fig3 is a screen print of an exemplary “ participant demographics ” screen by which the caseworker is guided to add client particulars . previously entered data appears in the screen and additional data as shown can be entered into the relevant fields per the above table . in addition to basic client data , subordinate client data is entered by a succession of like screens and is used to populate a series of related tables . preferably , in the context of employment placement , the subordinate data will include relevant information on the client &# 39 ; s children , drug addictions , criminal dispositions , employment history , license types , military history , test scores , marital status , medical benefits availability , prior placements ( including rejections ), program outcomes , referral sources , and other data as desired . the following are an exemplary set of table definitions for storing this subordinate data . name datatype null option is pk is fk “ childrelationshiptype ” table childrelationshipid smallint identity yes no childrelationship varchar ( 50 ) null no no “ choice ” table choice varchar ( 10 ) not null no no choiceid smallint not null no no “ clientaddictions ” table ssn varchar ( 11 ) not null yes yes addictionid smallint identity yes yes addictionhistory smallint null no no lenghtofdruguser varchar ( 30 ) null no no dateoflastuser smalldatetime null no no drugtested bit null no no dateofdrugtest smalldatetime null no no drugtestresult varchar ( 50 ) null no no recoveryinfo varchar ( 50 ) null no no “ clientchildren ” table ssn varchar ( 11 ) not null yes yes childfirstname varchar ( 20 ) not null yes no childlastname varchar ( 40 ) not null yes no childdob smalldatetime null no no childrelationship smallint null no yes “ clientcriminaldisposition ” table criminaldisposition varchar ( 30 ) not null no no criminaldispositionid smallint identity yes no “ clientemployment ” table placementid smallint not null yes no dateentered datetime not null yes no employerid smallint not null no yes terminationdate smalldatetime null no no jobtitle varchar ( 50 ) null no no hourly wage money null no no hoursperweek smallint null no no medicalbenefits - smallint null no yes availabilityid fringebenefitsavailable bit null no no coveredbyunemployment - bit null no no insurance employmentstatus smallint not null yes yes dotcode varchar ( 30 ) null no no completedprobation bit null no no startdate datetime null no no “ clientemploymentfoftypes ” table employmentfof varchar ( 50 ) not null no no employmentfofid smallint identity yes no “ clienti9licensetypes ” table i9licensetype varchar ( 30 ) not null no no i9licensetypeid smallint identity yes no “ clientmilitarydischargetypes ” table mildischargetypeid smallint not null yes no mildischargetype varchar ( 30 ) null no no “ clientpreviousemployment ” table ssn varchar ( 11 ) not null yes no company varchar ( 50 ) null no no jobtitle varchar ( 30 ) null no no startdate datetime not null yes no enddate datetime null no no hourlyrate money null no no hoursperweek smallint null no no reasonforleaving varchar ( 50 ) null no no “ clientsourceoflncome ” table sourceofincome varchar ( 50 ) not null no no sourceofincomeid smallint identity yes no “ clienttestscores ” table ssn varchar ( 11 ) not null yes yes testdate smalldatetime not null yes no dateentered datetime not null no no score numeric ( 5 , 2 ) null no no employeeid smallint null no no testtype varchar ( 50 ) not null yes yes “ employers ” table employerid smallint identity yes no name varchar ( 50 ) not null no no address1 varchar ( 50 ) null no no address2 varchar ( 50 ) null no no city varchar ( 30 ) null no no state char ( 2 ) null no no zipcode char ( 5 ) null no no contactname varchar ( 30 ) null no no contactnumber varchar ( 30 ) null no no commitment varchar ( 30 ) null no no rateofpay varchar ( 30 ) null no no benefits varchar ( 30 ) null no no employermatch varchar ( 30 ) null no no “ employmentstatuses ” table employmentstatus varchar ( 50 ) not null no no employmentstatusid smallint identity yes no “ ethnicities ” table ethnicity varchar ( 20 ) not null no no ethnicityid smallint identity yes no “ genders ” table gender varchar ( 50 ) not null yes no “ maritalstatuses ” table maritalstatus varchar ( 50 ) not null no no maritalstatusid smallint identity yes no “ medicalbenefitsavailability ” table medicalbenefits - smallint identity yes no availabilityid medicalbenefitsavailability varchar ( 50 ) not null no no “ messages ” table messageid smallint identity yes no messagetype smallint null no no messagetext text null no no messagedatestart datetime null no no messagedateend datetime null no no employeeid smallint null no yes “ militarybranch ” table militarybranchid smallint identity yes no militarybranch varchar ( 30 ) not null no no “ placementrejectionreasons ” table placementrejectionreason varchar ( 30 ) not null no no rejectionreasonid smallint identity yes no notes text null no no “ placements ” table placementid smallint identity yes no ssn varchar ( 11 ) not null yes no placementdate smalldatetime not null yes no scheduledstartdate smalldatetime not null no no employeeid smallint not null no no notes text null no no programid smallint null no yes placementtype smallint null no yes referralsource smallint null no yes rejectionreason smallint null no yes opentoplace bit null no no opentoplacedate datetime null no no “ placementtypes ” table placementtypeid smallint identity yes no placementtype varchar ( 30 ) not null no no “ previousemploymentreasonforleaving ” table reasonforleaving varchar ( 50 ) not null no no reasonforleavingid smallint identity yes no “ programoutcomes ” table placementid smallint not null yes no dateentered datetime not null no no empid smallint not null no no programhours decimal ( 10 , 2 ) not null no no date worked datetime not null yes no notes text null no no workactivitytype smallint not null yes yes “ programs ” table programid smallint identity yes no address1 varchar ( 50 ) null no no address2 varchar ( 50 ) null no no city varchar ( 30 ) null no no state char ( 2 ) null no no zipcode char ( 5 ) null no no programtype varchar ( 50 ) null no yes programname varchar ( 75 ) not null no no disabled bit not null no no “ programtypes ” table programtype varchar ( 50 ) not null yes no notes text null no no “ referralsources ” table referralsourceid smallint identity yes no referralsource varchar ( 30 ) not null no no column ( s ) of “ roles ” table “ roles ” table role varchar ( 50 ) not null yes no notes text null no no “ testtypes ” table testtype varchar ( 50 ) not null yes no notes text null no no “ workactivitytypes ” table workactivitytype varchar ( 50 ) not null no no workactivitytypeid smallint identity yes no at step 300 the individual case manager , after interviewing a particular client , enters goal - oriented information regarding progress elements ( points for improvement ) as well as social barriers faced by the client in accomplishing predefined social goals . for goal - oriented progress elements , the caseworker enters status information to a predefined categorical list of progress elements . again in the context of employment placement , exemplary progress elements may include retention ; new employment ; wage increase ; promotion ; and educational advancement . in addition to measuring the client &# 39 ; s progress , the caseworkers must also measure their own effort towards each progress element . this is important because it avoids vague “ checkups ” on clients when they have employment and helps the caseworkers focus their energies on aiding clients &# 39 ; progress towards specific goals . fig4 is a screen print of an exemplary progress element entry screen by which the caseworker can specify a progress element ( career path / employment planning ), and enter contact information ( location , time , date of next update and notes ) regarding their own effort toward facilitating the specified progress element . by this approach , caseworker efforts can be measured against the outcomes produced . the periodic client contact data is used to populate relational database tables as shown below . name datatype null option is pk is fk “ clientupdatereasons ” table reasonid smallint identity yes no reason varchar ( 100 ) null no no notes text null no no “ clientupdates ” table clientupdateid int identity yes no placementid smallint not null yes no employeeid smallint not null yes yes clientupdatereasonid smallint null no yes notes text null no no dateentered smalldatetime null no no “ contactlocations ” table contactlocation varchar ( 40 ) not null no no contactlocationid smallint identity yes no notes text null no no “ contacttypes ” table contacttypeid int identity yes no contacttype varchar ( 50 ) not null no no “ drugofchoice ” table drugid smallint identity yes no drugofchoice varchar ( 30 ) not null no no “ employeemessage ” table employeeid smallint null no yes employeemessageid int identity yes no messageid smallint null no yes readmessage smallint null no no “ employees ” table employeeid smallint identity yes no programid smallint null no yes firstname varchar ( 20 ) not null no no middleinitial char ( 1 ) null no no lastname varchar ( 40 ) not null no no employeetype varchar ( 30 ) null no yes role varchar ( 50 ) null no yes disabled bit not null no no username varchar ( 50 ) not null no no password varchar ( 50 ) not null no no “ employeetypes ” table employeetype varchar ( 30 ) not null yes no notes text null no no “ employercontactlocation ” table employercontactlocation varchar ( 40 ) not null no no notes text null no no employercontact - smallint identity yes no locationid “ employercontacttype ” table employercontacttypeid int identity yes no employercontacttype varchar ( 50 ) not null no no “ employerhistories ” table employerid smallint not null no yes historyid int identity yes no dateentered datetime null no no employeeid smallint null no no timespentoncontact int null no no contactlocationid smallint null no yes contacttypeid int null no yes nextexpectedupdate datetime not null no no notes text null no no in addition to the progress element data , the data entry screen of fig5 is used to specify barriers to progress ( such as literacy ), to specify barrier severity , and to enter contact information ( location , time , date of next update and notes ) regarding their own effort at each client contact toward reducing the specified barrier severity or eliminating the barrier completely . the periodic barriers data is used to populate a relational database table as shown below . “ clienthistories ” table name datatype null option is pk is fk clienthistoryid smallint identity yes no clientbarrierid smallint null no yes daterecorded smalldatetime not null no no employeeid smallint not null no yes note text null no no barrierseverityid smallint null no yes timespentoncontact smallint not null no no datenextupdate smalldatetime null no no ssn varchar ( 11 ) not null no yes contactlocationid smallint not null no yes contacttypeid int null no yes in the context of employment placement , an exemplary set of predefined barriers will include day care ( whether the client requires day care for dependants ); transportation ( whether the client requires transportation to / from work ); health issues ; family issues ( e . g ., divorce situation ); behavior ( behavioral issues ); attitude ; weight ; personal hygiene , disability , laziness ; money management ; lack of skills ; and literacy . specific barriers may be defined and added to the knowledge base by the agency or caseworker , and are preferably supplemented by the individual case managers as they know best what stands in the way of their clients &# 39 ; success . the method also requires the subjective ( but quantitative ) identification of the severity of these barriers . each barrier is assigned a barrierid number , and the corresponding severity is identified by a severityid field which may be a scale of from 1 ( lowest severity ) to 10 ( most severe ). this assessment and definition of barriers allows them to be tracked , overcome and eventually closed by the caseworker . the barrier data is used to populate a relational database table a complete example of which is shown below . “ clientbarriers ” table ” name datatype null option is pk is fk clientbarrierid smallint identity yes no barrierid smallint not null no yes ssn varchar ( 11 ) not null no yes barrieridentification date smalldatetime null no no barrierclosed bit null no no the barrier severity data is used to populate a separate table as shown below . “ barrierseverities ” table name datatype null option is pk is fk barriersevenityid smallint identity yes no barrierseverity varchar ( 50 ) not null no no barrierseverity value smallint not null no no in the software implementation , procedures are defined which enable the caseworker to define new client barriers , or to recall previously defined client barriers that already exist in the knowledgebase . an example procedure for adding a new barrier is as shown below , and predefined barriers are recalled based on the numeric barrierid field . spaddclientbarriers create procedure [ spaddclientbarriers ] ( @ barrierid [ smallint ], @ ssn [ varchar ]( 11 ), @ empid smallint , @ severityid smallint , @ contactloc smallint , @ time smallint , @ update smalldatetime , @ note text ) as declare @ newcbid smallint insert into [ clientbarriers ] ([ barrierid ], [ ssn ]) values (@ barrierid , @ ssn ) set @ newcbid = @@ identity insert into clienthistories ( clientbarrierid , ssn , employeeid , barrierseverityid , contactlocationid , timespentoncontact , datenextupdate , note ) values (@ newcbid , @ ssn , @ empid , @ severityid , @ contactloc , @ time , @ update , @ note ) once the caseworker , client , and client contact data ( including progress elements and barriers ) is entered as per steps 100 - 300 , at step 400 the caseworker continues periodic client contact and at each point of contact reassesses the client . at this point , a succession of information update screens are provided to enable the caseworker to update client information which may have changed since the last contact . for example , fig6 is a screen print of an “ update previous employment ” screen by which the caseworker can update the client &# 39 ; s employment history to reflect a change of employment . additionally , the caseworker can return to the progress entry screen of fig4 and provide a progress update based on a new client contact , and / or return to the barrier entry screen of fig5 to update progress or even close out a barrier to progress which has been overcome . all of the foregoing tables are relationally - linked . fig7 a - 7 c are a tabular listing of the preferred relational links between fields in the above described knowledgebase tables . a relationship name is given to each link , and the parent - child hierarchy is designated by the parent table name and child table name . the column designation indicates the field - to - field assignments between common fields in related tables . all table data is stored in memory pursuant to the above - described storage structure in relational database format and thereby supports meaningful queries . specifically , the method and data structure allows measurement of the efforts of caseworkers over time . in particular , one objective benchmark is provided by querying the client , caseworker and barrier data to measures the severities of barriers as caseworkers work against them ( with clients ) over time . this way , it is possible to assess how effective caseworkers are in reducing barriers over time . another objective benchmark is provided by querying the client , caseworker and contact data to measure caseworker effects in specific contact types over time . these contact types are mapped to outcome indicators ( like promotions ) and it becomes possible to assess how effective caseworker are when their contact types ( efforts ) lead to desired outcomes . given a fully populated database as per steps 100 - 400 , the caseworker and / or agency may initiate a reporting module as shown at step 500 which provides access to a predefined series of queries . the results of each query are displayed in a format conducive to the recipient of the information . a series of “ other reports ” can be generated for simple information . for example , a basic client information report can be generated as shown in fig8 to profile a given client . alternatively , the agency can generate a caseworker report as shown in fig9 to compile total client contact information for a given caseworker (“ john ”). client - specific reports can be generated such as that shown in fig1 , which is the result of a query of client and barrier data presented as the statistics for reducing a given barrier ( here job satisfaction ). further , job placement reports , client employment history reports , and other client - oriented reports can readily be generated by the appropriate queries . more importantly , the progress element and / or barrier data can be effectively queried and presented for the benefit of the caseworker and / or caseworker - assessment by the agency . for example , as shown at step 600 ( fig1 ) the caseworker may seek a client - centric “ efforts to outcomes ” report which details clients in the system for at least 6 months who had more than 2 hours of “ retention ” conversations with a casemanager . fig1 is an example “ efforts to outcomes ” report which details ( for each client ) possible months employed , total months employed , total number of contacts , total duration of contacts , and total duration of “ retention ” contacts . summary information is tabulated , and this includes average job retention rate ( 81 . 46 %), average contact ( 3368 minutes ), overall job retention rate of all students ( 69 %), and average “ retention ” contact ( 512 . 1 minutes ). alternatively , as shown at step 700 ( fig1 ) the agency may seek a caseworker - centric “ barrier reduction report ” which details caseworker success with clients to help them overcome the barriers they face . fig1 is an example “ barrier reduction report ” report which details ( for one or more caseworkers ) each barrier faced , the caseworker &# 39 ; s efforts against barriers , severity of the barrier , start date , and time in program ( both days and weeks ). the foregoing data is tabulated and a summary listing is provided which includes successful client barrier reductions ( 1 ), total work against client barriers ( 75 minutes , 1 . 25 hours ), number of client contacts ( 2 ), successful client barrier reductions ( 5 ), total work against client barriers ( 782 minutes ), and the total number of client contacts ( 16 ). this form of report ensures that the agency can provide caseworkers ( or caseworkers can provide the agency ) with quantitative accountability for social services based on objective reduction of barriers . the above - described method is implemented as software , and preferably “ network software ” designed to operate in the context of a local - area or distributed network that affords a multiple - user environment . the software is best configured as a true client - server application . this makes the software scalable in response to network expansion as well as capable of providing client data to different client - side applications without server - side reconfiguration . the server software runs on microsoft sql server , including sql 2000 . the client software runs under microsoft windows 98 , windows nt , windows 2000 , xp or the like . the software can be installed on any network hardware that is supported by microsoft windows 98 / nt / 2000 / xp , including ethernet or token - ring hardware using netbeui , ipx , or tcp / ip protocols . for example , the method may be implemented over a 10 - megabit ethernet network using a 266 - mhz single - processor pentium server with at least 64 megabytes of ram , and modest client - side machines ( for example , a 100 - mhz pentium with at least 16 megabytes of ram . the user interface is preferably a conventional color monitor , a dial - up or network connection , and a standard input device such as a mouse and keyboard . all data entry forms may be maintained on a designated internet server for user access . in any of the foregoing operating systems , the software may be incorporated as a program shell around existing relational database software such as , for instance , microsoft access ( graphical database access ), thereby providing built - in interoperability with peripheral programs such as microsoft word ( word processor ), microsoft excel ( spreadsheet ), and microsoft exchange ( email server ), etc . in operation , the present software provides a user interface that is simple and uncluttered . typical user - interface response time is 0 . 5 seconds or less . typical database response time ( for data transfers between a client computer and the database server ) is 2 - 3 seconds . of course , performance will depend on the speed of the computer hardware and network . the system described above ( inclusive of hardware and software ) provides for the tracking and assessment of social services based on a defined list of client barriers to success , and objective tracking of progress of the social worker based on the reduction and / or elimination of those barriers . the resultant information helps manage and coordinate resources for the achievement of optimal clinical and financial patient outcomes , and to facilitate collaborative patient care management across the continuum of available social services . having now fully set forth the preferred embodiments and certain modifications of the concept underlying the present invention , various other embodiments as well as certain variations and modifications of the embodiments herein shown and described will obviously occur to those skilled in the art upon becoming familiar with said underlying concept . it is to be understood , therefore , that the invention may be practiced otherwise than as specifically set forth in the appended claims .