Interoperability is generally more popular among those who mandate it than those who get stuck with the actual implementation. It demands meticulous planning, protracted implementation, monumental effort and convoluted problem-solving - not only to put data sharing technology in place, but also to create policies for sharing, establish common data standards and align operational procedures to coordinate care. Leaders of collaborative initiatives in public health and human services too often see the initial excitement evaporate and the ranks of participants dwindle as they somehow forget their initial commitment to make the initiative succeed.
But a health and human services interoperability initiative can't succeed without participants who grit their teeth and commit to achieving the initiative's goals. Interoperability requires collaboration because health and social services organizations must align their business processes toward the common goals of managing costs and improving care for consumers. The expertise that CIOs have - not only in information management, but also in project management, change management and business management - are essential for promoting the kind of collaboration that leads to interoperability.
While clinical care staff members generally find ways to communicate across program boundaries and coordinate care at the case level, interagency coordination too often remains unattainable. Aside from the understandable complications that arise from large-scale coordination, it may be easier for individuals to coordinate their efforts in this small-scale context because their risk of losing control is low.
By contrast, in large, multientity cooperative projects that aim to standardize data and operations, organizations often perceive the risk of losing control to be higher. Stubborn personalities and interdepartmental politics can force anyone with pie-in-the-sky notions about interoperability to confront the difficult reality of implementation. Any movement away from isolation and toward interoperability is bound to bring change that will be perceived as, or that may in fact, be invasive. The benefits of cooperating come at a price - the responsibility to coordinate and communicate, which not all participants will find equally convenient or desirable.
Terminology may also dissuade participants from full cooperation in a project. Calling an initiative an "integration project" implies a possible threat to the independent functions of participating entities, absorbing their unique identity into a homogeneous blob. By applying a little PR magic, not to mention describing the project goals more accurately, CIOs can call it an "interoperability project" and imbue it with more positive connotations. This "interoperability" terminology indicates an environment in which unique, independent organizations adjust their functions for the sake of cooperation. And this is, in fact, what interoperability projects aim to do. Even organizations that carefully guard their independence may be drawn to working together because of curiosity, a fear of missing out on the project's momentum and resulting benefits, and a desire to stay involved in protecting their turf. If CIOs promote interoperability projects well, they can motivate even skeptical organizations to join in, persuading them that, in the long run, they will retain far more control if they fully participate than if they opt out.
At the outset of an interoperability initiative, public CIOs and other project leaders must advise all participants that the project will require their responsible commitment to reduce the isolation of individual systems and increase accountability. Achieving these outcomes involves many changes, especially new forms of collaborative decision-making and information sharing.
For interoperable solutions to be successful, the participating groups must take a few important steps to make their cooperation fruitful:
- Clearly define the goals of their collaboration and the metrics that will be used to measure how well these goals have been achieved.
- Agree that within the framework of the joint initiative, common interests will take precedence over the interests of individual participants.
- Develop policies and procedures that are enforceable but that do not undermine the autonomy of individual entities.
- Make communication effective and unambiguous while keeping sensitive data secure.
Interoperability Governance: Who's in Charge?
To facilitate multientity collaboration and direct the business changes required, participating groups must choose representatives who will form a governing authority. In CIOs' leadership roles in health care and social services agencies, they likely will be called upon to govern projects as separate groups move toward interoperability.In Key Principles of an Interoperability Architecture, the European Public Administration Network (EPAN) defines interoperability governance as "the ownership, definition, development, maintenance, monitoring and promotion of standards, protocols, policies and technologies" of the government interoperability framework (GIF). EPAN recommends organizations that oversee aspects of the GIF be independent, unbiased groups with interoperability expertise to inspire participants' trust. They should be responsible for developing standards, monitoring compliance and advising agencies as they develop strategies to coordinate services. Ultimately they should work toward achieving interoperability among all public services.
To think about the implications of this kind of governance model, imagine a Department of Health and Human Services (DHHS) in a state that uses a county-administration model. While not responsible for a particular program's management, the DHHS coordinates the efforts of agencies with diverse specialties, such as behavioral health, developmental disabilities, children and youth, drugs and alcohol, and health and aging. These agencies' budgets are a combination of federal, state and local funding, and sometimes grant money. These agencies are subject to different state bureaucracies that often impose idiosyncratic guidelines for program administration, reporting and fiscal accountability. In certain instances, the same agency may be funded by two related but independent state offices that require funds to be used only for office-approved benefits. For example, a state Medicaid program may fund behavioral health care for county residents, while the state office of mental health funds behavioral health care for non-Medicaid consumers, and the state office of drug and alcohol programs funds substance abuse services for non-Medicaid recipients. The state offices' spheres of authority and their relationships to the other offices aren't easy to untangle, to put it mildly.
When the DHHS initiates cooperative efforts among its individual departments, the departments readily support the undertaking. But after a few months of planning, the participating departments start asking the tough, rubber-hits-the-road questions: What existing department or what new entity is in charge of the project? What entity will be responsible for the interoperable system once it's implemented? Who has the right to arbitrate disagreements among the participants? Who will resolve discrepancies from data submitted by different participants? Is there an exit strategy for a department that doesn't benefit from the initiative? How will departments be compensated for their efforts to set up the interoperable system, its policies and procedures? How will the cost savings from the initiative be allocated?
Designating the DHHS as the administrator of the interoperable system is logical, but on top of the department's usual duties, it piles the extra work of overseeing the new system. Alternatively elevating an existing department to be the administrator may not go over well with the other departments.
Because of the complicated relationships among participating organizations, it makes sense to create a new entity responsible for instating and managing the new interoperable system. In contrast to EPAN's recommendation that this entity be an independent group of interoperability experts, project participants may prefer to establish an authority that's more familiar with their needs. Public CIOs are uniquely positioned to take part in this new governing entity. They can demonstrate sensitivity to stakeholders' needs while formulating strategies for overcoming information silos and enabling more cost-effective business functions through technology.
Going back to the example, the newly created authoritative entity could be a board of directors with representatives from each department; the DHHS, including its CIO and other senior-level officers, could preside over the board. Board members may choose to consult interoperability experts to supplement their incomplete knowledge and address gaps in their experience, but the board retains management and oversight responsibilities.
As the concept of interoperability gains momentum in public health and human services, CIOs should focus on dedicated cooperation and representative governance as two crucial contributing factors that will help translate the concept of interoperability into practice. Using their knowledge of data exchange and position of authority, CIOs can help create a vision of interoperable systems and organizations, and also deal with the brass tacks of implementation by encouraging cooperation among project participants, managing organizational changes and providing appropriate governance. Their efforts, in turn, will yield more interoperable health and human services programs that deliver better services on tighter budgets.
