On this page

Legacy SHINES reference document. This page captures a Georgia DHS SHINES interface design as written (vendor spec, typically 2007–2025). It documents the system being replaced, not CRAIG behavior. CRAIG’s current implementation of the same data exchange lives under the craig-exchange API reference and in the design documents. Use this page only when mapping legacy integrations during CRAIG rollout.

Interface Detailed Design Document

CPRS FCC Interface

Georgia Department of Human Services

Statewide Automated Child Welfare Information System

(SACWIS)

9/24/2020

Version 5.0

Table of Contents

General Design (Functional)

Req. # Validated Requirement

535.9

Provide an interface with alerts from the Georgia Court System

MR057.1

Add four new APPLA fields from the placement information page.

MR-057.2

Create an outbound CPRS transaction when there is a change in Legal Status.

MR068.5

Send the Code and Decode of the Judge selected in the ‘Assigned Judge’ field of the FCCP Family Case Plan to the CPRS.

MR-074-2.35

Update page to recognize the "TPR - Putative Father" and "Voluntary Surrender - Putative Father" types.

MR-083.29

Send State current recruitment effort status for the child.

MR-094.1

Send updates to visitation plans current status.

CO-R5.2-2.2.1

The system shall calculate the discharge date and reason for a child based on their first change from an “In DFCS Custody” Legal Status to a “Not In DFCS Custody” Legal Status, in the current stage.

MCPRS-1.1

When a worker selects any of the following Not in DFCS custody legal statuses, the system shall trigger an update to the outbound CPRS interface: - Committed to DJJ - ILP Aftercare - Not In DFCS Custody – Adoption Finalized - Not In DFCS Custody – Child Turned 18 (No ILP) - Not In DFCS Custody – Child Death - Not In DFCS Custody – Custody To Other - Not In DFCS Custody – Custody Transferred To Tribe - Not In DFCS Custody – Emancipated - Not In DFCS Custody – Guardianship - Not In DFCS Custody – Parental Custody - Not In DFCS Custody - Custody To Relative - Not In DFCS Custody – Out of State Child Adopted by Georgia Family - Not In DFCS Custody - Custody With Other State - No Longer Committed to DJJ - DJJ Aftercare - Not In DFCS Custody - Runaway

MCPRS-2.1

When the system updates the placement status for a child to any of statuses below, the system shall update the outbound CPRS interface: - COMP - PEND - APRV - PROC

MCPRS-3.1

When a person is merged, the system shall send the previous person ID for that person

MCPRS-3.2

When a person is merged, the system shall trigger the outbound CPRS interface

MCPRS-4.1

When a case is merged, the system shall trigger the outbound CPRS interface

MCPRS-5.1

The system shall notify CPRS of all closed cases prior to release

PMII3.13

The system shall send Parent/Caregiver information to CPRS

PMII3.13a

The system shall send the updated fields and new fields added for Foster Care Family Plan redesign

PMII3.13b

The system shall send the new fields added for Practice Model Phase 1 project

SOW29DS-R3.4

The system shall capture sending data from the Diligent Search Notification Form to CPRS.

SOW29DS-R3.5

The system shall capture sending data from the Notice of Intent to CPRS.

The above were the initial requirements collected. Some of them were later invalidated due to changes requested by interface partners and due to constraints in their systems. The following detail design captures the most up-to-date functionality that the interface is designed to perform.

Introduction

Document Purpose

This document provides a detailed description of the Georgia SHINES – Court Process Reporting System (CPRS) Interface.

Functional Overview

Prior to the implementation of Georgia SHINES, CPRS maintained client information and case plans for children who are in Foster Care. DFCS and the Juvenile Courts utilized CPRS to create and update all case plans. Georgia SHINES is now the system of record for creating and maintaining Foster Care information as it is deployed through the state and, subsequently, CPRS shares a read-only copy of the Georgia SHINES Foster Care records. CPRS utilizes the Georgia SHINES – CPRS Interface to continue to provide reports for Court-related personnel such as Volunteer Review Panels, Child Advocate Attorneys, Court Appointed Special Advocates (CASA), and Assigned Judges. These Court-related parties will not have direct access to Georgia SHINES.

The interface between Georgia SHINES and CPRS ensures that CPRS operates on up-to-date versions of the Foster Care case plans.

Retrieve First Approved Case Plan

Functional Description

The SHINES – CPRS Interface operates in the following fashion.

Georgia SHINES was deployed to the entire state on a region by region schedule. As regions underwent “go[.line-through]#“#live” (the initial deployment of Georgia SHINES), CPRS requested, via the Georgia SHINES – CPRS Interface, the region’s case plans. Regions consist of several counties, and CPRS made one interface request for each of the region’s counties. Georgia SHINES then transmitted the county-specific case plans to CPRS. This initial request seeds the data within CPRS, and subsequent CPRS request results will include only those case plans that have been updated since the last Georgia SHINES – CPRS Interface exchange.

After a given county has been converted to Georgia SHINES, that county’s case plans are available via the Georgia SHINES – CPRS Interface on a nightly basis. CPRS will iterate through all 159 Georgia counties nightly and exchange case plans that have been updated within Georgia SHINES since the last Georgia SHINES – CPRS Interface exchange.

The definition of a case plan update in the interface context consists of two conditions:

Case plans that have been Supervisor-approved in the FCC stage.

Additional case elements that have been updated without Supervisor approval such as: Child’s name, Birth date, Gender, Date of the initial case plan, Date of removal, Reason for removal, Initial reason for placement in foster care, Services offered to prevent removal, Why child cannot safely remain in home, Harm which may occur if child remains in home, Permanency Plan type, Primary goal, Caretakers, Current caretaker type, Current Placement, Case worker, Current Visitation Plans.

The SHINES – CPRS Interface is triggered by a request from CPRS. The response is synchronous. If there is a failure on either the request or the response, CPRS will manage the retry, typically at a later date. There is no action on the Georgia SHINES side that triggers use of the interface; though supervisors’ approval of case plans makes plans eligible for transfer to CPRS.

The change to the ‘Assigned Judge’ field on an approved FCCP Family Case Plan page triggers the CPRS to pick the Case Plan.

Any Visitation Plan changes to Current status will trigger the CPRS_OUTBOUND table to send to CPRS.

Any legal status updates to those considered ‘Not in DFCS custody’ on the Legal Status page within SHINES will trigger the CPRS_OUTBOUND table to send to CPRS. The following values represent those ‘Not in DFCS custody’:

  • Aftercare/Supervision

  • Committed to DJJ

  • ILP Aftercare

  • Not In DFCS Custody – Adoption Finalized

  • Not In DFCS Custody – Child Turned 18 (No ILP)

  • Not In DFCS Custody – Child Death

  • Not In DFCS Custody – Custody To Other

  • Not In DFCS Custody – Custody Transferred To Tribe

  • Not In DFCS Custody – Emancipated

  • Not In DFCS Custody – Guardianship

  • Not In DFCS Custody – Parental Custody

  • Not In DFCS Custody - Custody To Relative

  • Not In DFCS Custody – Out of State Child Adopted by Georgia Family

  • Not In DFCS Custody - Custody With Other State

  • No Longer Committed to DJJ

  • DJJ Aftercare

  • Not In DFCS Custody - Runaway

Any placement status updates for a child will trigger the CPRS_OUTBOUND table to send to CPRS. The placement status may be updated to the following values: COMP, PEND, APRV and PROC.

When a person or case has been merged, it will trigger the CPRS_OUTBOUND table to send to CPRS. With a person merge, the previous person IDs associated with that person from the Person Detail submodule will be sent to CPRS. A Person in this instance includes a primary child, primary caretaker, and relative.

Process Flow for Newly-Approved Case Plans

Request Elements

Attached is a spreadsheet (CPRS Interface Dev Guide.xls) that lists the data elements requested to be passed to CPRS. This document also includes the mapping from the Shines Database tables to the requested elements and also the mapping from the Shines CPRS Interface response to the requested elements. The requested data elements is voluminous; with the possibility of over 400 data elements per child

Practice Model phase I and II updates

Error Messages

None

System Generated Events

None

System Generated To Dos

None

Design Requirements

Validated Functional Requirement Number Conceptual Design Requirement Number Conceptual Design Requirement

MR057.1

MR-057.1.1

Add new field for question “Is this a long term Foster Care Placement?”

MR057.1

MR-057.1.2

Add new field for Date Agreement Signed

MR057.1

MR-057.1.3

Add new field for question “Does this child have a connection to an Adult?”

MR057.1

MR-057.1.4

Add new field for Person Connected

MR-057.2

MR-057.2.1

Update TIAR_LEGAL_STATUS trigger to create a new CPRS outbound record when there is a change in Legal Status.

MR068.5

MR068.5.1

Send the Code and Decode of the Judge selected in the ‘Assigned Judge’ field of the FCCP Family Case Plan to the CPRS.

MR-074-2.35

MR-074-2.35.1

Update the data objects retrieval to recognize the TPR/VS on a Putative Father.

MR-083.29

MR-083.29.1

Send State current recruitment effort status for the child.

MR-094.1

MR-094.1.1

Send updates to visitation plans current status.

CO-R5.2-2.2.1

CO-R5.2-2.2.1.1

The system shall populate the "dischargeDt" field within the "Child" section of the response XML with the Effective Date of the child’s first change from an "In DFCS Custody" Legal Status to a "Not in DFCS Custody" Legal Status, in the current stage.

CO-R5.2-2.2.1

CO-R5.2-2.2.1.2

The system shall populate the "dischargeReason" field within the "Child" section of the response XML with the code value of the child’s first "Not in DFCS Custody" Legal Status that immediately follows an "In DFCS Custody" Legal Status, in the current stage.

MCPRS-1.1

MCPRS-1.1.1

When any of the following legal statuses has been updated on the Legal Status page, the system must trigger the outbound CPRS interface: - Aftercare/Supervision - Committed to DJJ - ILP Aftercare - Not In DFCS Custody – Adoption Finalized - Not In DFCS Custody – Child Turned 18 (No ILP) - Not In DFCS Custody – Child Death - Not In DFCS Custody – Custody To Other - Not In DFCS Custody – Custody Transferred To Tribe - Not In DFCS Custody – Emancipated - Not In DFCS Custody – Guardianship - Not In DFCS Custody – Parental Custody - Not In DFCS Custody - Custody To Relative - Not In DFCS Custody – Out of State Child Adopted by Georgia Family - Not In DFCS Custody - Custody With Other State - No Longer Committed to DJJ - DJJ Aftercare - Not In DFCS Custody – Runaway

MCPRS-2.1

MCPRS-2.1.1

When any of the following placement statuses have been triggered by the system then the system shall trigger an update to the outbound CPRS interface: - PEND - COMP - PROC - APRV

MCPRS-3.1

MCPRS-3.1.1

When a person has been merged, the system must send CPRS the previous person IDs from Person Detail submodule (Person includes primary child, primary caretaker, and relative)

MCPRS-3.2

MCPRS-3.2.1

When a person has been merged, the system must trigger an update to the SACWIS IFC CPRS outbound table

MCPRS-4.1

MCPRS-4.1.1

When a case has been merged, the system must trigger an update to the SACWIS IFC CPRS outbound table

MCPRS-5.1

MCPRS-5.1.1

If the stage closure date is later than the date processed, the system shall send all case data for all cases out of sync prior to the release to the CPRS outbound table (this is a one-time occurrence after release)

MCPRS-5.1

MCPRS-5.1.2

If the stage closure date is later than the date last updated, the system shall send all case data for all cases out of sync prior to the release to the CPRS outbound table (this is a one-time occurrence after release)

MCPRS-5.1

MCPRS-5.1.3

The SHINES application team shall send a list of closed cases and merged cases on 12/15/2016 (this is a one-time occurrence after release)

PMII3.13

PMII3.13.1

The system send all persons listed in the ‘Parental/Caregiver Information’ section of each child in the FCC stage.

PMII3.13

PMII3.13.2

The system shall send indicator for each Parent/Caregiver who is identified on the FCCP Detail page as a person working the Case Plan.

PMII3.13

PMII3.13.3

The system shall send most recent active email address for each Parent/Caregiver.

PMII3.13

PMII3.13.4

The system shall send a null value if the most recent active email address for each Parent/Caregiver is null

PMII3.13a

PMII3.13a.1

The system shall send the updated and new fields data as per the CPRS Interface Dev Guide in section 1.2.2

PMII3.13b

PMII3.13b.1

The system shall send the updated and new fields data as per the CPRS Interface Dev Guide in section 1.2.2

SOW29DS-R3.4

SOW29DS-R3.4.1

The system shall capture sending data from the Diligent Search Notification Form to CPRS.

SOW29DS-R3.5

SOW29DS-R3.5.1

The system shall capture sending data from the Diligent Search Notice of Intent to CPRS.

Technical Design

Technical Overview

The CPRS is a J2EE application with an Oracle database. The application currently resides within the GTA TOE; however, the application may move outside of GTA as DHR migrates Foster Care case plans to Georgia SHINES.

The application accesses the Georgia SHINES web service which is exposed by WebMethods. CPRS will invoke the web service in real time using SOAP/XML as the transport mechanism. The return message from Georgia SHINES will also be packaged as SOAP/XML.

The SHINES – CPRS Interface is defined as a basic web service. WebMethods activity is transparent during the client-server exchange, so the web service does not need include any WebMethods-specific logic.

This interface does not utilize the messaging database table interface pattern as defined in the Georgia SHINES Software Architecture Document.

CPRS Technical Specifications

Hardware/OS: Sun/Solaris

Programming Language: J2EE

Database: Oracle

Transactional Monitor: N/A

Physical Location: GTA

Current Interfaces: Web Services to IDS (SMI)

Protocols: WebMethods to provide Web Service interface to CPRS

Web Service Exchange

Technical Description

Georgia SHINES exposes a web service which WebMethods ServiceNet makes available to the trusted client, CPRS. The request and result data are encrypted by SSL. WebMethods invokes the Georgia SHINES web service by parsing the XML fields in the CPRS request.

Georgia SHINES then performs the requested search and returns case plans. Georgia SHINES packages this data into XML and returns the values in real-time to WebMethods. WebMethods then forwards the result set to CPRS. At this point, how CPRS manages the result data is transparent to WebMethods or Georgia SHINES.

Though the amount of data per case plan can be quite voluminous, the granularity of the web service interface ensures that the number of case plans in the result data set is restricted. For example, the foster care case plans that this interface includes are updated quite often in the life of a case; however, the supervisor approval occurs less frequently, typically every six months, prior to a case being presented in court. Also, by forcing the web server to operate on a county-by-county level, the number of case plans in the result set again reduced. Historically, in a given month the average number of foster care case plans updated (not just supervisor-approved) is approximately 20.

Service Description

The service, request message and response message are defined in the following wsdls.

This request message consists of two values:

County – This is the only county in which to search for case plans.

Search Date – The search for case plans should include only case plans that have been supervisor-approved or updated since this date.

The response message is voluminous with the possibility of over 400 elements per child (stage) in the response.

This request message consists of one value:

Case Id List – A list case ids of case plans to be retrieved.

The response message is voluminous with the possibility of over 400 elements per child (stage) in the response.

County – This is the only county in which to search for case plans.

Search Date – The search for case plans should include only case plans that have been supervisor-approved or updated since this date.

The response message returns the list case ids and meta-data for each case plan that meets the search criteria.

Data and WSDL Mappings

The following spreadsheet lists the mappings between the requested data and the Shines Database and also between the response message and the requested data. In the second worksheet, it also contains the database traversal rules to retrieve the major Shines Data Objects.

Outbound Table:

A new outbound table (CPRS_OUTBOUND) has been created. This table is populated with the cases that match the approval criteria. A series of triggers have been created to populate this table when a case has been approved or an approved case has been updated. (Defined in Section 1.2 of this document)

Static/ Dynamic Required (Yes, No) Data Name Description Possible Value Type Length

Dynamic

Y

ID CPRS Outbound

Unique identifier for the row

Dynamic

Y

Date Last Update

Indicates when the row was last updated

Dynamic

N

Date Processed

Indicates when the case was last processed by the service.

Dynamic

N

Date Created

Indicates when the case/row was inserted into the table

Dynamic

Y

CD County

The county code for the case.

Dynamic

Y

ID Case

The Shines case

N

Date Case Last Updated

Indicates when the case/row was last updated by the application

Method Narrative

CPRS schedules a series of web service invocations, one for each county in the state. Each web service call requests data that has been updated since the last county-specific invocation of the web service.

Error Handling

The SHINES – CPRS Interface is real-time so CPRS is informed of errors immediately. If the web service is not available, the client CPRS is notified, and CPRS can reschedule the request at a later time. In addition, web service invocations for other counties can be delayed.

Process Errors

Web Service and other application failures are reported to the web service client. The client should retry the request at a later time.

Security

The request and result messages are SSL encrypted. In addition, the GTA TOE traffic will be IP filter restricted: only data between the registered IP addresses of the web service client and server are allowed. No user authentication is required; the CPRS application is the client ‘user.’

Triggering/Scheduling

The case plan requests are scheduled by the client for nightly execution.

Matching Criteria

The county and the search date criteria are required.

Dependencies

WebMethods, network, and infrastructure operation are the only dependencies. No additional external processing is required.

SHINES Database Triggers

The following triggers have been added to the SHINES database to create interface records when certain changes take place in the underlying tables:

CAPS.TIAR_ADO_INFO

CAPS.TIAR_CAPS_CASE

CAPS.TIAR_DILIGENT_SEARCH

CAPS.TIAR_FCCP_FAMILY

CAPS.TIAR_LEGAL_STATUS

CAPS.TIAR_PLACEMENT

CAPS.TIAR_PROFESSIONAL_ASSMT

Open Discussion Points

Point# Description Resolution/Comments Status (Open, In Progress, Resolved)

1

Does the Georgia SHINES application need to build in constraints to restrict the size of the result data sets?

Open

2

Is the SSL encryption and firewall-based IP filtering sufficient for security?

Open

Document Change Log

Date Author Change Description

2/7/2018

David Fink

Updated Title Page release date

03/13/2017

Ashwini Rege

SOW9 – Practice Model II – FCCP Family Plan redesign Updated as per level 1 comments

02/17/2017

Ashwini Rege

SOW9 – Practice Model II – FCCP Family Plan redesign Updated the embedded worksheet to include Practice Model I changes

02/01/2017

Ashwini Rege

SOW9 – Practice Model II – FCCP Family Plan redesign Updated the following sections 1.0, 1.2.2 and 1.3

12/13/2016

Christine

Updated per Level 2 comments received from Nick – removed Case Manager and Healthcare Provider as type of person considered for merge Section 1.2 (functional) Section 1.3 (design requirements)

12/5/2016

Christine Nguyen

Updated per Level 1 comments received: Section 1.0 (functional) Section 1.2.1 (functional description) Section 1.3 (design requirements)

11/17/2016

Christine Nguyen

Updated document name to accurately capture its purpose for FCC stages Updated the following sections based upon the Minor Enhancements – CPRS unit of work from SOW 9: Section 1.0 (functional) Section 1.2.1 (functional description) Section 1.3 (design requirements)

05/15/2012

Candis L. Curd

CO-R5.2 – CPRS - Section 1.0, Section 1.3, Section 1.2.2 – Updated to indicate that we are looking at the first Legal Status change from ‘In DFCS Custody’ to ‘Not in DFCS Custody’ in the current stage.

05/08/2012

Candis L. Curd

CO-R5.2 – CPRS Corrected acronym for CPRS to read, “Court Process Reporting System”.

04/26/2012

Candis L. Curd

CO-R5.2 – CPRS Section 1.0, Section 1.3 – Update requirements text wording. - Section 1.2.2 – Updated mapping document to indicate the Discharge Date is the Effective Date of the Legal Status.

4/23/2012

Terry Zasio

CO_R5.2 – CPRS Add new requirement for calculating the child discharge date. Update the “CprsInterfaceDevGuide” spread sheets.

2/28/2012

Seung-eun (Caroline) Choi

STGAP00017923 for R5.03: In CPRS Interface Dev Guide.xls in section 1.2.2 and CprsInterfaceDevGuide in section 2.3.3, updated the following sentence “Child is an abandoned infant as set forth in O.C.G.A. Section 15-11-81(b)” To “Child is an abandoned infant as set forth in O.C.G.A. Section 15-11-94(b)(3)” per database change and corrected minor punctuation for AFSA items

8/18/2011

Hai Nguyen

MR-94 Updated requirement to send updates to visitation plan current status.

08/3/2011

Dat Nguyen

MR-094 update in section 1.0 and 1.3, add trigger to indicate current Visitation Plan. Update to section 1.2 Any Visitation Plan marked Current will trigger the CPRS_OUTBOUND table to send to CPRS.

6/7/2011

Hong-Van Vo

MR-083: updated the embedded Dev Guide (Data Objects Retrieval – Shines sheet) that Adoption data elements should only be sent when the ADO stage is open.

5/19/2011

Hai Nguyen

MR-083 Updates from Comment Review meeting. -Update requirements to Send only the State current recruitment effort for the child CPRS Interface Dev Guide.xls: Removed proposed County recruitment effort status. - ‘CprsInterfaceDevGuide.xls’ same action. - CprsQueryWS.xml removed proposed County recruitment effort status indicators for Adoption. - CprsCaseDataQueryWS.xml Removed proposed County recruitment effort status indicators for Adoption.

5/11/2011

Hai Nguyen

MR-083 My Turn Now / Exchange Child Detail -In 1.0 added new requirement. - CPRS Interface Dev Guide.xls: Added indicators for State and County recruitment effort status. - ‘CprsInterfaceDevGuide.xls’ same actions. - CprsQueryWS.xml updated with new State and County recruitment effort status indicators for Adoption. - CprsCaseDataQueryWS.xml updated with new State and County recruitment effort status indicators for Adoption.

3/29/2011

Candis L. Curd

MR-074-2 AFCARS Phase 2 - CPRS Interface Dev Guide.xls: For Date TPR Filed, look at the Court Action Date (not the Court Order Date), per an email from Pat. - CPRS Interface Dev Guide.xls: For Date TPR/VS Achieved, don’t consider the Permanent Custody outcomes when retrieving the date for TPRs. - 'CprsInterfaceDevGuide.xls': same actions

3/17/2011

Hong-Van Vo

MR-074-2 AFCARS Phase 2 - CPRS Interface Dev Guide.xls: removed previous release’ highlight & clarified that legal action must be in COMP or APRV status. - 'CprsInterfaceDevGuide.xls': same action

3/7/2011

Candis L. Curd

MR-074-2 AFCARS Phase 2 - Updated section 1.0 to strike through the "…​ and include them in the logic hierarchy." requirement - Updated section 1.1.2 to reflect CPRS formerly being the system of record for Foster Care Case Plans, and GA SHINES now being that system of record. - Renamed section 1.2 to "Retrieve First Approved Case Plan". - Updated section 1.2 to reflect how GA SHINES currently behaves (since "go-live"). - Updated 'CPRS Interface Dev Guide.xls' embedded within design to contain current logic as of 3/4 meeting. - Updated 'CprsInterfaceDevGuide.xls' embedded within design to contain current logic as of 3/4 meeting. - Updated section 1.3 to strike through technical requirement MR-074-2.35.2.

2/22/2011

Candis L. Curd

MR-074-2 AFCARS Phase 2 (Section 1.2): Reworded header from, “Retrieve Newly-Approved Case Plans” to “Retrieve Case Plans”. Renamed header for graphic from “Process Flow” to “Process Flow for Newly-Approved Case Plans”. Updated process flow to remove the arrow going from “Case Plans Approved within Georgia SHINES” to “Approved Case Plans Found?”, to indicate that this step is independent of the request[by CPRS] for approved case plans. Updated process flow to indicate that no further processing happens if there is no approved case plan.

02/07/2011

Candis L. Curd

MR-074-2 AFCARS Phase 2: Updated the 2nd tab (Data Objects Retrieval - Shines tab) in the CPRS Interface Dev Guide.xls in section 1.2.3 and CprsInterfaceDevGuide in section 2.3.3 to indicate that Putative Father information should be pulled, only in the event that there have been no other TPR/VS done on Fathers (i.e. Legal, Biological, etc.).

02/01/2011

Seung-eun (Caroline) Choi

MR-074-2 AFCARS Phase 2: - In Validated Requirements and 1.3 Design Requirements sections: Added a requirement to recognize the "TPR - Putative Father" and "Voluntary Surrender - Putative Father" types and include them in the logic hierarchy - Added “Voluntary Surrender - Putative Father” field to the 2nd tab (Data Objects Retrieval - Shines tab) in the CPRS Interface Dev Guide.xls in section 1.2.3 and CprsInterfaceDevGuide in section 2.3.3

08/31/2010

Brandye Orr

MR-068 -In 1.2.1 Functional Description section, added that modifications to the Judges field of approved FCCP Family plans would trigger the CPRS Interface.

07/28/2010

Bhavna Gehlot

Added working in section 12. Added back the existing ‘Assigned Judge’ field in the CPRS Interface Dev Guide.xls in section 1.2.3 and CprsInterfaceDevGuide in section 2.3.3 Added back the existing ‘Assigned Judge’ field inCprsQueryWS.xml CprsCaseDataQueryWS.xml In section 2.3.2

07/13/2010

Bhavna Gehlot

Added new requirement to section1.0 and section 1.3 Updated the ‘Assigned Judge’ field in the CPRS Interface Dev Guide.xls in section 1.2.3 and CprsInterfaceDevGuide in section 2.3.3 Updated ‘Assigned Judge’ field in CprsQueryWS.xml CprsCaseDataQueryWS.xml In section 2.3.2

11/23/2009

Herve Jean-Baptiste

Added new Placement fields in the CprsInterfaceDevGuide in section 2.3.3 Added new fields in the CprsQueryWS.xml & CprsCaseDataQueryWS.xml for APPLA Placements in section 2.3.2 Added new functional and technical requirement for a DB trigger to create an CPRS outbound record on Legal Status change.

11/03/2009

Ashwini Rege

Changed CPRS Interface Dev Guide spreadsheet to reflect change on Contact Detail page

04/17/2009

Bhavna Gehlot

Changed mapping spreadsheet to reflect new addition of fields NbrPostReqCred, NbrPostReqEar, dtDecision, flgDate and added the translation rule for Tpr Filed Date, and TPR Appealed.

2/9/2008

Charles Johnston

Added Section 2.3.11 SHINES Database Triggers

01/21/2008

Michael Chillman

New wsdl: CprsCaseIdQueryWS.xml

01/09/2008

Michael Chillman

Added new wsdls for issue: STGAP00006994

09/17/2007

Michael Chillman

Updated requirements

08/22/2007

Michael Chillman

Changed relative retrieval in spreadsheet

08/21/2007

Michael Chillman

Changed mapping spreadsheet to reflect new court order mapping in case tracking area

08/03/2007

Michael Chillman

The spreadsheet contained an incorrect mapping on the participation area for the Child Support Enforcement referral fields

07/30/2007

Michael Chillman

Added spreadsheet that captures data mappings. Also reworded narrative to describe spreadsheet and the new outbound table

05/25/2007

George Li / Dinesh Jayapalan

Updated data elements.

04/11/2007

George Li

Updated design document for language usage consistency as per comments received from state on 04/09/2007

04/05/2007

George Li / Dinesh Jayapalan

Updated data elements from state (pw) review.

03/27/07

George Li / Dinesh Jayapalan

Updated design comments from state and data elements. Updated Formatting

02/16/2007

George Li

Initial

Note: A new row explainin document chanes must be added to the Document Chane Lo for each revision. The Document Chane Lo must be maintained in reverse chronolo__ical order. The most recent chanes are on the top of the list.

Edit this page · latest