3 Interoperability

From Parent-Wiki
Jump to: navigation, search

Methodological guidelines » 3 Interoperability

Content
3.1 Introduction
3.1.1 Contexts
3.1.1.1 EU context
3.1.1.2 Registry interoperability context
3.1.1.3 Generic use case context
3.1.2 The PARENT Framework
3.2 Registry interoperability guidelines
3.2.1 General
3.2.2 The political (stakeholder) context
3.2.2.1 Context stakeholders
3.2.2.2 Context maintenance
3.2.2.3 PARENT framework context
3.2.3 Legal interoperability level
3.2.3.1 PARENT framework formal implications
3.2.4 Organizational/process interoperability level
3.2.4.1 PARENT framework organizational and process implications
3.2.5 Semantic interoperability level
3.2.5.1 Standards, models and tools
3.2.5.2 PARENT framework organizational and process implications
3.2.6 Technical interoperability level
3.2.6.1 PARENT framework technical implications


Whether you govern, develop, operate or use registries, being interoperable with your registry stakeholders and peers can significantly improve your performance and resolve your challenges. But most of all, interoperability can help you to become a part of an integrated resource, relieve you of chores beyond your personal and professional interest and consolidate your status, integrity and autonomy.


Key principles:

  • Get acquainted with the big interoperability picture (a network of stakeholders, users, services and registries) and how registries fit in it.
  • Understand four levels of interoperability (legal/formal, organizational, semantic and technical).
  • Apply interoperability principles to all aspects of registry including establishment, development, operation, use and governance keeping in mind that the user is a key interoperability factor.
  • The PARENT framework is an objective-based interoperability framework, in other words its function is to provide a shared infrastructure for development of common interoperability support and functionalities to all stakeholders and projects joined around the PARENT objective.


3.1 Introduction

As a multi-stakeholder project and effort PARENT is a model environment in which interoperability is the key prerequisite for successful accomplishment of project objectives (including objectives and outcomes for each particular stakeholder), since all PARENT issues are, in essence, interoperability issues.

Interoperability, in the broadest sense, stands for “ability to operate with others”, thus can be applied to any situation where two or more entities achieve their goals or purpose by successfully interchanging services.

This principle can and should be applied to all aspects of registry establishment, development, operation, use and governance. This principle is also crucial for efficient cooperation with other national and EU registries and stakeholders and incorporating your registry in the connected European environment.

Since both registry and interoperability basic principles are by rule generic (bear no specifics regarding patient registries), these guidelines should be viewed as a brief introduction to the topic, necessary to understand, participate in and achieve the PARENT-specific goals as described in the rest of this document.

For the purpose of this chapter, the term registry includes the formal, current, verifiable, undisputable structured list of patient-related, medical or public records and the organizational and technical mechanism required to adequately maintain its function and records and provide related services.

Interoperability maximises the utility of patient registries and provides new opportunities for research, reduces administrative workload, provides accelerated communication and more efficient collection of data from multiple systems, enables automated data sharing and meaningful comparisons of data between registries. This finally results in the better effectiveness of registry information. The benefits of interoperability are plentiful, and it is thus recommended for a patient registry that it takes interoperability issues into account from the very start, during the registry creation phase.

These guidelines will provide essentials for assessing and building interoperability capabilities, and should be seen as a living reference which will be enhanced and supplemented through development of the PARENT framework.

For a deeper insight and advanced concepts behind these guidelines please consult and study the given references.

3.1.1 Contexts

3.1.1.1 EU context

Being an EU effort, the best way for PARENT to both support overall EU objectives and efficiently and effectively achieve goals is through compliance with EU interoperability context.

Interoperability is a key prerequisite for timely achievement of EU-level strategic plans by efficient and coordinated joint operative action of all stakeholders across all Member States. This is reflected throughout EU strategic and operational documents and activities. Becoming acquainted with them can help to build an initial interoperability capacity and adequately position a role and goals in the context. eHealth Action Plan 2012-2020 [1] defines the overall operative context for the Plan period. It is facing significant challenges of interoperability in eHealth, some of which have been detected by eHGI [2], and many are directly reflected as patient registry interoperability issues.

Success of EU-level action plans rely on interoperability of all involved parties. An excellent high level interoperability context overview is given in the eHealth EIF study [3].

For an insight into a service environment that demonstrates cross-border interoperability between electronic health record systems in Europe please review epSOS project website.[note 1]

Among the significant projects focusing on particular interoperability level issues are SemanticHealthNet[note 2] and EHR4CR[note 3].

For a practical context working model and coordination outcomes refer to CALLIOPE[note 4] EU thematic network site.

Patient registries are key healthcare information repositories, therefore interoperability of their stakeholders and users is crucial for eHealth Action Plan execution.

3.1.1.2 Registry interoperability context

In order to contextualize registry interoperability the following figures illustrate the intended approach. Figure 3.1 is shown for easier comparison of small, but significant differences between a simplified traditional registry context and the interoperability development context (Figure 3.2).

Figure 3.1: Generic single registry context


In the generic single registry context (no interoperability) all registry rules, administration and service provision are determined by the registry holder according to current legislation and business decisions. Dedicated administration (human actor) performs four-way interoperability actions when needed, as a part of a “business-as-usual” job description. It is a closed system where each interaction is prescribed by the administration and, regardless of the IT solutions being used, requires human intervention in every use service.

When we want to optimize the relationship and enable parties to interoperate we need to establish a new, unprecedented joint business environment. If this is not mandated through legislation, the first prerequisite is a formal agreement/commitment of all stakeholders to jointly develop and use new functionalities (services). In eHealth EIF terms this formal mandate or formal agreement is called political context.

Once the political context is established, stakeholders need to make sure that their mutual interoperability is adequate to efficiently achieve the functionality determined on the political level, or what is needed to build the required capacity.

Figure 3.2: Interoperability development context


Competent and appointed stakeholder representatives need to review, verify and agree on requirements on four interdependent levels: legal (formal), organizational, semantic and technical level and adequately adjust their business systems and services. Elimination of any level from the process can result in inadequate solutions.

Once a number of stakeholders reaches higher levels of interoperability we are going to be able to delegate more functions to a fully interoperable registry service context, as presented in Figure 3.3.

Figure 3.3: Advanced registry interoperability context


Figure 3.4 shows a functional PARENT framework (interoperability) context. The user now represents all stakeholder roles in previous contexts, while user services provide the interoperability environment. In this context registry holders ensure interoperability by developing and maintaining own registry services and using standardized and shared user services to interoperate either with human users or other technical systems and registries.

3.1.1.3 Generic use case context

Keeping in mind the previous contexts and disclaimers, a generic use case “perform registry service” covers key registry interoperability situations.

Figure 3.4: PARENT framework (interoperability) context


In this use case the actor user should also be viewed in the broadest sense. It can be anything, a human individual or a machine in any role: from a registry holder, physician, patient, government official to another service performed by a hospital or completely independent system.

If needed, each shown task can be also viewed as a separate interoperability use case and performed by any number of stakeholders that can provide the best result. Each task can also connect to one or more registries when the needed interoperability conditions are met.

Each task can and should be viewed from all interoperability level angles.

Each task can be performed either by a human or a machine. This enables modular development and can help a gradual interoperability capacity development for complex traditional registries. For example, at one point a nurse can perform all registry service tasks by hand and paper, while later one step, several or all steps can be automated until the nurse takes the position of a user and is relieved of administrative tasks.

From an interoperability point of view, the service or any particular task in this context could be delegated and performed by different independent stakeholders and systems located around the EU and supported by registries located somewhere else.

The value of this use case context is that it contains all key elements needed to perform create, read, write and delete actions (the core of any registry operation) through services. This can help to map a particular registry situation to this generic model as a starting point in interoperability development that can be either the initiator’s task or a task which the initiator participates in. It can also be a tool for conceptualizing a new registry that has all the interoperability prerequisites. The PARENT framework will provide tools to help achieve this.

3.1.2 The PARENT Framework

At the initial stages of interoperability development most of the burden lies on individual stakeholders, but one of the most important interoperability possibilities is resource and capability sharing. Having a standardized system that could systematically build, incorporate and manage resource and capability sharing would relieve stakeholders and users of the interoperability and standardization overhead (the need to re-build and re-learn to be interoperable) and allow them to focus on their core business.

The PARENT framework is an objective-based interoperability framework, in other words its function is to provide a shared infrastructure for development of common interoperability support and functionalities to all stakeholders and projects joined around the PARENT objective. It should support the full interoperability range and functions as its integrator. It is a constantly active mechanism governed by key stakeholders on the political context level, providing support and service repositories for all interoperability levels.

At a strategic level it is intended to provide means to unify, standardize and deliver functions needed by all participating and potential stakeholders, as well as to gather and disseminate information and knowledge that can generally speed up interoperability development among the target group.

At an operational level it is intended to develop functions to support interoperability harmonization, project deployment and integration of project outcomes in the framework. The PARENT framework’s development and functionality will follow stakeholder requirements and priorities. Therefore it directly depends on the level of participation and involvement of participating stakeholders.

3.2 Registry interoperability guidelines

3.2.1 General

These guidelines primarily focus on providing initial orientation interoperability recommendations intended to aid patient registry stakeholders in grasping their interoperability environment, potential and issues, building own interoperability capacity and participating proactively in PARENT activities. The guidelines contain two viewpoints:

  1. the stakeholder viewpoint focuses on interoperability issues which might be directly faced, and
  2. the PARENT framework viewpoint, showing how the framework is envisioned to provide interoperability environment to PARENT participants, stakeholders and users.

The guidelines structure follows the interoperability structure as described in the eHealth EIF document.

3.2.2 The political (stakeholder) context

The political context, once well defined, is a simple and powerful overview tool. It can be compared to a letter of intent, defining a common goal, participants and their responsibilities in a multi-stakeholder development initiative.

The political context defines general initiative goals and measures. All later outcomes of the interoperability process on each level should be checked and verified against the context. The political context can be defined in various ways:

  • it can be dictated by public legislation, strategies and planning,
  • it can be defined through project or taskforce initiation documents,
  • it is proposed by an initiative leader, or
  • define it with partners or alone.

Whenever it is required or necessary to participate/lead in one of the listed possibilities it is necessary to assess the position in the context: who are the entities to interoperate with and how does each relationship reflect on the environment and operation?

The context simplifies problem analysis and solution drafting, since the relationship overview helps to detect requirements, differences and interdependencies that define what changes need to be made (or proposed) to achieve interoperability. It is recommended that a relationship overview be created and maintained even for simple situations (2-3 stakeholders). Often it will be quickly found that important stakeholders were initially omitted from the picture or that there are some valuable relationships that were not apparent in the beginning.

3.2.2.1 Context stakeholders

Key interoperability stakeholders are entities whose participation is required to achieve a goal, since it can be done only if mutually interoperable. It is advisable to include all known issue stakeholders in the context, even if at a certain point they are not considered to be essential for the cause in point. Awareness and early inclusion of the full context can help in anticipating or orchestrating situations that might prove critical for success or solution to a broader issue that might arise later. Continuously review any stakeholder list, propose and consult with them to avoid the most common mistake: to omit inclusion of indispensable stakeholders. This often happens with end users.

3.2.2.2 Context maintenance

Before moving on to harmonization by issue’s interoperability levels it is important to have at least all key stakeholders conclusively agree on the mutual purpose, commitment, responsibilities and a well-defined scope of the joint undertaking. Lacking a commitment of a key stakeholder means there is a high probability of failure and loss of time and resource investment. In that case it is important to either consider reducing the scope to a level at which all key stakeholders can be on board, or postpone all further activities.

Interoperable development is an iterative process, allowing continuous adjustment and correction at all levels. If an issue emerges that challenges the political context (whether in outer environment, on a political level or on lower levels), stakeholders must jointly review the issue and decide how to handle it. This can result in a context revision that requires revision of all lower interoperability level developments.

3.2.2.3 PARENT framework context

When defining or participating in a political context it is useful to compare it to the PARENT framework context, since it is a prototype of all patient registry contexts. All (current) general stakeholder groups are presented, and generic group names can be replaced with stakeholder names within the required context. It is most probable that a given context does not contain all presented groups, so these can simply be excluded.

The context can actually be used and overlapped for different initiatives and projects. It is very probable that parts will be able to be reused with minor changes or with no changes at all. This is very helpful if there are separate project teams on different projects, as they can easily synchronize and spot possible synergies (reducing and joining development efforts and costs).

A core business stack of information can also be continuously maintained, helping to be ready to join future interoperable projects. In that case each project can start using a common and updated template.

This context also describes stakeholder generic roles in an interoperable system. This might enable anticipation of possible interoperability issues and preparation for them at early project consideration phases.

Figure 3.5: PARENT framework


On the operation side it is possible to start building an interoperable service set that fits respective description and that could be universally used in many or all contexts. When the PARENT framework prerequisites are met the services operation and maintenance to the framework might also be delegated and it might be possible to allow other stakeholders in the group to use them.

The central service set (envisioned to be incrementally provided by the PARENT framework) is a set of services required in all interoperability projects (person-driven or automated). For project risk management purposes actual political contexts should define stakeholder responsibilities for all of them.

3.2.3 Legal interoperability level

Patient registries need to pay special attention to legal issues, since they contain very sensitive personal data, are subject to frequent updates, and support multipoint and multi-stakeholder data exchange.

The first step after agreeing on the project political context is to review it against the legal frameworks of each key stakeholder and the project as a whole. Besides compliance with official legislation (an important issue in cross-border projects due to legislation differences between participant countries) each stakeholder might be affected by particular legal restrictions or obligations (compliance to professional or sector rules, valid contract with other parties, constituent or owner-related issues, etc.).

If any of these presents an obstacle to the project, parties must propose either a reduced project scope compliant with the legal framework or feasible enabling measures or decisions to be approved at the political context level. Otherwise it would be wise to recommend postponement of further activity until these issues are solved or conditions are met or to terminate initiative activities.

An example could be that a registry holder’s country legislation forbids cross-border exchange of specific data and a research organization from another country is interested to use the data. If both stakeholders want to achieve this they can work together to define legally acceptable options.

If all key stakeholders can agree on an acceptable initial legal frame that enables project continuation, project harmonization can continue to the next interoperability level.

Registry holders should pay particular attention both to domestic legislation and EU regulations on exchange of registry data. Registries with no previous experience in exchanging data with any but traditional stakeholders, or registries where a part of the registry processes and services are off-line should pay particular attention and start early. We strongly recommend a thorough review of the entire legal context of registries and implications of intended changes.

Special attention should also be given in cases where a registry receives part of its content from other registries, in which case their holders must be included in the political context.

In some cases registry holders must also review legal situations where the intended interoperability solution might affect in any way the content delivered to users (for example where part of the delivered content now comes from other sources.

We encourage registry stakeholders to consult national personal and data exchange agencies, as well as healthcare and social security institutions, as they should have an overview of latest developments in this area.

On the EU level the following should be taken into account:

  • Cross Border Healthcare Directive (CBHD)[note 5]
  • Personal data protection regulation proposal[note 6]
  • LIBE committee proposal[note 7]

3.2.3.1 PARENT framework formal implications

The PARENT framework provides a general communication and harmonization platform for participation of stakeholder legal representatives on general legal review, recommendation and legislation change initiatives. At the beginning the scope will be limited to isolated cases and a task force model.

The PARENT framework will enable tracking of the legal environment in general and through single projects, both as an interactive reference resource and application support. The framework itself might initiate or develop its own rules that would ensure optimization of the framework.

3.2.4 Organizational/process interoperability level

Based on the previously agreed project political context and the legal frame, stakeholders need to review in detail operational responsibilities, roles, outcomes, service and data exchanges. Stakeholders should precisely define these elements for all required project processes, without overlaps or gaps. This includes governance, quality control, and other issues pertinent to smooth, traceable, controllable, uninterruptable and conflict-free process execution, as well as risk management measures.

Organizational and process interoperability is the most complex issue to tackle to achieve smooth interoperability, thus it is hard to generalize or describe in a guidelines format. It can be taken as a rule that each stakeholder has a specific organizational approach, when complexity grows with the level of IT influence on the organization and processes.

Patient registries are used throughout the healthcare process, reflect on numerous national services and report to different EU level institutions. This makes this process extremely sensitive and need thorough analysis of each process step where data creation, recording, usage or exchange takes place. This is the level where previously hidden project or legal issues might emerge. There might also be some unresolvable operational issues (e.g. inability to agree who should be responsible for a process). These should be documented and returned to the appropriate higher level for review and final decision.

An example could be a project where a patient’s treatment is carried out in a number of hospitals in different Member States, so different medical records, practices and insurance schemes need to be harmonized.

A pragmatic approach on this interoperability level would be to avoid all cases that would involve complex organizational interventions in existing stakeholder business environments. It is better to develop a business case consisting of an integral set of services that can perform manageable, automatic and traceable functions. The case should reflect joint stakeholder effort to minimise the need for human intervention in the process and reduce cross-system data exchange and transformation.

A more long-term approach would be a full business implementation of SOA[note 8] with EDA[note 9], also known as SOA 2.0.

The business level is also the level where an IT business strategy and financial implications should be agreed on. It is recommended to maximize and optimize the use of existing business and IT resources. It is up to stakeholders to determine which stakeholder will perform which function without jeopardizing functionality and sustainability of the whole system.

In general, use of a standardized business modelling is recommended, and BPMN encouraged, to facilitate articulation of the solution and its communication to the IT level.

When all key stakeholders agree on the acceptable organizational model and business process specification that enables project continuation, project harmonization can continue to the next interoperability level.

3.2.4.1 PARENT framework organizational and process implications

Although at the beginning the framework is not intended to go beyond resource provision and development support, it is actually a potential provider for all shareable organizational and process models and building blocks resulting from successful interoperability projects by stakeholders.

PARENT has developed and provides the following organizational support at framework level (aiding stakeholder organizational leaders in issue harmonization, project execution and deployment, and local application):

  • A governance model and services,
  • a collaboration model and services,
  • a roles and responsibilities model and services,
  • a quality assurance model and services.

3.2.5 Semantic interoperability level

Patient registries, particularly in EU cross-border data, multi-lingual and information exchange and sharing, need a careful semantic consideration, analysis and harmonization.

After agreeing on clear legal and business project definitions they should both pass the stakeholder semantic review and result in full agreement and implementation (where required). The main focus is on these general semantic review areas:

  • Processes that generate or transform data exchanged between stakeholders,
  • The data that is exchanged,
  • Roles and identifiers of stakeholders present in the process,
  • Information and instructions for general users given or exchanged on all system access points,
  • Information system metadata, data structures and ontologies.

This does not exclude any other aspect of semantic review and acceptance.

3.2.5.1 Standards, models and tools

Since the semantic interoperability is a highly structured, rule and standard-rich segment governing terminology, knowledge, standard interpretation and document interpretation, identifiers, etc. all agreements should aim to be compliant with standards or practices dominantly accepted for a particular area, particularly if determined at EU level.

Naturally, the interoperability process requires an initial assessment of stakeholders’ current compliance with semantic standards, models and tools, so users should be able to be acquainted and ready to exchange such information about their system with others and be aware of acceptable alternatives to be able to adjust.

Here is an overview list of key semantic standards, tools and approaches for future reference. Their implementation and use closely depends on particular circumstances.

Metadata

  • ISO/CEN Metadata standard 11179
  • Dublin Core Metadata

Data structure/exchange

  • OpenEHR
  • HL7 RIM CDA, C-CDA
  • HL7 FHIR
  • I2b2
  • ISO/CEN 13606
  • IHE
  • Clinical information modelling initiative

Terminologies

  • CTS2 standard
  • IHTSDO SNOMED-CT
  • ICD10
  • LOINC
  • ATC
  • ICPC-2
  • ICF
  • ICHI
  • DRG

Ontologies

  • OWL

Pharma and research

  • C-DISC
  • BRIDG

Semantic approach

  • Archetypes
  • Templates

3.2.5.2 PARENT framework organizational and process implications

PARENT should develop and provide the following organizational support at framework level for participation of stakeholder semantic experts. The main areas:

  • data harmonization, unification and standards,
  • ontologies,
  • data integration and reuse rules,
  • multilingual support,
  • archetypes,
  • PARENT dictionary,
  • data quality.

3.2.6 Technical interoperability level

This level of interoperability should be reviewed after all previous levels are fully harmonized and defined, since together they represent a detailed system specification. The most important part of the specification comes, from the IT point of view, from the organizational/process interoperability level.

Depending on the agreed business process and responsibilities, there are numerous possibilities regarding use, interconnection and sharing of existing stakeholder IT systems, using cloud capacities, building shared infrastructure, or EU modelled infrastructure, such as Connecting Europe Facilities (CEF), etc.

Before engaging in IT interoperability harmonization assessment of IT system standards in the context of agreements reached on previous interoperability levels is essential. The following should be reviewed:

  • The database solution,
  • The business application solutions,
  • Web technologies used and supported,
  • Web portal and interface used,
  • Communications protocols supported.

In interoperability projects it will probably be discovered that Patient registries currently operate on highly diverse IT infrastructures, and it would be unreasonable to expect their major modification in the near future, due to complexity, sensitivity and risk of such action. That’s why, in general, project technical interoperability efforts should focus more on solutions which rely on web technology based service and data exchange between existing IT systems wherever possible, in a way that uses existing systems without major modifications.

In each particular interoperability case stakeholders should review and decide on the most convenient suite of standards and protocols that best match their existing systems. All new development should adopt EU initiative models and standards as much as possible. A good reference point is the epSOS project and other references given in the Introduction.

XML is a well-established and universally accepted data exchange format that should be adopted whenever feasible, particularly in mixed health and public stakeholder environments.

HL7 is a data-communication protocol and format for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. As it is especially developed for health systems it should be reviewed as a possible choice in dominantly health-oriented cases.

Interoperability frameworks, such as eHealth EIF and its more general counterpart and predecessor EIF Annex II [4] give models for IT implementation of interoperable solutions. The development and implementation of new IT systems, as well as for more advanced cases, should be founded on these models.

3.2.6.1 PARENT framework technical implications

PARENT framework fully implements the eHealth EIF and EIF Annex II in the SOA 2.0 environment, including the service model and adequate development and operational structure.

The technical implementation of its componentized model (fully compatible with the EIF service model) should provide continuous quick development, sharing and reuse of PARENT service IT solutions, reducing efforts in technical interoperability harmonization and development. Each component is a set of dedicated non-redundant services that comprise the whole framework service portfolio.

Incorporation of every interoperability project into the PARENT framework will augment the PARENT stakeholder service portfolio and reduce the need to develop new IT solutions for each new interoperable business case.

Actual PARENT framework IT environment will implement EU regulations, guidelines project results, key standards and technologies and take into account actual technical status, ensuring user and framework interoperability with systems and projects out of PARENT boundaries.

Figure 3.6: PARENT framework technical infrastructure model

Notes

  1. epSOS - Smart Open Services for European patients: http://www.epsos.eu
  2. SemanticHealthNet, a scalable and sustainable pan-European organisational and governance process for the semantic interoperability of clinical and biomedical knowledge: http://semantichealthnet.eu
  3. Electronic Health Records for Clinical Research, adaptable, reusable and scalable solutions for reusing data from Electronic Health Record systems for Clinical Research; http://ehr4cr.eu
  4. EU-funded Thematic Network "CALLIOPE - Creating a European coordination network for eHealth interoperability implementation: http://www.calliope-network.eu/
  5. CBHD: http://europa.eu/legislation_summaries/information_society/data_protection/l14012_en.htm
  6. http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52012PC0011
  7. http://eur-lex.europa.eu/legal-content/en/ALL/?uri=CELEX:52012PC0010
  8. Services oriented architecture
  9. Event-driven architecture

References

  1. eHealth Action Plan 2012-2020 – Innovative healthcare for the 21st century: http://ec.europa.eu/information_society/newsroom/cf/itemdetail.cfm?item_id=9156
  2. eHealth Governance Initiative Discussion paper on semantic and technical interoperability, page 2-3: http://www.ehgi.eu/Download/eHealth%20Network%202%20Paper%20-%20eHGI%20Discussion%20Paper%20Semantic%20and%20Technical%20Interoperability-2012-10-22.pdf
  3. eHealth European Interoperability Framework: https://ec.europa.eu/digital-agenda/en/news/ehealth-interoperability-framework-study-0
  4. European Interoperability Framework: http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf