Business process automation

The basics of business process automation have been explained sufficiently. On the other hand, the structuring of technical processes is something experts could talk about for days on end. That is why projects see extensive discussions about how to define disqualifications, distributions, clearing and automation levels.

 

The explanation for this is that good business process automation is supposed to support case handlers to the maximum extent possible, and insurance companies generally want a high degree of automation. This ensures that standard processes are handled automatically and case handlers no longer have to deal with these routine procedures.

 

Instead, they are left to work on challenging or disputed cases. To automate the payment settlement process, for example, data received by input management (from scans, apps, e-mails etc.) are documented and prepared for further processing. Bills are then checked by a machine and reduced if necessary, and the statement is sent to the customer automatically (by e-mail, app or post).

 

These automated processes are based on process stages controlled by a business process engine (BPE). The various technical processing stages are subject to specific rules which can lead to the process being disqualified from automated processing (to be dealt with manually instead) for individual customers.

Even the question of how many cases are processed automatically is interpreted differently from insurer to insurer: some companies only count the cases that run through a machine entirely, whereas others also count processes which are reassigned for manual processing at the clearing stage. It’s all a matter of the definition. The general rule of thumb is that the more standardised a process, the more suited it is for automation, and only a few other parameters require extensive coordination – more on that later. For example, recipes lend themselves well to automation because pharmaceuticals have a clear ID thanks to the pharmaceutical registration number (PZN), a nationally standardised identifier for drugs, pharmaceuticals and other products commonly sold in pharmacies in Germany. The pharmaceutical registration number makes it possible to check what the product is and whether the products can be reimbursed as per the agreement.

 

In contrast, remedies are more difficult to automate. Automation here depends heavily on the quality of the data (which, in turn, depends on the incoming channel and input management). With regard to financial assistance, for example, remedies must have specific names and come with an expert appraisal, which makes the entire process highly complex and dependent on commitments. In cases like these involving dependencies and individual specifications, a regulatory framework for automation has to be made more elaborate, which leads to more adjustments and manual follow-up work.

Established expert systems are used in the payment settlement process. For example, medical invoices in the private health insurance segment are checked by the expert system ZABAS, which features fully automated, rules-based checking and settlement of medical bills for health insurers and financial support offices for e.b. civil servants. The expert system KOLUMBUS SUITE is used to check invoices for medical services in the field of somatic treatment for inpatients in hospitals and specialised departments based on diagnosis-related groups, for example, as well as outpatient invoice verification. The more deeply these expert systems are integrated into the payment settlement process, the more effectively the process automation can be developed and controlled. When interfaces are developed jointly, it is possible to define the exact rules of automation, when cases are ‘looked into’ and what does not have to be checked across the board. These rules make intelligent disqualification part of automation. This way, the expert systems with the results in the system can be accessed from the payment settlement directly without any media interruptions, even in the dialogues.

 

As standard, msg.Health Factory provides full integration with the expert systems ZABAS and KOLUMBUS. The interfaces are developed jointly in this context. The developers of these systems – Global Side GmbH and innovas GmbH – are even subsidiaries of msg.insur:it. This optimises interaction between all the systems with no additional integration, which is convenient for case handling and quick and transparent to automate.

In order to optimise process automation, we must dive deep into the subject and the following parameters have to be taken into account:

 

• The economic perspective – how exactly may and does it have to be
• Data quality, scope and granularity – how exactly can and should it be

When it comes to the economic perspective, the desired range of tolerance has to be determined. It can be prudent not to max out every single parameter or use every reduction option, yet save time in a generalised process and accept a certain results tolerance. This corridor is defined and evaluated thoroughly in technical consultations between the provider of the solution and the insurance company.

 

These decisions concerning the economic perspective are based on what implementations are technically possible; these, in turn, are heavily dependent on the quality, scope and granularity of data. Through input management, the benefit system receives a large volume of data from various input channels in various formats: apps, portals, phone calls and traditional post. The input is documented and processed electronically – optical character recognition software is used to process traditional post, for example. It is now up to the insurance company whether to have only one type – ‘Invoice’ – or one hundred different document types. This granularity determines how the processes can be controlled and defined – if there is just one document type across the board, then there can only be one general, fine-grained process. These processes map customers’ requirements, making them customer-specific.

 

Likewise, there is no standard in input management – what is written on documents, whether there is an easily assignable pharmaceutical registration number, how complete information is, such as inpatient or outpatient – and it can only be influenced to a limited extent. All other processes depend on the quality of data that flow into the system through various channels. There can be any number of input channels and they are administrated as effectively as possible by input management. The range of the input itself is just as wide, such as daily sickness benefits and care expenses. Additional documents such as consent forms and orders must also be taken into account, as must cross references and intermediate documents. All of these documents might even have been submitted at different stages or contain historical references.

 

Building on this, transactions are defined through business process engines in the consultation and the desired criteria for disqualification from automated processing are implemented. There can be hundreds of these processes in a large-scale project.

Artificial intelligence opens up another aspect of optimisation. The reasons for disqualification from automated processing can now be analysed retrospectively and simulations can be run with AI mechanisms, making it possible to adapt rules when patterns emerge. It is not inconceivable for AI or machine-learning to be integrated into the process sequence, with decisions being made based on probabilities, thus creating a self-learning system. The definition of ranges of expectations and certain tolerances is a significant factor in this case too.

 

All of the factors described here have a significant effect on the possible degree of automation, and it is clear that the best results cannot be achieved unless insurers and providers consult carefully with one another. It is important that the desired customer-specific document types, data quality and the economic aspects – all considered as a whole – achieve the ideal degree of process automation in payment settlement, with deeply and soundly integrated technical and functional factors as well as cleanly defined processes.