SACWIS maintains information regarding approved resources (including service providers, foster home, and adoptive homes) in what is commonly referred to as the Resource Directory. Using the Resource Directory, Resource Developers can add resources in which Case Managers can utilize to either authorize services, place children in foster homes, or place children in adoptive homes. In all of these situations, there is an approved resource/payee in which payments are to be made in the form of provided service payments, foster care per diem payments, or adoption assistance benefits. Therefore, the information listed for each payee in the Resource Directory would need to be setup and updated accordingly in SMILE.

When a new resource is added to SACWIS via the Add Resource page and a contract is setup and approved, SACWIS will create an outgoing record in the VENDOR_OUTBOUND table, which the web Methods broker will pick up and send to SMILE to be setup as a new vendor.

In the case of Foster/Adoptive homes, after adding the home via the Add Home page, they are required to go through further approvals and training. After completing this approval/training process, the status is set to Approved (Full), Approved (Special), or Approved (Temp). Once the Foster/Adoptive Homes status is set to Approved (Full), Approved (Special), or Approved (Temp), the home is added to the VENDOR_OUTBOUND table for transmission to SMILE.

If the resource exists in SMILE, then the Contract Manager is provided with a report from SMILE as requested to review the updates and manually update information as appropriate. If the resource does not exist in the database, then the resource is added as a new vendor and the Contract Manager is provided with a report from SMILE as requested of the newly added resources/vendors.

Figure : Setup/Update Vendor Information Process Flow

None

None

Similar to setting up resources/vendors in SMILE, every person/client provided services or children in DFCS custody, placed with a relative or in an adoptive placement receiving adoption assistance benefits must be known to SACWIS as well as SMILE.

Client data is sent to SMILE when the Program Area Supervisor approves Service Authorization or Payment of Care (all clients receiving services/authorized for payment of care are sent to SMILE). In addition, creating a new approved Adoption Assistance entry triggers Person information to be sent to SMILE.

Within SHINES when a child’s Pre-Adoption stage is closed with the reason of adoption finalized a new client record will be inserted in the SHINES-SMILE Client interface table (SACWISIFC.CLIENT_OUTBOUND ) for the newly created post adoptive child which includes the SHINES Person Id of the existing, pre-adoptive child in the ID_CLIENT_PREV column.

<Similar to Vendor Setup >

None

None

SACWIS maintains information regarding approved resources (including service providers, foster home, and adoptive homes) in what is commonly referred to as the Resource Directory. Using the Resource Directory, Resource Developers can add resources in which Case Managers can utilize to either authorize services, place children in foster homes, or place children in adoptive homes. In all of these situations, there is an approved resource/payee in which payments are to be made in the form of provided service payments, foster care per diem payments, or adoption assistance benefits.

Once a service/benefit is entered into the system for a person/client, a financial batch process observes the various parameters required (based on the type of service/benefit) and generates an invoice to process payment to the approved vendor where services were provided or benefits were sanctioned. These generated invoices are then reviewed and approved/rejected by regional accounting staff and forwarded to SMILE via the interface. Assuming the provider exists in SMILE, the invoices are batched nightly (marked ready for approval), and are recorded to the INVOICE_OUTBOUND table once approved by regional accounting. The web Methods broker will pick up the invoice items from the table and send to SMILE.

Once the invoice is sent to SMILE servers (writing to SMILE incoming tables or using secure FTP to send an XML file), SMILE reviews the invoice and generates payment using the program code defined on the invoice to the identified payee on the invoice. After the invoice is processed, SMILE informs SACWIS of the payment information. (See Send Invoice Inbound Section for details.)

In the situations where a payee is overpaid/underpaid, SACWIS manages this using the invoice generation process. If a payee is overpaid, SACWIS subtracts the overpaid amount from a subsequent invoice; if a payee is underpaid, then SACWIS adds the underpaid amount to a subsequent invoice.

Under MR-039, the Invoice Detail page was updated to capture the Provider Invoice Number textbox. The Provider Invoice Number is available for financial staff as needed. This information is added to the SHINES to SMILE invoice outbound record layout for purposes of printing this information on the check or remittance advice that goes on the payment to the provider.

As per MR-059, three new fields are added to the Invoice Outbound table - ID_ORIG_REVERSAL_INV, DT_ADJ_INVO_PAID_CHECK, NBR_ADJ_INVO_PAID_CHECK.

ID_ORIG_REVERSAL_INV: The Prior Period Adjustment batch is updated to associate all the rerate and recoupment adjustment records with the Invoice Id of the original invoice that corresponds to the adjustments .This invoice id will be written to the column ID_ORIG_REVERSAL_INV of the Invoice Outbound table to pass it to SMILE interface.

DT_ADJ_INVO_PAID_CHECK: The Prior Period Adjustment batch is updated to associate all the rerate and recoupment adjustment records that correspond to an originally paid invoice with the check date of the originally paid invoice. This check date will be written to the column DT_ADJ_INVO_PAID_CHECK of the Invoice Outbound table to pass it to SMILE interface. This field is populated only if the original invoice is in paid status when adjustments invoices are generated by the batch.

NBR_ADJ_INVO_PAID_CHECK: The Prior Period Adjustment batch is updated to associate only the rerate adjustment records(not applicable to recoupments) that correspond to an originally paid invoice with the check number of the originally paid invoice. This check number will be written to the column NBR_ADJ_INVO_PAID_CHECK of the Invoice Outbound table to pass it to SMILE interface. This field is populated only if the original invoice is in paid status when adjustments invoices are generated by the batch.

Figure : Send Invoice Process Flow

None

None

After payment is made, SMILE informs SACWIS (the web Methods broker will invoke a web service on SACWIS) of the payment information including check number, restricted funds balance, payment date, check amount and invoice number. A single SACWIS invoice may result in multiple checks in the rare event that an invoice has more than 12 line items, but SMILE will process each line item as a separate transaction.

The status of the payment information that SACWIS receives from SMILE will determine what actions need to be executed in the SACWIS system. Those statuses are Paid, Rejected, Cancelled or Void. See below for a description of the operations performed when those statuses are received.

Paid

In the event that the invoice was paid, the SACWIS application will update the Invoice, Line item, and the Restricted Funds information if applicable. The application will also update both the County and Case budget limits to indicate that the payments were made.

Rejected

In the event that the invoice was rejected, the SACWIS application will be updated with the rejection reason and both the Invoice and Service Authorization detail will be updated to show that the payments were not made. We will also flag the line item to show that the payment was rejected.

Cancelled

In the event that the invoice was cancelled, the SACWIS application will update the overall status of the invoice to indicate that the payment was cancelled. The service authorization detail will also be updated to show that the payment was cancelled.

Voided

If the invoice was previously paid and later voided in the SMILE system, then all payment updates will be reverted to the values that existed before the payment and the overall status of the invoice will be updated to show that the payments were voided.

The SMILE application is hosted outside of DHR and GTA and is developed, hosted, and maintained by SMI. The C/Unix application currently interfaces with other systems via secure FTP file transfer.

SACWIS will write outgoing information into separate interfacing tables for vendor, client, and invoice. The GTA web Methods broker will access those tables directly via JDBC support, convert them into web Methods objects, and then send them to SMILE. The current plan is that the broker will either write records into incoming SMILE tables or send XML files to SMILE. However, the web Methods broker will handle that transformation and transport for us, so technically it is not our concern.

The major technical assumption is that the interface will not be synchronous. The end user of SHINES is not waiting on a response from the SMILE system before proceeding to the next step. SHINES will write out the database records for transmittal as soon as the person, vendor, or invoice is approved, updated, or assigned. How often the broker picks up these records is out of the hands of the SHINES team.

SHINES will need to host a web service for the response to these transactions. There will be three web services: one for handling client responses, one for vendor responses, and one for the invoice responses. The GTA web Methods broker will be invoking these SHINES web services when it picks up outgoing responses from the SMILE system. SMILE is currently a batch-oriented architecture on their side. The SHINES side is architected to support that, but more rapid message handling essentially involves a configuration option in the broker, with no code changes need on the SHINES side.

In summary, the outgoing messages will be handled by basic inserts into new database tables that other applications can subscribe to. The SHINES application code writes out messages to the table; therefore, there is no performance impact to the live SHINES application if there are delays relaying a message out to the SMILE application in Carrolton. SHINES will be creating records in real-time. Incoming messages will be processed in real-time via web service invocations that will hook into the SHINES Enterprise Java Bean layer.

Prior to initially rolling out the SMILE interface, a conversion effort (to be documented by the conversion team) will load into SACWIS existing, active, approved Vendors from SMILE. Client information should be synchronized as well (client definition will come from IDS/CPRS, but Person IDs from SACWIS need to be loaded into SMILE for reference purposes).

Below is an Entity Diagram for the outbound tables used by this interface.

Added new column ID_CLIENT_PREV to CLIENT_OUBOUND in the below Entity Diagram

Hardware/OS: HP-UX on HP Hardware

Programming Language: C

Database: Informix

Transactional Monitor: N/A

Physical Location: SMI in Carrolton, GA

Current Interfaces: Batch text files

Protocols: Secure FTP

Expected Volume of Transactions: TBD

The Resource Retainer will add a new resource to CAPS_RESOURCE. Regional Accounting Staff will define a SHINES contract for that resource if it is a resource that needs to be paid. Once the SHINES contract is defined, that resource (or vendor) will be added to the OUTBOUND_VENDOR table for sending to SMILE. For Foster/Adoptive homes, once they get full approval, they will be added to the OUTBOUND_VENDOR table.

The updating of the OUTBOUND_VENDOR table will happen in real-time via Java code. So contracted/approved resources will be available to be sent to SMILE immediately. The web Methods broker at GTA will use a JDBC driver to query the OUTBOUND_VENDOR table on a scheduled basis. Due to SMILE’s daily batch architecture, the vendor records may only be picked up by the broker a few times a day, or hourly. However, due to the fact that SHINES populates this table right away, the pickup time could be scheduled more often once the SMILE architecture can process updates more frequently. While it will still be asynchronous in nature, it can in the future be very fast.

The table for publishing Vendor information does not contain “SMILE” in the table or field names. It is a generic mechanism that has a field that can specify the target system, but this table could be used by future interfaces that require receiving Vendor information from SHINES.

This message contains a resource that was added/approved. The vendor data is used by SMI to add or update the vendor profile, so that when an invoice arrives for that vendor, SMI knows how to pay the vendor.

Newly added/approved resources that need to be paid are inserted into the OUTBOUND_VENDOR table at the time of approval, within the same transaction that updates the SHINES core tables. The web Methods broker will poll this table with the JDBC adapter for Oracle looking for records that need to be sent or resent based on INTERFACE_STATUS field. When the broker has picked up the message, it changes the INTERFACE_STATUS to picked up, and updates the DT_PROCESS field. When the message has been delivered to SMILE, the INTERFACE_STATUS field is updated to reflect it was sent, and the DT_PROCESS field is updated to reflect the date/time of delivery.

Error codes are written by the web Methods broker into the CD_ERROR field. The broker is responsible for retries, and if needed, emails are sent by the broker to administrators to notify them of problems in this interface.

If a field in a record to be extracted has a validation error, that row will be skipped; CD_ERROR and DT_PROCESS updated, and an email should be sent to the application administrators by the broker.

The broker should update CD_ERROR and DT_PROCESS if possible. Regardless, the broker should send an email to application administrators.

The most likely process level errors will be network and other communications errors. The interface broker will handle retries, and send emails to application administrators as needed.

Broker will be configured to scan this table. The initial configuration will most likely by hourly, but can be easily changed within the broker configuration. For testing/development, that time will more likely be 1-5 minutes.

Matching of responses to our requests will be done through the Resource ID within SACWIS and the transaction_id of the specific record. If NPI is agreed to, that can be used in some cases.

The resource page must have all mandatory fields filled out and a contract approved before it can be transmitted to SMILE. Adoptive/Foster homes must be added and *approved *before being extracted and transmitted to SMILE.

The technical process of sending new or updated clients is identical to the vendor process. In this case, when a client is first authorized to receive payment of care, the CD_SMILE_CLIENT flag in the PERSON table will be checked and updated to reflect it is ready to send, and a new record is created in the CLIENT_OUTBOUND table.

Within SHINES when a child’s Pre-Adoption stage is closed with the reason of adoption finalized a new client record will be inserted in the SHINES-SMILE Client interface table (SACWISIFC.CLIENT_OUTBOUND ) for the newly created post adoptive child which includes the SHINES Person Id of the existing, pre-adoptive child in the ID_CLIENT_PREV column.

See the Vendor technical description for more information on what follows.

This message contains the information for a client, typically a child in a case or the mother, that has been authorized to receive service/payment of care. The client information needs to be sent to SMILE to process invoices associated with services provided for the client.

Newly authorized or updated clients are inserted into the OUTBOUND_CLIENT table at the time of approval, within the same transaction that updates the SHINES core tables, including the CD_SMILE_CLIENT field in the PERSON table. The web Methods broker will poll this table with the JDBC adapter for Oracle looking for records that need to be sent or resent based on INTERFACE_STATUS field. When the broker has picked up the message, it changes the INTERFACE_STATUS to picked up, and updates the DT_PROCESS field. When the message has been delivered to SMILE, the INTERFACE_STATUS field is updated to reflect it was sent, and the DT_PROCESS field is updated to reflect the date/time of delivery.

Error codes are written by the web Methods broker into the CD_ERROR field. The broker is responsible for retries, and if needed, emails are sent by the broker to administrators to notify them of problems in this interface.

If a field in a record to be extracted has a validation error, that row will be skipped; CD_ERROR and DT_PROCESS updated, and an email should be sent to the application administrators by the broker.

The broker should update CD_ERROR and DT_PROCESS if possible. Regardless, the broker should send an email to application administrators.

The most likely process level errors will be network and other communications errors. The interface broker will handle retries, and send emails to application administrators as needed.

Broker will be configured to scan this table. The initial configuration will most likely by hourly, but can be easily changed within the broker configuration. For testing/development, that time will more likely be 1-5 minutes.

Matching of responses to our requests will be done through the Person ID within SACWIS. SMILE will use SSN or SUCCESS/CRS ID to check if the child already exists, but will also store our SACWIS Person ID for future updates.

The person detail page must have all mandatory fields filled out before it can be transmitted to SMILE. Initially, the person must be a primary who has transition into the Investigative stage. An update will be sent once CRS Id and Medicaid numbers have been obtained.

Once an accounting representative approves an invoice, each line item on the invoice will be added as a separate transaction in the OUTBOUND_INVOICE table. It is important to note that the SMILE accounting system handles invoices at the vendor level, not the combination of vendor and child as SHINES does. So SMILE has no understanding of a SHINES invoice; therefore, the two systems are interfacing at the line-item level.

While an approval of an invoice will result in the record being written to OUTBOUND_INVOICE in real time, there is a batch process that runs nightly involved in invoice processing. When a user creates an invoice manually or one is generated by the system, a batch process examines the submitted invoice, and approves/rejects line items. After this process has completed, an accounting representative may give their approval. The point is that one cannot create a new invoice and send it to SMILE it real-time. The invoice batch process must run before final approval (and sending to SMILE) can occur. This is especially important in recognizing that SHINES as it is today cannot send an immediate “emergency” invoice to SMILE in real-time, or even in that same day.

An invoice is generated to pay a vendor for a service provided to a person in a DFCS case. While the most common invoices are automatically generated (foster parent payment), invoices are generated for a variety of services, for both children in foster care and families needing services. An invoice contains an invoice ID, vendor information, client information, and the amount of the invoice. Also include is the client’s per diem rate and monthly rate, along with a policy waivers that are in place that affect the invoice.

The following section describes the rules and mappings for processing inbound invoices. It describes how to populate invoice, service details, case budget limits and county budget limits values

Outline:

Key functionality

Updates to DELVRD_SVC_DTL

Updates to INVOICE

Updates to RESTRICTED_FUNDS

Updates to COUNTY_BUDGET_LIMIT

Updates to CASE_BUDGET_LIMIT

Follow Up Items

Enhancement Note

Key Functionality

For Georgia SHINES, data will be both sent and returned on an invoice line item basis. The SHINES SMILE return interface operates in the following manner:

The normal processing will be for all line items on an invoice to be paid nearly simultaneously and usually from the same check number.

Invoice validation is performed in SHINES, therefore the number of line items not paid after being sent to SMILE should be extremely small to zero

The amount paid for any line item returned is the correct amount for that line item – i.e., if SMILE resends a line item for any reason, they will send the correct total for that line item, not the delta.

Based off of this behavior, SHINES will perform the following actions:

On receipt of the first line item, the overall SHINES invoice phase will move to paid, with the expectation all line items are paid (even if some of the information is coming in following transactions)

The check number for line items should be the same – so we will just save the first check number returned

Updates to DELVRD_SVC_DTL:

Based off the invoice inbound record – find the correct DELVRD_SVC_DTL where

Inbound invoice transaction number = INVOICE_OUTBOUND. ID_INVOICE_OUTBOUND

Inbound invoice number = DELVRD_SVC_DTL. ID_INVOICE (will

only be true for one or the other)

INVOICE_OUTBOUND.ID_LINE_ITEM = DELVRD_SVC_DTL.ID_SVC_

For the correct record in either table, set the new columns

AMT_SMILE_PAID = interface paid

NBR_CHECK = interface check number

DT_PAID = interface payment date

If the AMT_SMILE_PAID was not formerly empty, then this is an updated inbound transaction – move the previous amount into a working variable for the next step.

Set the invoice phase to either paid, void or cancelled: INVOICE.CD_INVO_PHASE – ‘PAD’, ‘VOD’,’CAN’

If the check number is not already populated, move the check number into the “warrant” number field INVOICE. NBR_INVO_WARRANT

If the date of payment is not already populated, move the date to INVOICE. DT_INVO_WARRANT_DATE

Increment the overall amount paid on the invoice by the new AMT_SMILE_PAID for the line item MINUS the previous amount for the line item if it existed. Normally, we can just add AMT_SMILE_PAID, but including the working variable allows us to handle any updates to the amount paid for a line item. The total should be stored in INVOICE. AMT_INVO_WARRANT.

If the returned line item maps to a DELVRD_SVC_DTL line item, update

RESTRICTED_FUNDS.AMT_CHECK_BAL = interface checking balance

RESTRICTED_FUNDS.AMT_SAV_BAL = interface savings balance

Where RESTRICTED_FUNDS. ID_PERSON = DELVRD_SVC_DTL. ID_SVC_DTL_PERSON

Note: If the month is January-June, the fiscal year equals the calendar year. If the month is July through December, the fiscal year is one more than the calendar year – i.e., an invoice for August, 2007 is a part of fiscal year 2008.

For each line item which for which payment information is returned –

If a row in COUNTY_BUDGET_LIMIT can be found where:

INVOICE.,CD_INVO_COUNTY

The GA state fiscal year determined from DELVRD_SVC_DTL.MO_SVC_DTL_SVC_MONTH