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 end point. ‘POST’ When submitting an investigation recommendation, all clients that exist in the related incident report must be specified, together with their status. The clients on the investigation recommendation “investigated” will be matched to the clients on the related incident report by use of the and “SourceSystem” fields as the key. “SourceSystemId” On a successful POST the is returned. This must be included in the URL for any PUT ‘dhhsFollowUpId’ or GET requests. This must also be included in the URL when submitting outcomes ‘dhhsFollowUpId’ through the relevant outcome endpoints. The follow-up recommendation can be resubmitted with changes using the relevant endpoints if ‘PUT’ the department has withdrawn the follow-up recommendation (DHHS Follow-up status = ‘Rec Withdrawn’). The supplied on a successful POST must be supplied in the PUT URL. ‘dhhsFollowUpId’ The Follow-up status, dates and withdrawal information can be retrieved using the end points. This ‘GET’ data can be useful to gauge the progress of the follow-up recommendation in the department. The supplied on a successful POST must be supplied in the GET URL. ‘dhhsFollowUpId’ 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 so the system which investigation recommendation is being updated. ‘dhhsFollowUpId’ 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
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
Application%20programming%20interface%20specification%20%28CIMS%29.docx