Manual Data Entry is for Dummies…

One of the best ways to improve workflow is to eliminate manual data entry and lookup through integration and interfacing, but you can’t auto-populate what you don’t know. Decisions is being used in a wide range of industries to access, aggregate, manipulate, transform, validate, and eventually auto-populate data in a variety of user experiences. Decisions can connect apps, databases, web services, devices and other data sources to create an enterprise-ready logic layer that adds intelligence to your data workflow.

(Quick Aside: Decisions versus ESB’s)

While there are other categories of tools that touch this idea – ESB’s (Enterprise Service Bus) in particular – looking at data communication in your system with a workflow and business rule lens can add more value. In some cases Decisions is used with ESBs to add intelligence to the routing and transforming of the data. In other cases Decisions has replaced ESBs completely. At the end of the day workflow moves and manipulates data while business rules evaluate data. Put those two fundamentals in a series combined with Decisions integration wizards and other supporting features and you can get data from any one place, do whatever you need to do with it for it to be “ready”, and then you can send it to its final destination – complete with exception or error handling and manual tasking if absolutely necessary.

Back to the Future of Your Data Workflow

Healthcare is an area completely buried in what they call “interoperability” problems. Systems that all need to work together to get a job done are simply not able to communicate because they are speaking different languages. Even efforts to standardize data in healthcare are suffering from this translation problem.The time and effort required to stay current with these standards works against organizations who adopt the standards at different points in time and who need to maintain their own unique quirks.

In some cases, the interfacing problem has a one-to-many relationship. Meaning there may be many sources of data that all need to be aggregated in one system of truth. In other cases this problem may manifest itself with a many-to-many scenario complete with requirements for bi-directional communication among all systems involved. We’ve dealt with both (see HL7Flow.com) – some easier than others – both built upon the same basic principles.

Let’s take the most simple example and break it down. One-to-Many with Uni-Directional communication.

While the diagram above is rudimentary – it outlines the basic steps. Step 1: Define where the data is coming from and how it will be received. Step 2: Decide what to do with that data – does it need to be changed, validated, or discarded? Does it need to be mapped to a new structure? Step 3: Update the system of truth.

To illustrate this further – let’s consider a medical billing practice. This medical billing practice gets data from multiple data sources around what activities occurred when and to whom. From this – they need to decide how much to bill and who to send the bill to. Once this is determined, the system of truth can be updated and the next set of activities can take place – actually sending the bills.

While many of these examples are healthcare specific – the same basic ideas can be applied to other areas where data needs to be managed. For example – in the mortgage arena they use the MISMO standard and at different points in a customer lifecycle data may be coming from non-MISMO sources.

Decisions can act as an interfacing engine… so what?

Decisions provides tools that can solve this problem, along with many others, but the value is not in the “YES WE CAN” – it is in the “HOW WE CAN”. We solve this problem by exposing the right business logic to the right person at the right time for them to make changes without writing any code. We want the business to participate in the design and maintenance of the software solution. We want developers to focus on innovation with the creative puzzle pieces the business uses to get that done instead of translating business requirements into code.

This means that as the interfacing challenge becomes more complex – the puzzle pieces can stay the same and the business can understand what needs to happen to make things work.