What is an API really?

APIs for … Intelligent People!

We love the Dummies© series of books, but being unfamiliar with something new does not a dummy make.  For perspective, here are some background facts about the three biggest realms in science affecting economic activity over the last 2000 years:

1. Medicine – Hippocratic Oath, (350 BC)

2. Business Finance – Financial Equation, (500 AD)

3. Computer Science – First Computer, (1954 AD)

Computer Science and IT are still in their infancies. Do your eyes glaze over when a techie raves about Application Programming Interfaces generally called APIs? Let’s unpack the meaning and purpose of an API.

An API Analogy

You have standard electrical outlets in your home. You can plug in any household appliance into that outlet that meets the Underwriter Laboratory Electrical Standard for Home Appliances, (i.e., UL 60335) 

1). Do you care about knowing the UL Standard Specification, (i.e., UL 60065) for your cell phone charger? 

No? Me neither.

When you plug your cell phone charger into the outlet, do you care how the electricity is transmitted from the electrical company through the outlet to your cell phone? 

No? Me neither.

Does the electrical company care what brand of cell phone is on the other end of the plug? No. Nor does the cell phone care who supplies the current. How these two things relate:

· The wall outlet shape and voltage is the API for the electric company – how you connect to them as a vendor

· Underwriter’s Laboratory Specification: the rules for exchanging electrical current

· Electrical current: the data to be sent

· The electrical cord and plug: is the API for the appliance

We see in these analogies of electricity a separation of the need for understanding the details of what goes on behind the wall plug or in front of the wall plug.  The requirements have already been spelled out and everyone on both sides of the plug plays by the rules.  Application Programming Interfaces, (APIs) differ from electricity in that they’re implemented in software rather than hardware, but it’s the same principle.  With software, we have the same need for standard specifications, data, and application endpoints for data-exchange. You don’t have to be an electrical engineer to charge your cell phone. You don’t have to be a software engineer to use your cell phone app. APIs enable your ability to use them both without having to know or understand their underlying complexity. Lovely.

So where does the real beauty lie in the software world? 

When a community of users can write add on software applications – the APIs –  to supplement the capabilities of a major EHR system, then the Commercial Off the Shelf Package, COTS, become customizable by any developer. Having a library of these APIs could mean the difference between having a 90% functional solution with a COTS and having a 100% solution. Maybe you have heard the saying that most software system achieve 90% functionality and stay there. The right APIs can bridge the gap of the last 10%.  Although EHR vendors try, a COTS system cannot foresee and meet 100% of the functional needs of their entire user community.  The larger you are and the more unique your mission is, the greater the likelihood is that there will be functional gaps between your needs and the COTS package you buy. Thus, by creating your own APIs, you can add new appliances / functions to plug into the EHR’s wall plug. You can extend the vendor’s software to do exactly what you want.