# Serverless Architecture

## Scenario

As patients book appointments, they will book via a publicly accessible website. This will need a custom domain, certs, and the ability to version with zero downtime. The website needs to be able to communicate with a home-grown system that is currently on-premises to get scheduling information (REST API, at a private address like http://192.168.10.10). They do not want to move the on-premises system at this stage, but the website will need to access it to pull information. The customer does have some concern if the patient booking website could overwhelm the legacy system with too many requests.

After booking an appointment, an automated process needs to kick off to prepare the patient for their appointment.

Before check-in, patients need to upload a few different documents to the patient portal.

* Identification
* Insurance policy
* Payment information

Each of these 3 things can be uploaded separately, but must all be uploaded before the visit.

The system should be able to remind a patient if they have an appointment within 24 hours and don’t have the required documents.

Once all 3 documents have been uploaded, a stored procedure needs to be executed in a SQL Server (on-prem) to complete the registration process.

This customer wants to optimize for low cost and low overhead. They realize it may not be entirely "consumption serverless" but would like low cost for compute and data where possible.

### Assumptions that can be made
The intent of this workshop is to explore and discuss architecture patterns around serverless. It's not a real-world simulation and test. While we are using healthcare as an example, don't worry to much about the complexity of cloud requirements specific to healthcare. This is a very forward thinking healthcare company. :smile:

You can also make certain assumptions as needed. For example, how does Azure connect on-premises? It's safe for you to assume things like they already have an ExpressRoute configured (or that they would be willing to). Don't make it too easy, but also don't make it too hard.

## Key questions after proposed architecture
- What are the main benefits the customer would get from this approach?
- Based on the tech you chose, are there any constraints (scale, security, flexibility, features, etc.) that are worth noting?
- Are there any additional capabilities or features we could also propose to this customer to delight their patients or enable them to operate their business better?

## Extra Credit

a. Take the above solution and make any necessary adjustments for it to be highly available across regions (safe against a regional outage)

b. Include solving for the following scenario

As patients come into the hospital for their appointments, they hit a few key stages:

1. Check in at the desk and wait for a nurse
2. Nurse takes them back to wait for the dr.
3. Dr. treats patient
4. Patient checks out at the front desk

For each patient, the hospital wants to track each one of the stages. They want to be able to process these events in real time and drive reports on how long customers generally have to spend at each step in the process. How would you recommend the hospital gets those events sent? How could you process them and generate a weekly report of patient throughput / bottlenecks? Would real-time alerting be possible? (e.g. a patient has been waiting for treatment for longer than 15 min)

## Potential Docs for Help
* App Service Networking Options - https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet
* Azure API Management - https://docs.microsoft.com/en-us/azure/api-management/api-management-using-with-vnet
* Logic Apps Batch Trigger - https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-batch-process-send-receive-messages
* Azure Durable Functions - https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp