Robotic Process Automation (RPA) has emerged as a very cost efficient and non-intrusive method to quickly automate highly repetitive business processes. Thanks to advances in AI, software robots can also process and intelligently understand documents, often with the help of specialized tools such as CaptureFast, and take necessary action. 

A side effect of RPA implementations is the avoidance or postponing of expensive technology development that may otherwise be required for automation. While robotic automation helps to reduce swivel chair operations, the evolving need for business transformation means that significant technology transformation is still required. Enterprises have to think about multiple systems of record and data islands that often have to be reconciled and managed to ensure reliable and compliant business operations, both within their organization, as well as with other organizations they interact with.

Today, I’d like to show how a combination of RPA, Intelligent Document Processing and smart contracts can accelerate automation and bridge of data islands. In addition, you’ll see that the potential for collaboration enabled by Daml smart contracts will result in significant operational savings of its own. 

Background on Use Case Scenarios

Almost every business process requires handling of physical documents that are digitized and processed. According to a Gartner study on RPA and Intelligent Document Processing, even internal departments such as finance can save almost 30% of the time they spend doing repeatable document processing tasks. The study also indicates that business processes must be standardized before they can be considered for robotic implementations. This phase is where Daml smart contracts can come in. 

Since DAML is several times more productive than traditional general purpose languages (see the comparison with Kotlin here, and comparison with Python here), there are a few significant benefits to using DAML smart contracts as part of, or in preparation for, your RPA initiatives:

1. Centralize business rules in one place instead of having to spread them out
2. Build a secure and robust audit trail for all robotic activities
3. Automate downstream actions that cannot be easily done by bots
4. Bridge data islands within the enterprise so that every business application has the same view of the business process state
5. Extend the business process outside of the enterprise thus dramatically improving customer experience.

To illustrate these points, let’s take a simple business process scenario that all of us are familiar with. Anyone visiting a medical provider often fills out their medical history. This medical history is processed (scanned and fed into a tool such as CaptureFast) by the office and stored. There is no easy way to review and update this information except at predefined time intervals (every 6 months for example) when the form can be filled out again. In addition, when we visit a different medical provider, we need to do this all over again. Apart from the inconvenience, the risk to our privacy has increased, and updates to one provider does not update others. Transfer of records is also a manual and costly process.  We can also outline at least a few challenges this poses  to the ambitious charter of outcome based health and proactive, preventative medicine.  

Here’s the overall business process flow. This is a simplified version for illustration only. For example, we cover only the medical history form, but don’t consider other diagnostic information and provider differences.

The Smart Contracts Model

We will envision a futuristic scenario where multiple medical providers may want to securely and privately share information. Therefore a designated operator will create a network and onboard multiple providers. The operator does not have access to the data of each provider. They are purely an infrastructure provider and business process enabler only.

These providers will operate as “connected islands” - they share a common business process blueprint, have the potential to transact across their islands, but their data will remain fully private. 

A provider must consent to being a part of this network. Without that consent they cannot be made part of the network. This is an important construct of the rights and obligations model of DAML. A provider is obligable for actions they perform, so their consent must be on record. Thankfully, DAML handles that seamlessly.

Now that the providers are part of the network, as per their role contract, they can onboard customers and their own Document Processing Bot. In DAML we call these “rights” afforded to them.

For simplicity, we don’t require specific consent from the Document Processing Bot (assuming it’s a software platform such as CaptureFast). Customers however must consent and accept this invitation from the provider. 

Additionally, in an ideal scenario, customers can choose to make themselves visible to multiple providers so that they can create a single logical view of their medical information stored with different providers. We’ll tackle that in a subsequent post when we specifically consider multiple provider collaboration. 

When customers fill out their medical history, the Document Processing Bot will scan the paper medical history form, understand the data, and send it to the provider for approval. 

There are multiple automation opportunities when this data is received. The data can automatically be matched to the customer based on the right identifiers included in the processed document. It can be enriched from other sources. A customer record can also be flagged so that other relevant providers will be able to automatically use updated information - subject to customer consent of course. In addition, an automatic audit trail can be maintained. The RPA bot that is executing actions can also do so contextually and securely by being given the necessary rights on the DAML contracts. 

In this case, the smart contract checks if a customer exists, and then approves the data to be appended to the customer record.

Since the customer is a stakeholder, this medical information is automatically available to the customer when they log in to view it. Daml has a strong privacy and disclosure model so many of these data access authorizations come out of the box. This simplifies technical implementations. In this case, both the provider view and customer view can be derived from the same underlying physical smart contracts store. Contrast this with the traditional technology landscape where multiple data islands must be kept in sync because they reside in different applications. 

By using Daml, we have already bridged these data islands! Now, an RPA bot can access a uniform smart contracts API to make all these decisions in context. 

Conclusion

As you can see this smart contracts based implementation is incredibly simple to implement if you are using Daml. At the same time, DAML may enhance compliance, security and privacy of an RPA program. A DAML model is also extensible to multiple legal entities and dramatically simplifies business collaboration and secure data sharing. 

By integrating intelligent document processing with Daml, CaptureFast has opened the doors to the next wave of business process automation with smart contracts. If you are considering an RPA implementation, get in touch to see how Daml smart contracts can complement your program.

Information referenced in this post:

1. Gartner study on benefits of RPA & Intelligent Document Processing
2. Comparison of Daml with Kotlin 
3. Comparison of Daml with Python