HealthTech — The Doctor is (always) In
Summary — In my previous article, I touched upon what factors are important in a good healthtech solution / product. In this article, I would like to continue on the same Healthtech topic and write about how healthtech companies use technology stacks. I go from an overview of high level system requirements, to a logical architecture and finally to actual technologies that may be used including the latest cloud platform technologies today.
But, before we delve into the technical details, a quick note on the categories of companies in the Healthtech domain. Unlike some other industries, Healthtech boasts a wide variety of sub domain categories and it is due to the nature of the industry.
Do keep in mind that the categorization below is indicative, there are always healthtech solutions that span across more than one of the categories below. In reality, the combinations are endless and limited only by technology practicability and market needs. Categories will continue to evolve as the healthtech industry matures.
Here is a list of Indian companies (mostly startups) in each category. This is not a comprehensive list:
Typical Healthtech Technology Stacks:
Disclaimer: I have not worked for or with any of the companies mentioned above and hence you should not assume that the technical details below represent the actual tech stacks of these companies. The descriptions below are my own reflections based on prior experience in this domain.
I touch upon only a couple of categories / stacks for the sake of brevity. If you are interested in knowing more or knowing about the other stacks not touched upon, please drop me a message and I shall get back to you.
- Aggregators: We’ll take an example of an online retailer of medicines. A high level mind map of the various players in this ecosystem is shown below. This allows us to gain an appreciation for the Aggregator (online medicine retailing) ecosystem and the various use cases involved. And we can use it to draw up a logical architecture of the tech stack.
I’ve not included regulatory and other details so that we can focus on the key aspects. Take a look.
The architecture of such a platform can be modeled logically as show in the figure below:
The above figure shows the typical important components of the stack. Please note that this is not a comprehensive architecture simply because to discuss that requires a detailed architecture document. Each of the block above is in itself a reasonably complex system and requires careful design. Some components would be event driven, others may require ETL transforms and yet others may use a pipelined architecture. I have also not shown other needed components like load balancers, database replicators, registration components for suppliers/logistics, validation components, development, build and qa environment etc.
So, what technologies would typically be used to build such an architecture? There are many options to choose from here. On the web front-ends, it would be great to go for standard frameworks off Java, Python or .NET. They have building blocks in place (via frameworks) that allow rapid development and qa for various form factors. The technology for the integration sub systems (with the supplier and logistics’ systems) may be dictated by the available SDKs (if any). Or if the integration is off an enterprise bus, more options open up. A 3rd possibility is that those system’s make REST (or SOAP) API’s available. Again here, there are many possibilities like Java, Python, C# etc. The database instances shown above may not all be physical but partitions in a physical database. This depends on the scale and the data model. The database itself could my MySQL / MariaDB, Postgre SQL or MS SQL Server. In certain cases like recommendations (via the analytics engine), a graph database like Neo4j could be a good choice. The recommendation’s job could be to cross/up sell non drug products to the customers (based off their purchase history).
If you are hosting this system on the cloud (this should be your first option for hosting), then you need to start thinking from the perspective of the hosting infrastructure. Your focus is in driving more business, not managing your IT infrastructure.
An online retailing system would definitely benefit from some excellent building blocks available at cloud providers like AWS or Azure — they do a lot of the heavy lifting for us. Of course load balancing, redundancy and a defined SLA matching with your scale and performance goals are easier to achieve than an on premise solution.
AWS:
If you go for AWS you would probably use these building blocks: Route 53 for DNS and maybe a local CDN off Amazon S3. You may choose to have your own VPC in AWS to run all your workloads. You can spin up EC2 instances with your chosen ecommerce suite (off the shelf ecomm suites are available, or for the right reasons you can build your own) to serve the various web sites, back end server side logic and other workloads. You can use AWS CloudWatch to monitor your workloads to ensure they stay reliable. Using AWS ElasticSearch is useful to analyze your operational logs easily. Authentication and RBAC is built into AWS with the IAM service. For additional oversight from a security perspective, you can use the Detective controls available. For high scalability you would configure auto-scaling on your EC2 instances. Elastic Beanstalk is another option in case you want to seamlessly orchestrate deployment and scaling of your services. If, for example, you need low latency order fulfillment (and you do need it), order details could be saved in DynamoDB. For running small, independent and well defined workloads you can go for AWS Serverless by itself or if these are event driven, using AWS Lambda (for example, inventory changes for fast moving medicines may need an out of bound update).
Azure:
Or if you prefer to go for Azure, these could be your building blocks: Azure DNS and pull content off Azure CDN. To run workloads in a virtual private cloud you can use Virtual Network. You can spin up Azure Virtual Machine instances with your chosen ecommerce suite (again, off the shelf ecomm suites are available, or you can build your own) to serve the various web sites, back end server side logic and other workloads. You could also use Azure offerings like App Services and API Apps. You can use Azure Application Insights and Azure Monitor to monitor your workloads to ensure they stay reliable. Using Azure Marketplace’s ElasticSearch helps to analyze your operational logs (built off Apache Lucene). Authentication and RBAC is built into Azure with the Azure AD and Azure AD Premium service. For additional oversight from a security perspective, you can use the Azure AD Ops, Security Center and Azure Advanced Threat Protection. For high scalability you would configure auto-scaling on your Azure VM instances via Azure AutoScaling or use VM Scale Sets. For orchestration and deployment, Azure offerings such as App Service, Cloud Services and API Apps are a great option. For low latency order fulfillment, order details could be saved in Cosmos DB. For running small, independent and well defined workloads you can go for Azure Logic Apps or if these are event driven, using Azure Functions.
Please note that I am not associated with AWS or Azure in any capacity. The above are examples based on their current offerings and they both support many more choices.
There are many more permutations possible in both AWS and Azure (with offerings not discussed here). The general guideline is to design a cost optimized architecture (deliver business value at lowest price point) and choose proven and mature technologies.
It also prudent, during development, to try different applicable technologies and select the right one (at least for the most critical components). If you are already developing such a stack, the skills of your existing team would also determine which technologies you can play with.
One important consideration is the integration with 3rd party systems (e.g. suppliers and logistics’ systems). If their systems are on premise only, custom integrations may have to be written to ensure a seamless pipe from your infrastructure to theirs and back.
Note that all of the above are only indicative and the actual final choice depends on a lot of factors. Ultimately, you may have more than one option but a judicious pro/con analysis can help to choose one.
2. Medical Devices: As can be seen from the figure earlier in the article (discussing healthtech categories), this category is actually a catch all of many different sub-categories since there is a huge variety of medical devices (or equipment). They can be differentiated by their function, purpose, connectivity, portability and so on. Federal / Central agencies have their own classification mechanisms, usually by the risk they represent to the human body. For all these reasons, a standard definition of medical devices is difficult to arrive at.
I shall take one type out of the many for this article — monitoring devices. Here is a mind map of this particular ecosystem:
You will notice a stark difference between this mind map and the aggregators mind map.
The difference is essentially a function of the diverse category attributes of aggregators and medical devices. It is evident from the mind map that even in this sub category, there is a wide variety of devices.
The next step is to build a logical architecture. But the diversity here is wide enough at this level that a generic logical architecture, if attempted, will be too high level and of limited practical use. So, I shall become a bit more specific and now onward talk about a monitoring device that integrates with a smart phone as a 3rd party system and the smart phone in turn integrates with a cloud platform. This is also a standard embodiment of an IoT (Internet of Things) platform. As I have mentioned earlier, one of my own projects was to build and conceptualize a similar platform. The logical architecture of a Monitoring device platform can be modeled as follows:
In the figure above, the medical professional is essentially controlling the monitoring device and is doing that via their smart phone. The device itself could optionally have HMI (Human Machine Interface). The device could sync with the cloud directly or via the smart phone. Both are valid possibilities. The cloud is used for heavy duty back-end processing of the data sent to it by the smart phone or the device itself. The intent is to show actionable intelligence to medical professionals via, say a dashboard. You may have noticed that some components are a little generic. This is by design. For e.g., on the device hardware side, there are many options for the various components and next level details would change depending on the chosen components. The same applies to the smart phone app and cloud blocks too.
Let us talk a bit about some of the technologies that could be used to build this architecture. On the device side, there are a lot of options for the hardware components. You could use an ARM, PIC or Atmel micro controller, or if the device processing and functions require it, a SBC (Single Board Computer). You would typically program the micro controller in C and/or Assembly (or what ever is native for your micro controller architecture). If you have plans for a wired connection with your smart phone, you could go for the USB OTG protocol. Wireless communication could be via an ad-hoc 802.11 network or Bluetooth. I am not expanding on the other modules like the connectors, battery, power module etc for sake of brevity. On the smart phone side, you could support either iOS or Android phones (or both) and hence your technology options could range from Objective C++, Swift, Java, Kotlin, C++. Of course, you could utilize the excellent mobile development frameworks that are available and allow targeting multiple mobile platforms with a single development code base. On the cloud side, the technologies would be similar to what we discussed before in this article (in Aggregators). However, there is one difference as called out in the accented text below.
When a device wants to directly talk to the cloud, there are supported options available from both AWS and Azure. They have a decent number of certified devices under their IoT umbrella that could be considered. When a match is unavailable, you may have to build a custom cloud integration layer in your device.
A discussion of cloud platforms’ support for such architectures is beyond the scope of this article but I will put in a few links to the relevant places on their websites. Reading through them should give readers an idea of cloud support possibilities when dealing with such architectures.
AWS IoT — here, and, Azure IoT — here.
Non Functional Requirements (or cross cutting architectural concerns) for healthtech stacks:
Finally, we talk about something that has applicability irrespective of the categories and their architectures: Non Functional Requirements. All technology architectures have cross cutting concerns (or non functional requirements). Depending on the domain, some are more important than others.
Non functional requirements are often the weak link in an otherwise solid architecture. Pay much attention to these. Using cloud platforms frees you from a lot of headaches related to NFR’s.
I have not touched upon these in the previous post or this one till now. The reason is that they are assumed to be characteristic of architectural imperatives for any healthtech stack and that the subject is best treated at this point with the hindsight of all the previous discussions:
- Security — for data at rest and data in transit
- Authenticated and RBAC’d (Role Based Access and Control) gated access to data for all users and systems integrating with it
- Regulatory intelligence — adhere to and be able to provide proof of adherence to health regulations
- Certification — almost all medical devices need to be certified by a central / federal body before being launched. There are certifications to adhere to for medical data handled by software applications too
- Scalability — be able to scale per demand at run time. Optimal usage of resources per observed load
- Performance — guarantee a minimum performance and QoS. This applies to so many metrics (page load time, search time, order fulfillment times, device time to ready state, monitoring-control feedback loop time and so on …)
- Reliability — the system must be able to recover from infrastructure or underlying service (or component) disruptions, must scale (scalability) and must be able to mitigate issues arising from misconfigurations or temporary network issues
- Testability — Ensure that the key components of the system are always testable at any point in time from both functional and non functional perspective
- Usability — Ensure that usability norms are followed for user interfaces (software as well as HMI’s), documentation and API sub systems (wherever systems integrate)
Thank you for reading this article! I welcome any comments or queries you may have. I am an independent technology consultant in the area of digital transformation and its related fields. I help organizations navigate their journey towards leveraging technologies like Cloud Computing, Internet of Things, Mobile Applications and others for their business. Most recently I’ve helped bootstrap, design and prototype a biofeedback platform and am helping organizations in the IoT sector. If you or your organization are looking for help in digital transformations, drop me a message!
