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. |
IONS Outbound Update Interface Service **Detailed Design Document
Investigation Outcomes Notification System (IONS*)*
Georgia Department of Human Services
Comprehensive Child Welfare Information System
(CCWIS)
12/21/2020
Version 2.3
Table of Contents
General Design (Functional)
| Req. # | Validated Requirement |
|---|---|
CARIONS-R1.1 |
The SHINES system shall utilize the real-time webservice to send updated case information to Investigation Outcome Notification System (IONS). |
CARIONS-R1.2 |
The system shall send the Shines Case ID. |
CARIONS-R1.3 |
The system shall send Investigation Stage ID. |
CARIONS-R1.4 |
The system shall send the Admin Review Date. |
CARIONS-R1.5 |
The system shall send the Administrative Review Disposition (Unsubstantiated). |
CARIONS-R1.6 |
The system shall send the Maltreator Person ID. |
CARIONS-R1.7 |
The system shall send the Allegation ID. |
1.1.1 Document Purpose
The document provides a detailed description of the Georgia SHINES outbound updated interface that sends unsubstantiated case data (SHINES Case ID, Investigation Stage ID, Admin Review Date, Admin Review Disposition, Maltreator Person ID, and the Allegation ID) to the Investigation Outcomes Notification System Outbound Update Interface (IONS). This project is to develop an interface that would allow real-time updates of Administrative review outcomes from SHINES to IONS.
1.2 Functional Description
The IONS Outbound Interface is used to provide real-time webservice between SHINES and IONS with limited information regarding the unsubstantiated maltreator and allegation. An administrative Review disposition type ‘O’ (Overturn) will be sent to IONS for an unsubstantiated allegations.
The trigger point for the real-time webservice between SHINES and IONS is when an individual clicks SAVE/CLOSE on the Administrative Review Page and sends the updated case information of the unsubstantiated allegations.
1.4 Security Rules
| User Type | View | Add | Update | Delete | No Access |
|---|---|---|---|---|---|
Case Manager (Assigned) |
X |
X |
X |
||
Supervisor (Assigned) |
X |
X |
X |
1.8 Input Data Elements
| Name | Data Type | Is Required | Notes |
|---|---|---|---|
ShinesCaseNumber |
Numeric |
Yes |
SHINEs Case Id |
Stage ID |
Numeric |
Yes |
Investigation Stage ID |
Admininistrative Review Date |
Varchar (10) |
Yes |
Administrative Review Date will be provided in mm/dd/yyyy format. |
Administrative Review Disposition |
Varchar (1) |
Yes |
O – Overturn. Only unsubstantiated allegations information will be sent to IONS. |
Person ID |
Numeric |
Yes |
Maltreator Person ID |
Allegation ID |
Numeric |
Yes |
Unique ID of each allegation. |
1.9 Output Results
| Name | Data Type | Notes |
|---|---|---|
UpdateAdminReviewResult |
Varchar |
True or False. True : when successfully completed. In this case, Errormessage will be empty. False: when there is any validation or exception. In this case, Errormessage will be provided. |
ErrorMessage |
Varchar |
Contains validation or exception message. Varchar length of 4000 characters. |
1.19 Removed Baseline Functionality
| Functionality Type | Functionality Name/Description | Reason for Removal |
|---|---|---|
N/A |
1.20 Design Requirements
| Validated Functional Requirement Number | Conceptual Design Requirement Number | Conceptual Design Requirement |
|---|---|---|
CARIONS-R1.1 |
CARIONS-R1.1.1 |
The system shall create a new outbound interface update service with Investigation Outcome Notification System (IONS). |
CARIONS-R1.1 |
CARIONS-R1.1.2 |
The system shall send real-time webservice case data for each allegation to IONS. |
CARIONS-R1.1 |
CARIONS-R1.1.3 |
The system shall send updated information for cases to real-time webservice, IONS to Manage Overturn. |
CARIONS-R1.1 |
CARIONS-R1.1.4 |
The system shall send unsubtantiated cases to the real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.1 |
CARIONS-R1.1.5 |
The system shall send substantiated to unsubstantiated overturned cases to the real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.2 |
CARIONS-R1.2.1 |
The system shall send the SHINES Case ID from the Administrative Review and Appeal Page to the real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.3 |
CARIONS-R1.3.1 |
The system shall send the Investigation Stage ID from the Administrative Review and Appeal Page to the real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.4 |
CARIONS-R1.4.1 |
The system shall send the Admin Review Date from the Administrative Review and Appeal Page to the real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.5 |
CARIONS-R1.5.1 |
The system shall send the Disposition Code of Unsubstantiated from the Administrative Review and Appeal Page to the real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.6 |
CARIONS-R1.6.1 |
The system shall send the Maltreator Person ID from the Person Detail Page to real-time webservice, Investigation Outcome Notification System (IONS). |
CARIONS-R1.7 |
CARIONS-R1.7.1 |
The system shall send a unique Allegation ID to the real-time webservice, Investigation Outcome Notification System (IONS). |
Technical Design
Detailed Process Flow
Detailed Process Flow Diagram
SHINES to IONS Outbound Interface Workflow Diagram
File Layout
Technical Description
AdminReview Page Identify all the allegation which are unsubstantiated from substantiated along with Case number , Investigation Stage id, Admin Review date, Disposition (Overturned) Maltreator Person ID from database /Page using Sql queries and JSP.
Validate all the updated allegation in ARI stage with the existing allegation that already SENT to IONS .If both IDs are matched then only sent updated Allegations to IONS (To perform update).
Create database Outbound table i.e IONS_UPDATE_OUTBOUND add all the information that are sending to IONS.
Update build.xml to generate webservice client from WSDL shared by GTA
Implement webservice client in AdminReview Code so that webservice will be called on click “Save and Close ” button.
Add Logic if there is any error in response from IONS , insert it in IONS_UPDATE_OUTBOUND with Transmission status =ERR.
Once The ERR status inserted in IONS_UPDATE_OUTBOUND table ,Correct it with data correction and change the status to NEW so that the GTA will pick up it and send to IONS again.
Service Description
None
Database Elements
| IONS_UPDATE_OUTBOUND |
|---|
ID_IONS_UPDATE_OUTBOUND NUMBER(160) NOT NULL ENABLE |
DT_LAST_UPDATE DATE NOT NULL |
ID_STAGE NUMBER(160) |
ID_CASE NUMBER(160) |
SUB_INV_DATA BLOB |
DT_REVIEW DATE |
CD_DISPOSITION VARCHAR2(4 BYTE) |
CD_TRANSMISSION_STATUS VARCHAR2 (3 BYTE) |
CD_IONS_ERROR VARCHAR2(500 BYTE) |
Open Discussion Points
| Point# | Description | Resolution/Comments | Status (Open, In Progress, Resolved) |
|---|---|---|---|
N/A |
Document Change Log
| Date | Author | Change Description |
|---|---|---|
12/18/2020 |
Rasika Jahagirdar |
Review the Latest document shared by BA and provided review comments 2.1.4-Section Updated 2.1.6-Section Updated |
12/18/2020 |
Tatsinda Taylor |
Updated the name of the document. Section 1.0 – General Design (Function) Section 1.2 – Functional Description Section 1.20 – Design Requirements |
12/15/2020 |
Tatsinda Taylor |
Updated Section 1.67 Mock-up with changes from Administrative Review ALM-20582 & ALM-20587. |
11/19/2020 |
Tatsinda Taylor |
Updated Section – Table of Contents Section 1.2 – Functional Description Section 1.8 – Input Data Elements Section 1.9 – Output Results Section 1.20 – Design Requirements Section 2.1.5 – Service Description Section 2.1.6 – Database Elements Section 2.2.1 – Detailed Process Flow Diagram Section 2.3 – Sequence Diagram Section 2.6 - Messages |
11/18/2020 |
Tatsinda Taylor |
Updated Section 1.6 – Page Mock-up Section 1.7 – Request Elements Section 1.8 – File Layout Section 2.2 – Web Service Exchange |
11/16/2020 |
Rasika Jahagirdar |
Corrected the Below sections a/c to updated service – Updated Sections: 1.1.1 Document Purpose 1.2 Functional Description and Figure 1 1.7 Request Elements 2.1 Technical Design 2.2 Web Service Exchange Added Technical Review 2.3 Technical Description |
11/12/2020 |
Tatsinda Taylor |
Changes based on Internal Review with team and Developers. Removed CARS Functional |
Note: A new row explaining document changes must be added to the Document Change Log for each revision. The Document Change Log must be maintained in reverse chronological order. The most recent changes are on the top of the list.