.png?width=714&height=129&name=Social%20Icon%20(2).png)
A Case Study for Serverless Patient Information Systems
Licensed via Adobe Stock
When a colleague of mine invited me to consult on a new app concept for a pharmacy, I was a little hesitant. I knew nothing about pharmacies outside of what I saw at your average shop. Much like any other retailer, they had customers, inventory, subscription cards, and a need for a web presence. The pharmacy would also maintain a health management portal where patients and their health care providers could interact. In short, the solution would be a patient management portal with a few commerce-like features. It would be a challenge and a great opportunity to introduce a fully serverless enterprise solution. I told them I was in.
Patient Sharing
It’s not what you think. Well, it is, to a certain degree. All healthcare practitioners share patients. What they do not share, at least without a patient’s consent, is patient data. By law, sharing patient data without consent is strictly prohibited. In the portal, patients have access to all of their health care providers in one spot. They would be able to schedule appointments and submit prescription notices to their pharmacy group. Most healthcare providers are connected digitally nowadays. While these portals provide patients access to their digital health records, they leave out the pharmacy and prescription fulfillment aspects. The owner of this particular patient portal wanted both sides of the house and we were keen to make it happen.
Law Abiding Solutions
All patient data is protected by law. Improper management or dissemination of this data may lead to hefty fines and criminal penalties. The onus is on the technologists to provide avenues in which healthcare providers may collect and disseminate patient data in a safe and permitted manner. On a national level, patients are protected by the Health Insurance Portability and Accountability Act, HIPAA for short. Healthcare providers and healthcare technologists are bound by the privacy, security, and breach notification policies in place.
HIPAA compliant cloud storage and database implementations should be one of the first items on everyone’s checklist when implementing an online patient portal. For our cloud-managed DB solution, we opted for MongoDB. It is important to note that like all cloud services, it is a shared responsibility between the cloud service provider and the customer to maintain HIPAA compliance. There is no official HIPAA compliance certification recognized by the US Department of Health and Human Services (HHS). For more information, visit the MongoDB HIPAA information page.
Security is a concern with any web portal, but patient portals are especially tricky. The mobile and web applications would directly link to cloud services for user authentication. They would also interact with serverless services such as the respective health care provider service, user management service, and e-commerce service. The lockdown of services would involve the interaction points and the users themselves.
For interaction points, OAuth JWT flows were used for authentication between the apps and serverless services. Production and development/sandbox instances were split by authorization groups to prevent accidental prohibited data exchange.
User interaction was limited by whether or not they were signed in and their respective roles. They were able to search for drug information, access the prescription discount cards, and search for healthcare providers, but all private information and e-commerce features were hidden behind the login. As an added measure, user permissions and roles were enforced to where only healthcare providers may search for patients within their subscribed practice and users marked as patients were the only ones permitted to submit prescriptions pending a prescription order from a physician.
As is required, all traffic in production instances was with HTTPS, the database encrypted, and all PII was obfuscated in logging. This app was restricted to the United States and so full GDPR considerations were postponed at the time.
High-Level Architecture
The web and mobile clients interact with the API gateway, notification service, and auth service directly. The APIs are individual serverless services deployed and are what bridge several third-party API queries and DB query results and into a common format for the clients.
Some features of the solution were obfuscated for brevity and to adhere to contract regulations. In the diagram above, you see we isolate the business logic within functions or lambdas and those services leverage the peripheral cloud services to bring everything together.
Unveiling the Costs
Developers shy away from solutions that have unknown costs and they should. No one likes hidden fees, their clients doubly so. With any serverless solution, it is important to establish the number of requests per service per use case. For setups that contain EC2s, the above setup could become expensive depending on tiers selected for storage and compute resources. With the above setup, the most expensive part is the database as data retention is required for records for a certain amount of years.
For those that don’t know, each cloud service provider gives a number of requests free per month for a number of services. Every subsequent batch of calls is billed at less than a dollar per batch. This remains true for functions/lambdas, the queueing service, and a few others. Every use case counts in the cost analysis. Cloud service providers will have their own respective price tables for these services. Every interaction point in the architecture will have a price point per request or storage limit.
Final Thoughts
It’s important to consider the pros and cons of all solutions. The specific use cases within this project coupled with the projected usage per healthcare provider allowed us to move forward with a serverless implementation. Cost-wise, it was a no-brainer. Something to consider is that lambda service commitment is reported with at least 99.95 percent uptime and Google cloud functions SLA is reported with at least 99.5 percent uptime. Clients interacting with these services will need to account for retry logic in the case of a down period. There are limitations in storage and other services as well. These are all factors to consider in your serverless implementations.
For those starting off on their Serverless journey, I’ve put together a bite-size book covering the initial project creation all the way through testing and automated integration and deployment in Building Serverless Node.js Apps on AWS.
