Business Domain Overview - Interoperability

Schlagwörter: IES, IHE, Interoperability, overview

IES_logo1605.jpg

 

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

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 agreements.

Interoperability is often defined as the ability of systems to exchange information: Letters on paper, telephones and fax machines enable organisations to cooperate. However, human receivers must actively read or listen to the incoming information, record it locally, and initiate further process steps. This additional effort of "media breaches" 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.

European Interoperability Framework (EIF) - element of a structured approach towards interoperable solutions.

The European Union has recognised that interoperability is crucial to cooperation but complex to achieve. Over time the EU established the "European Interoperability Framework (EIF)" as part of the Communication (COM(2017) 134) from the European Commission adopted on 23 March 2017. The framework gives specific guidance on how to set up interoperable digital public services.

EIF acknowledges that interoperability must be addressed on all involved layers:

  • legal interoperability
  • organisational interoperability
  • semantic interoperability and
  • technical interoperability.

EIF Conceptual Model image source: EIF homepage

EIF also provides recommendations to assure efficient implementation, by re-using existing standards, specifications, services, data, and other building blocks. See e.g. the EIF Brochure (2017, ISBN 978-92-79-63756-8).

Within the EU ISA2 program "Interoperability solutions for public administrations, businesses and citizens" , one key action is the European interoperability architecture (EIRA). EIRA classifies and organises building blocks relevant to interoperability, which are used in the delivery of digital public services. The goal is to facilitate interoperability and reuse when developing public services, by supporting implementers to document and share their designs, referencing the common elements of the EIRA model.

Get started on a impressive journey through available EIRA models.

European Interoperability Cartography (EICart) enablers to view and edit the reference architecture and to document other interoperable solutions and specifications, see at https://ec.europa.eu/isa2/solutions/eira_en. The European JoinUp platform offers several services that aim to help e-Government professionals share their experience with each other. We also hope to support them to find, choose, re-use, develop and implement interoperability solutions. EIRA and the EICart are also available via JoinUp platform.

EIF now has an even stronger focus on openness and information management, data portability, interoperability governance, and integrated service delivery.  This is the result of taking into account new EU policies, such as the revised Directive on the reuse of Public Sector Information, the INSPIRE Directive, and the eIDAS Regulation. New EU initiatives, such as the European Cloud Initiative, the EU eGovernment Action Plan 2016-2020, and envisaged ones, such as the Single Digital Gateway, are also considered.

Funded by the "Connecting Europe Facility" (CEF) key funding instrument, the CEF Digital initiative  enables implementers to build digital services faster and cheaper and create a European digital single market. CEF Digital provides the "CEF Building Blocks". These Building Blocks shall support "Sector Specific Digital Service Infrastructures", for example the eHealth Digital Services Infrastructure (DSI).  Find a detailed description at the "DIscover CEF eHealth DSI" pages, and explore more on how the eHealth milestones will be achieved, for example the „Cross-Border Patient Summary Service“ und die „ePrescriptions“ and „eDispensations“.

Achieving interoperability in use cases for eHealth by using standards and profiles: the Refined eHealth European Interoperability Framework (ReEIF)

Refined_eIF_ReIF_Model.jpgIn order to support interoperability in the eHealth domain, 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 provides guidance to efficiently achieve semantic interoperability in practice.

The goals of the refined eEIF were to:

  • Provide an overview of the different levels of interoperability. 
  • Be  understandable  for  all  stakeholders  involved  in  interoperability  discussions  - technical terms should be avoided 
  • Show the relationship between the different levels of interoperability.
  • Show examples of the different parts, within the schema.
  • Show the stakeholders involved in the different levels of interoperability.
  • Build upon existing interoperability models.

The ReEIF introduces "eHealth interoperability cases" that also describes selected profiles of IT standards that support semantic interoperability for the most important European eHealth use cases. Because it is based on earlier versions of the EIF, the ReEIF approach is more simple that the current EIF and tailored to the eHealth domain. However, specifications and solutions that were developed under the ReEIF may be descibed and shared using the methods of EIF. Therefore ReEIF and EIF align well to each other, in that they both support interoperability in very similar ways. Futore efforts might lead to formal ways of merging both approaches efficiently.

Integrating the Healthcare Enterprise (IHE) - Interoperability in reality on a large scale

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 single region, vendor or healthcare organisation.

The "Integrating the Healthcare Enterprise" (IHE) initiative was founded in 1998  by a consortium of radiologists and information technology (IT) experts. 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. "Where in the World is XDS and CDA" for example shows implementations of the "Cross Enterprise Document Sharing" (XDS) profile, which enables sharing of medical documents like reports e.g. in a national electronic healthcare record (EHR).

The methods of IHE are now applied in other domains as well, for example by the project IES Austria. This page in the following describes the basic elements of this approach.

2015 Milestone: 27 IHE profiles eligible for referencing in procurement in Europe

One major milestone to recognise the benefit of IHE profiles for interoperability was achieved in 2015: Having consulted the European multi-stakeholder platform on ICT standardisation and sectoral experts, on 28th July 2015 the EU Commission issued the Decision (EU) 2015/1302 on the identification of ‘Integrating the Healthcare Enterprise’ profiles for referencing in public procurement. It was found that IHE profiles have the potential to increase interoperability of eHealth services and applications to the benefit of patients and the medical community. According to the Decision, the following profiles are eligible for referencing in public procurement:

  1. IHE XCPD: Cross-Community Patient Discovery
  2. IHE XCA: Cross-Community Access
  3. IHE XCF: Cross-Community Fetch
  4. IHE XDR: Cross-Enterprise Document Reliable Interchange
  5. IHE CT: Consistent Time
  6. IHE ATNA: Audit Trail and Node Authentication
  7. IHE BPPC: Basic Patient Privacy Consents
  8. IHE XUA: Cross-Enterprise User Assertion
  9. IHE PRE: Pharmacy Prescription
  10. IHE DIS: Pharmacy Dispense
  11. IHE XPHR: Exchange of Personal Health Record Content
  12. IHE XD-MS: Cross-Enterprise Sharing of Medical Summaries Integration Profile
  13. IHE XD-SD: Cross-Enterprise Sharing of Scanned Documents
  14. IHE PIX: Patient Identifier Cross-Referencing
  15. IHE PDQ: Patient Demographics Query
  16. IHE XDS.b: Cross-Enterprise Document Sharing
  17. IHE XDS-I.b: Cross-Enterprise Document Sharing for Imaging
  18. IHE XD-LAB: Laboratory Reports
  19. IHE XDM: Cross-Enterprise Document Media Interchange
  20. IHE SVS: Sharing Value Sets
  21. IHE SWF: Radiology Scheduled Workflow
  22. IHE SWF.b: Radiology Scheduled Workflow
  23. IHE PIR: Patient Information Reconciliation
  24. IHE PAM: Patient Administration Management
  25. IHE LTW: Laboratory Testing Workflow
  26. IHE LCSD: Laboratory Code Sets Distribution
  27. IHE LWA: Laboratory Analytical Workflow.

Introductions to these and other IHE profiles are available at the IHE Profiles Wiki page.

Many of these profiles support cross organisation sharing of documents, especially XCPD, XCA, XCF, XDR, CT, ATNA, BPPC, XUA. PIX, PDQ, XDS, XDM, SVS. Although these profiles were developed for healthcare, they cover basic requirements for sharing many kinds of documents. They may therefore also be useful in other business domains.

Step 1: 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.

Step 2: 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.

Step 2, the details: 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 extract the business information from the digital message to enable further processing on the receiver system.

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.

Steps 3 and beyond: Implement and test, 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.

EU project for certification: eHealth Interoperability Conformity Assessment Scheme for Europe (EURO-CAS)

2016-2018. The eHealth Interoperability Conformity Assessment Scheme for Europe (EURO-CAS) will between 2016 and 2018 develop the sustainable Conformity Assessment Scheme (CAS) for Europe, which will promote the adoption and take-up of interoperability testing of eHealth solutions against identified eHealth standards and profiles defined in the Refined eHealth European Interoperability Framework.  

IHE and the Personal Connected Health Alliance (PCHA) / Continua are partners in EURO-CAS. The project results wil be valuable for implementing interoperable solutions on a large scale in Europe.

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.

Kommentare

sobia
28. Mai 2017, 10:51
1 Kommentar