IHE Connectathon Testing

Hi all.

The OpenHIE architecture uses, as its underlying transaction specifications, a family of globally balloted interoperability profiles from the international standards organization: Integrating the Healthcare Enterprise (IHE: www.ihe.net). Each year, IHE hosts 3 international engineering events called Connectathons. At a Connectathon, health software products demonstrate their adherence to IHE profiles by passing a set of interoperability tests. Products that successfully complete these tests (as adjudicated by IHE) publish interoperability conformance statements for the profiles they support.

At various times, the OpenHIE Architecture Community has discussed whether successful IHE Connectathon testing should be considered a mandatory requirement in order to be an OpenHIE “certified” infrastructure component. Presently, the open source reference software products that make up OpenHIE’s architecture do meet this criterion. However, these software products have evolved; and OpenHIE’s workflows have evolved; and so have a number of the IHE profiles upon which these workflows are based. A number of OpenHIE’s certifications are now out of date.

In the “OECD” markets (Canada-US, Europe, Australia, NZ, Japan, etc.) – public procurement of health software often stipulates (in the RFP documents) a requirement for successful IHE Connectathon certification. Donor-funded initiatives in LMICs, however, have only recently been considering interoperability as important aspect of an implementation. I’m happy to say that OpenHIE’s “pre-adoption” of standards-based interoperability specifications has been an important contributor to the emerging importance of this topic in LMIC implementations.

OpenHIE has, over the last number of years, provided leadership on the international technical committees at IHE that have developed and balloted interoperability specifications important to the needs of LMICs. These specifications, many of which are now also “named specifications” in OECD procurement documents, include:

There is a reason, in OECD markets, procurement documents make it a requirement that HIE infrastructure components be demonstrably interoperable: it mitigates risk and it operationalizes ecosystem-level interoperability. These are equally important attributes in LMIC settings. In fact, it could be argued that, for LMICs, mitigating such risks are maybe even more important. Unlike in OECD countries, there are often not sufficient funds available to MOHs to overcome the inefficiencies and challenges associated with a proliferation of health data silos.

The IHE ballot cycle has just concluded and a number of OpenHIE’s specifications (ADXv2 and mCSD in particular) are now released for Connectathon testing (as specifications for Trial Implementation). This poses some important questions for our Implementer community:

  1. Do we want to continue our practice, on behalf of LMICs, of having our OpenHIE reference software certify against the international standards in the IHE profiles?
  2. Should it be a mandatory requirement that other software products, be they open source or commercial, must successfully pass IHE Connectathon tests in order to also be OpenHIE “certified”?
  3. Is it appreciated by donors and/or ministries of health that OpenHIE goes through this effort (e.g. is certified interoperability an important and compelling “marketing message” for OpenHIE)?
  4. How do we avoid the “tragedy of the commons”; how will IHE Connectathon testing be funded for OpenHIE’s open-source, community-developed software products?
    I hope we can garner some good discussion regarding these topics. As the OpenHIE initiative moves into its “implementation” phase, the value propositions of being interoperable – or not – should start to become evident. But it is an inconvenient truth: interoperability comes at a price… and commercial software products are much better equipped to shoulder that cost than community-based software products.

I look forward to active discussions.

Warmest regards,

Derek.