Open Source Integration Engine
The Open Health Tools (OHT) initiative aims to create a software tooling ecosystem that facilitates the sharing of medical data across political, geographic, cultural, product, and technology lines. At its heart, OHT believes that having high-quality, interoperable tooling will move the industry forward, allowing organisations and suppliers to create products and systems that work well together. As a result of providing resources that just function, this would “lift the interoperability level.”
To achieve these lofty goals, careful thought must be given to the people who would be most impacted by an OHT-influenced environment. The effect of OHT on these stakeholders is outlined in this paper. It doesn’t go into detail about the OHT process or how the OHT group works. Rather, we focus on the effect of the mechanism on the health-care sector. The term “code is king” runs through this text, implying that every open source community’s manifestation is found in the goods and technologies it creates.
Stakeholders in OHT
To get a deeper understanding of OHT and the effect it can have on the market, we’ll look at how three stakeholder groups can communicate with the technology. It’s worth noting that each of the above categories focuses on people rather than businesses. Members of any given entity can fall into one or more of the following groups, either as workers or as beneficiaries/customers.
Individuals that communicate directly with applications that contain OHT code are referred to as end-users. Caregivers, patients, managers, case workers, and anyone else who provides or receives healthcare services or benefits through healthcare information technology (IT) applications fall into this category.
Individuals that have an impact on the acquisition, implementation, processes, maintenance, and sustainability of healthcare IT systems and solutions within the organisations they serve are known as operational users. CIOs, system administrators, department managers, standards managers, health informaticians, and IT personnel are all included.
Individuals who design and create working, executable implementations of software code that runs on a computer are referred to as developers. Developers, software engineers, product architects, and systems integrators are all included.
The above concepts make it clear that these groups are distinct, with different expectations, desires, experiences, and, essentially, performance measures in relation to OHT. Healthcare companies are likely to have a presence in all categories, and certain people are likely to cross over into several categories. These distinctions will be clarified in the following section.
Expectations of Stakeholders
We go through the following topics to better understand the stakeholders and their expectations:
Current market challenges: Healthcare information is currently unavailable to end users when, where, and in the format that they need. There are inconsistencies and discrepancies among systems, as well as long wait times for IT personnel to resolve these issues. Best-of-breed applications generate integration problems and additional cost for operational customers, while best-suite applications don’t meet all of the business needs. Inconsistent operating requirements lead to redundant facilities, staffing, and support. Any technological infrastructure that is not central to a developer’s product offerings necessitates substantial investment. Explosive heterogeneity complicates development even more, particularly when it comes to application programming interfaces (APIs) and support for standards.
End-users expect applications to be dependable, simple to use, user-customized, scalable, and to embrace new modalities such as mobile devices, cell phones, and the Internet. In a nutshell, operational users expect systems to: I be operationally reliable; ii) perform well; and ii) comply with market drivers such as government requirements and security concerns. They’re also looking for the ability to deploy, track, and control deployed systems in a flexible manner. Software tools that offer versatility and the ability to produce high-quality code quickly are expected by developers. They also favour tools that make tasks simpler or that remove repetitive tasks so that the developer can concentrate on the task at hand.
End-users expect improved access to healthcare information and interoperability among vendor and supplier packages as a result of OHT. As a result of more aligned industry offerings, operational users expect a reduced integration burden, improved interoperability among off-the-shelf packages, and a reduced support burden. Developers anticipate high-quality tools and components that “only work,” increase efficiency, and reduce time to market.
Intersection with OHT: End-user contact would be indirect since they will be using applications that have OHT components. Interaction with organisational users will be direct, since they will be using OHT-based tools and applications. It will also be indirect since they will specify transactions that meet with OHT’s industry requirements and vendors will be encouraged to participate in OHT. Developers can have direct contact with the OHT codebase when they use OHT resources, components, and other contributions.
End-users expect reduced pressure, increased job efficiency, and ubiquitous access to information when and where they need it as a measure of success. Operational users anticipate better product integration and interoperability both inside and outside the business. OHT anticipates a gradual increase in the number of developers.
OHT and Healthcare Organizations
Healthcare is a highly complicated business. These dynamics are self-evident within healthcare institutions, as most, if not all, of the stakeholders mentioned above are likely to be present. We must look beyond organisational labels in order for OHT to bring value to healthcare organisations.
We examine the contact points of various organisational positions with the OHT group in order to better understand the importance of their experiences with OHT and the business benefit that can be realised from participating. It’s worth noting that these functions are classified by purpose, such as delivering care or paying for services, rather than by the organisations themselves. Simply put, several organisations take on multiple roles, particularly when differences between countries are taken into account. We chose to enumerate the various types of activities that government agencies can engage in rather than discussing a governmental function.
This position benefits from OHT participation in the following ways: I the ability to incent and optimise co-investments with peer organisations; ii) improved de-facto interoperability among commercial applications; iii) improved ability to influence and impact commercial vendors; and iv) influence on OHT priorities. Usage cases, subject matter experts, organisational criteria, development tools, hl7 developer support, and code contributions are all examples of contributions to the OHT community. The following technology outputs will be provided by OHT: I applications as proof-of-concept or architectural prototypes; ii) tooling to promote custom integration or development; and iii) marketplace vendor product offerings aligned with requirements needs.
Benefits include: I reduced cost of testing and ensuring implementations due to a shared codebase; and ii) increased marketplace enforcement due to requirements support in an open source software (OSS) codebase. Quality assurance, conformance, research, subject matter experts, and specifications are all possible contributions from this position. It may also aid in the determination of OHT goals. The establishment of standard test harnesses and an OSS codebase that meets oversight expectations are among the technology outputs received.
Product vendor advantages include: I lower costs of non-differentiating software product infrastructure investments; ii) increased market share as a result of overall community development fostered by OSS; iii) improved quality as a result of a vetted OSS codebase; v) improved sight lines to the needs of a potential customer base; and v) improved market branding and product positioning. Code and development tools are examples of acceptable contributions.
Reduced integration risk due to improved distributor product interoperability; ii) improved sight lines to the needs of a potential customer base; iii) the ability to control OHT priorities; and iv) business branding and positioning. Contributions may take the form of human or financial resources, subject matter experts, code, integration and implementation expertise, testing, and quality assurance. A reusable codebase in the form of tools and applications is one of the technology outputs.
Benefits include: I reduced or removed custom tooling; ii) improved marketplace product support; iii) improved capacity to create standards; iv) increased value of healthcare standards produced; and v) control over OHT priorities. Use cases, subject matter experts, organisational criteria, and funding are also possible contributions. Tooling to support the standards creation process, healthcare standards-compliant market offerings, and an OSS codebase are among the technologies obtained in exchange.
Benefits to the Foundation include measurable health community effects and the potential to incent conventional business reform that is consistent with the Foundation’s goals. Influence over OHT priorities and funding to the OHT community are examples of contributions. One of the many advantages of technology is the ability to use it.
