Event Trigger Script Processing

Introduction

This specification is about adding the ability to create billing wizards for the event system.

The goal is that a user for create and publish an event form. Then the user will select from the published event forms which one is the active one (like they do for the enquiry form).

Then users with can select events from the patient record and run the chosen even form. This event form will need to have trigger scripts written to be able to do anything with the events. He before trigger script will allow the user to setup the form, and the approve script will allow them to process the selections in the form to create invoices and mark the services as billed.

This spec details how this is to be achieved.

The primary changes are:

●    Change in display of events to enable easier interpretation

●    Ability to define a form for processing events

●    Ability to select unbilled services and execute the predefined trigger script and form

Intelligent Form

The ability to define a form to use processing events.

Add "Event" as a type when creating new assessments. These behave different to normal assessments. They have combined behaviour aspects of the Enquiry type an the Express Forms in the following way.

●    Like Enquiry forms they are not assessable to be created or processed via the assessment screens on a patient record.

●    Unlike Enquiry form an Event form must be a patient form.

●    Like an express form the event form is not saved to the patient record until it is successfully approved.

Event Config

Add global configuration that allows the user to set (and remove) a published event form to user for event billing. (This is how it is done for enquiries http://cr.test.clintelsystems.com/admin/enquiries ). Create a setting like this for Events.

Patient Event List

The patient event list ( http://cr.test.clintelsystems.com/patients/4/events ) shall be changed to display the events in panel list rather than a grid view. The below is a suggestion

The key requirements are:

  • User can select which services, across multiple events, they wish to have processed by the select event form. There is a "Invoice Selected" button at the top of the screen that will run the form (and trigger scripts) passing the list of selected services to the trigger scripts.
  • The user can elect to run the form against a specific event by select "Invoice" button on that event. The system will run the form passing in the unbilled services from that event. 
  • Service already billed, or not billable, cannot be selected.
  • If an Event has no unbilled services then there is no Invoice Button.
  • The "Invoice Selected" button must handle edge cases like no selections meaningfully to the user (e.g. descriptive error message or disabled state)
  • The event screen starts sorted with oldest events first and only unbilled events visible.

If the user has not configured a Event form in the global config then no checkboxes or invoices buttons should be displayed.

The display of the date times for an event should be intelligent:

  • Always display the start date and time.
  • Only display the end date and time if the date is a different date to the start date.
  • Display the duration of the event only if end date time if different to start date time. (Some events are recorded as zero duration).
  • Display the duration in a human readable format. (E.g. "20 Mins", "3 hours 15 mins") do not display seconds.

Translations

The text to use for the "Invoice Selected" and "Invoice" buttons shall be translatable using the existing method CareRight uses for translations.

Running an Event Form

Once the user initiates the event form the systems needs to :

  • Provide an array of the selected services to the trigger script.
  • Run the "before creation" trigger script.
  • Display the event form

The user can then interact with the event form as designed by the builder of the form. The only option is to 'Approve' or 'Cancel' the form cannot be saved for later. If the form is cancelled then nothing should be persisted to the database. 

If the form is approved then the 'After Approval' script is run. If no errors are raised then the changes created by the script and the form are saved to the database. The form is saved as archived and then available in the archived section of the patient assessments screens.