On the Design of an "Easy-to-Integrate" Care Coordination Platform

Remember that scene in Apollo 13 where they figure out that the air scrubbers are wearing out, and that the astronauts will soon be choking on their own carbon dioxide?

Copyright Imagine Entertainment and Universal Pictures – All Rights Reserved

Copyright Imagine Entertainment and Universal Pictures – All Rights Reserved


Building software for healthcare is a lot like that. That was my face after I settled in and began to understand the complexity of the environments in which our new software would sit. There are dozens, or even hundreds of other applications in a typical hospital system, each of which has its own data, sometimes duplicated, often inconsistent. There are systems tracking patients, care plans, medications, appointments, surgeries, surgeons, nurses, support staff, accounts, billing, and so on. We were going to bring one more application to an already crowded pool party.

download (1).png

Okay, so we’re not the only game in town. There are lots of other systems and we’ll have to get along with them.

A few principles came forward:

  1. Don’t attempt to be the source of truth when there is already another source of truth.
  2. Be the source of truth for the things that you really are the source of truth for.
  3. Don’t be stingy with that data. Share it when necessary.

Now, let’s go through those in more detail.

1. Don’t attempt to be the source of truth when there is already another source of truth.

It’s really tempting when you’re building software to fall into a couple of traps.

  1. My software is better than any other software.
  2. No, seriously, your software stinks.

Clearly this isn’t the case. There’s plenty of good software out there (and yes, there’s plenty of bad software too). This kind of myopic thinking can clearly lead to problems, but perhaps the biggest problem is that this mindset leads to decisions like, “Hey, I know that <insert other vendor’s application here> tracks patient demographics, but it’s really <ugly/slow/painful> so I’ll just build my own patient demographics modules!" This is generally a terrible decision. It leads quickly to duplicated data that’s never quite in sync, as well as wasted engineering time on functionality that wasn’t really necessary. 

In the case of PinpointCare, we flirted with this mindset early on as well. In our defense, it was always in pursuit of the ultimate piece of healthcare software. A great example of how weird it got was when we started talking about the calendar functionality in our application. At this point, we were still laboring under the impression that surgeons were going to log into our application. (On another day, we’ll discuss the concept of naïveté.) Suffice to say for now that we envisioned that there might be some kind of calendar screen that the surgeon could look at, which showed the important dates from the care plans of his or her patients (things like the surgery date, the admission and discharge dates from skilled nursing facilities, and so on).  The conversation went something like this:

“Okay, so the surgeon has all of those dates on the calendar. That’s cool, but what about all the other dates that are important? I mean, if she wants to go shoot a round of golf and block out every Thursday morning to do it, how is she going to see that too?”

“How about this – we let her put other interesting dates on the calendar, like those golf outings. That way she can see if there is a conflict between her tee time, and a patient surgery.”

On the surface, you can see how tempting this is. It seems like great functionality; after all, why wouldn’t you want to get all that data together in one screen. It’s a pain to have to go look at this calendar, and then crack open Outlook to look at the other stuff you have on your Outlook calendar, and then… oh, wait a minute.

2. Be the source of truth for the things that you really are the source of truth for.

Outlook is a great tool. It is described by Microsoft as a “personal information manager," but for most people, it’s the source of truth for their email and their calendar. It has been available for almost 20 years. It has always supported a user calendar, and if you include users of the desktop version, the Office 365 version, and the consumer version, you’re probably looking at around 500 million users.

But, yeah, we were going to build our own calendar. And you’d put everything in it that you would normally put into your Outlook calendar. Because, well… our calendar would be really awesome. More awesome than the one put out by Microsoft. Oh, and let’s not forget the other 500 million users of Gmail (which also has a calendar). Those people would use the calendar in their PinpointCare application too. Totally. Those billion users were ours for the taking!

It was at this point that logic returned, and the conversation turned.

“Are you nuts? Who would possibly choose the PinpointCare platform as their source of truth for their entire calendar? Do we really expect them to log into our application to see when their tee time for golf is?”

Obviously, the answer to this is, no, we are not. And why?

Because we aren’t the source of truth for a person’s calendar. That battle has been fought and won by Microsoft, Google, and a small handful of others. Plus, it’s not our mission. Our mission is to provide the best platform for coordinating patient care, controlling costs, and ensuring better outcomes. So, back to the drawing board.

So what sort of data is the PinpointCare uniquely qualified to handle? Care plan data. Dates that a patient is supposed to move from one care venue to another. Dates that the patient actually did move from one care venue to another. The planned location for that patient care.  The actual location for that patient care. Data necessary to ensure that the patient gets the best collaboration possible between the surgeon, care coordinator, and the post-acute care providers. Data that patients need so that they know what to expect as they progress through their recovery.  

But wait a second - don’t our customers' other systems need some of that data? And don’t we also need some of the data they are the rightful source of truth for too (like patient demographics data, including email addresses and phone numbers)?

3. Don’t be stingy with that data.  Share it if necessary.

Healthcare IT is an amazing, crazy , complicated thing. There are many systems behind the scenes of a typical healthcare practice. The trend of hospital consolidation makes it even harder. A typical hospital system might have several different EHR systems up and running.

This complexity, and the need for linking all those systems up has created an entire industry of HL7 consultants, all standing by to help clean out your wallet integrate your systems.

(Copyright Paramount Pictures – All Rights Reserved)

(Copyright Paramount Pictures – All Rights Reserved)


We got really good at figuring out what data PinpointCare was the source of truth for, and what data it wasn’t, but there are still some overlaps. We still need some data from other systems in those environments. And HL7 was designed for moving around healthcare data.  Obviously, we’d support integrations using HL7 and that ought to do it.  Right?

Well, sort of.

We did indeed build customer integrations from many different EHR systems, using an integration engine as a front end. Customers have their systems send some of the data that overlaps with our platform (typically patient demographics, and scheduling messages, but could be more) into our integration engine and then that integration engine pumps the data into the PinpointCare databases. Simple.

This is where we put another development principle into place that turned out to be a powerful ally.


Now, we understand our software very well. We designed and built it from the ground up, and we certainly understood the inside of it well enough that we could have just built code in the integration engines to just reach deep under the hood, and move the data that was sourced from another system in. That would have been pretty quick and simple. 

And if we did it that way, it would have been pretty much the same amount of work the next time a different customer came along with data we needed in a slightly different format. We could pull out the toolbox again, get under the hood, and get the data integrated.

But we had big plans. We were going to do (and have now done) lots of integrations with lots of different customers. And the work of getting down under the hood and getting that data pumped in, while well understood, was still a reasonable amount of work. And it required our trained mechanics developers to do it. How could we make this a little easier, and allow other non-specialized developers to integrate with us?

download (2).png

To deal with this, we created a series of standardized interfaces to our application. Programmers call them “APIs”, which is short for application programming interfaces. Automobile manufactures call them “gas nozzles." Either way, the effect is the same. Provide a standard interface (the gas nozzle) that allows easy connection to well-known dispensers (the gas pumps found everywhere).

This approach led to a lot of great outcomes for us:

  1. The APIs made it easy for our developers to encapsulate business rules and sanity checking around our database. This helps us to ensure the quality of our data.
  2. Developers working on data integrations didn’t need to know the intricacies of every last detail in the platform databases. They only had to know that the APIs existed, and that they could rely on them working as intended. This is the same reason that you can fill your own car with gas, and not know how to rebuild the whole engine on your car.
  3. By building these interfaces, we were able to look at the platform as a repository for care coordination data and events in a reusable way. This allows us to build our web application for clinicians, the mobile applications for patients and clinicians, and all of the interfaces to our clients’ other applications using the same reusable components.  This is a little like buying one automobile engine and multiple different car bodies (say, a sports car, a family sedan, and an SUV), and then being able to simply swap the engine from one body to the other, depending on your current needs.

Perhaps most importantly, this mindset has ensured that our platform is very connectable. The fact that it isn’t one large, monolithic application has allowed us to service interesting scenarios in very complex healthcare environments. One simple example is allowing other systems to create a new patient care plan in our system through these APIs based on the scheduling of a particular surgery in a hospital. A more nuanced example might be to then further customize the recommendations for the care plan lengths of stay and visit counts based on internal machine learning algorithms, or to recommend specific patient learning materials based on physician preferences. Because we have allowed any system to do pretty much everything that our web and mobile applications can do via those standard interfaces, the possibilities are truly endless.