Interoperability is one of the hottest buzzwords in government.  It is harder to say than chrysanthemum, and yet I hear it flowing effortlessly out of the mouths of our leaders across all sectors.  Everyone wants it, yet it seems to evade a precise definition and means different things to different people.  I offer that is just how it should be.

Just what makes interoperability so desirable?  Interoperability supports the information sharing and coordination that are critical in improving services to our constituents and maximizing our programs’ performance. Interoperability supports goals like streamlined eligibility determination and coordinated program enrollment which serves the beneficiary while also improving government stewardship by reducing redundancy and waste.  Such benefits are magnified the more organizations invest in interoperable solutions.

While my career in the human services field is just beginning, my work in government interoperability spans a decade.  Over that time I have learned that interoperability is about much more than technology – it’s about embracing a relationship based on sharing, collaboration, and partnership.  Without these shared values interoperability, no matter how you define it, is incredibly difficult to achieve.  In other words, interoperability is a difficult thing to simply mandate.  In any scenario there can be a litany of reasons given for why interoperability is not needed or even risky.  But there are always compelling reasons to the contrary, many of which are rooted in a simple truth – interoperability is good government.

Interoperability: “leads to connected government, and represents a shift in philosophy from building monolithic, stovepipe systems toward modular, reusable, and more integrated systems. ..“

“…means data sharing that can be initiated in a matter of days instead of months or even years…”

and

“…reflects the idea that government programs are all inter-related and should not be managed in a vacuum. “

So how do I define interoperability?  For me, it’s easiest to define based on the end results, which include information sharing, shared services, and system integration. Achieving these outcomes requires adherence to common frameworks that include interoperability as a key business requirement.  Variations in the business, policy, and technology environments will determine the specific interoperability components that are meaningful in your domain, but I find the following list to be broadly applicable, and therefore a useful starting point for discussion.

  1. Policy and Business Rules
  2. Architecture
  3. Transport
  4. Data
  5. User Interface

Policy and Business Rules

Policy alignment is a critical precursor to interoperability and is an element often neglected -- possibly because it can be the most difficult.  Yet it is these policies (which include legislative/legal directives) that set the goal posts for what can be achieved.  By examining these factors across programs and organizations, we can take advantage of natural alignments in business process, program goals, and end-user workflow to deliver functionality that meets the needs of multiple stakeholders.  We can also identify inconsistencies or gaps in policy that must be resolved before interoperability can be achieved. 

In the best case, we are even able to use shared/aligned policies to electronically enforce business rules.  For example, if consensus can be reached on which agencies need access to HIPAA-covered data and under what circumstances, the system can consult a rules engine to determine whether the requestor has permission to view the data.  Here the problem of achieving interoperability has been reduced to ensuring that all participants in the exchange agree to abide by a common set of data access rules.  This can alleviate the problem of negotiating point-to-point data exchanges, each with different requirements.  This obviously gets very time consuming and costly; especially once the lawyers get involved!  The challenge of ensuring protection of privacy and confidentiality across human services programs is one that ACF has already begun to address, which you can read more about here.

Architecture

Architecture implies a thoughtful planning process that is as much strategic as tactical.  There are many different kinds of architecture in IT, with numerous examples at the federal level, starting with the Federal Enterprise Architecture (FEA).  Enterprise Architecture (EA) has been around for years.  A major challenge when using EA for interoperability projects is defining the ‘enterprise’ that fully encompasses the scope of the effort.   An enterprise may include many organizations and even many different lines of business.  EA can be compared conceptually to a building blueprint that describes the major features and characteristics, such as the overall dimensions, size and number of rooms, location or doors and windows, etc.  A blueprint is necessary but not sufficient on its own to build a house (you also need plumbing and electrical diagrams) much in the same way that EA is a useful planning and design tool, but does not itself guarantee interoperability.  It does, however, reinforce the interoperability concepts of modular design, component reuse, and standardized interfaces.

Organizations like the National Association of State Chief Information Officers (NASCIO) have pushed to adapt these concepts at the state and local level, and indeed states often lead with respect to IT best practices.  NASCIO is a member of an advisory committee that I worked with at DOJ that created the Global Reference Architecture (GRA) in the criminal justice field.  Architecting our systems in a way that enables shared services, common APIs, and reusable software components will virtually guarantee a platform that is robust and ready to meet both current and future interoperability challenges.

Transport

Transport addresses the actual mechanism used to move data from sender to receiver.  In technical terms, this typically maps to TCP/IP protocols, but in more practical terms we sometimes think of this as the services layer (in an SOA sense) in that it defines the method for requesting and accessing services between systems.  There are many common choices that software developers will be familiar with, such as SOAP vs. REST.  These choices impact interoperability, because different systems either need to agree to use the same transport mechanism, or we need something between them to translate. 

Different developers choose different means of connecting systems more as a matter of preference than of technical superiority.  But in an environment where we must connect systems that are developed independent of each other, and without the benefit of a shared planning process, sometimes you must accept that the best solution is the one that works.  Some of the more successful mission-critical projects still rely on periodic bulk data upload, sometimes over email.  That is not necessarily the way I would have drawn it up, but it works! 

Transport also includes non-functional requirements like security and encryption, which are extremely important for many of the sensitive data sets managed by government agencies.  These topics require significant and careful attention before expanding access to systems and data.  For those interested in diving deeper, one of the more innovative projects I have seen lately with respect to security and identity management is Trustmarks.

Data

Government has probably been most successful in addressing the data exchange requirements of interoperability projects.  Many ‘domains’ within government have created their own data models to facilitate information sharing within their communities.  Health Level 7 (HL7) provides a standards framework for the exchange of electronic health data.  The Common Education Data Standards (CEDS) were created to improve sharing of education data.  The Global Justice XML Data Model was developed by criminal justice agencies to share law enforcement, court, correctional, and related data across the criminal justice system. 

However there still remains the fundamental problem of how to translate information across domains that have unique vocabularies.

So here’s the good news!  The National Information Exchange Model (NIEM) has stepped in to solve this problem bringing together many domains across government, including human services, to drive consensus on common data terms, definitions, and relationships.  NIEM is very stable and uses a mature governance process to drive the model.  The reason I am so supportive of NIEM is because it solves the problem of connecting the space between existing models, while leaving those models in place, which truly is one of the key value propositions of interoperability.  It allows us to maintain local control of our own systems, while embracing collaboration and data sharing.  Human Services has embraced NIEM, with some exciting progress to show for it. 

User Interface

The end-user interface can often make or break an interoperability project.  The interface is what actually delivers software services to the user.  Ideally a user interface will be intuitive, user-friendly, integrated, and seamless.  If a user must break their workflow to retrieve additional data, say by signing into a separate system, then interoperability has really failed to deliver on its promise. 

Users also want to see a clean interface, with all the information they need, and none that they don’t.  They also want to access these systems on their own terms, which means desktop, laptop, tablet, smartphone, and other devices.  We can no longer make assumptions regarding the preferred mode of access by our users. 

Analytical tools need to be right-sized to the task, and should not be constrained by lack of access to the underlying data necessary to perform the analysis.  You also don’t want to see your analysts spending more time acquiring data than analyzing it, which is all too common.  Many would not consider the user interface to be part of the interoperability equation, but it cannot be ignored because it truly is where the proverbial rubber hits the road.

Conclusions

So what does all this mean?  First, it means interoperability is rarely easy.  There are many factors that can influence the success of an interoperability project.  However, the rewards are significant.  And there are numerous resources available to learn from, gain inspiration, and take meaningful steps toward interoperable solutions. 

Interoperability means connected government, and represents a shift in philosophy from building monolithic, stovepipe systems toward modular, reusable, and more integrated systems.  Interoperability means data sharing that can be initiated in a matter of days instead of months or even years.  It means democratizing data and systems, and reflecting the idea that government programs are all inter-related and should not be managed in a vacuum.  Interoperability means open systems, but not by simply throwing open the barn doors.  We have almost limitless flexibility to share our data and services as we see fit, but also the tools to control and manage access in accordance with applicable laws and policies.  It means simplified and streamlined government that operates with transparency, efficiency, cost effectiveness, and dramatically improved citizen experience.
Interoperability is all these things and more, which certainly makes this an exciting time to be in the business of human services interoperability.  In future blogs, I will discuss ACF’s Interoperability Initiative, current resources, and future plans to help make interoperability a reality.  Stay tuned!

News Source: 

Health and Human Services, Administration for Children and Families, Blog Post by Chris Traver, Senior Advisor for Information Sharing, Office of the Assistant Secretary, on 19 April 2016. Chris Traver was recently hired as ACF’s Senior Advisor for Information Sharing, and will be responsible for managing ACF’s Interoperability Initiative working with various ACF and HHS operating divisions, state and local partners, and the private sector to make human services interoperability a reality.  After nine years spent working on related issues at the Department of Justice, Chris is new to the human services field and would appreciate your feedback and ideas on where ACF should focus its efforts to promote broader information sharing and system integration.  Reach Chris at christopher.traver@acf.hhs.gov