November 2008

"We expect to build the project ecosystem by encouraging the healthcare trading partners to participate as contributors, members of the project advisory council and early adaptors of tools delivered by the project."

Open Health Tools

The Open Health Tools (OHT) initiative is creating an ecosystem focused on the production of software tooling that promotes the exchange of medical information across political, geographic, cultural, product, and technology lines. At its core, OHT believes that the availability of high-quality tooling that interoperates will propel the industry forward, enabling organizations and vendors to build products and systems that effectively work together. This will "raise the interoperability bar" as a result of having tools that just work.

To achieve these lofty goals, careful consideration must be made to the constituencies that will be most affected by an OHT-influenced world. This document outlines a vision of OHT's impact to these stakeholders. It does not explain the OHT process itself or how the OHT community operates. Instead, we place emphasis on the impact of that process within the health industry. The catchphrase "code is king" underpins this document, meaning that the manifestation of any open source community lies in the products and technology it produces.

OHT Stakeholders

To better understand OHT and the impact OHT can have within the industry, we will consider the interaction with three stakeholder groups that will be consuming or using OHT technology. It is important to highlight that each of the below categories focuses on individuals and not organizations. Any given organization may have members in any or all of the categories below, either as employees or as beneficiaries/customers.

End-users: individuals that are directly interacting with systems that contain OHT code. These include caregivers, patients, administrators, case workers, and any other individual providing or receiving healthcare services or benefits using healthcare information technology (IT) applications.

Operational users: individuals that affect the purchase, deployment, operations, maintenance, and sustainment of healthcare IT systems and solutions within the organizations they support. This would include CIOs, system administrators, department managers, requirements managers, health informaticians, and IT staff.

Developers: individuals that design and produce working, executable implementations of software code that run on a machine. This includes developers, software engineers, product architects, and systems integrators.

From the above definitions, it is fairly clear that these communities are distinct and will have different expectations, interests, interactions, and ultimately different success measures vis-a-vis OHT. It is reasonable to anticipate that healthcare organizations will have presence across all categories and even some individuals are likely to span across groups. The next section will clarify these differences.

Stakeholders' Expectations

To better understand the stakeholders and their expectations, we discuss the following:

Current business challenges: to end-users, healthcare information is currently not available where, when, and in the format it is needed. There are inconsistencies and differences among systems with long wait times for IT staff to address these issues. For operational users, best-suite applications don't address all the business needs and best-of-breed applications create integration challenges and added expense. Inconsistencies in operational needs foster duplicative infrastructure, staffing, and support. For developers, significant investments are required to build any software infrastructure that is not core to their product offerings. Explosive heterogeneity further complicates development, especially for application programming interfaces (APIs) and standards support.

Operational objectives and expectations: end-users expect that systems should be reliable, easy-to-use, user-customized, flexible, and support new modalities such as mobile computing, cell-phones, and the Internet. In short, "IT shouldn't make my job any harder." Operational users expect systems to: i) be operationally reliable; ii) perform well; and iii) comply with industry drivers such as government mandates and security considerations. They also look for the ability to flexibly deploy, monitor, and manage installed systems. Developers expect software tools that provide flexibility and the ability to delivery high-quality code quickly. They also have a preference for tools that make tasks easier or which eliminate tedious chores and allow the developer to focus on the task at hand.

Anticipated benefit from OHT: end-users expect improved access to healthcare information and interoperability among vendor and supplier packages. Operational users expect a reduced integration burden, improved interoperability among off-the-shelf packages, and a reduced support burden resulting from more aligned industry offerings. Developers expect high-quality tools and components that "just work", improve productivity, and improve time to market delivery.

Point of intersection with OHT: the interaction with end-users will be indirect as they will use systems that have OHT components. Interaction with operational users will be direct as they will use tools and applications built using OHT technology. It will also be indirect as they specify purchases complying with industry standards implemented by OHT and as vendors are incented to engage in OHT. Developers will have direct interaction as they will use OHT tools, components, and other contributions to the OHT codebase.

Success measure: end-users expect reduced burden, improved job performance, and ubiquitous access to information where and when they need it. Operational users expect improved ability to effectively integrate products and interoperate within and outside of the business. OHT expects a controlled growth in the number of developers.

Healthcare Organizations and OHT

As a market sector, healthcare is particularly complex. These complexities are self-evident within healthcare organizations, as any given organization is likely to have most if not all of the stakeholders identified above. For OHT to add value to healthcare organizations, we must look beyond organizational labels.

To better understand the nature of the interactions of different organizations with OHT, and the business value that may be realized by participating, we provide an analysis of the touch points of different organizational roles with the OHT community. Note that these organizational roles are categorized by function, such as providing care or paying for services, and not by the organizations themselves. Quite simply, this was done as many organizations take on multiple roles, especially when differences across countries are considered. We do not discuss a governmental role as we instead elected to enumerate the different types of activities government organizations may play.

Provider, payer, or public health organization: this role receives the following benefits from OHT involvement: i) the opportunity to incent and leverage co-investments with peer organizations; ii) improved de-facto interoperability among commercial applications; iii) improved ability to influence and impact commercial vendors; and iv) influence on OHT priorities. Contributions to the OHT community include use cases, subject matter experts, organizational requirements, development resources, funding, and code contributions. OHT will provide the following technology outputs: i) applications as demonstrated proof-of-concept or architectural prototypes; ii) tooling to facilitate custom integration or development; and iii) marketplace vendor product offerings aligned with requirements needs.

Oversight and regulatory: benefits include: i) reduced cost to test and assure implementations due to a shared codebase; and ii) improved marketplace compliance resulting from requirements support in an open source software (OSS) codebase. This role can contribute quality assurance, conformance, testing, subject matter experts, and requirements. It can also help to establish OHT priorities. Received technology outputs include the establishment of standard test harnesses and an OSS codebase conformant with oversight expectation.

Product vendor: benefits include: i) reduced cost of non-differentiating software product infrastructure investments; ii) increased market share resulting from overall community growth fostered by OSS; iii) improved quality resulting from a vetted OSS codebase; iv) improved sight lines to the needs of a potential customer base; and v) market branding and product positioning. Contributions can include code and development resources.

Integrator: benefits include: i) reduced integration risk resulting from enhanced vendor product interoperability; ii) improved sight lines to the needs of a potential customer base; iii) the ability to influence OHT priorities; and iv) market branding and positioning. Contributions can be resource contributions such as personnel or capital, subject matter experts, code, integration and implementation experience, testing, and quality assurance. Technology outputs include a leverageable codebase in the form of tools and applications.

Standards development organization: benefits include: i) reduced or eliminated custom tooling; ii) improved marketplace product support; iii) improved ability to develop standards; iv) improved value of healthcare standards produced; and v) the ability to influence OHT priorities. Contributions can include use cases, subject matter experts, organizational requirements, and funding. In return, the technology received includes tooling which supports the standards development process, healthcare standards-compliant market offerings, and an OSS codebase.

Foundation: benefits include tangible health community impact from investment and the ability to incent mainstream marketplace change aligned with the Foundation's objectives. Contributions include influence on OHT priorities and funding to the OHT community. Technology benefits include a leverageable open source platform codebase, tooling, and interoperable commercial marketplace product support.

Conclusion

Spanning beyond cultural, organizational, and geopolitical lines, healthcare organizations the world over share a tremendous number of qualities and objectives. Objectives such as improving care quality and outcomes are shared needs. Fostering information quality, availability, and access is essential to success. Recognizing marketplace heterogeneity while still promoting interoperability is key. OHT fosters these objectives by providing an ecosystem where organizations across the domain can collaborate, engage, and ultimately produce solutions that work to realize these goals.

"Code is king" has tangible impacts and implementation matters. By establishing a common, open, available code infrastructure that can be used by organizations, vendors, and integrators, the bar to interoperability is raised and the costs and risks of doing so are reduced. OHT establishes an ecosystem into which a huge variety of constituents and organizations can effectively engage. This is of paramount importance, as it fosters the environment needed for collaboration, co-investment, and ultimately the development of solutions that address the diverse needs of the community while fostering the sharing of ideas and investment burdens.

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!