### Service Request API ###

Purpose of this documentation is to describe what has been implemented and what is still needed to integrate the Chiasm with Availity API - service request.

### Needs and Expectations ###

* When referring a patient to another doctor, the referring physician may consult the health plan if the patient can be consulted by the desired physician/clinic.
* When a patient is referred to a doctor on the platform, he can consult the health plan himself by sending it to Availity.
* When a patient is referred to another physician, and the Availity has been consulted, the page (inbox) should show a flag indicating that the health plan has been consulted.
* When a request to Availity is made, the request must be saved for later consultation of the result (authorized, when closed, or needs adjustments).
* When we consult the request made previously, and adjustment is necessary, the doctor can make adjusts and then resubmit to Availity/Health Plan.
* When the request for Availity is complete, this information must be present in the page (inbox) list and in the detail page with more details.

We surveyed all health plans that Availity has integration with, and together with Giannie we defined that we will have integration with 55 health plans on the platform. Therefore, although we have 500+ Health Plans registered at TheChiasm, so just a few can/should have this integration.
So, we must inform the user (doctor) at the time of patient referral.

### What's up so far? ###

- [x] Creation of the necessary structure for integration with Availity.
- [x] Refactored the referral, adding repository and entity, mapping behavior into class.
- [x] Refactored the patient, adding repository and entity, mapping behavior into the class.
- [x] Refactored the upload and file, adding repository and entity, mapping the behavior into the class.
- [x] Refactored the office, adding repository and entity, mapping behavior into class.
- [x] Refactored the appointment, repository and entity, mapping the behavior into the class.
- [x] Refactored the referral handler to facilitate integration with Availity.
- [x] Refactored the doctor, inclusion of some fields when referring a patient.
- [x] Refactored the diagnostic, entity added, mapping behavior into class.

- [x] Adjustments and addition of new manufacturing fields to integrate with Availity
- [x] Script and necessary adjustment in the reference table to receive new fields, and Availity reference on request, including the Request Review Status.
- [x] Added field: Location of Service - based on this field, the health plan may require other fields in the request.
- [x] Added field: Gender - required by some health plans.
- [x] Added doctor's specialty code to office structure - required by some health plans.
- [x] Added the result of the request with the results: Success, Info, Warning or Error (when an error occurs, indicate what adjustments may be necessary).
- [x] Added new tab in the detail page indicating the result or resubmit option if was not sent previously.
- [x] Added state VOs structure to map name to state codes, mandatory by Availity (eg AL -> Alabama).
- [x] Added script to add taxonomy_code to specialties table - required by Availity.
- [x] To add this information we had to map all specialties to a taxonomy code, this was done via script.
- Must run in production.
- [x] Added script to add code (Availity reference) to the Chiasm Insurances, this information is necessary by Availity to identify the health plan.
- Must run in production.

- [x] Service Request API Integration.
- [x] Integration with Availity Authentication API.
- [x] Addition of structure to store authentication token in temporary files.
- [x] Availity API integration using demo endpoints.
- [x] Ability to test in develop mode (locally).
- [x] Integration with Availity API for Service Request creation.
- [x] Added structure to validate the data before submitting to Availity.
- [x] Integration with Availity API for Service Request query.
- [x] Structure needed to show the status of the request.
- [ ] Integration with Availity API for Service Request update.
> Integration with demo endpoints: with this endpoint in request formulas, and deployment settings for all endpoints/screen

### What's still needed to complete? ###

In order to communicate with the 55 health plans, we must need to understand the requirements of each and to do that the easiest way is to integrate with the **[Configurations API](https://developer.availity.com/partner/documentation#configurations)**.
By integrating with **Configurations API** we are going to be able to create the form dynamically, mount the options (select), validate the payload, and understand the requirements for each health plan before sending it to Availity through **Service Reviews**.

- [ ] Integrate with Configurations API.
- [ ] Create the html form dynamically - This may change a lot in the form already defined with Giannie.
- [ ] Create all the fields required with its specefic validation.
- [ ] Consult the select options and display in the form.
- It will require to recreate the whole form and may not be able to work with the existing one.
- [ ] Validate the payload with the configurations retrieved by Configurations API.
- Refactored the struct created previously using the configurations retrieved.

> Validate Configurations API response, in some cases the links referenced in the response does not work. We may need to validate with someone from Availity.