Defining the basics

[02:45 - 05:00]

What is an integration?

"An integration in its simplest form is just a way of connecting two pieces of software together. And typically, what we actually mean is moving data from one system into another system.

So an example might be if an applicant tracking system pushes the name of an employee into a HR system, which system “owns” that piece of data? So, if they had different bits of data in them, which one is the true bit of data?”

What is an API?

“API stands for an Application Programming Interface. But all that means is there is a special part of most software, which is specifically designed for communicating with other pieces of software.

It might have a user interface for connecting, for communicating with people via a web browser. There will be a third part of that system which is specifically optimised for communicating with other systems."

Sometimes these parts are “public facing.” These are, generally speaking, easier to integrate with than other systems."

Types of integrations

[06:45 - 15:00]

After making sure that integrations and API were clear terms, Ben went on to explain why some integrations take more development effort than others and when it is important to differentiate between types.

"To make the most of the integration process, you’ll have to discern the type of integration needed for the best outcome. That means knowing the difference between what’s possible and the pros and cons of implementing any of the following solutions." 

One-way or two-way integrations?

“One-way integrations are often the simplest integrations to build and so have the highest likelihood of success.”

“In a one-way integration, one system needs to transfer data to another system, but there is no requirement for that second system to pass updated data back to the first”

So, a typical example of a one-way integration might be an Applicant Tracking System to a HR system: 

1. The Applicant Tracking System manages all of the data while somebody is being hired. 
2.  Once that person has been hired, you would then take that data and push or pull it into a HR system. The HR system has no need to push data back into that applicant tracking system.
3. Once the data has been passed over, the Applicant Tracking System ceases to be the “source of truth” of that data.
4. The HR System becomes the source of truth.

Two-way integrations are more complex, but they will mean two systems are “communicating” with each other, i.e. passing information back and forth.

So, the decision that has to be made is: How often does this need to happen? If the answer is "always", that is a real-time integration. If it's "occasionally," then you need a batch-update integration.

Real-time or batch-update integrations?

“The important thing when deciding between real-time and batch integrations is: 'Do you genuinely need the real time data? What is the benefit of the real time data versus the batch data?' 

Because in quite a lot of situations where we might start off thinking that we absolutely need something, in real-time, which might be more complex and more expensive to build as an integration, in practice, all the same benefits can be realised with a batch integration, which might happen every hour or even every 15 minutes.” 

Which systems should “speak to each other” in Social Care?

[16:00 - 22:00]

Ben goes on to explain the Social Care Tech Map and which systems would ideally be communicating to ease the admin burden on teams, save time, minimise mistakes and streamline cross-departmental efforts.

“Here you have your core people systems, so your HR, your Rostering, and your Payroll system. And then you have the systems that sit around them, like for example, eMAR, Digital Care Planning.”

“So you probably need a two way integration, in particular for Digital Care Planning which may need to push into Scheduling what the minimum safe staffing levels are, and it's possible that Scheduling will need to push some data back into Care Planning around what actually happened.”

So, while two-way integrations are typically more complex, this is one example among many where it makes sense to do the upfront planning and work to integrate these two systems. It will mean that the workload is lifted across multiple teams and all reporting is up to date.

When considering the wider tech ecosystem i.e. Scheduling, HR, and Payroll, Ben went on to explain:

“This is where the majority of the complexity sits because things like HR and Scheduling need to know a huge amount about each other.

So, if you take holidays as an example, the HR system is probably responsible for understanding what is somebody's contract, what is somebody's holiday allowance based on that contract. But in practice, if for example, you have casual employees or people on variable hours contracts, the HR system will need to understand a lot about the schedule to work out what that holiday should be.”

Generally it's very, very difficult to separate out HR and scheduling because they need to operate on exactly the same data. And from an operational perspective, a lot of the inefficiencies that we've seen are where these systems have been completely separated.”

What to ask before committing to an integration?

[23:00 - 28:00]

One of the most popular questions from the audience was around being able to tell in the sales process whether an integration would work well when implementation started. 

“As part of an integration, you'll want to do a very detailed taxonomy of what data sits in each system and how it maps between those systems.”

Then you'll want to ask:

“Who's going to own that integration? Is it going to be owned by one of the vendors? Is it something that you're owning in house, if you have technical capability in house? Or is it something you're outsourcing to a third party integrations company? Who is owning the build of this integration?”

However, Ben also highlighted another question that is just as important:

“What doesn't necessarily get asked is who's going to own the maintenance of that?”

“Generally, if they're vendors that follow best practices, they'll give notice of 6, 12, 18 months, 2 years, that changes are going to happen and these might come with an additional cost.

If you’re going through an integration now, consider using this same map when talking to vendors to understand exactly what your integration is going to look like and who owns the responsibility of maintenance in the long-term."

(The above dialogue has been softly edited and condensed for clarity.)