On a successful POST the ‘IncidentID’ and ‘IncidentReferenceNumber’ are returned. The ‘IncidentID’ must be included for any PUT or GET requests as part of the URL. The incident report can be resubmitted with changes the ‘PUT – Incident’ end point if the department has withdrawn the incident report (DHHS Incident report status = ‘Withdrawn’). The ‘IncidentID’ supplied on a successful POST must be supplied in the PUT URL. The incident report status and withdrawal information can be retrieved using the ‘GET – incident’ end point. This data can be useful to gauge the progress of the incident report in the department. The ‘IncidentID’ supplied on a successful POST must be supplied in the GET URL. Figure - Example of a successful response Figure - Example of an unsuccessful response API entity list (POST/PUT - Incident) The following table lists all of the Data Fields that belong to the CIMS Incident API entity when creating/updating an incident report. The data entity list for the POST/PUT is the same however the URL for the PUT contains the unique ‘IncidentID’ so the system which incident report is being updated. to section 3.5 for a detailed description of the Incident reporting data fields. Data from Service Provider/s externalIncidentId reportedDate referenceVersion Incident Report - organisationName Incident Report - organisationAddressStreetNumberAndName Incident Report - organisationAddressSuburb Incident Report - organisationAddressState Incident Report - organisationAddressPostCode Incident Report - dhhsArea Incident Report - program Incident Report - serviceType Incident Report - incidentDate Incident Report - incidentDateAccuracy Incident Report - incidentTime
When sending a PUT request to any of the /api/followups/…/recommendation endpoints, the reference version number needs to be the same that was used when the recommendation was first created with the POST request. A Follow-up recommendation should only be submitted once using the ‘POST’ end point. When submitting an investigation recommendation, all clients that exist in the related incident report must be specified, together with their “investigated” status. The clients on the investigation recommendation will be matched to the clients on the related incident report by use of the “SourceSystem” and “SourceSystemId” fields as the key. On a successful POST the ‘dhhsFollowUpId’ is returned. This must be included in the URL for any PUT or GET requests. This ‘dhhsFollowUpId’ must also be included in the URL when submitting outcomes through the relevant outcome endpoints. The follow-up recommendation can be resubmitted with changes using the relevant ‘PUT’ endpoints if the department has withdrawn the follow-up recommendation (DHHS Follow-up status = ‘Rec Withdrawn’). The ‘dhhsFollowUpId’ supplied on a successful POST must be supplied in the PUT URL. The Follow-up status, dates and withdrawal information can be retrieved using the ‘GET’ end points. This data can be useful to gauge the progress of the follow-up recommendation in the department. The ‘dhhsFollowUpId’ supplied on a successful POST must be supplied in the GET URL. Figure 5 - Example of a successful response Figure 6 - Example of an unsuccessful response API entity list (POST/PUT – Investigation recommendation) The following table lists all of the Data Fields that belong to the CIMS Follow-up API Entity when creating/updating a follow-up investigation recommendation. The data entity list for the POST/PUT is the same however the URL for the PUT contains the unique ‘dhhsFollowUpId’ so the system which investigation recommendation is being updated. to section 4.7 for a detailed description of the Incident follow-up data fields. Data from Service Provider/s externalId incidentId referenceVersion Recommendation Data Recommendation Data - investigationType Recommendation Data - jointInvestigationManagerGivenName Recommendation Data - jointInvestigationManagerSurname
The Follow-up outcome can be resubmitted with changes using the ‘PUT’ /api/followups/…/{id}/files endpoint until the department accepts the outcome, or if the department has withdrawn the follow-up outcome (DHHS Follow-up status = ’Outcome Received’, ‘Outcome On Hold’, ‘Outcome Withdrawn’). The ‘dhhsFollowUpId’ supplied on a successful PUT will be the same that has been supplied on the relevant recommendation. The Follow-up status, dates and withdrawal information can be retrieved using the ‘GET’ end point. This data can be useful to gauge the progress of the follow-up outcome in the department. The ‘dhhsFollowUpId’ supplied on a successful PUT must be supplied in the GET URL. NOTE: Only the outcomes for investigations and root cause analysis need to be submitted to DHHS. Case review outcomes are not submitted. Figure 7 - Example of a successful response Figure 8 - Example of an unsuccessful response API entity list (PUT – Investigation outcome) The following table lists all of the Data Fields that belong to the CIMS Follow-up Outcome API Entity when creating/updating a follow-up Investigation outcome. Refer to section 5.5 for a detailed description of the Incident follow-up data fields. Data from Service Provider/s externalId Client - sourceSystem Client - sourceSystemId Client - primaryOutcome Client - secondaryOutcome Client - primaryTheme Client - primaryThemeAction Client - primaryThemeDueDate Client - primaryThemeSecondaryAction Client - primaryThemeSecondaryDueDate Client - secondaryTheme Client - secondaryThemeAction Client - secondaryThemeDueDate