Polonious Integrations – our journey – part 2

This is the second part of our three part blog series about our Polonious Integration journey. We hope it’s useful for IT teams and businesses seeking to develop their integration practices, integrate with Polonious or hopefully both. If you haven’t read part 1 yet, it is here.

When the light bulb went on

Around 5 years ago, our transition started to a newer, more flexible integration capability. Most importantly for our team, this also meant less time spent on integration and a whole lot less stress on the projects involved.
The reduced IT spend on Integration meant smaller invoices for customers and more time for core UI and micro service developments that are starting to really bear some fruit.
We still encounter integration challenges, however they are quicker to resolve with minimal interactions. Once all parties understand how to operate, we can break down these project meetings into three to four distinct groupings:

1. Business discussions between our business facing experts and the customers front-line business people to determine the business requirements. In particular – what data needs to be transferred between which systems and what should the high-level workflow look like.

2. Technical integration discussions with client IT systems owners to discuss the business requirements and discuss the technical approach. This includes determining the relevant endpoints, the communication methods / protocols to use, and what authentication methods are supported.

We also have some internal discussions in case we need to write an adaptor to deal with translating the other parties preferred communication method to ours. We then work with the systems owners to determine the technical details to implement the adaptor.

3. IT Security and network discussions. No business users needed. Generally these are fairly rapid as we are well across all security / technical needs and are ISO27001 certified, which means we follow best security practices and generally have great solutions for  security related questions.

How we made the transition

To move to this better place, we needed to create tools that allowed the business users to have discussions about ‘what goes where’ without any IT involvement.

This required building secure, flexible REST capabilities for our primary integration driver. In our world, this was ‘Create Case’.

REST APIs actually date to the early 2000’s. It wasn’t until 2014 that they became widely acceptable as an alternative to XML Web Services and other protocols commonly used by large corporations. The reasons for this change were the ease of adoption by other teams, the speed, simplicity and flexibility of the specification.

We started around this time to look very closely at REST capabilities and decided to re-develop our case ingestion to have a REST API.

Flexible REST

Most REST APIs are fixed in nature, you get a few fixed parameters, well documented and defined which you can POST (in the case of creating things) but these are not very adaptable.
To meet our need to ensure the ‘what goes where’ conversations could happen without our IT team involved, we had to develop a very adaptable, configurable, Web User Interface for this crucial service.

So our Create Case REST API is actually up to the customer. What fields are POSTable, is defined in a web interface, how our POST api responds to these is also up to the customer. By doing this, we can handle 95% of create case needs. For the rest, there are adaptors.

The upside for our customers

Since this capability is now an easy to use part of our user interface, it’s really easy not to involve internal IT teams (from both sides) in the many of the conversations required to get business data transferred between systems. Here is how the conversation generally goes:

Polonious: “Send me a JSON example of what you want to send to us”

Customer: “What’s JSON?”. A short discussion of this format ensures, usually we send a simple example over like this:

{

“claimNumber”: “GHT202320”,

“referralReason”: “Claim initiated within 7 days of policy inception”

}
Customer: “Ah, I get it!”… sends example of data to be used to create case.

Polonious: “Here’s a few things we need to alter and discuss” this is usually a short discussion about types of fields, how fields should be formatted etc. This can involve customer IT, or that can be deferred to an adaptor we write to absorb whatever is easiest to send from the customer’s end.

Customer: “OK, that’s it, we’re ready, here’s some examples of what to load”

Polonious: “I’ve mapped them using our create case api tool, here’s the URL for your team to test it, here’s some test credentials to use, here’s where it will appear”.

Customer IT and our IT then usually get involved if there are firewall/network/other issues with data. This is often a fast process as it’s a simple port 443 request (secure TLS 1.3).

Polonious: “Looks like the cases you send created successfully, let’s get back to talking about the process you need to follow up these cases, and what the feedback loop looks like”

If everyone is available, networks are in place, this process can be over in hours. This used to take days, weeks, months of elapsed time depending on availability of many parties to the discussion.

Learning: As REST services expand, integration projects shorten

The rather unscientific graph on the right shows effectively what’s been happening for the last 5 years at Polonious. As we invest more time and effort into our REST services, the time taken to integrate to new platforms decreases.

Crucial to this transformation was understanding the best way to structure our REST services. There are conventions for naming and versioning REST services that are important to provide these advantages:

    • Conventional naming of APIs means quicker adoption by IT teams wanting to integrate to your services. This book was a lot of help: https://www.manning.com/books/irresistible-apis
    • REST service versioning means IT teams do not need to re-develop their integration to your software every time you alter the API. Believe me, they don’t want to.
    • Documentation. Great API documentation greatly speeds adoption of your APIs to other IT teams. We invested a considerable amount of time in explaining, in documentation what our services do and how to use them. We even wrote an SDK in Spring Boot to demonstrate using them in Javascript.

For us, the first step of the API journey was making our own ‘case intake’ web forms use REST APIs instead of requiring Java engineers to bespoken write each of them in our chosen tool (Java/JSP).

Doing this, expanded our public APIs to cover most GET requirements an external team might need. This further shortened integration projects.

We can now hand over web form development to any client team willing to invest a little in learning our REST APIs.  Of course we’re still available if clients don’t have capacity. Many client IT teams have done this. We hear all the time of IT teams building REST calls to our system with web forms or other means.  This is great for all concerned as it saves ours and our client’s time and effort. Since our key system updates and reads are now wrapped in REST calls, we are pleasantly surprised by the capabilities client’s teams have developed with these APIs. A recent example was a team developing a button on a sales force mobile app, this button was used by sales reps in the field to photograph potential fraud and have immediate cases created in Polonious to process the leads from the field.

Learning: As external teams need more information, add that to your REST APIs first

We integrate to our own client’s internal systems, but also to other partners in the vendor space. With each information need a client expressed, our process became ‘REST FIRST’ which meant we expanded our REST APIs as these needs evolved over the last 5 years. This has had a profound impact on how easy it is for a customer to integrate to our software.

In the third and final part of this series, we will go over the integrations we have developed to other systems and where we’re expecting to take this capability in the future. Thanks for reading so far, I hope you enjoy part 3.

Polonious Integrations – Our journey – Part 1

Integration, done well, is a powerful time-saver for a business. Data magically moves from one system to the next with no re-typing or errors. The business cost benefits are immediate and cumulative.

IT Integration projects used to be slow and expensive. Polonious have been on a journey to improve this over the last decade. We now know that we, and our customers can be confident integration challenges are not the painful undertakings they once where.

Polonious currently have 21 product integrations that push and pull data from many sources including:

  • Investigation information sources (7)
  • Claims systems (2)
  • Fraud analytics products (4)
  • Video interviewing systems (1)
  • Accounting systems (2)
  • Link analysis systems (2)
  • Others (3)

We also have many more integrations to internal client systems scattered across a multitude of data sources, methods and security protocols.

Each of these integrations built on the methods of the previous one. All have the same foundations to their success.

This integration series will explain what’s different about our approach and why we are great to partner with if integrations are something you’re concerned about.

Part 1 is concerned with the state of integrations when we began the journey, what the problems and frustrations where and a little bit of a look ahead to what our principles for integration became.

Part 2 covers the first pieces we use to ensure significant cost and delay is removed from integration projects without causing quality and security issues. I’ll discuss the lego blocks that make up an easy integration process.

Part 3 covers our current list of integrations to give an example of what’s possible for your business, as well as some of the more complex components we wheel in for complex requirements.  One thing that is pleasing is to see our clients take our API sets and use them in place we never expected. Sales reps triggering fraud cases from Sales Force Mobile being one recent example. We will also touch on the future, what we’re doing next to further help with the integration needs of our customers.

Our journey

A decade ago, when Polonious needed to integrate to other systems,  this was how the projects generally worked:

  • Big budget integration projects.

  • Regular, big, team meetings involving project milestones. Participants included the business, IT network and security people, IT development teams. Lots of discussion about approach, governance, everyone being heard. Very expensive undertakings.

  • Waterfall project plans which coordinated the efforts on both sides of the IT discussion.

  • Delays by any part of either party’s team slowed the whole project down. For example, we once waited 9 months for the other party’s FTP site to be set up correctly.

I and many or us at Polonious were very frustrated with this process – we knew a lot of it was out of our hands. Unlike many things in the IT world which had clear paths and standards, a lot of the issues we encountered were associated with ‘bikeshedding’. By way of example, here are some of the long discussions from those days:

  • Security. Many teams we encountered needed a detailed discussion of how we were communicating securely. They often had different thoughts and requirements that needed to be discussed and agreed upon.

  • Protocols. This was the glue that allowed systems to communicate. This varied from SFTP / XML / Webservices and other methods. A lot of people are still used flat file importing also.

  • Field discussions: what goes where. This was to the most point a business the discussion that required IT resources. These discussions shouldn’t have needed IT resources.

Integration projects accounted for at least 30% of our IT resource budget most years until we spent the time to work out how to get control of this process. As a bonus, during this time, the IT world moved on a little – clearly we weren’t alone in these frustrations.

We  believe that we now have the integration challenge down to a fraction of it’s previous frustrations and delays. I’m hoping that this little series can help a little with your team’s challenges, if not, with understanding our approach and how that can help if we need to integrate together someday.

Here are the main points of advice I’ll be covering with examples of where it’s worked and how it works for us and our clients:

  • Fix your integration efforts on secured REST, preferably with OAuth2 – as soon as possible.

  • Make your REST services flexible enough so that business people who will use them. Yes, business people..

  • When considering working on integration, start with improving your core REST services, the next integration project will benefit from it.
  • When you can’t use REST – adapt.  Write adaptors to translate the other party’s communication needs into your common REST calls so that all of your internal verification, security and updates are consistent.

Of course, I’d love feedback on this as I’m sure the journey is not complete. You can reach me by email here: stuart@polonious.com.au or by linked in here. Part 2 follows next week.

 

IASIU Panel Questionnaire – How to Improve Performance Through Measurement

A ruler is measuring blocks which spell the word 'Outcome', representing the purpose of the IASIU panel questionnaire

Polonious recently ran a panel discussion at the IASIU conference held virtually on 14th and 15th September. Prior to the panel we ran a short questionnaire about approaches to performance management within SIUs, and the results were quite interesting. Firstly, 30.77% answered that they did not have a system for measuring the effectiveness of their SIU. This was surprising as most operations these days come with some sort of performance metric, to justify expenditure and tune performance.

Obviously, we would love people to use Polonious to track and report on expenses and outcomes, but you don’t have to use Polonious. Even if you don’t use case management software at all, we would highly recommend some system for tracking performance, to guide future decisions on resources and methods. If you would like to know more, we’ll be putting together a longer paper with more of the results.

For those that do measure the performance of their SIU, most answered that this is done by SIU management, and reported monthly, which is about what you would expect, with some variations. 55% reported that operating costs are allocated to the claim file which, again, is expected. However 30% reported that costs are unallocated – which would make it hard for an SIU to identify high cost problem cases/areas.

Sources of referral were fairly evenly spread. A big surprise for us was that around 50% of respondents didn’t record the number of false positive referrals from either an analytics tool or their claims unit. A similar percentage said they didn’t feed these false positives back to their source, to improve referrals. When you compare this to the SIUs who did record these numbers, there were significant amounts in the 41-60% bracket, even in the 61-80% bracket.Nearly 80% say they’re recording their reasons for rejecting referrals, but those who aren’t feeding that back are going to keep getting 40-80% bad referrals which they have to process before getting back to productive work.

Performance measures were as expected, e.g. referrals and ROI. A large number also report on indirect performance measures such as training and deterrent effects. Productivity measures were also as expected, focussing on cycle times and cases per investigator. However few SIUs were measuring time per stage, which is something we would recommend for identifying bottlenecks in your process and improving productivity.

Lastly, less than 50% of SIUs answered that they measure surveillance quality. This includes measures such as time stamps on the video, subject centred in the video, in focus, etc. This means a number of SIUs are receiving – and paying for – surveillance footage which is less likely to have impact on a case. Less impact from your footage means less savings for every dollar spent on surveillance. Polonious highly recommends tracking surveillance quality and feeding this back to investigators and vendors.

Please note – this was a brief questionnaire to participants and other respondents for interest’s sake ahead of the panel. It is not intended to be statistically representative.

Polonious Release 20.2 Announced

Polonious Release 20.2 Announced

Polonious release 20.2 is ready for all clients with some great new features that we know will improve your team’s productivity, user experience, and capability.

Version 20.2 further enhances the front-end with new Dashboard technology which was introduced in version 20.1, adding eleven (11) SmartWidgets to enable you to build any sort of dashboard your team needs. This allows you to create dashboards from any case data quickly and easily.

Additionally, we have added a Document Library feature to help your teams use the same documentation, we have expanded our list of integrations. We have also added better, more secure Multi-Factor Authentication methods.

Analytics

Release 20.2 includes a full set of Charting capabilities that enable end-users to construct dashboards that total and drill through their Case Management system.

A full set of capabilities 

Eleven new dashboard SmartWidgets are ready to use:

Pie Charts

Bar Charts

Sunbursts

Circle Packs

Treemaps

 

 

 

Stream Charts

 

Data Aggregators

Tables

Maps

 

 

Time Series Charts

Counters

 

 

Dashboard Layout Manager

This drag-and-drop capability allows your configuration team to layout the dashboard views in an easy-to-use and configurable way.

For example, we have created this dashboard view layout from the SmartWidgets available on the left by dragging, dropping onto the rows, then configuring each SmartWidget in a simple user interface. 

When you render the dashboard from the above layout, you will see something like this:

You can control the width of each widget as well as the contents. You can fit as many as six widgets across on wide screens. When this renders to mobile devices, it puts only one widget across and displays them down the page. A responsive design that enables our dashboard tool to adapt to your device size.

Document Library

The Document Library allows users to create a library of essential documentation shared according to security access with various teams and external vendors. Making it easy to update and share essential compliance, process, and form print requirements in one central location.

Security – MFA with Google Authenticator

With 20.2, you can now use the popular Google Authenticator to generate multi-factor authentication codes, instead of entering a code sent to your mobile device by text message or email.

Google Authenticator is a more secure method of generating MFA codes than using SMS or email delivery, as it cannot be as easily intercepted and changes values every minute. It is also explicitly tied to a user’s mobile device.

Integration with Simple2Connect

Full integration with Simple2Connect’s video interviewing software makes it very easy from the case management view to request and start a new video interview. The final video is uploaded automatically to the case notes upon completion.

Integration with Guidewire DevConnect

Guidewire created DevConnect recently to enable easier integration with their Claims Center product. Polonious had already successfully completed the accelerator several years ago. This new method is the preferred way to connect to Guidewire going forward; this September 2020, we received certification with DevConnect.

REST API Improvements

We added two new secure communication options in 20.2, which extend the integration capabilities of Polonious with other products. 

  • Basic Authentication Header capability was added to allow REST calls to services that are protected by Basic Authentication.
  • JWT (JSON Web Token) was added to enable calls to services protected by JWT.

We have also added many improvements in payload contents and API endpoints. As always, backward compatibility of payloads and requests is preserved to ensure that existing integrations with Polonious continue to operate without modifications on your end.

Other improvements

This release has implemented many more features whose full details are in the release notes and user guides available from Polonious on request.

Full release notes (pdf) and a comprehensive user manual are available on the user group for current customers. Please contact your representative for more information.

Links and contact information

We are always looking for feedback and thoughts on our software, please contact your local Polonious office for more information, help or feedback. We’re keen to keep improving.

Related Articles

https://www.polonious-systems.com/polonious-analytics-a-first-look

Video demonstrations

Analytics - a first look

Polonious Analytics – a first look

This is a demonstration of our new Analytics capability, which is part of our 20.2 release.

This demonstration will show you how easy it is to create a useful and visually compelling dashboard specifically, in this case, to help with team coordination.

We will build this dashboard in 10 minutes, stopping here and there to explain some of the capabilities and concepts.

We believe your team can take on the task of building their own uniquely useful dashboard views into your case data.

So how does Analytics help your team?

Analytics give them the ability to:

  • Prove your team’s value to the organization.
  • To create greater efficiencies by analyzing performance.
  • To track Compliance by examining the data you can easily capture on compliance KPIs
  • To improve referrals to your unit by examining past cases referred vs case outcomes and savings.
  • To measure quality by creating dashboards to measure the quality of work our vendors and team are doing

 

Drag and drop, configure, run..

View, filter, list and then view cases.

So, what did we just see?

The dashboard build took around 10 minutes with stops to explain some of the concepts.

I think you will agree, it was easy to drag, drop and construct this dashboard.

We believe you can do this task now with no IT involvement required. This is a big saving in doing time, turnaround time and internal costs.

So what did we just see in terms of Polonious Analytics capability?

You can easily filter and select the case data you need to answer your questions.

There are a bunch of smart widgets to visualise your data as you need.

When you are using the dashboards, if you see something interesting, it’s very easy to drill down to that detail and see all cases in a list represented by that point of interest.

You can view a case straight out of that filtered list to see the full detail of what went on during that individual case.

What else can we do with this new capability? What are the other possibilities?

Rick Shepherd and Steve Epstein of Polonious  gave a metrics presentation at IASIU on the key areas analytics help a team such as yours. Proving Value, Improving Referrals, Creating Efficiencies, Measuring Quality and Compliance. All of these are now easy to create with Polonious Analytics..

We hope you enjoy our new 20.2 release. We really look forward to seeing what your team are able to put together with this new capability.

If you have any questions or improvement suggestions, we are very keen to hear from you. Thank you.

Be More Flexible With Our Change Support Subscription

  • Do you find yourself going through lengthy project/budget approvals to make improvements to your system? Are some changes not even worth the budget hassle?
  • Do you have operational budget for increasing your subscription, but no capital budget for improving it?
  • Have you got the newest features, but no new budget to start using them?

We work hard to constantly improve Polonious software, but these issues prevent some clients adopting our improvements, or adapting to change.

We have heard you, and we are pleased to announce a new, optional addition to licencing subscriptions allowing you added flexibility for improving your system. We have developed a model and a management process for a ‘Change Subscription’. This adds a set number of hours per year to your subscription budget for changes, i.e. system changes that are not bug fixes. This has the following benefits:

  • Change budget is already set aside, so you can make changes and improvements much quicker. No lengthy budget approvals.
  • Configuration time set aside to immediately capitalise on new features.
  • Manage projects through operational expenditure, instead of capital expenditure. 

Additionally, we are offering a 5% discount to their hourly consulting rate for customers who purchase more than 20 hours per year as part of their regular subscription. We increase this to 10% for customers who purchase more than 40 hours, 15% for more than 60 hours, and 20% for more than 80 hours per year. 

Please note, if you purchase change support with their subscription, this does not replace the normal support charge in your licence subscription. We will still provide support for bug fixes and other errors without taking time from your change budget. We will use the change support budget for design changes, new workflows and so on. Also, if you use the full change budget in one year, you can still make additional changes, but hours will be billed on a per project basis again. Your change support subscription will invoice and renew your hours at your anniversary date each year.

GICOP changes 2021Download the GICOP whitepaper and stay compliant.

Our whitepaper covers all aspects you need to know to stay compliant with the latest GICOP changes coming into effect in 2021. Submit below form to receive the download link.