top of page
Search
  • Writer's picturePeriscope News

Lessons Learned from the Periscope API with DHHS Incident Reporting System

​The Victorian Department of Health and Human Services (DHHS) has implemented a new Client Incident Management System (CIMS) that went live on 15 January 2018. The focus of CIMS is the safety and wellbeing of clients and applies to DHHS funded organisations and Victorian-registered NDIS providers of disability and psychosocial supports. CIMS replaces the previous fax-based reporting system. The Tipping Foundation (Tipping) uses Periscope’s Incident Management System (PIMS) for reporting all incidents affecting Tipping staff and clients (including DHHS clients). In order for PIMS to exchange data with CIMS, an application programming interface (API) was developed by Periscope in partnership with Tipping and support from DHHS staff. A summary of the scope of Periscope’s API and some of the key lessons are provided below. What were the objectives of the API? The objectives of the API were to:

  1. Lodge incidents from Tipping Foundation’s PIMS to CIMS

  2. Enable PIMS and CIMS to exchange data at various stages of the incident reporting, review and investigation workflow

  3. Enable timely exchange of information between DHHS and Tipping.

Scope of the project The scope of the project included the development of 16 unique APIs, with each API completing an individual transaction between PIMS and CIMS. Broadly the APIs covered:

  1. Data from PIMS being transmitted to CIMS at various stages of the workflow for major Incidents

  2. Data from CIMS being transmitted to PIMS at various stages of the workflow

  3. The ability to upload a client investigation report from PIMS to CIMS

  4. The ability to bulk upload non-major incident records at the end of the month. This is done through an automated process that runs at the end of the month.

Lessons learned

  • Form building and validation – the original PIMS form used by Tipping was retired and replaced with a new Incident report that supported the new DHHS policy, APOI requirements and internal Tipping requirements. to CIMS being in place needed a major rework based on the specific field and field validation requirements specific by DHHS.

  • Data Validation - Each CIMS API is highly specific so if the data submitted does not meet the specific requirements, the transaction is rejected. To exchange data between two systems in real time the precise nature of the data is paramount.

  • Process Alignment – CIMS expects specific data sets to be submitted based on agreed workflows that support DHHS policy. This means data exchange must also be timely as well as precise.

  • Currency of documentation – the CIMS documentation was evolving throughout the project implementation as the API requirements were developed, so it became necessary to check the documentation on a regular basis. Some initial errors occurred due to differences between the staging and production environments

  • Error handling within CIMS system – some data transfer errors were difficult to determine as to what caused them, as the error handling for these specific errors weren’t in place. As the system evolved, the error handling improved enabling our client and us to self-correct. It was also important that users were not confronted with highly technical errors, as they would be uncertain how to understand and respond to these errors

  • Error handling within Periscope – Periscope updated its error handling information to provide greater detail as to the reason a record could not be transmitted to CIMS. Error handling has also evolved as every type of error was difficult to test for in such a large and complex system that was rapidly changing

  • Record audit history - Periscope has a detailed record audit history which made the diagnosis of any issues or confirmation of system transactions highly efficient

  • Agile environments - Both PIMS and CIMS were developed in highly agile but separate environments, so it was inevitable that some issues would arise. However, the ability for both systems to be updated in near real time ensured that no extensive delays were experienced.



bottom of page