The project IES attempts to migrate and adopt an established methodology on achieving interoperable IT systems delivered from different vendors. The methodology has matured over many years in the medical sector, starting with digital X-ray images (radiology) in 1999, and by today achieved wide acceptance in the US, Europe and East Asia. The methodology implements the four basic steps shown in Fig. 1.
-
1.
Identify use cases where interoperability is an issue and specify these by identifying system borders and requirements (Gottschalk et al. 2017).
-
2.
Jointly identify how certain interoperability issues can be prevented best and specify it normatively as Integration Profile (Frohner et al. 2017).
-
3.
Test independent prototype solutions against each other on annual plugfest and improve the Integration Profile until it is firm (IHE Europe 2016).
-
4.
Publish successful testing activity: who has successfully tested an Integration Profile, which products implement which Integration Profiles (IHE Europe 2016).
The core idea of this methodology is lively cooperation. Integration Profiles shall be living documents that improve and grow until they become stable. In practice, the basic steps split up into a number of individual steps (Franzl et al. 2018). Users and vendors participate in the process as peers and jointly contribute to developing demand-oriented solutions.
When it comes to testing the individual implementation of profiles, all peers participating in a test case have a common goal: they want to ultimately pass the test. The IHE Connectathon (plugfest) provides the environment and time to learn and make corrections prior to running the final, recorded and monitored, test. Comments on errors revealed at the Connectathon are the most valuable and powerful input to improving the Integration Profiles. This feedback is practice driven and supports the Integration Profiles in becoming a most reliable basis for interoperable systems development (IHE Europe 2016).
The process coordination and control of the IES process is handled by peer committees, e.g., industry delegates. They manage and implement the industry integration process, as performed by IHE. Their influence may be subsidiary and hidden by the shining results, being Integration Profiles and test events organized, but it requires coordination and cooperation to achieve interoperability. Committees are a way to support the required socializing among industries. The formal requirement for a committee is that it shall be addressable, so tasks can be forwarded to it, and that its decisions are jointly accepted. If one person can assume a committee’s task, that person can be it. Committees fulfill required roles, which demand certain skills.
To coordinate and control the IES process, different skills are essential to execute various management tasks. The foreseen skills-grouping (i.e., the committee composition) is depicted in the center of Fig. 2. These committees constitute functional roles required to execute the process. Experts may serve in one, two or all, depending solely on the skills they actually contribute.
The main working bodies are the planning committee and the technical committees. The former assigns Integration Profiles to Technical Frameworks (TF) and organizes testing events, which includes the decision whether profiles are ready for testing, either as trial or mature Integration Profile. The latter are task forces writing Integration Profiles and specifying test scenarios and tools. In between and slightly above the two resides the domain coordination, consisting of experts covering all domains. This board decides which domain a TF shall be assigned to and support technical committees in proposing cross-domain reuse of existing Integration Profiles.
A TF is dedicated to a Business Case, e.g., the operation of a VPP, which belongs to a Business Domain, here the electrical energy production, distribution, regulation, and market area. The structure of the TF is divided into two volumes: The first part describes the informative view by a business case overview and business functions that result from Use Cases with interoperability issues. The second part contains normative solutions grouped into Integration Profiles, which contain the message exchange, specified as Transactions, and the Actors (software modules) that perform it as depicted on the left side of Fig. 2.