A few weeks ago we set out to develop a healthcare supplies procurement app to meet the demands of the COVID-19 pandemic. Now that the app is ready I wanted to share our journey and some interesting takeaways we took away from the process. Many thanks to Manish Grover from Digital Asset for his business inputs and guidance.
The challenge was not that the procurement processes did not exist, but that there was a need to accelerate the cycle and bring granular visibility into the value chain. In a scenario such as the COVID-19 pandemic, having multiple islands of procurement that don’t talk to each other is not enough. Instead, we need an ability for every player to review the demand and supply patterns and maximize their responsiveness to meet public health demands.
Given the sudden spike in demand, and the shortage of supplies, currently there is no easy way to get a bird's eye view across hospital networks, buyer agents, and manufacturers of what was being procured, where it was being shipped, and also what supplies were available to be purchased.
Not to mention that as supply is ramped up in a short period of time, new manufacturers have to be onboarded, verified, and aligned with the shipping and standard operating processes that health institutions need to comply with.
In addition, supplies for healthcare need the stamp of approval from the FDA, and the fact that a bulk of these supplies would be sourced from countries like China created potential delays with receiving and customs processes as well.
So, we needed a way to get all these things tracked and visible under a single umbrella while preserving confidentiality, with integrations out to existing enterprise systems as needed. For example, a network buyer should be able to see new manufacturers, their products, and whether they have FDA approval. At the same time, we needed these confidentiality provisions to be customizable. How could we achieve this objective of creating a single source of truth while preserving confidentiality and privacy?
It was apparent that regular technologies would not be an optimal fit because we could not possibly develop, and deploy a multi-party system of this scale in a reasonable timeframe. The need for data segregation and confidentiality requirements would be far too complex to meet. Not to mention the cost of hosting the data for such an application while meeting data domicile requirements of the various legal entities. We did not want to end up in a place where we’d have to constantly troubleshoot, aggregate and reconcile data from multiple databases and systems.
To meet the data confidentiality requirements by the various players in the supply chain, it would be an uphill battle to try and use traditional web technology architectures. So we decided that smart contracts and DLT would be a good candidate to base this architecture on. That way we could achieve the features and agility needed, while also integrating any existing legacy technologies with this foundation being built.
Given that we did not yet know which ledger we would choose to deploy on, we decided to build this application using Daml. That’s because Daml is fully portable across ledgers (so we could build now without tight dependence on the target ledger). Daml also allows interoperability across different blockchains so we could then integrate any complementary deployments if needed.
Further, to minimize the complexity of prototype development, we decided to host the initial version of the Daml app on project:DABL, a fully managed environment for Daml applications. That would allow us to do away with infrastructure management, authentication, performance and other non-value added considerations at this stage of the project. As outlined in this post comparing Daml & Kotlin, we would use Daml for the smart contracts layer, and use the event based automation framework of Daml ledgers (including project:DABL) to communicate using APIs with 3rd party systems such as shippers etc.
This entire process was modeled and deployed to project:DABL using Daml within a few short days! It was a fully functional application and provided strong confidentiality and disclosure guarantees out of the box - e.g. one seller may not be able to see quotes from another seller etc. Not having to specifically program for these requirements was a big benefit of using Daml. Interested readers can read more about that here (Daml ledger model). Imagine building the entire backend of such a business process in 3 days. It’s a testament to how powerful Daml is.
For example, here’s a screenshot of what the quoting process in Daml looks like:
At this point, the app lacked the registration and onboarding of multiple parties, their authentication, and other common UX features. It was not very practical to use. We thus set out to create a web based, mobile responsive front end to allow for that functionality. Creating this front end turned out to be a more challenging experience and took us several weeks to get right. Even though an open source Daml UI template in React is available to use from the Daml team, that template was too simplistic to build a practical enterprise application without major customizations. e.g. In order to create a Request for Quote, the buyer would need a list of available products and sellers too. However, given that the Daml ledger exposes easy to REST APIs for this purpose, our decision to use Daml did shave many months of development time.
For this app to be practical, we needed to model the business process right from onboarding hospitals, manufacturers, cargo providers (international shippers), domestic shippers for last mile shipping, buyers and their various buyers agents across the globe. The processes would include making inventory available for procurement, requesting and receiving quotes, placing purchase orders, and then tracking the shipments all the way through FDA and customs to the hospital where the supplies were needed.
A representative process covered by the Daml application
While we programmed the entire business process using Daml in a few days, and built a fully functioning application within a few weeks, I’d like to bring up the bigger supply chain challenge we discovered. That problem is of matching demand with supply. It became obvious that with rapidly changing demand patterns, we need a way to route inventory in a much more agile way than we are used to.
There are a variety of demand sensing technologies in use today. What if we could integrate real time analytics with the DLT app we built?
Our belief is that some of the key challenges with the supply chain arise from a lack of visibility (islands of data) and the inability to effectively include demand patterns in the manufacturing and distribution processes. There is a lot of innovation underway in demand sensing and retailer-supplier collaboration so the future does look promising. Innover has also been pioneering the use of AI based analytics and various digital capabilities such as conversational agents to solve these problems for our clients.
With the use of DLT based architectures using Daml we hope to provide additional impetus to the resolution of these challenges.