What is An API and Why It Matters to Social Work

Technology is making the world shrink and this is good thing for social work.  The more we can use technology to increase connectivity, the better.  Technology between this blog and other apps and services exists but quite honestly I have no idea how this works.  My interest in technology has lead me to want to learn a little more.

It turns out the “secret sauce” is what is called an API or Application Program Interface.  Googling information about this was quite overwhelming but I highly recommend your take the little under four minutes to understand what API’s are via  this MuleSoft video ….

 

You might be wondering, what does this have to do with social work? While some might be figuring this out and some might be tuning out a bit. You might be thinking, there is no way I am going to be programming. It’s an important bit of information technology we should, at best, be simply aware of.  To ponder how things can connect and this code can be plugged in to shrink the world is important. Social work should be a voice in developing these solutions.

The next level might be (where I am) is how to you get disparate systems within social work, healthcare, etc… to talk to each other?  Well… it gets complicated.  As a care manager there are three systems I enter data into. There is a medicaid database for enrollment, one for an initial assessment, and one for the electronic health record. The only one way connectivity between the three is the enrollment database “talks” to the EHR a bit.  But the initial assessment (about 50 question check boxes updated every six months) doesn’t talk to either.

These barriers seem to be at the state and regulatory level (way above my pay grade).  These are the things program designers and regulators should be thinking about. It is my experience they are not. As the MuleSoft video points out how can we create “butlers” or “concierges” between these systems. I would like to re-frame it and say that desperate electronic systems need social workers.

One of the companies that specializes in increasing connectivity between healthcare systems is Redox Engine. Earlier this week I ran across their blog post which talked about the unique challenges of creating API’s for connectivity.  If we are talking about HIPAA protected data then systems need to develop legal and security understandings.  There are other considerations such as narrowing the vast amounts of data between systems and make them usable for billing/clinical care.

Another project worth noting is Open Referral. They are attempting to “develop data standards and open platforms that make it easy to share and find information about community resources”.

These are conversations that social work should be at the table for.  We are oexperts in getting complex real life systems to talk to each other. We should be a voice in developing code to get systems to talk to each other.  So make friends with the people in the IT department, talk about barriers to connectivity. Get on the committees at work seeking to drive these solutions. Seek out people that are solving these problems. Be a voice for policy and regulatory changes.  Or for the really ambitious learn the coding yourself or partner with an information technologist to develop your own solution.

Technology continues to offer bright future for our work, however social work needs to be part of the solution. Having a butler between technology services is nice but having a social worker is better.