Consumer health portal on Azure

API for FHIR
API Management
App Service
Application Insights
Active Directory External Identities
Blob Storage
Blueprints
Cosmos DB
Front Door
Functions
IoT Hub
Key Vault
Notification Hubs
Azure Role-based access control
Web Application Firewall
Office 365
Synapse Analytics

Throughout the health and life sciences industry, organizations are adopting a digital health strategy. One of the core pillars and a necessary component of a digital health solution is a consumer health portal. A consumer health portal may be used for tracking progress and statistics from a wearable device, engaging with a medical provider, or even tracking healthy eating habits. This article describes a typical architecture of such a portal, that aligns with the pillars of the Azure Well Architected Framework. You may choose to customize this architecture to meet your particular needs.

Potential use cases

  • Track statistics of a wearable device.
  • Gain access to medical records and engage with a medical provider.
  • Enter times and doses of medications, which can be used for refill data or self-tracking of medications.
  • Interact with a healthy eating coach for weight loss or diabetes.

Architecture

Consumer health portal architecture

This solution leverages the global footprint of Azure Front Door and edge security features of Azure Web Application Firewall (WAF) to authenticate the inbound data. The authenticated data is then routed by Azure API Management (APIM) to either the front-end interface for the users on the Azure App Service, or APIs hosted in Azure Functions.

The primary backend data service used in this architecture is Azure Cosmos DB. The multi-model abilities of Cosmos DB, in addition to its scalability and security, allow flexibility for any type of consumer health portal. Any data that is not in a record format is stored in Azure Blob Storage as an object. This could include data such as, medical images, photos taken by the consumer, uploaded documents, archived data, and so on. Blob storage provides an affordable storage for large volumes of unstructured data. Such type of data is not optimized for storage in CosmosDB, and can negatively impact its cost and performance.

Components

  • Azure HIPPA HITRUST 9.2 blueprint is an Azure blueprint that uses Azure Policy. It helps assess HIPPA HITRUST 9.2 controls and deploy a core set of policies for Azure workloads. While this does not give full compliance coverage for HIPPA HITRUST, it is a great place to start and add additional controls where applicable and necessary. Compliance with the policy initiatives can also be visualized in this blueprint as well as in Azure Defender.

  • Azure Front Door is used to manage at-scale edge traffic, and to increase performance for end users by presenting endpoints all around the world. This is a cloud-native technology which doesn't require any licensing; you only pay for what you use. In this workload scenario, Azure Front Door serves as the ingress point for all traffic to the consumer health portal.

  • Azure Web Application Firewall protects applications from common web-based attacks such as OWASP vulnerabilities, SQL injections, cross-site scripting, and others. This is a cloud-native technology which doesn't require any licensing and is pay-as-you-use.

  • Azure API Management aids in the publishing, routing, securing, logging, and analytics of APIs. Whether the API is only being used by the end-user or integrated with a third party for external interoperability, API management allows for flexibility in how APIs are extended and presented.

  • Azure App Service is a service used to host HTTP-based web services. It supports a wide array of languages, can run on Linux or Windows, fully integrates with CI/CD pipelines, and can even run container workloads as a PaaS offering. App Service allows for both scale-up and scale-out, in addition to having native integration with identity, security, and logging services in Azure. It is able to meet the scaling needs of the consumer health portal while maintaining compliance. In this architecture, it hosts the front-end web portal.

  • Azure Function Apps is a serverless platform solution on Azure that allows developers to write compute-on-demand code, without having to maintain any of the underlying systems. In this architecture, Azure Functions can host APIs, and any work that needs to be done asynchronously, such as running periodic jobs and computing statistics over a certain period of time.

  • Azure Cosmos DB is a fully managed, multi-model, NoSQL database offering that offers single-digit response times, and guarantees performance at any scale. Each user in the consumer health system will have only data related to themselves, which justifies the use of a NoSQL data structure. Cosmos DB has nearly limitless scale, as well as multi-region read and write. With the drastic growth of the amount of data collected by these types of consumer health systems, Cosmos DB can provide appropriate security, speed, and scale, regardless of whether there are 100 or 1,000,000 active users.

  • Azure Key Vault is an Azure native service used for securely storing and accessing secrets, keys, and certificates. Key Vault allows for HSM-backed security, and audited access through Azure Active Directory integrated role-based access controls. Applications should never store keys or secrets locally. This architecture uses Azure Key Vault to store all secrets such as API Keys, passwords, cryptographic keys, and certificates.

  • Azure Active Directory B2C provides business-to-consumer identity-as-a-service at massive scale, the cost for which scales along with your active user count. In consumer-facing applications like this solution, instead of creating a new account, users may want to bring their own identity. It can be anything from a social ID, to an email account, or any SAML provider identity service. This provides an easier onboarding experience for the user. The solution provider only needs to reference the user identities, and does not need to host and maintain them.

  • Azure Log Analytics, an Azure Monitor Logs tool, can be used for diagnostic or logging information, and for querying this data to sort, filter, or visualize them. This service is priced by consumption, and is perfect for hosting diagnostic and usage logs from all of the services in this solution.

  • Azure Application Insights, another feature of Azure Monitor, is the native Application Performance Management (APM) service in Azure. It can be easily integrated into the front-end App Service, and into all of the Azure Functions code to enable live monitoring of the applications. Application Insights can easily detect performance, usability anomalies, and faults directly generated from the applications themselves, and not just from the compute platform hosting them.

  • Office 365 Email is an industry-leading service used for email and communications. Many organizations have already invested in this service. In this solution, it can be used for sending out any emails related to the consumer health portal, such as appointment confirmation or reminder emails.

  • Azure Notification Hub is a simple and scalable push notification engine that enables the ability to send notifications to any mobile platform. A consumer health portal leveraging a mobile app, can integrate with Azure Notification Hub for a cost-effective way to push notifications to users who have installed the app on their mobiles. In this architecture, notifications can be sent to remind users of their appointments, to enter information for disconnected devices, to reach certain health goals, and so on.

  • Azure Defender is the core of security monitoring and posture management for this entire cloud-native solution. Azure Defender integrates with almost all major services on the Azure platform. Its capabilities include security alerts, anomaly detection, best practice recommendations, regulatory compliance scores, and threat detection. In addition to HIPPA/HITRUST compliance monitoring, and overall Azure Security best practice monitoring, this solution uses the following:

Alternatives

  • Twillo's SendGrid may be used as an alternative for email notifications. SendGrid has direct marketplace integration in Azure, is easy to set up, and has a free tier of email services. However, if customers already have an Office 365 subscription and if they plan on sending a large number of emails, using Office 365 integration could be a more cost effective solution.

  • Azure API for FHIR may be used for interoperability of medical records, using HL7 or FHIR communication standards. This service should be used if your application needs to receive or transmit medical records from other systems. For instance, if this were a portal for medical providers, Azure API for FHIR could integrate with the provider's electronic medical records system directly.

  • Azure IoT Hub is a service fine-tuned for ingesting device data. If the portal is the front-end for a solution which collects data from a wearable or any other medical device, IoT Hub should be used to ingest this data. For more information, read the INGEST process of the Remote Patient Monitoring Solutions architecture.

Availability considerations

This solution is currently designed as a single-region deployment. If your scenario requires a multi-region deployment for high-availability, disaster recovery, or even proximity, you may need a Paired Azure Region with the following configurations.

Security considerations

The following sections describe the security best practices for each of the services used in this solution.

Azure Front Door

Azure Front Door's Web Application Firewall (WAF) should be used to mitigate many different common attacks. A good baseline is to start out by using the latest version of the Open Web Application Security Project (OWASP) core rule sets (CRS), and then add custom policies as needed. Although Azure Front Door is designed to absorb large amounts of traffic, consider using the caching mechanisms available with this service to reduce the traffic load to the backend systems where possible. For troubleshooting and supporting potential security investigations, logging should be configured for both Azure Front Door and the Web Application Firewall. You can read more at Security practices for Azure Front Door.

Azure API Management

All traffic to APIM should be authenticated, either by using Azure AD B2C APIM authentication or with token-identified sessions. Azure API Management should also be configured to store resource logs. You can read more at Security practices for Azure API Management.

Azure App Service

All traffic to this architecture, including the App service, should be secured end-to-end with TLS. The App Service should deny insecure protocols to tighten the attack surface. Additionally, APIM should pass back the client's authentication to the App Service to allow it to validate against its own client authentication and authorization. All secrets used in App Service should be stored in Key Vault, using a managed service identity where possible. The App Service should also store diagnostic logs to support any security diagnostic efforts, and should be integrated with Azure Defender for App Service. You can read more at Security practices for Azure App Service

Azure Functions

All requests to the Azure Functions in this solution should require HTTPS, use Azure API Management to authenticate requests, and use Managed Identities where possible. Store all keys in Azure Key Vault instead of leaving them in the Function code. As with any application, make sure to validate data at input, and integrate with Azure Defender. Lastly, always configure logging and monitoring for Azure Functions. You can read more at Security practices for Azure Functions.

Azure Blob Storage

Where possible, restrict access to blob storage by using Azure Active Directory to authorize user access, and Managed Service Identities for resource access to blob storage. If these authentication types may not work for your application, use a Shared Access Signature (SAS) token at the most granular level, instead of an account key. SAS tokens are invalidated after rotating account keys.

Make sure to also use role-based access control for the blob storage. Use Azure Storage Firewalls to disallow network traffic other than that from Trusted Microsoft Services. Always integrate Azure Storage with Azure Defender and configure monitoring. You can read more at Security practices for Azure Blob Storage.

Azure Cosmos DB

Role-based access controls should be enabled for CosmosDB management. Access to the data in CosmosDB should be appropriately secured. Configure CosmosDB to store diagnostic logs for control plane operations as well as to store resource logs. You can read more at Security practices for Azure Cosmos DB.

Azure Key Vault

Requests made to the Azure Key Vault should be authenticated using Azure AD or MSI in addition to privileged access controls. Integrate Key Vault with Azure Defender in addition to logging Key Vault actions in Azure Monitor. You can read more at Security practices for Azure Key Vault.

Azure AD B2C

Use the built-in features in Azure AD B2C to protect against threats such as, denial-of-service and password-based attacks. Configure Audit Logging to allow security investigations, and to create log alerts for any threat management logs generated by B2C. You can read more at Security practices for Azure AD B2C.

Azure Log Analytics

Role-based access controls should be in place for Log Analytics to allow only authorized users to access data sent to the workspace. You can read more at Security practices for Azure Log Analytics.

Azure Application Insights

Any personal data should be obfuscated before being sent to Application Insights. Role-based access controls for application insights should also be put in place to only allow authorized users to view data sent to Application Insights. You can read more at Security practices for Azure Application Insights.

Additionally, see the Security practices for Azure Notification Hub.

Cost considerations

Pricing for this architecture is largely variable based on the tiers of services you end up using, the capacity, throughput, types of queries being done on the data, number of users, as well as business continuity and disaster recovery. It can start from around $2,500/mo and scale from there.

To get started, you can view the Azure Calculator Generic Estimate here.

Depending on the scale of your workload and requirements for enterprise functionality, using the consumption tier of Azure API Management could bring down the cost.

Next steps