APIs Aren't For Integration or You're Barking Up the Wrong Tree

In the usual ritual this morning I stumble across "Sansoro Hopes Its Health Record API Will Unite Them All.” Kudos to Sansoro.

Waiddaminit.

An API is not what you need. A database is what you need.

Here is a ten second intro to what I mean:

"Get me a rock," your Drill Sergeant says

"What kind of rock?” you say, having heard this one before.

"Any kind of rock,” he says, "Just about the size of a quarter.”

There are two ways to solve this problem, first, you can go pick up every rock and examine it and toss out ones that don’t fit the criteria. This is painfully slow and goes by the Name RBAR (Pronounced 're-bär, like the stuff that reinforces the concrete their little developer heads are made from), meaning 'Row by Agonizing Row.'

The better way is to build two boxes, one with holes slightly bigger than a quarter, and one with holes slightly smaller than a quarter and sift all the rocks through both, leaving you with a pile of rocks that fit the description.

Why do I bring this up? The first method, pick up and discard, is called procedural programming, and it is what the startling preponderance of programmers (with concrete heads) use and what Sansoro is proposing. There are about 7,400,000,000 people in the world and procedural just won’t work with that kind of volume. The second is called set based programming. Its what we do here at Sentia and it is the prescribed method for handling data. This is why your "Big Data" guys are not too bright. They use procedural code to sift thorugh large amounts of unordered data. The better way is to order the data, then run queries against it in your database. This is the set based way.  ...and the procedural way takes orders of magnitude more time.

Another problem is that you have to know where the data sits before you can access it. "So you mean Carolinas Medical in Huntersville or Cornelius?” The patient probably doesn’t know where his or her doctor is even if he or she is even conscious at that point.  Worse, is that you can’t get the insights that a single data store can give you (remember the "Big Data" chowderheads, above?). You don't see emerging trends, you can’t link symptoms to diagnoses on a large scale, and your local practitioner/hospital certainly isn’t going to hire someone to give him or her those nuggets of information. Even worse, what Sansoro has isn’t hooked up to anything out of the box, you have to point it at your EMR and hope they have a way to read and write to it or you have to hire someone with that kind of knowledge to figure it out. Basically they just stuck their flag in the sand and said "this is the way to do it.” Ask Sony how that works out.

So yes, the only way to do this is to have one repository and have an integration tool that feeds the repository in the background. Then we can do the searches and run the queries to find the emerging trends and have one place for everyone in the United States (world?) to look for medical records. Look at the blog from 06/03/2016 to see an example of the integration tool we designed, developed and use. Even worse, what happens when the medical community finally wakes up and starts to use SNOMED (look at previous blogs), that is designed to do what they are doing, instead of ICD codes, which aren't? Sansoro will be left in the dust.

Good job, Sansoro, but you’re barking up the wrong tree.

Real Solutions