Business Domain Overview - Interoperability

Schlagwörter: IES, IHE, Interoperability, overview



IT system integration is a challenge in many business domains. Go here to see how integration profiles of IT standards help to implement operative systems.


Back to the main page

The challenge of IT system integration - Feasible ways forward

As digitalisation moves on in the many domains of business, we experience typical stages: 

Paper processes go "digital" within a regional project. An IT system emerges that supports all local user requirements. All is fine! Suddenly scaling hits in: The business expands beyond one region, bringing in other regions with new business partners and IT vendors. Typically each region grows IT islands that now need to be connected. Vendors have invested into local proprietory islands. Pain and additional effort occurs, adopting something that was not invented here ...

In the best of worlds, all regions involved will call out for "IT standards for interoperability!!" The answer is "Fine! Which standard?" Standards are complicated, and we need many of them to address a specific business transaction. Additionally, solutions from one region may not fit the other, where business evolved a bit different over time, using other processes, words, and agrements.

In healthcare, in the 1990es, the business of imaging and radiology turned digital. This started on two ends of the business: patient administration, admission, discharge and ordering, using the HL7 standards. On the other hand film was replaced by digital images, driving the medical reports towards digial as well, using the DICOM standards. How to merge both worlds, integrating the many companies and organisations involved? This was too big for a songle region, vendor or healthcare organisation.

The "Integrating the Healthcare Enterprise" (IHE) initiative was founded. IHE developed methods to achieve "semantic interoperability" in practice in the health care domain. Over time, IHE made significant impact, with thousands of implemetations of IHE specifications worldwide. These methods are now applied in other domains as well, for example by the project IES Austria. This page describes the basic elements of these methods.

Semantic (!) Interoperability: Subtle but main difference

Interoperability is often defined as the ability of systems to exchange information. Historically this has become very common: Letters on paper, telephones and fax machines enable organisations to cooperate in this way. The downside of interoperability is, that a human receiver must actively read or listen to the incoming information, and then record the information locally, to initiate further process steps. The additional effort of "media breaches", as humans transfer information between systems, also increases the number of errors. 

Semantic interoperability on the other hand is often defined as the ability of systems to share information so that the receiving system is able to automatically process the information without the need of human interaction. This adds substantial value to IT systems, so that users can better focus on applying their skills instead of wasting time on re-entering information that was already entered by somebody else before.

Refined_eIF_ReIF_Model.jpgGlobally, methods for semantiv interoperability have evolved. On 23rd November 2015, the EU eHealth Network adopted the Refined eHealth European Interoperability Framework (ReEIF) that was developed by the JAseHN project. The ReEIF model shows the layers and activities needed to achieve semantic interoperability in practice. The ReEIF also describes selected profiles of IT standards tht support semantic interoperability for the most important European eHealth use cases.


Business Domains, expertise, overview: Orientation comes first!

IT system integration involves many people from many backgrounds. Healthcare for example has doctors, nurses, patients, who cooperate in the care of a person. Administrators, managers, lawyers, politicians run the system on a higher level. Supporting professions like medical device and software vendors provide the many products needed. The energy system also touches basically everybody.

These many individuals all being in specific expertise, knowledge, and skills. To sucessfully support the required business processes, IT system integration must acknowledge, embrace and consider all knowledge that is necessary in these processes. This means that all these individuals, as they get in contact with an IT system integration effort, must discuss and agree on the many large and small details of business and IT. Long, exhausting discussions will first generate a common understanding of the basic business elements and methods, until the IT integration finally moves forward.

A Business Domain Overview documents this common understanding of the basic business elements and methods,in order to support newcomers on their way into the domain. Find a Business Domain Overview for the Energy system here and a  Business Domain Overview for Health Care here.

As a link to the implementation the Business Domain Overviews introduce reference IT Architectures for informative Business Use Cases. These architectures show how "Actors" within IT components can link to other Actors, to form integrated IT systems. See below how the Technical Frameworks then exactly specify the exact way these Actors exchange the required information, using integration profiles  based on IT standards.

Developing Technical Frameworks and Integration Profiles

Technical Frameworks include so called integration profiles that clearly outline how the information exchange shall be implemented, in explicit: which document and data formats have to be supported, which standards apply and how options thereof shall be used. These profiles can be implemented during initial product development. They can also be introduced into operative systems, for example by introducing adaptors that convert proprietary interfaces into IES profile conformant transactions without a redesign of the original hardware and software.

To develp an interoperability profile, users and vendors from a specific business domain together first agree on a set of use cases to be supported. They then develop interoperability specifications in the form of integration profiles. Integration profiles refer to appropriate IT standards and exactly describe how these standards shall be implemented to achieve semantic interoperability. These specifications are then used by vendors to implement solutions. The Integrating the Healthcare Enterprise (IHE) initiative has sucessfully developed interoperability profiles, using the IHE processes. Many systems today implement these specifications.

Use cases, Architectures with (Sub-) Actors and Transactions: Bridging from business to implementation of IT systems

In the early stages of an IT system integtration project, a basic understanding of the requirements is established, and documented e.g. as "User Requirements". These requirements are often captured as "Business Use Cases" that describe specific busines transactions in a domain.

Based on this, "System Architectures" then capture how the makers of IT will assemble many IT components to provide all functions needed by the users as they do business. Software vendors can then further elaborate the requirements and functions of IT components during "Detailed Design", generating many and complex documents and specifications.

In "Technical Frameworks" and "Integration Profiles", System Architectures specify how "Actors" exchange business information using specific "Transactions". Each Transaction in an Integration Profile" describes in all detail, how a specific "Interoperability Use Case" shall be implemented. These "Transactions" specify which information is exchanged, how it shall be coded electronically, and which communication protocols shall be used to move the information between the Actors involved.

In order to provide all information for engineers, as they implement software, the specifications for a specific "Transaction" will include a lot of technical details. Detail is good, but you want to hide it safely away from those who do not need and understand it. Therefore "Actors" may be assembled of "Sub-Actors", that provide a specific function in semantic interoperability. The following Sub Actors are used in the Integration Profiles of the IES Austria project:

  • "Encoders" receive specific business information that is needed in the Transaction, and generate a digital message, according to the coding rules specified in the Transaction.
  • "Transaction Initiators" receive the digital messages from "Encoders". They then initiate the Transaction to electronically exchange this message to another "Actor", using communication protocols specified in the Transaction
  • "Transaction Responders" form the other end of the electronic Transaction. They respond according to the communication protocols specified in the Transaction.
  • "Decoders" then

No two businesses are the same, so there may be different ways to assemble "Interoperability Use Cases" into "Business Use Cases", e.g. in different organisations, regions and implementations. Drawing from sets of well-defined and specified Actors and Transactions, users and implementers of IT systems can then choose which Actors are needed for their specific project, and which Transactions are needed to connect them.

Connectathon, CAS etc: Test and certify software for conformance

Well defined conformance tests enable users to see if a given software module conforms to the interoperability specification. Testing occurs throughout the complete lifecycle of a software product, from prototype to product to installed system.

Prototype testing at Connectathons

Testing at organised events provides interface developers the opportunity to formally test their implementation against those of peer developers from other companies without revealing their implementation details. If a sufficient number of normalised profile based interoperability tests are performed with success, a test will be documented as passed. The results of test events may be published. This enables users to follow the growth of implementations of specific profiles over time, as more and more sucessful tests show up at periodic testing events. During development, implementers may already use test tools to ensure that components work together well, even in early stages of a project.

IHE has developed a large set of tools to support developers and testers and provides the IHE Test Tool Information Wiki to introducers developers into the process of testing.

IHE Connectathons (go here for the full story) provide a detailed implementation and testing process to enable the adoption of standards-based interoperability by vendors and users of healthcare information systems. During a Connectathon systems exchange information with corresponding systems in a structured and supervised peer-to-peer testing environment, performing transactions required for the roles (IHE actors) they have selected to perform in carefully defined interoperability use cases (IHE profiles).

Connectathons are held annually in Asia, Europe and North America.  Thousands of vendor-to-vendor connections are tested each year. The results of testing are published in the Connectathon Results Database. The advanced browsing view e.g. enables you to see a record of testing for the XDSb profile (select Cross Enterprise Clinical Documents Share XDSb as integration profile), which companies (select "All companies" for columns) has tested over the history of Connectathons (select "all Connectathons" for rows).

The IHE Gazelle test platform (see the local instance at UAS Technikum Wien) supports formal testing at IHE Connectathons.

The planned IES implementation conformity test events will be comparable to IHE connectaton.

Impressions from the Tiani team at 2017 Europe Connectathon in Venice, Italy.

Product Certification

Testing also helps both vendors and users: During procurement buyers refer to specific profiles as needed. Vendors then develop and certify software modules as specified. At the time of installation, the effort for system integration decreases dramatically.

IHE has established the IHE Conformity Assessment Scheme (CAS) to certify specific products for conformance to IHE profiles. The test methods that will be developed by the IES project may also in the future be used for similar purposes.

Project - oriented testing within specific communities

On top of available profiles, implementation projects typically add project-specific specifications. In order to test these, a community may start a  "Projectathon", to test software for conformance to the interoperability profiles and to the project specific specifications at the same time. This further reduces the effort for tool and software development. Vendors may also re-use existing modules, skills and know- how to serve several communities.

The European project epSOS for example conducted an epSOS Projectathon in November 2010 in Bratislava.


28. Mai 2017, 10:51
1 Kommentar