Posted by: adelvecchio
application programming interfaces, electronic data interchange, Interoperability, NIST
In the eighties, when organizations first used electronic data interchange (EDI) to open up integration at the enterprise’s edge, systems weren’t exactly agile — organizations had to recompile, retest, and re-engage with their partners whenever anything was updated.
Enterprise application integration (EAI) and business process management emerged in the nineties, and organizations were able to reuse the interfaces they offered their partners.
EAI was succeeded by service-oriented architecture (SOA) in the next decade. SOA made collaborating web services — like simple object access protocol — possible.
But even SOA had problems. Architects had to build a framework that developers had to be trained in, and whole libraries of interfaces and structures had to be set up. Only a mature IT organization could use it as an agile, cost-effective long-term option.
Today representational state transfer (REST) is the new de facto architectural model for mobile enablement, cloud enterprise enablement, and for reusing enterprise service capabilities on new endpoints. Unlike SOA, REST:
- Doesn’t have framework-knowledge demands
- Allows the enterprise to enable a user at the edge to use an endpoint to deploy services and issue commands (i.e., get, put, post, and delete)
- Is stateless
- Features caching
- Enables layers
- Uses less bandwidth
- Scales to billions of conversations
All of these enhancements call for application programming interfaces (API) management and platforms — a suite of analytics, traffic control, and performance tools that offer the best ways for your organization to:
- Ease its way into this new world
- Reconcile the legacy of old SOA services, old remote procedure calls, and legacy EDI structures to meet the demands of mobile and cloud
- Build out a reliable, centrally-manageable structure
- Govern APIs during the development lifecycle and in operations
To make the most of API, you must first map out your current policies, determine what’s missing, and do a risk assessment using the National Institute of Standards and Technology guidelines. You’ve got to ensure that policy was respected, adhered to, and used correctly, and that your network can successfully sustain the scrutiny of an audit — the hallmark of effective governance.
Next, you must issue credentials. Recognize, however, that credentialing is now a much more complicated issue than ever before, and that you’ll need to decide which manner of credentialing is right for your organization. Will you:
- Use secure email attachments with a health information service provider (HISP) to enable users to securely share documents?
- Use an online certificate status protocol to validate a healthcare provider’s good standing and their HISP membership?
- Use federated IDs to allow a healthcare provider to log in with the same credentials they use to log into their own network?
There are a variety of security protocols, alignment, and brokering tasks to consider, and they all fall into a common pattern. When you understand that pattern, the value of API management and platforms will be clear.
Once all of the above is in place and a foundation is set, you’re ready for interoperability: the holy grail of health IT. In my next post, I’ll explore how an organization can use a multiphase-delivery roadmap to chart a course to a future where connected, collaborative-care communities can engage their patients’ healthcare activities and ensure that primary care providers always have up-to-date information.