semantic!interoperability!for!health!network! - i~hd 288408 d6_1... · 2015-08-11 ·...

!

!

!

!

!

Semantic!Interoperability!for!Health!Network!!

!

Deliverable)6.1!Recommendations, to, industry, and, to, health,ministries:!!on! the$ scaling$ up$ and$ widespread$ deployment$ of$semantic)interoperability)solutions!!!

Version!1.0,!29!May!2015!

!

Call:!FP79ICT9201197!Grant!agreement!for:!Network!of!Excellence!(NoE)!Project!acronym:!SemanticHealthNet!Project!full!title:!Semantic!Interoperability!for!Health!Network!Grant!agreement!no.:!288408!Budget:!3.222.380!EURO!Funding:!2.945.364!EURO!Start:!01.12.2011!9!End:!31.05.2015!Website:!www.semantichealthnet.eu!Coordinators:!!

!The! SemanticHealthNet!project! is! partially! funded! by!the!European!Commission.!

!

!!

D6.1.!Recommendations!to!industry!and!to!health!ministries! ! ! 2!

Document description

Deliverable: D6.1. Recommendations to industry and to health ministries Publishable summary:

The SemanticHealthNet work plan recognizes the importance of engaging with industry to ensure that approach is taken to the design of semantic interoperability assets are practical and affordable to deliver through usable system functions. Early in the project it was agreed that industry engagement should not be isolated through an independent advisory board, but that industry representatives should participate in multi stakeholder activities in many areas of the work plan. This especially included the Sustainable Semantic Interoperability Task Force driven by work package 7, reported in other deliverables, that has given rise now to the formation of the European Institute for Innovation through Health Data, reported in deliverable 8.1. Industry representatives were also specifically invited to a joint and contribute feedback into a joint SHN CIMI workshop held in March 2014. It was, however, considered important to invite industry more specifically to comment, towards the end of the project, on the understandings arrived at within SemanticHealthNet about semantic interoperability, what the principal challenges are, how they should be prioritized and addressed, and what kinds of action now needs to be taken by different stakeholders. A two-day Industry Forum on semantic interoperability was held in January 2015, hosted by COCIR in Brussels, in which different stakeholder viewpoints were discussed through panels, in each case complemented by industry viewpoints on those topics. This deliverable primarily reports on that event, and presents its recommendations. Further industry consultation was undertaken by COCIR on the Forum recommendations, and the Executive Summary of this deliverable presents the post consultation version of the recommendations. Triggered by the event, industry representatives and representatives from several EC projects are now collaborating to define some key semantic fragments that are often needed within semantic interoperability specifications. The annexed to this deliverable presents the initial work of this ad hoc group, which is continuing to work through the summer of 2015 on a voluntary basis.

Status: FINAL Version: 1.0 Public: ! Yes – after approval by the EC Deadline: May 31, 2015 Contact: [email protected] Co9editors: Charles Parisot, Stephan Schug, Giorgio Gangoli, Luc Maes, Nicole

Denjoy, Geert Thienpont

Document history Date Revision Author(s) Changes May 27, 2015 V0.1 Dipak Kalra Insertion of post-consultation

version of the Industry Forum report, and of the Think Tank Annex

!

!!


!

Contents!

1! Executive!Summary!..........................................................................................................................................!4!

2! Industry!Forum!on!Realising!Semantic!Interoperability!Across!Health!IT!Systems!..........................................!9!

2.1! Background!to!the!Industry!Forum!..........................................................................................................!9!

2.2! Structure!of!the!event!............................................................................................................................!10!

2.3! Opening!presentations!...........................................................................................................................!12!

Panel!sessions!.......................................................................................................................................................!13!

2.4! Panel!I:!Interoperability!requirements!for!the!delivery!of!integrated!and!person9centred!care!...........!15!

2.4.1! Panel!and!audience!discussion!9!summary!of!points!raised!...........................................................!18!

2.4.2! Key!principles!and!recommendations!............................................................................................!19!

2.5! Panel!II:!Importance!of!interoperability!policies!for!healthcare!payers,!ministries!and!insurers!..........!21!



2.6! Introduction!to!Day!2!by!Gerald!Cultot!..................................................................................................!27!

2.7! Panel!III:!Interoperability!for!large9scale!clinical!research!and!learning!healthcare!..............................!29!



2.8! Panel!IV:!Interoperable!Standards!Development!and!Interoperability!Profiling!Organisations!............!34!



2.9! Conclusions!and!next!steps!....................................................................................................................!39!

!

!

!!


1 Executive Summary

The SemanticHealthNet project is developing a network of excellence and establishing good practices in the development, adoption and scaling up of semantic interoperability across Europe. The project has worked with clinical and public health domain experts to establish their semantic interoperability needs, as example requirements holders and end users, and worked with standards and specification development experts to propose semantic interoperability assets to meet these requirements. Other multi stakeholder groups have examined the challenges with scaling up the adoption of semantic interoperability standards, including the value propositions and business models needed to grow the market and to make it more responsive to real user needs. Although industry representatives have been part of many of these activities, SemanticHealthNet wished to collate a wider consensus of industry opinions on these semantic interoperability adoption challenges, and in particular to look at the interface between industry and several other critical stakeholders who are driving the needs for, and procurement of, interoperable eHealth solutions. A two day industry forum on semantic interoperability was held in January 2015, with around 60 participants from the health IT industry, clinicians, health ministry and health insurer representatives, public health and clinical research representatives, standards development organisation representatives and others active in the field of health IT / eHealth. The event was hosted by COCIR and organised as a series of panel discussions focusing on:

• clinician and patient perspectives; • healthcare purchaser perspectives; • clinical research and learning healthcare perspectives; and • standards development organisation perspectives.

Each panel comprised three or four representatives from each perspective, along with three or four representatives from small or large health IT companies. The panellists each spoke for around five minutes to describe the opportunities that they saw for semantic interoperability and from richer health information sharing, and the challenges ("pain points") that they saw inhibiting the successful scale up of semantic interoperability today. Each panel session included a substantial time for interaction among the panellists and with the audience, followed by a drawing together of the emerging themes, key principles that should be reflected in the approach going forwards, and possible recommendations. The panellists’ contributions and discussion points from each of the panels are described in the body of this report. Each section lists the recommendations as they were drafted during the event. The initial report of the January event was circulated as a draft for wider industry input. Following that consultation, the recommendations – being directed to particular stakeholder

!!


groups - have been consolidated and are listed below in this Executive Summary. These recommendations are supported by industry in order to help grow and focus the market in semantically interoperable health IT products and to promote the adoption of semantic interoperability standards. Main principles and recommendations arising from the panel on: Clinician and Patient Perspectives A. Standards and nomenclatures should not impose an unreal precision on the

interpretation of clinical statements: they need to cater for uncertainty and excluded findings.

B. High quality documentation is key: applications and medical terminologies must reflect the words and phrases of the clinicians, and the patients.

C. Terminology systems within records and summaries should be enabled to accommodate lay language – both for the input of self-recorded health data as well as for the understanding of existing documentation

D. Standard vocabularies should be developed by national bodies seeking consensus, not just the vendors.

E. Design systems to encourage and to ease structured documentation, with fewer free text elements.

F. We collect too much irrelevant data: involve clinicians in defining what data are really needed to support decision making. The starting point has to be capturing the clinical context, and for clinicians to be able to transfer their needs to clinical modellers in a standardised way (we need more participation from clinicians).

G. Incentives, including funding, need to be provided to ensure good documentation, including manually curated summaries.

H. Provide benefits to clinicians from good documentation such as contextual advisory systems: an added value for health professional work flow and the outcomes of care.

I. Develop full interoperable health records by starting from patient summaries, and growing content incrementally

J. eHealth interoperability needs to be simple - learn from the supermarkets that are now offering simple healthcare services to their customers; (but note that making things simple is often far from easy).

K. Do not adopt a one size fits all, standardise everything, approach - we need multiple standards but they must be integrated in the clinical workflow and shown to work together.

L. Smart incentives and penalties must be developed and applied to push healthcare providers (organisations and individuals) to explore and follow evidence based practices.

M. Procurement contracts on Health-IT services need to prioritise interoperability, to stimulate industry adoption of standards and profiles.

N. Innovative Health regions should provide integration platforms on which multiple vendor solutions can build, to support smaller vendors and ensure they will be interoperable.

!

!!


Main principles and recommendations arising from the panel on: Healthcare Purchaser Perspectives A. Health ministries and authorities should specify and promote the role of eHealth to help

remodel healthcare services, empower patients and shift the focus towards prevention and wellness.

B. Health ministries and authorities should make investments in clinical content standards and terminologies and make them freely available for healthcare practitioners and industry to use

C. Health ministries – jointly with economy and finance ministries – should create the market conditions that promote (multi-vendor) interoperable applications and devices

D. Health ministries, insurers and commissioners should promote contracts endorsing person centred care, i.e. requiring healthcare providers to collaborate, to co-ordinate care and to engage patients

E. Health authorities should define the use cases for which standards are needed, but not develop standards. Governments should then purchase rights for royalty-free use of standards

F. Ministries need help in how to promote the use of standards G. We need evidence for the added value of semantic interoperability, to convince

healthcare funders & procurers - position it as an infrastructure, and as a protection of jobs - OR evidence for the services

H. Semantic interoperability needs to be widely understood as a business model for investment in building and maintaining the necessary infrastructure, info-structure and services

I. SMEs often bring a rapid response to user needs (agile), but may need guidance on strategies for adopting interoperability standards e.g. follow examples of IHE and Continua.

J. Agree standards at a European level, so that SMEs can sell products in multiple countries, but recognise that most cannot easily enter the US market (while the US vendors can more easily enter Europe).

K. Health authorities should provide the framework for interoperability, and central services such as registries, allowing industry to design useful services without the overhead of establishing each time the basic info-structure.

!

!!


Main principles and recommendations arising from the panel on: Clinical Research and Learning Healthcare Perspectives A. A clinical trial is a nice picture of a dirty world: we need to complement this with data from

real world use of medicines. There are huge opportunities for insight from re-used patient data, but can we create a continuously tracking & learning world?

• We can give value back to healthcare from a clinical trial by feeding trial data back into the EHR.

• An open data access mentality is needed, so that research sponsors and data sources support each other with scaling up data access and use

• Semantic disharmony is a major obstacle to scaling up data on a global level e.g. to understand dementia, to combine data from multiple wearable devices and sensors.

• It’s time to move from innovation to implementation. • Is healthcare unique compared to other sectors - is our interoperability inherently hard?

Don’t make excuses for not starting somewhere. • Let’s start by agreeing how we can share and make good use of the data items we already

capture consistently. • Is industry risk averse? This results in localised innovations, not making good use of

standards. • We need to stimulate our “demand side”: this is vital to promote standards adoption. • Governments can promote standards adoption by mandating the use of standards - but

they also need to reduce the costs of standards adoption, especially for SMEs. Main principles and recommendations arising from the panel on: Standards Development Organisation Perspectives A. SDOs want to collaborate towards interoperability - the brand wars are over, the

community know each other and want to work together - yet the list of currently available and overlapping standards relating to EHR data is huge!

B. Standards have to be accessible financially and intellectually, and a “delight to use”!- this includes providing clarity about which ones to use, and when.

C. The value of using a forthcoming standard must be defined prospectively, used to justify its adoption, and then evaluated. We have especially to show the benefits to clinicians e.g. avoid duplicate data entry.

D. Mappings between different, non-interoperable standards introduce patient safety risks and have huge maintenance issues. In addition the need for mapping must not be left to each vendor to work out - these are real costs incurred today.

E. We should share quality assured multi-lingual assets (including guidance, education and mappings).

F. The current standards development process (necessary) takes time to gain community engagement and consensus - SDOs must be honest about what can be delivered, and by when.

!!


G. We can work more quickly on guidance on how existing standards can be used - guidelines must be clear and help bring “interoperability of minds”.

H. It is important to show that standards can be profiled to meet specific use cases, and demonstrated to work in the real world (e.g. with testing tools, support packs, a support community).

I. Quality Management Systems are required in health informatics standards development - top down and bottom up, including feedback loops to learn from standards’ adopters.

J. We need to form collaborative communities of standards’ experts in the Member States, through coordination and iterative consolidation at the European level to strengthen the voice of Europe internationally.

K. Incompatible Data models should no longer be the point of vendor competition or lock in L. EHRs need to be tested for interoperability – reduces the diverse interpretations of the

standards by implementers.

!!


2 Industry Forum on Realising Semantic Interoperability Across Health IT Systems

2.1 Background to the Industry Forum

We have now invested around 20 years in the development of health informatics standards to support the interoperability of health information between heterogeneous systems and services. The early focus of such standardisation efforts was on the development of messages to support particular healthcare business processes, such as billing and the exchange of laboratory test orders and results. More recent efforts have recognised that routinely collected health information, such as the content of electronic health records, has some generic structural features that can be standardised. Parallel efforts have developed clinical classification systems and more recently large-scale terminology systems to represent the content of electronic health records. The binding between structural standards and terminology systems is most commonly reflected through clinical information models, such as archetypes. The challenge of semantic interoperability is to standardise the representation of potentially very variable user needs for documenting aspects of health and health care about individuals, using some combination of structural standards, terminology standards, and clinical models, and at the same time finding an appropriate balance between using the standards to enforce consistency of documentation and interoperability, but supporting enough of the flexibility and diversity needed across healthcare settings, specialties and professions. This challenge is greater because there are many different kinds of user, whose needs differ and have had varying degrees of influence over the development of the current generation of health informatics standards. On the other hand, industry faces a somewhat confused marketplace for the incorporation of rich interoperability within its products, and a portfolio of somewhat perverse incentives exists between the stakeholders. This can easily give rise to a mismatch between the functionality supported by interoperability standards and the functionality that is required by the purchasers of health ICT products. As a general observation, it seems that the standards are usually more sophisticated, and therefore potentially more complex and expensive to implement, than the interoperability demands of the marketplace. In order to scale up successful and cost-effective adoptions of semantic interoperability standards, it is essential that they are practical to incorporate within existing and near-term future systems, able to be utilised by end users via realistic user interfaces and persisted in EHRs and PHRs and population and clinical research repositories with robust preservation of meaning and good analytic performance. Tracking, validating and disseminating updates to these interoperability assets should not be inappropriately burdensome. These requirements are important not only to make future interoperable systems affordable, but to ensure vendors can implement

!!


semantics consistently and safely - to ensure the consistent creation of data as well as their subsequent use and re-use. Better defined interoperability services, backed by harmonised assets, will lower the cost of standards adoption and the cost of opening up standardised interfaces to evolve a more plug and play market. Interoperable component-based health ICT architectures and products are vital to stimulate the market, stimulate competitiveness, and enable innovation especially amongst SMEs. This is also essential in new areas of ICT, such as personalised care, personal health systems and wellness, which have so far proved sluggish despite huge potential. This Industry Forum focused on examining in more detail the barriers to the wide-scale adoption of semantic interoperability standards and specifications, and identifying possible changes and incentives for scaling up Europe-wide interoperability for health data. Through panel discussions with a selected range of stakeholders and key opinion leaders, with strong industry representation, the forum examined reasons why “scaling up”!had not spontaneously occurred - and why and how it may be now be stimulated. Action is vital as the continued lack of interoperability across supplier systems constitutes gross economic waste and, importantly, generates significant patient safety risks. The aim of the event and subsequent industry consultation has been to identify short and medium term actions and outcomes that can be taken forward by the SemanticHealthNet project and by partner organisations within the Network of Excellence, and to clarify multi-stakeholder actions that will achieve growth in the market for interoperable health ICT solutions and deliver benefits from them. 2.2 Structure of the event

The two day industry forum on semantic interoperability was held in January 2015, with around 60 participants from the health ICT industry, clinicians, health ministry and health insurer representatives, public health and clinical research representatives, standards development organisation representatives and others active in the field of health informatics. The event was organised as a series of panel discussions focusing on:

• clinician and patient perspectives; • healthcare purchaser perspectives; • clinical research and learning healthcare perspectives; and � standards development organisation perspectives.

Each panel comprised three or four representatives from each perspective, along with three or four representatives from small or large health ICT companies. The panelists each spoke for around five minutes to describe the opportunities that they saw for semantic interoperability and from richer health information sharing, and the challenges ("pain points") that they saw inhibiting the successful scale up of semantic interoperability today. Each panel session included a substantial time for interaction among the panellists and with the

!!


audience, followed by a drawing together of the emerging themes, key principles that should be reflected in the approach going forwards, and lead to proposed recommendations. 1. Interoperability requirements for the delivery of integrated and person-

centred care: from the perspective of clinicians and patients. What are the priorities? Have we over-complicated the standards landscape in relation to affordable interoperability needs, or is it not yet rich enough to meet these needs? Can we agree the most important use cases to support person centred care, beyond those already defined in the eHealth European Interoperability Framework?

2. Importance of interoperability policies for healthcare payers, ministries

and insurers: why should they invest directly and indirectly in interoperability, and how they can recognise and reverse the perverse incentives within health systems that presently exist. Can innovative targeting of payer reimbursements and other incentives on collaborative care models incentivise the procurement of interoperable ICT solutions and achieve patient benefit?

3. Interoperability for large-scale clinical research, business intelligence

and learning healthcare: “The world has changed”!- and the systematic supply of interoperable data for evaluation of evidence for treatment effectiveness and of new treatments is now a priority. To radically defragment the landscape requires collaborative interoperability for research and service evaluation. For discovery science and pragmatic drug trials, high-scale analysis of semantically-controlled phenotypes will create new high value market demand dependent on cross-system interoperability.

4. Interoperable Standards Development and Interoperability Profiling

Organisations: can profiles and standards adoption be made faster, easier, more affordable, robust - so that adoption really does deliver plug and play interoperability? The modern world is full of pragmatic standards that have transformed our lives –!but healthcare/research remains fragmented and difficult. The eHealth European Interoperability Framework, guidelines on Patient Summary and ePrescription, epSOS testing platform are the first step for starting the deployment of the interoperability in Europe. Can a pragmatic approach based on real projects and future EC research projects, working in strong collaboration, support harmonisation and avoid competition between standards?

!!


2.3 Opening presentations

Dipak Kalra, representing the SemanticHealthNet project, opened the meeting, and welcomed participants. He thanked COCIR for hosting the meeting, and for leading on the industry consultation that will follow this event. Dipak emphasised that we are at an exciting time in our field. An increasing number of information sources exist on our patients and healthy citizens to allow us to better understand their health needs and health trajectories. However, we also have a landscape in which the natural ICT market forces have not enabled interoperability to thrive. This may in part be due to the many different stakeholders and purposes of use for which health ICT solutions might be procured, some of which are quite removed from the end users of those systems: the healthcare professional and the patient (see below).

SemanticHealthNet has come to understand the value chain that indicates the ranking of financial influence on the marketplace, which emphasises the distance between those who determine procurement requirements and those who are the intended endpoint beneficiaries of those systems (see below). Dipak indicated that one of the purposes of this event was to understand this value chain better, and how value propositions might be better constructed to facilitate a growth in the marketplace for the scale up of standards adoption for semantic interoperability.

!!


Dirk Colaert, representing COCIR, also welcomed participants to the meeting. Whilst agreeing with Dipak, he also emphasised the importance of going beyond the results of individual research projects to ensure that industry have results it can use operationally. He pointed out that we have spent two decades exploring interoperability, but not generating many practical and useful solutions. We should not hold our breath waiting until we have the ultimate ontology, but should proceed in little steps, focusing on small pieces of information that are useful to share. We also need to focus on the "what" and not on the "how". Organisations like IHE can make profiles, validated through Connectathons, to establish the how. But it's clinicians who need to determine what content they wish to share. This should not be a top-down process, nor will it be only bottom up, and in practice it will be some kind of middle out. Dipak then set the scene for the panel sessions. He stressed that it was important to determine positive actions that can be undertaken in the short to medium-term, 1 to 3 years. This event was not intended to explore an academic agenda for the next 5 to 10 years. The audience, representing many diverse and relevant stakeholders, had been invited to help to co-create a practical agenda to move the field forwards, in particular to help focus the market for standards development and the industry adoption of them. Panel sessions Veli Stroetmann, from Empirica, acted as the moderator for all of the panels. She briefly introduced the members of each panel, and facilitated their interaction and audience questions.

!!


The rest of this report summarises, for each of the four panels, the key points made by each of the panellists, and the themes that emerged from the subsequent interaction between the panellists and with the audience. The section for each panel closes with a set of principles and recommendations that were proposed in order to help to accelerate the scaling up of semantic interoperability. Most of the panellists gave oral presentations, without slides, and only an occasional slide diagram has been included within the transcript where this explains or amplifies a point being made by one of the panellists.

!!


2.4 Panel I: Interoperability requirements for the delivery of integrated and person-centred care

Suzanna Hardman explained her role as the lead for the heart failure service provided by Whittington Health, an integrated care organisation, in North London. She has been working within SemanticHealthNet to provide clinical input on the development of informatics specifications for a heart failure summary record. She pointed out that the accurate diagnosis of heart failure is critical to optimal care and patient outcomes, including survival. However, chronic conditions do not come gift wrapped, and the diagnosis can be complex. Diagnostic criteria are completely agreed across all countries, and reflected in all guidelines. The challenge is not from clinicians being unable to make up their minds or disagreeing on these criteria. Rather there is clinical uncertainty inherent within the pathway until a diagnosis is reached, and this uncertainty needs to be reflected in the clinical information and its interoperability. Suzanna described, through an example patient story, how important it was to have access to the complete record of the patient from another hospital, in order to arrive at the correct diagnosis and treatment, and thereby prevent an avoidable death. She also presented data from the UK National heart failure audit, showing that mortality following discharge from hospital with heart failure is radically altered by the quality of inpatient care including specialist engagement facilitating diagnosis and the prescription of disease modifying drugs (see graphs).

Suzanna closed by emphasising again the importance of accurately reflecting where clinical uncertainty exists, within the information, and not falsely coding interim opinions as if they are certain diagnoses an area of recurring healthy tensions within this project.

!!


Paul Rastall, a physician and clinical research fellow at the Royal College of Physicians, spoke about his experience of engaging with patients on their priorities and wishes in relation to long term conditions, such as heart failure. Through SemanticHealthNet he has run focus groups, interviewed individual patients and conducted online surveys in order to understand the patient perspective. Firstly, he found that patients want to have individualised care, not so much focused on the physiological parameters as on their lifestyle: what limits their present experience, the impacts on their life and the life of their families, employment and finances. They wish to learn about, and prioritise, care towards symptoms that trouble them most, such as being tired all the time or poor sleep. They also wish their care to take into account the multiple medical problems they may have. Secondly, patients want to access their records. But he stressed that we need to learn much more about what patients actually want to see, how they want to use that information and how we can facilitate them making such use. Thirdly he found that patients want to actively contribute to their records, to self care, to set priorities and to improve the dialogue they have with their clinicians about the things which matter most to them. Paul believes that clinicians are being trained to be better at patient centred care, but that our records systems have not yet caught up with that approach. Robert Vander Stichele, a GP from Belgium, focused on the role of the GP as the integrator of information. The GP will document a clinical encounter in order to look up and be reminded of what happened when he next sees the patient, but he also documents for his colleagues. More and more, that record is also important for the production of a shareable (often online) health summary that can be used by other specialists and generalists. He emphasised the importance of data entry at the point of care, which is the beginning of this information chain. The quality of the information is at its highest in that original system, and will degrade as it moves from system to system, from language to language (see below).

Our systems therefore have to facilitate the capture of the best possible quality of original documentation, so that it is suitable for use by other colleagues including specialists in an emergency situation. The data quality must also support internal secondary uses, such as clinical audit and use by decision support systems, and external secondary use such as clinical research and public health. Creating documentation with the quality and completeness needed for all of these purposes will take additional effort, and will need incentives. The starting point for capturing high-quality data entry is the interface terminology. Bob expressed the view that we have not been very good at developing interface terminologies, and that we should start by harvesting the words and phrases that doctors and patients use, and from that build up end user lexicons with links to international reference terminologies and classification systems. Secondly we should respect and use the interoperability standards for electronic health records, and grow a collection of clinical models and ontologies through the involvement of multiple medical subspecialty teams and

!!


patients. These sources must be openly accessible, as linked open data, and not embedded within proprietary systems. He urged for cooperation across medical specialties and standards developers to tackle this quest. Mark Leaning, Chairman of Helicon Health, has an engineering background and has worked in health informatics over many years, involved in the translation of research results into general practice and intensive care systems including medical devices. Helicon Health is also a university spin out company which is clinically led and delivers integrated and person centred care, in particular for cardiovascular diseases such as atrial fibrillation and stroke prevention. Its goal is to enable clinicians, patients and, increasingly, healthy citizens to collaborate electronically in hospital and the community, for which communication is a sine qua non. This is complicated because there are so many different venues, systems and types of people, including patients. A real stumbling block has been integration with existing GP systems, because the system providers have not usually made their data base interfaces very accessible. The Helicon Health system is based on EN 13606, and this integration would have been a lot easier had other suppliers also used the same standard. However, Mark emphasised the importance of recognising that communication is also a human experience, in which fears and expectations and emotions are also shared, some of which will include uncertainty. It is critical not only to consider the data and its structure and semantics, but how we intend to use it. Mark concluded that the adoption of the EN 13606 standard had not yet bought the company interoperability, because other systems were not using it. Toma��Gormik, CEO of Marand, has been working actively over the last few years promoting semantic interoperability other EHR system vendors, and offering his company's platform as a way to achieve this. He has found that the larger vendors do not have the imperative or have the capacity to change, so he has found it more beneficial to focus on the smaller vendors and new entrants to the market. He has observed that truly disruptive innovations come from these smaller new entrants, whereas the established vendors tend to evolve their products incrementally by adding small areas of functionality. However, the smaller vendors find it difficult to compete with the larger ones, except by offering modular solutions that can be combined to form best of breed solutions. This is where standards should play a strong role, but where we have seen a history of failure in health. This has a lot to do with the customer requirements not being clear. In contrast, in high-tech industries this disruption from modular standardised components has already happened. In healthcare the larger monolithic solutions predominate, whilst customer requirements are still not well met. Disruption can come in other ways: Walmart claims they want to be number one in health care, and they do have a big advantage with the customer (the patient) coming onto their premises once a week. Toma��believes they will not take an existing health ICT product but will build or commission their own. This will give them an opportunity to adopt the right approach from the beginning. Another example in healthcare is where the Norwegian vendor DIPS has partnered with the government on the development of clinical data models, which they will then use within all of their Norwegian hospitals. Another disruptive example is the city of Moscow, which is a green field environment of 12 million persons needing EHR systems. It has given the contract to four vendors who need to collaborate by connecting to a single city-wide health data platform.

!!


Annika Sonne Hansen is a registered nurse who has recently spent eight years working for a company as a terminology expert. She is also a patient with chronic disease. She has spent the last decade developing terminology and classification systems, internationally, and believes that these are now quite good. Annika believes that we primarily need education to be able to bring semantic interoperability into the daily experience of patients and clinicians, in hospital and primary care. SDOs have not been good at marketing their terminologies and classifications for the purposes that they can support well. The focus now must be on implementation. Policymakers, as well as end users, need education - they need to develop strategies and national standards that require compliance with standards. Patients are also important to educate. Through her experience of a Danish innovation project, Patient at Home, in heart failure, she can see that patients will need to be able to read and understand their health data including the data on their medical devices. We also need to focus on how we present questionnaire templates to patients, in a way that is clear to them and easy to answer. Annika also wonders if all of the data we can capture will be needed. There is a need to develop better ways of filtering the data, to allow the clinician to focus on what is important. Finally, it is important that those who develop standards are clear about the "food chains" in using their standards. This may be another case for education, and the development of use cases to demonstrate how standards can prove useful. Vendors need to be clear on why they should adopt each standard. 2.4.1 Panel and audience discussion - summary of points raised

� Patient associations need to be involved in defining information from the patient

perspective to be included within data sets and templates, to share with clinicians. � Our templates need to reflect capturing how the patient feels about their illness, including

what activities and functions they want the treatment to enable. � Patients want to be able to review and contribute to their records, to include their

perspectives and priority symptoms, for discussion with clinicians, and shared decision making. � Clinicians are getting better at patient centred care, and our records and record systems

now need to catch up. Communication, and therefore interoperability, is a sine qua non for integrated and person centred care. � Information can only degrade when communicated, so it needs to be as good as possible

on data entry: we must support the end user to make the best possible clinical documentation, with better lexicons and interfaces. We need investments in better interface terminologies, dealing with multiple languages and with medical jargon � Health records and interoperability need to capture and �look after areas of clinical

uncertainty - and not seek to make this more precise than is the clinical reality. � Have we paid too much attention to data structure and taxonomy, and not enough to how

we wish to use the data? Do we seek to collect too much data? We should focus only on the data that will facilitate integrated care. � Develop fully interoperable records by starting from patient summaries, and growing

content incrementally. However, a summary can be useful, but making sound clinical decisions may need access to historic clinical data. An automatically generated summary needs a lot of manual curation - automated summarisation might not prove helpful.

!!


� We should specify individual (high priority) data elements, their relationships and their clinical context, specified as clinical models, and develop for each the smartest formats for EHR data entry, including the semantics for optimal user interface components. But how do we find and make best use of the clinicians who are willing to work with us to develop this semantic interoperability?

� Multiple systems are in use within a hospital - these are not interoperable with each other, but need to be. We need to persuade vendors to respect and use the available standards for EHRs: however, adopting a standard may not buy real interoperability - not everyone else speaks this language. Are standards sometimes too complex?

� Larger vendors don�t have the capacity or the imperative to change to improve their semantic interoperability. Small vendors can grow modular solutions to displace large vendors - only if the large players have established how to meet the user requirement. SMEs have difficulty entering the market when the products of large players do not yet meet the requirements but continue to be procured.

� Healthcare organisations should receive incentives or penalties, based on their adherence to best practice e.g. guidelines

� Could a health region provide an integration platform on which multiple vendor solutions can build, to ensure they will be interoperable?

� What educational needs should be met to help users and end users better understand the available terminologies? � Education is also needed for policymakers - to understand the standards and why they are

needed.

2.4.2 Key principles and recommendations

A. Standards and nomenclatures should not impose an unreal precision on the

interpretation of clinical statements: they need to cater for uncertainty and excluded findings.

B. High quality documentation is key: applications and medical terminologies must reflect the words and phrases of the clinicians, and the patients.

C. Terminology systems within records and summaries need to include citizen language: standard vocabularies should be developed by national bodies, not the vendors.

D. Design systems to encourage and to ease structured data entry, with fewer free text elements.

E. We collect too much irrelevant data: involve clinicians in defining what data are really needed to support decision making. The starting point has to be capturing the clinical context, and for clinicians to be able to transfer their needs to clinical modellers in a standardised way (we need more participation from clinicians).

F. Incentives, including funding, need to be provided to ensure good documentation, including manually curated summaries.

!!


G. Provide benefits to clinicians from good documentation such as contextual advisory systems: an added value for health professional work flow and the outcomes of care.

H. Develop full interoperable records by starting from summaries, and growing content incrementally.

I. eHealth interoperability needs to be simple - learn from the supermarkets that are now offering simple healthcare services to their customers; (but note that making things simple is often far from easy).

J. Do not adopt a one size fits all, standardise everything, approach - we may need multiple standards but they must be shown work together.

K. Smart incentives and penalties must be developed and applied to push healthcare providers (organisations and individuals) to explore and follow evidence based practices.

L. Procurement contracts on Health-IT services need to prioritise interoperability, to stimulate industry adoption of standards and profiles.

M. Innovative Health regions should provide integration platforms on which multiple vendor solutions can build, to support smaller vendors and ensure they will be interoperable.

!!


2.5 Panel II: Importance of interoperability policies for healthcare payers, ministries and insurers

Jeremy Thorp works for the Health and Social Care Information Centre in England, a national competence centre for the delivery of information IT projects, working closely with the UK Department of Health. There is now a recognition that the existing model of the National Health Service may no longer be affordable, given the ageing population and increased prevalence of disease. There is a need to organise healthcare differently, and one such change is to place more emphasis on wellness and prevention, and to offer earlier interventions to improve quality-of-life and reduce downstream health care needs. This in turn can be achieved by stronger engagement and empowerment of patients, and by developing new models of care. There may need to be multiple new models, determined locally, and not a �one size fits all change. This will require information systems that support integration across multiple sectors, multiple sources of data and are multidisciplinary. His organisation has therefore had to reconsider what its role should be in fostering local innovations and new local models of care. It continues to feel appropriate that there is a national role in terms of an underpinning infrastructure and standards, where appropriate, and creating an environment within which a number of parties can play: in which large numbers of organisations and people are able to develop and to share things such as apps. However, the big issue that Jeremy believed we have not yet asked is how to stimulate the demand side: how to make the case from the buyer point of view. We are still trying to push things, solutions and answers, but somehow we have not been able to stimulate the pull. This might now come from patients. Mich� le Thonnet works for the Ministry of Social Affairs, Health, and Women Rights in France. She used to work for industry, in clinical research and on standards. Dipak already presented the state of play from the pure �semantic point of view ; it appears the community of semantic interoperability (IOP) progresses quite substantially recently. Nevertheless we have to consider at the same time other �correlating aspects. For instance, even if we solve the semantic part of IOP, unless the technical part will be mature enough and deployed, nothing will be improved in terms of usage. At the same time, the organisational level and governance is still far away to be adequate if we expect cross-border exchanges and Mich�le is presently also focusing on the legal level of interoperability. This is one reason why it is important to have all stakeholders on board. To stimulate the discussion, she invited the audience to help her to develop the convincing arguments, that she could use with her Minister, for convincing her to invest in �semantic at long run i.e. clarifying how to express the added value of semantic interoperability in terms of concrete outcomes for the health professional clinical use. Mich�le commented on earlier remarks, in the previous panel, about incentives, which she described as a Pandora's box. They could have in some cases a perverse role. She challenged the audience on whether we could develop a balanced set of incentives, not just for industry but for every type of stakeholder, not just expressed in terms of financial return but allowing to move forward together. If we make the convincing case for and with interoperability and standards, that could potentially open up a bigger market, but not equally in all countries because some will have a lot of legacy applications and find it difficult to move forward from that point (time and resources challenges). Quality criteria and certification are also considered a kind of

!!


incentive, but can prove a particular barrier to SME�s, as the certification process may be too costly, and too long till they are able to enter the market. This applies also to innovative procurement contracts, which can take a long time to develop. In navigating the long chain between producers and implementers we sometimes could lose a lot of time, resources, and connection with the user needs and expectations. This is one more reason to try to build upon outcomes of national and European projects rather than always starting from scratch. The large pilot projects and experimentations are certainly one way to continue to co-design and co-operate by allowing all the stakeholders to work together. This is what we experiment at regional and national level in France as well as at European level. Christoph Rupprecht works for the Health Policy and Health Economics department of the AOK Rheinland/Hamburg, which has 3 million insured in the region of Hamburg, Cologne and Dusseldorf. Around 25 million are insured by the federated AOK-group (5% of the EU population). The AOK has to balance the interests of the insurees and the patients. The German healthcare system loses up to 10-20% of possible revenues through deficiencies in communication, cooperation and co-ordination. eHealth, or digital communication, is a main answer to those deficiencies. The AOK undertakes a large number of patient centred, integrated care contracts and projects in many diseases. This includes patient coaching for which many apps and devices are used. More than 10,000 of the patients of the whole AOK Group use telemedicine in chronic heart failure. It makes sense to connect these apps and devices to the routine process of health care, provided they are standardised, safe and certified. Semantic interoperability, though, is so far only meaningful for AOK in the context of the German health system. There is not an immediate concern to address cross-border health data transfers and semantics, for the patient: national standards would probably be sufficient. However, there is a clearer need for health professional EHR systems to use common European or international standards. For AOK, semantic interoperability holds great potentials for analytical purposes and for clinical research. So far, basic digital communications in health care, enabled through German legislation many years ago, clearly focused on the use cases of emergency care, a medication record and telemedicine applications such as teleradiology. In order to be useful, the medication record cannot only be on a smart card but needs to be accessible online, for all patients. This is not yet enabled by German legislation. A stakeholder consensus on the types of clinical use cases that would benefit from semantic interoperability is needed. However, there is also need for clear roles and clear responsibilities. Incentives will help, but not only money - eventually hospitals will experience more efficient discharges etc. The AOK will only indirectly act as a procurer of telemedicine solutions: if these kinds of solution are procured across Europe, large international providers will eventually become more competitive. Industry can play a very helpful role in this scaling up. Miroslav Koncar, from Oracle Healthcare, told the audience that the health marketplace doesn't really have any standards with which it has to comply. This means it is possible to sell one-off products. Almost no other sector would work this way and, without standards, products would be too expensive to build. We really need to push standards, so that industry can build products that can benefit from economies of scale and be sold in many different places. Products would then also be more sustainable. Semantic interoperability is not an easy term to define. When speaking in another natural language, such as a Croatian speaking English, the things one says are not the same as one�s thoughts. And, when listening in another language, what one stores in the brain will depend on how one plans to use that information. So semantic interoperability may mean different things to different

!!


people. Having listened to Jeremy Thorp, Miroslav agreed that any government should be careful about buying apps. Governments should enable an ecosystem for apps, since a different company may build the best cardiology app or the best diabetes app, and other companies might build better applications six months later. Governments should focus on standards for the data. He closed by remarking that even the telecoms industry does not have this problem sorted: between the providers they have 10 million current Croatian customers although there are only 4.2 million Croatian citizens! Alexander Berler, from Gnomon Informatics SA, emphasised that the mobile world seems to be a good starting point for developing new models of health care. However with almost 200,000 mobile health applications we are now creating new information silos. There is a clear need for interoperability, and the smaller companies certainly need guidance, probably top-down guidance, on the best strategies for this. At another scale, the European Commission has just spent about �36m on the epSOS project, which has published many useful deliverables and a reference implementation that is free to use. If we want to tackle the big picture, it's best to do so in small chunks and avoid long and complex procurements. Greece has, for example, designed and built its national ePrescription system in small chunks, achieving 90% of prescriptions being electronic within two years. They avoided reinventing the wheel, and used software that had been developed in epSOS. Smaller companies can sometimes listen better to what the end user wants, and react faster. We should try to harmonise the market, such that a Croatian company can go to Germany, or a Greek company can go to Portugal etc. For this we need interoperability and standards. This will also improve competition and give the end user a wide selection of good applications that can all work with their other systems. IHE and Continua are actively trying to help by developing integration profiles for the mobile world. We need to harmonise the market at a European level. We are competing with huge companies from the United States. Interoperability standards, including semantic interoperability, is the way to go. The Antilope project has developed a strategy for taking this forward. Jos Devlies, from Custodix and a former GP system supplier and former GP, pointed out that health authorities need knowledge in order to manage their health systems, and therefore they need data. This data is coming from health professionals who have concepts in their mind - linguistic expressions - and who have to translate these into terms. This introduces a danger because different coding systems have been developed for different purposes, and the granularity is not always there to accurately reflect the original linguistic expression. Health informatics must not reduce the quality and richness of the information. We need to record information in as granular a way as possible, to preserve the quality of the data. This quality must include the context of the information. It also applies to the quality of the systems, for which there has to have certification. Without certification conducted by a third party there is no guarantee of quality. Another important issue is that health authorities do not want patient data to be trapped in particular systems. For this we need a common model for transferring the full electronic health record between systems. Belgium has invested a lot in this, and has a "patient migration format . There is also a "software migration format" that allows a physician to move all of their historic data from one system to another. This means that that historic data is also available for decision support. Jos stated his opinion that it is not the role of industry to invest in defining the content standards for health information: health authorities should invest in that, and then make the standards freely available. Jos knew of many small companies bringing systems onto the market that are

!!


attractive but do not use standards, because standards are hard and expensive to obtain. We have to give health authorities the strong message that if they want interoperability they have to make all the standards and tools available for free.

2.5.1 Panel and audience discussion - summary of points raised

� Health ministries and authorities should specify and promote the contribution of eHealth

solutions to remodel healthcare services, empower patients and shift the focus towards prevention and wellness. � Health ministries, insurers and commissioners should promote contracts endorsing person

centred care, i.e. contracts requiring healthcare providers to collaborate, to co-ordinate care and to engage patients. � eHealth legislation that mandates digital communications solutions must define these in

ways that encourage the data to be usable by healthcare professionals and patients for person centred care. � Health authorities should make investments in clinical content standards, and make them

freely available for industry to use � Ministries should define the use cases for which standards are needed, but not develop

standards. Governments should then purchase rights for royalty-free use of standards. � Ministries need help in how to promote the use of standards. Ministry supported disease

registries should act as role models of standards adoption � Health authorities and insurers need data not to be locked into individual systems. They

should provide the framework for interoperability, central services such as registries and perhaps cloud services, but industry needs to play a stronger role in the growth of the app market. � Health ministries should help to create the market conditions that promote (multi-vendor)

interoperable applications and devices. Note that standards adoption is harder when there is a lot of existing legacy, which might not achieve the desired opening up of the market. � The current financial incentives within healthcare do not mandate interoperability - this

needs to change. � Avoid monolithic procurements that are time consuming to deliver, instead procure smaller

parts (focused functions) � Financial incentives are easy to propose, but can divide stakeholders: what could be the

balance of incentives for each type of stakeholder in order for all to move forwards together?

� We need evidence for the added value of semantic interoperability, to convince healthcare funders & procurers: perhaps by positioning it as an infrastructure, and as a way of protecting jobs, and evidence for services. � What is desirable semantic interoperability may vary depend on who creates the

information and why, and who needs to consume the information and why

!!


� Health authorities and insurers need data, that originates from the healthcare professional. When they code, using different coding systems, they will lose some of the richness of their original linguistic expression. Therefore keep the original linguistic expressions as part of the EHR. � More standards are needed for social care data. � Semantic interoperability needs a business model for investment in building and

maintaining the necessary infrastructure, info-structure and services. � It is vital to link semantic interoperability with technical, organisational and legal

interoperability

� Industry claims to want certification, but also fears this will be too expensive and slow: certification does not guarantee usage of certified products � How do we speed up converting new user requirements into deployed products and

updates? � SMEs bring a rapid response to user needs (agile), but need guidance on strategies for

adopting interoperability standards e.g. follow examples of IHE and Continua � Agree standards at a European level, so that SMEs can sell niche products in multiple

countries, but recognise that most cannot easily enter the US market (while the US vendors can more easily enter Europe). � More standards-conformant health ICT tools are needed, that will encourage products (that

use them) to become more standards conformant.


A. Health ministries should specify and promote the role of eHealth to help remodel

healthcare services, empower patients and shift the focus towards prevention and wellness

B. Health authorities should make investments in clinical content standards, and make them freely available for industry to use

C. Health ministries should create the market conditions that promote (multi-vendor) interoperable applications and devices

D. The financial incentives within healthcare do not mandate interoperability - this needs to change

E. Health ministries, insurers and commissioners should promote person centred care contracts that require healthcare providers to collaborate and co-ordinate care and to engage patients

F. Health authorities should define the use cases for which standards are needed, but not develop standards. Governments should then purchase rights for royalty-free use of standards

G. Ministries need help in how to promote the use of standards

!!


H. We need evidence for the added value of semantic interoperability, to convince healthcare funders & procurers - position it as an infrastructure, and as a protection of jobs - OR evidence for the services

I. Semantic interoperability needs to be widely understood as a business model for investment in building and maintaining the necessary infrastructure, info-structure and services

J. SMEs bring a rapid response to user needs (agile), but need guidance on strategies for adopting interoperability standards e.g. follow examples of IHE and Continua

K. Agree standards at a European level, so that SMEs can sell products in multiple countries, but recognise that most cannot easily enter the US market (while the US vendors can more easily enter Europe).

L. Health!authorities!should!provide!the!framework!for!interoperability,!and!central!services!such!as!registries,!allowing!industry!to!design!useful!services!without!the!overhead!of!establishing!each!time!the!basic!info9structure.!

!!


2.6 Introduction to Day 2 by Gerald Cultot

Gerald Cultot had just taken over the European Commission brief for interoperability from Benoît Abeloos, at DG Connect in the unit for Health and Well-being. He summarised his reflections from the first day of the Industry Forum, as sound-bites captured during the day (see below).

He had heard during the day that physicians still struggle to use terminology systems, and that there is a need for patient education. He also learned that we have veto players. The European Commission cannot impose solutions on Member States, but can find incentives, which is a word he had heard many times during the day. Incentives could include certification processes that are harmonised at a European level. But what they are really keen to do at EU level is to stimulate the demand side. This could be through working with procurement and healthcare organisations to articulate their demands and to specify their needs. The EC already has a program called PPI 9!Public Procurement of Innovative Solutions - which could be a route to promote the use of international standards to achieve interoperability. This will be very important for SMEs as well. Gerald emphasised that he is very keen to hear

!!


from all of the audience members about other ways in which he and his colleagues can help further.

!!


2.7 Panel III: Interoperability for large-scale clinical research and learning healthcare

Veli welcomed the audience back for the second day, and introduced this third panel, and the panelists. Ed Conley, speaking from the perspective of the UK Clinical Research Network and the Farr Institute of Health Informatics Research, drew attention to new drivers shaping the way data is being collected, used and analysed. This is part of shifts towards value-driven healthcare and large-scale distributed research by consortia. Another big area of change is the advent of genomic medicine and new biological data underpinning the development of the diagnostics industry, stratified medicine, and ultimately, personalised medicine. To summarise the need for collective actions, Ed presented a learning healthcare (knowledge cycle) diagram. He stressed the importance of collaborative work to improve the flow of information around the cycle. For example, inter-system interfaces must be well defined, standardised and designed so that they can be widely adopted and enable the analysed results of research to feedback into patient care (see below).

Throughout the cycle, establishing a consistent scalable approach to semantics is essential, for example in the challenging area of phenotype descriptions. Consistent semantics are also required to improve matching to criteria for inclusion/exclusion in clinical trials. It is also vital for the consistent recording of clinical outcomes and the understanding of impacts on phenotype of genetic variants. Use of international standards benefits not only patient-centred sharing of care information but also the establishment of research interoperability and the multiple levels of data aggregation that is needed. Bart Vannieuwenhuyse, from Janssen Pharmaceuticals and the co-ordinator of the EMIF project, began by saying he was pleased that this industry forum was on realising semantic interoperability, so about implementing rather than developing. He believes it is time for us to move from innovation to implementation: there has been a lot of innovation but not enough

!!


broad implementation. Bart�s role within Global R&D means that he is specifically focused on the reuse of data, but he is concerned about the hype surrounding the recent term "Real World Data . The need to reuse data for research has been around for a long time: the opportunities are the same and the problems are still the same. However, Pharma has not really taken advantage of the potential insights to be gained from data - presently locked in population health databases and cohort studies - to inform the product life-cycle through drug discovery, clinical trials, launch and post-launch. Real-world data can improve the way we undertake clinical trials, such as protocol feasibility and patient recruitment. The European Medicines Agency is now discussing how to best create new evidence to enable adaptive licensing. Fortunately there are now a number of initiatives that are bringing different data sources together to enable large-scale research. But the first obstacle encountered when trying to do this is semantic disharmony: it currently takes a lot of effort to bring these datasets to a common level of understanding, for analysis. Governance and trust are also essential, in order to enable the sharing of data, especially with organisations like Pharma. The EMIF project is trying to build such a framework; this is a socio-technical endeavour which also includes governance policies and approaches to establish trust. As a company, Janssen has established an open data initiative in collaboration with Yale University, for which trust is again an important aspect. Once trust is established, and one can obtain access to the primary data sources, the next challenge will be their integration to map out longitudinal patient journeys. For this, we need to move from innovations to implementation. Dirk Colaert, from Agfa Healthcare, picked up on the theme of Real World Data. He recalled an observation made by our colleague Christian Lovis, that a clinical trial is actually "a nice picture of a dirty world" because patients are carefully selected and the data items are collected in a very meticulous way. It is very important to use real-world data to discover how effective and safe new drugs actually prove to be when given to more typical patients. Dirk stressed the importance of both primary and secondary uses of data: we should converge our technological approaches for generating and using individual patient views and population views of the data, because we need both. He welcomed Pharma interest in real-world data, but also challenged the industry to make its own data accessible in a computer readable format so that it can be used to develop and evaluate predictive analytic models. This data and its analysis is needed in order to help implement evidence-based medicine. Dirk also agreed with the need to focus now on implementation. He felt that we have been talking about semantic interoperability for many years, and that we should not wait until we have fully interoperable systems. Let's start by connecting systems bit by bit with other systems, resulting in a network of open interfaces to the data in multiple systems (he stressed open interfaces, not open access to the data). This won�t be a free lunch: it will cost money and certain stakeholders will need to be prepared to pay for widely implemented interoperability. Vasa Curcin, from Kings College London, focused his talk on the learning health system, which really captures the "why" of semantic interoperability. The concept of a learning system originated in the US, in which routinely collected health data is aggregated, analysed and knowledge from it is disseminated when needed within the health system. There are great examples of this within single academic medical centres, but these are individual silos (see below).

!!


To develop a learning health system at national and international levels one needs interoperability of data, but also a data-driven improvement ecosystem. Vasa referred to the example of the TRANSFoRm project which is, among other things, helping GPs to fill case report forms from routinely collected data, and then feeding back knowledge from trial data into the electronic health record. Vasa also challenged the assumption made the previous day that data quality can only deteriorate over time when it is transferred. He believed that data quality can be improved if it can be enriched through an understanding of its context and metadata, and that data quality improvement cycles should become embedded within our information systems. His vision is that a learning health system incorporates multiple interleaved improvement processes feeding off each other and informing each other, at the same time being minimally intrusive and self-improving (see below).

A learning health system also has to be trusted and certifiable, so the data and algorithms informing clinical decision-making can be trusted. The challenge will be to produce a digital infrastructure at scale, which will require common and certified components supporting semantic interoperability, traceability and provenance. However he has observed that presently examples of these learning health system components are being developed at local levels, not necessarily using standards. They therefore inadvertently create barriers to adoption. Whatever the limitations are in our present generation of standards, they are the best we have and it is important that we use them. Michael Strubin, from the Continua Health Alliance, wished to complement some of the other speakers on the panel by looking at the other end of the data life-cycle: the patients and citizens who will generate much of the �big data. Continua Health Alliance was founded in 2006 by a group of companies that included some that came to healthcare from the world of consumer devices. Their vision was of multiple devices that could collectively cover health

!!


care and lifestyle to create a vendor-independent ecosystem in which data could be exchanged between multiple devices and with any computer systems. At that point the smartphone hadn't yet been invented, but that vision has great potential today. Unfortunately today data remains in walled gardens, locked in our devices or proprietary clouds, unable to be used at a meta scale. Continua has not been universally adopted. Its starting model was inspired by the adoption of USB, but as we had discussed earlier health care is not like other sectors, and interoperability is perhaps not the natural state of this industry sector. As with USB, there is a chicken and egg situation in which the vendors originally did not adopt this standard because there was no market, and purchasers could not buy products with USB because there weren't any. In the case of USB it took one big supplier, Apple, to unilaterally decide to adopt it when it launched the iMac in 1998 - which instantly expanded that market across all suppliers. Michael has seen situations where a health purchaser has mandated Continua standards in a public tender, but had to pull back because they were not enough such products on the market. However governments are increasingly realising the benefits of an interoperability ecosystem, for example through recent national telemedicine strategies from Denmark and Norway. It may only take a few countries to stimulate the market enough to make it attractive for other countries to follow.


� A clinical trial is a nice picture of a dirty world: we need to complement this with data from real world use of medicines. There are huge opportunities for insight from reused patient data, but can we create a continuously tracking & learning world? � Should a clinical trial endpoint be a set of physiological parameters, or the outcomes as

perceived by the patient? � Pharma already publish trial results, including unsuccessful studies, but using traditional

channels. Pharma need to publish their study data in more computable forms, to allow other users and uses of that data, to feed that knowledge into the healthcare system. We can give value back to healthcare from a clinical trial by feeding trial data back into the EHR.

� Is Pharma ready to accept provisional licensing pending greater real world evidence (i.e. adaptive licensing)?

� New generation devices and apps allow citizens to monitor our diet, mobility etc. - a health and lifestyle data ecosystem, but today the data often still remains in walled gardens, in our devices or proprietary clouds. How do we de-fragment the existing data landscape, and scale this up? � Semantic disharmony is a major obstacle to scaling up data on a global level e.g. to

understand patterns of early dementia. � International standards are vital for a rich data ecosystem, we will always need to

interconnect multiple (best of breed) systems. But reduce the number of competing standards. � Is healthcare unique compared to other sectors - is our interoperability inherently hard?

Don�t make excuses for not starting somewhere. Let�s start by agreeing how we can share and make good use of the data items we already capture consistently.

!!


� The knowledge-learning cycle can be put into practice (e.g. demonstrated for heart failure in the UK) � An open data access mentality is needed, so that research sponsors and data sources

support each other with scaling up data access and use. We need a secure trusted environment - ecosystem - in which all parties know their data will be used in an appropriate (well-governed) way. This will cost money - and we have to accept that a commercial underpinning is needed.

� Give real time data quality feedback, to encourage best quality data capture. Can data quality be enhanced by adding richer context?

� Is industry risk averse? This results in localised innovations, and not making good use of standards. It�s time to move from innovation to implementation � What are the blockers to adopting standards, and what positive steps need to be

promoted. How can we stimulate our �demand side ? This is vital to promote standards adoption Governments can promote standards adoption by mandating the use of standards - but then they need to reduce the costs of standards adoption, especially for SMEs.


A. A clinical trial is a nice picture of a dirty world: we need to complement this with data from real world use of medicines. There are huge opportunities for insight from reused patient data, but can we create a continuously tracking & learning world?

B. We can give value back to healthcare from a clinical trial by feeding trial data back into the EHR.

C. An open data access mentality is needed, so that research sponsors and data sources support each other with scaling up data access and use

D. Semantic disharmony is a major obstacle to scaling up data on a global level e.g. to understand dementia, to combine data from multiple wearable devices and sensors.

E. It’s time to move from innovation to implementation. F. Is healthcare unique compared to other sectors - is our interoperability inherently

hard? Don’t make excuses for not starting somewhere. G. Let’s start by agreeing how we can share and make good use of the data items

we already capture consistently. H. Is industry risk averse? This results in localised innovations, not making good use

of standards. I. We need to stimulate our “demand side”: this is vital to promote standards

adoption. J. Governments can promote standards adoption by mandating the use of

standards - but they also need to reduce the costs of standards adoption, especially for SMEs.

!!


2.8 Panel IV: Interoperable Standards Development and Interoperability Profiling Organisations

Jane Millar, from IHTSDO (shortly to be named SNOMED International), started off by making clear that all of the standards bodies want to collaborate towards interoperability and implementability. She and colleagues hope to evolve the Joint Interoperability Council from a group of the SDOs who meet together to share ideas into a one-stop shop for reaching consensus and meeting the needs of governments vendors, clinicians and regulators. Standards bodies also have individual agreements with each other. In addition, IHTSDO forms specific collaborations as directed by their members. Jane echoed comments made in the previous panels - that we want to move from projects to implementation and sustainability. The international standards have been developed by observing and meeting the requirements for representing national and local health information, and so a common set of (international) standards can and should be adopted at local levels too. However, we have to demonstrate the benefits in order to get clinician buy in. A direct consequence of using common standards may be mapping, but we should seek to avoid mapping as far as possible - for safety and quality of care to individuals (mapping might be good enough for epidemiology and statistical purposes). Mappings introduce maintenance issues as well, as they have to be updated when any of the cross-mapped standards is updated. This has recently been illustrated by the Trillium Bridge project, which has had to develop multiple mappings on the US and the EU sides. IHTSDO is focused on implementation. An important aspect of this is usability: SNOMED CT needs user friendly interfaces, and so we need to work together with vendors on this. Translation is another effort that cannot be underestimated: it is important to quality assure translations and then to share them. Charlie McCay, representing HL7, confirmed that he largely agreed with Jane, but wished to take up the mapping issue. Although not ideal, unless the SDOs take on the mapping role it will happen elsewhere, at the supplier side, possibly without the same skills and of course may end up being undertaken separately by each supplier. It is hugely important for SDOs to recognise and demonstrate the value of what they are doing: to know what the benefits are and demonstrate that they are being achieved. Years ago there were brand wars amongst SDOs, but nowadays everyone wants to collaborate, and contribute to the learning health system we heard about in the last panel. For this the health community also has to learn to share information, including getting the legal framework right for shared care provision and health improvement. SDOs can contribute its know-how on this, and also themselves learn, for example that their standards have to be widely accessible, and accessible economically - a thousand pounds is a lot of money for an SME. Standards also need to be delightful to use - easy for developers to digest and to put into products. Karima Bourquard, from IHE Europe, explained that IHE is a profiling organisation: it is neutral vis-�-vis standards and uses many standards. It focuses on implementing them to see what can work in real life. IHE promotes the Connectathon, where SMEs and bigger companies come and test a profile specification, between them, and see if it works. IHE is a kind of neutral third party within the testing environment. Interoperability is not just reflected in standards, but in the proof that they have been implemented and work. IHE has a collection of use cases that some countries have picked up and are using, an interoperability framework, a testing procedure, a quality label and certification processes. Everyone now

!!


recognises that there are legal, organisational, technical and semantic layers to interoperability. When epSOS started in 2008 every country was using different words and terms for the same concept, which required mappings, and more recently Trillium Bridge has had to undertake mappings between the EU and the US. Even now countries will sometimes develop different national standards for the same purpose. We have a European Community of experts, and we need to work together on standards and share them, to avoid the mappings. Karima recommended that we should work together, as a coordinated set of stakeholders, on new use cases to support patients at home using mobile phone applications to monitor their own data for a chronic disease, and a patient seeing a new GP. Adoption would also require educating end-users, competence centres and vendors on the development of harmonised solutions, and also a single European conformity assessment scheme. Steve Kay, representing CEN, started with a riddle: why is an SDO is like an English hospital in wintertime? Patients turn up at an emergency department with unrealistic expectations of being treated immediately and of receiving a high-quality service, but causing overload on the system. There are similarly a number of unrealistic expectations of what standards can do. It takes time to gather inputs for a new standard and to gain consensus. Typically a new 'requested' standard will take a minimum of 18 months, and may be even 3 years for regional and international consensus processes to gain agreements. The demand is increasing for standards as a means to deliver better business (health & wealth) outcomes. We need to bring policy and implementation closer together, rather than these blaming each other for any shortcomings. The standardisation life cycle is not �waterfall , and often 'profiling' and 'standards' are regarded as separate and competitive approaches when they are part of the same process. Relevant standards in a fast moving socio-technological area are difficult to produce, and short term 'fixes' endanger sustainable solutions. However, the current funding models and commitments cannot deliver safe semantic interoperability. Concurrent Use, a CEN initiative, is one attempt to ensure that existing, large scale architectures can be used to deliver benefits; it is a start. The EU should actively promote European standards, and stakeholders need to be engaged to demonstrate value from them. Mario Romao, from Intel Corporation and the Continua Health Alliance, remarked that ICT is by definition a network environment, so interoperability comes naturally. A mobile phone uses around 250 standards to work seamlessly, anywhere. The ITU is a standards body, now 150 years old, through which people work on these standards and agree to use them. Healthcare has many more stakeholders who want information systems to work in their way, making it more complex. Intel was a founder of Continua, but has found that plug and play is much harder to achieve in healthcare. Its equivalent to IHE Profiles, Continua Guidelines (also ITU standards), are free to download, but there is still a need for training programmes. Mario suggested that we should put more of the public money spent on national eHealth programmes into training. Continua Guidelines reference about nine other SDOs and their base standards, and it works well with these bodies. However, there is a tension between standardisation and innovation. Some of the actors to which we look to first stimulate demand are perhaps some of those that don't understand the value of having standards, or at least interoperable standards. The Nordic example mentioned in a previous panel by Michael Strubin may break open the chicken and egg problem: tenders for interoperable solutions using standards gives a strong signal to the market to get such products ready.

!!


Herman Muys, of Agfa Healthcare, has experience of building semantic interoperability platforms for Agfa�s EPR product. He is presently working on the semantic integration of data from 40 hospitals around Paris (9 million patients), and has encouraged them to adopt SNOMED CT. For this he has needed to become trained as a SNOMED CT terminologist, and found that he needed those skills to work amongst the clinicians - to help to prevent errors as they annotate their forms and map them to SNOMED CT concepts. Sometimes concepts are missing: one has to add a local term to the local terminology server and replace it when an update arrives. However, mapping single fields in forms is certainly not enough. They had also to map relationships between fields, for example, a systolic blood pressure, diastolic blood pressure, a position, a cuff size. To retrieve this data these fields need to be combined. One ideally needs an information model. His team investigated HL7 version 3, HL7 CDA, EN 13606, openEHR, and could not easily determine which one to use. So they adopted the semantic technologies promoted by the W3C and the health care and life sciences group, to build a semantic data virtualisation model. They now have an ontology that does not try to reinvent the wheel but reuses existing ontologies. His team can use this as a tool to explore the data that they have extracted from the hospital systems. So, in the end they found a terminology, but didn't find a good information model, and therefore used Semantic Web technologies. Razvan Costea-Barlutiu works with Laitek, a medical data migration and storage company, primarily in the medical imaging field. Working with roughly the top 10 PACS and EHR systems vendors, and with more than 25 PACS solutions, has helped them to design their medical archiving solutions, and in particular to learn what a medical archive should not do. It is difficult to move data from legacy systems, but standards and standard interfaces are not enough. It is important to know what is behind the interface. Data and data models are no longer the competition turf between companies, but instead companies should compete on user interfaces and other user features. Unfortunately, instead, data ownership and data permanence have become issues, which gives his company a lot of work attempting to decode all kinds of proprietary format starting with image compression formats. There is absolutely no need for proprietary image compression to exist any longer: this is simply a means of locking in customers. Similarily with annotations, DICOM has a standard way of maintaining annotations over the long term in greyscale presentation states, but there are still a lot of systems that store annotations in a proprietary format. When migrating between systems, physicians expect to see their images with annotations in exactly the same way in the new system, but this might have been held in a proprietary format in the old system and the standards may not allow one to model that same information. This applies even when the vendors claim to have used a standard, because there are a lot of individual deviations from the standard which still makes it difficult for transition from one system to another. When it comes to EHR systems, Razvan concluded that there is a real need for a certification process that tests their interfaces and their internal data handling. At present there seem to be too many standards that are hard to put into a product correctly, so one ends up with too many dialects of a standard. It would be great to have an online version of the IHE Connectathon, so that this kind of testing can be used by more vendors on a broader scale.

!!



• Healthcare is a network environment - it needs ICT to survive - but we do not have

a global co-ordinating body for healthcare standards. • SDOs want to collaborate towards interoperability - the brand wars are over, the

community know each other and want to work together - yet the list of currently available standards relating to EHR data is huge!

• The Joint Interoperability Council will evolve to become the one stop shop for governments to bring their interoperability requirements, for standardisation.

• SDOs and industry are keen to move from standards adoption by projects and pilots to sustainable implementations.

• Standards need to be used locally, nationally and internationally - they are a way of sharing best practices and know how.

• The current standards development process (necessary) takes time to gain community engagement and consensus - SDOs must be honest about what can be delivered, and by when.

• We can work more quickly on guidance on how existing standards can be used - guidelines must be clear and help bring “interoperability of minds”.

• We should share quality assured multi-lingual assets (including guidance, education and mappings).

• Standards have to be accessible financially and intellectually, and a “delight to use”!- this includes providing clarity about which ones to use, and when.

• It is important to show that standards can be profiled to meet specific use cases, and demonstrated to work in the real world (e.g. with testing tools, support packs, a support community).

• Let’s work on 2 use cases: the patient at home with a long term illness, and the patient visiting a new GP.

• The value of using a forthcoming standard must be defined prospectively, used to justify its adoption, and then evaluated. We have especially to show the benefits to clinicians e.g. avoid duplicate data entry.

• Qualified terminologist support is needed to help a hospital to use SNOMED CT and to map its data to this. Mappings introduce patient safety risks and have huge maintenance issues - but this need must not be left to each vendor to work out - these are real costs incurred today.

• Do standards stifle innovation, or do only some standards do that? Avoid a waterfall approach to standards development.

• Quality Management Systems are required in health informatics standards development - top down and bottom up, including feedback loops to learn from standards adopters.

• We need to form collaborative communities of standards experts in the Member States, through coordination and iterative consolidation at the European level to strengthen the voice of Europe internationally.

!!


• Semantic interoperability needs to be backed inside the vendor organisation and

supported by the customers. • Interfaces are not enough - data models should no longer be the point of vendor

competition or lock in. • EHRs need to be tested for interoperability – reduces the diverse interpretations of

the standards by implementers. • We need more patient involvement - the main user of person centred care. 2.8.2 Key principles and recommendations

A. SDOs want to collaborate towards interoperability - the brand wars are over, the community know each other and want to work together - yet the list of currently available standards relating to EHR data is huge!

B. Standards have to be accessible financially and intellectually, and a “delight to use”!- this includes providing clarity about which ones to use, and when.

C. The value of using a forthcoming standard must be defined prospectively, used to justify its adoption, and then evaluated. We have especially to show the benefits to clinicians e.g. avoid duplicate data entry.

D. Mappings introduce patient safety risks and have huge maintenance issues - but this need must not be left to each vendor to work out - these are real costs incurred today.

E. We should share quality assured multi-lingual assets (including guidance, education and mappings).

F. The current standards development process (necessary) takes time to gain community engagement and consensus - SDOs must be honest about what can be delivered, and by when.

G. We can work more quickly on guidance on how existing standards can be used - guidelines must be clear and help bring “interoperability of minds”.

H. It is important to show that standards can be profiled to meet specific use cases, and demonstrated to work in the real world (e.g. with testing tools, support packs, a support community).

I. Quality Management Systems are required in health informatics standards development - top down and bottom up, including feedback loops to learn from standards adopters.

J. We need to form collaborative communities of standards experts in the Member States, through coordination and iterative consolidation at the European level to strengthen the voice of Europe internationally.

K. Data models should no longer be the point of vendor competition or lock in L. EHRs need to be tested for interoperability – reduces the diverse interpretations of

the standards by implementers.

!!


2.9 Conclusions and next steps

This Industry Forum was considered by participants to have been helpful articulation of many of the factors that inhibit the natural scale up of standards adoption, and of the wide deployment of interoperable eHealth solutions. The issues raised were numerous, and too diverse, to consolidate during the event itself into focused and targeted recommendations. This report has been shared within a wider network of large and small health ICT industry experts, through COCIR, to shortlist and gain consensus on a set of key recommendations to grow the demand and supply of interoperable products and services. These recommendations will be promoted by the SemanticHealthNet project, and by partner organisations within the Network of Excellence, as well as the various stakeholders that contributed to this Forum. !!

Project co-funded by the European Commission within Dissemination Level PU Public PP Restricted to other programme participants (including the Commission Services RE Restricted to a group specified by the consortium (including the Commission Services CO Confidential, only for members of the consortium (including the Commission Services)

Annex 1

Proposal (for(a(robust(process(to( identify, (ref ine(and(share(re5usable(semantic(fragments Intermediate REPORT of the Semantic Interoperability Think Tank Revision: 1.0

Authors: Persephone Doupi THL, Finland /

PARENT Joint Action

Patrick Ruch Univ. Applied Sciences Geneva / EXPAND

Charlie McCay Ramsey Systems Ltd, HL7 Int. Foundation / Semantic Health Net

Dipak Kalra Eurorec / Semantic Health Net

Charles Parisot COCIR, EXPAND, GE, IHE, Semantic Health Net

Christel Daniel AP-HP, INSERM France / EHR4CR

Dirk VanHyfte COCIR, Intersystems

Dirk Colaert COCIR / DebugIT, SALUS

Luc Maes COCIR Staff Stephan Schug Facilitator Giorgio Cangioli Editor

Proposal for a robust process to identify, refine and share re-usable semantic fragments

D6.1. Recommendations to industry and to health ministries Intermediate Report Page 2 of 24 28/05/2015

Revision History, Status, Abstract, Keywords, Statement of Originality

Revision History

Revision Date Author Organisation Description

0.1 27/04/15 G. Cangioli First Release for internal comments

0.2 06/05/15 G. Cangioli Added Executive summary; Integrated notes from the meeting minutes.

0.3 07/05/15 G. Cangioli Changes based on the comments of Dirk Colaert

0.4 10/05/15 S. Schug, G. Cangioli

Changes from the May 8th call and from Christel Daniel and Persephone Doupi comments. Introduction updated..

0.9 15/05/15 S. Schug, G. Cangioli

Added the “next steps” section. Reorganized the open issues items. Merged the Aim and Scope and the background sections. Included Charlie McCay comments.

1.0 20/05/15 C. Parisot Minor editorial changes. Final Document.

Abstract (for dissemination)

This document summarizes the initial results achieved by the Semantic Interoperability Think Tank team including the experience gained and the outline of main component of an execution process for the convergence towards increased semantic interoperability.

Keywords Semantic Interoperability, Fragments

Statement of originality This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.



Table of Content

Revision History, Status, Abstract, Keywords, Statement of Originality .......................... 2(Executive Summary ............................................................................................................... 4(1( Aim and Scope .............................................................................................................. 5(2( Glossary ......................................................................................................................... 7(3( The SIOp Think Tank initiative ..................................................................................... 9(

3.1( Team Composition ................................................................................................... 9(3.2( Desired Results and Course of Actions ................................................................... 9(3.3( Risks ...................................................................................................................... 13(3.4( Targets ................................................................................................................... 13(

4( Outline of an execution process ............................................................................... 14(5( Lessons Learned on basic features/ principles of robust process to identify, refine and share re-usable semantic fragments ................................................................ 21(6( Next Steps ................................................................................................................... 22(

6.1( Topics to be further analysed ................................................................................. 22(6.1.1( Process representation and composition .................................................................................... 22(6.1.2( Tool Box for the robust process to identify, refine and share re-usable semantic fragments. ..... 23(

List of Figures Figure 1 Project Management Pyramid ................................................................................................. 10(Figure 2 Goal ........................................................................................................................................ 10(Figure 3 Milestones ............................................................................................................................... 11(Figure 4 Intermediate Report Sub-Objectives ....................................................................................... 11(Figure 5 Strategies ................................................................................................................................ 11(Figure 6 Tactics ..................................................................................................................................... 12(Figure 7 - Approach Overview .............................................................................................................. 14(Figure 8 Process Overview ................................................................................................................... 16(Figure 9 Manage Fragments ................................................................................................................. 18(Figure 10 Analyse and Document Fragments Usage ........................................................................... 19(



Executive Summary The Semantic Interoperability Think Tank is an initiative promoted by COCIR, Semantic Healthnet Industry Advisory WP Leader, as follow-up to the industry workshop organized in January 2015 by SemanticHealthNet to capture the feedback of industry representatives about their specific semantic interoperability needs. The SemanticHealthNet project is a network of excellence and establishes good practices in the development, adoption and scaling up of semantic interoperability across Europe.

In a first step – which gives substance to this report - the Think Tank has explored for a limited number of use cases the definition of a step-wise process to more effectively progress semantic interoperability in eHealth. The process has at its centre the identification and refinement of semantic fragments, i.e. building blocks that can be shared between projects and implementations without urging complex and time-consuming choices and subscriptions to certain reference information models.

The strategies applied for achieving those results have been to work with a small, diverse, well focused, and skilled team; to privilege a practical incremental approach based on real cases, considering widely applied solutions; to focus on manageable and reusable pieces of information (fragments) to establish a foundation layer of semantic interoperability.

The robust process outlined is an iterative, continuously improved process, including the identification, selection and shaping of fragments; the documentation of related information; the scoring of their usage maturity (task not completely defined yet). This process is not involves several participants for the management of known issues and artefacts associated to the selected fragments.

In the second phase of this initiative, the team will therefore continue, using as baseline the process outlined, with the collection of evidences from existing experiences that will be used to determine potential gaps and gain more experience in the identification and selection of fragments. Hence, a set of topics identified in this first phase will be analysed more in depth and the results, together with all the further experiences gained, will be used by the team to improve, refine and specify more in detail the process, exploring how the convergence path toward “harmonized” fragments could be realized.



1 Aim and Scope The perception of very slow progresses, with few measures, on Semantic Interoperability is commonly shared, above all among health authorities and vendors, with a general consciousness about the need of tackling pragmatically this problem.

In January 2015, the SemanticHealthNet1 project organised a dedicated workshop to capture the feedback of industry representatives in order to establish their specific semantic interoperability needs, as well as to leverage their expertise towards defining a pragmatic, step-wise approach for realising the benefits of re-usable interoperability “bite-size data elements”.

In this context (i.e. the Semantic Health Network (SHN) Multi-Stakeholders Workshop) the Industry Advisory Group shared an initial idea for more effectively progressing with semantic interoperability in eHealth: break the problem in units of concern/exchange/information around which to work; draw a path or approach2 for those units; try to apply this approach, evaluate progress and bridge gaps where possible. It was agreed to leverage a number of pre-existing efforts in Europe, involving some of the people that worked on those projects.

Those ideas have been then further developed in a position paper (“Practical steps towards eHealth semantic interoperability”) that describes the reasons, the principles and the methods that should be applied for evaluating this new approach, and that could be summarized in the following point:

• Learn(from(the(past(

o Use(a(practical(approach.(o Reduce(the(complexity(of(the(problem(considering(commonly(used(“bite5size(data(

element”(o Do(not(focus(on(all(the(possible(variants(of(those(“bite5size(data(elements”,(but(on(the(

relevant(commonly(used(information(((wide(scope)(

• Put(the(lessons(in(action(towards(a(new(approach((

o Launch(a(few(months(project(creating(a(small(scale(but(fertile(“incubator”(that(can(foster(the(emergence(of(a(new(credible(and(effective(approach.((

o Pilot(the(identified(approach(for(evaluating(its(feasibility.(

This initial idea has been therefore concretized by the Industry Advisory Group facilitating the creation of a Semantic Interoperability (SIOp) Think Tank whose composition, ends and means are described in the following sections.

The aim of this project is to explore the definition of best practices for such a step-wise process to more effectively progress semantic interoperability in eHealth and summarize the proposed results in a well-articulated final report.

1 The SemanticHealthNet project is a network of excellence and establishes good practices in the development, adoption and scaling up of semantic interoperability across Europe. 2 The term methodology is not used in this context on purpose



This document is an intermediate report, whose scope is to summarize:

• the(initial(results(achieved(by(the(Semantic(Interoperability(Think(Tank(team(including(the(

lessons(learned;(

• the(principles(of(the(robust(process(for(establishing(at(least(a(starting(set(of(semantic(

fragments:(

• the(next(steps(to(be(performed(for(the(convergence(towards(increased(semantic(

interoperability.(

For achieving those results the document has been organized as follows:

1. a(short(introduction(about(the(initiative(and(the(scope(of(this(document((this(section)(2. description(of(some(of(the(main(concepts(used(in(this(document((section(2)(3. description(of(the(team(composition(and(of(the(desired(results(and(course(of(actions((section(

3)(4. outline(of(the(robust(process(to(identify,(refine(and(share(re5usable(semantic(fragments(

(section(4)(

5. Lesson(learned((section(5)(6. Brief(summary(of(the(next(steps(and(of(topics(that(need(to(be(further(analyzed((section(6)(



2 Glossary

Note: in the choice of terms, to prevent any misunderstanding about the actual content and scope, the team agreed to avoid those that exhibit a high level of ambiguity, since they have been already used with varying and/or multiple meanings in other standards/initiatives (e.g. resources; archetypes; data elements,…).

This glossary is loosely based on the structure and attributes defined for the Vocabulary specification by the Semantics of Business Vocabulary and Business Rules (SBVR) standard (http://www.omg.org/spec/SBVR/1.2/PDF).

In this context a fact is considered a “proposition that is taken as true”

Term: Fragment

Description: a small cluster of things that gives a clinical meaning to the receiver

Fact: a fragment can be reused in different contexts.

Fact: a fragment has a Data Structure

Fact: a fragment is frequently used across use cases.

Fact: a fragment belongs to the logical (or Platform Independent Model) layer of the Model Driven Architecture and may have multiple implementations.

Fact: a fragment has a name

Fact: a fragment has a defined scope – describing the use cases and/or contexts for which the fragment is intended, and those where it is explicitly inappropriate. For use cases and contexts that are not explicitly covered in the scope a local decision must be made.

Term: Data Structure

Description: Interrelationship among Data Elements that determine how data is recorded, and/or manipulated and/or stored and/or presented.

Fact: a Data Structure can be shared among different Fragments

Fact: a Data Structure has one or more Data Element

Fact: different Data Structures may be used for different use cases.

Term: Data Element

Description: Any atomic element of an information model (generic information model or template) can be considered a Data Element

Fact: a data element can be shared among different data structures

Term: Code System

Description: Managed collection of concept identifiers, usually codes, but sometimes more complex sets of rules and references. They are often described as collections of uniquely



identifiable concepts with associated representations, designations, associations, and meanings.

Fact: a given concept representation must resolve to one and only one meaning within the Code System.

Example: ICD-10, SNOMED CT, LOINC, etc.

Synonyms: terminology, vocabulary

Term: Ontology

Description: Semantic artifact formally describing properties and relations of types of entities.

Fact: Domain-independent categories, relations and axioms are typically provided by top-level ontologies, whereas the types of things specific to a domain of interest are represented by domain ontologies.

Term: Concept domain

Description: Named category of like concepts (a semantic type) that will be bound to one or more attributes in a static model whose data types are coded.

Fact: Concept domains exist to constrain the intent of the coded element while deferring the association of the element to a specific coded terminology until later in the model development process.

Fact: Concept domains are independent of any specific vocabulary or code system.

Example: Concept domains represent an abstract conceptual space such as "countries of the world", "the gender of a person used for administrative purposes", “languages of the world”, etc.

Term: Value Set

Description: Uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Fact: Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Fact: A value set has a definition, which describes a set of codes referencing a collection of unique concept identifiers

Fact: A value set can be resolved to an expansion, which is a set of concept designations defined by the concept identifier.

Fact: The collection of unique identifiers referenced by a value set is drawn from one or more code systems. Each of these identifiers is represented by a code.



3 The SIOp Think Tank initiative

3.1 Team Composition The SIOp (Semantic Interoperability) Think Tank initiative is accomplished by a small and skilled team composed by representatives solicited from

! The(Semantic(Health(Net(EU(project(! The(EXPAND(EU(project(to(bring(some(of(the(experience(gained(in(epSOS,(

! The(EHR4CR(EU(project(to(add(the(clinical(research(needs(and(creativity(! The(PARENT(EU((Joint(Action(to(provide(the(needed(public(health(information(challenges(! Industry(with(COCIR,(that(has(experience(in(semantics(and(large(complex(projects(execution(

Supported by a Facilitator and an Editor.

SIOp Think Tank Members Name Organization EU Project

Persephone Doupi THL, Finland PARENT Joint Action, EXPAND, ASSESS CT

Patrick Ruch Univ. Applied Sciences Geneva, CH

EXPAND

Charlie McCay Ramsey Systems Ltd / HL7 Semantic Health Net

Dipak Kalra EuroRec Semantic Health Net

Charles Parisot COCIR, IHE, GE Expand

Christel Daniel AP-HP, INSERM France EHR4CR

Dirk Colaert COCIR, AGFA DebugIT, SALUS

Dirk VanHyfte COCIR, Intersystems

Luc Maes COCIR, Staff

Stephan Schug Facilitator

Giorgio Cangioli Editor

3.2 Desired Results and Course of Actions

The GOAL of this initiative is “to explore the definition of a step-wise process to more effectively progress semantic interoperability in eHealth and summarize the proposed results in a well-articulated report.”

The proposed step-wise process is to structure the wide and complex field of semantics interoperability around the concept of a set of information fragments, to form a widely reusable set of interoperable semantic building blocks. This type of approach is not novel and has been applied to a variety of ehealth projects. What is proposed here is to formalize the approach, and to enable its application as part of a foundational step to develop semantic



consistency across larger contexts such as national or cross-national health information exchange.

It is out of the scope of this initiative the definition of new or harmonized models, ontologies, resources, implementable specifications for those “bite-size data elements”.

This goal needs to be achieved in a 4 months period, balancing adequately the typical project management dimensions: Scope, Quality, Time and Budget.

Figure 1 Project Management Pyramid

This goal has been therefore quantified in two main objectives:

[1] The production of an intermediate report summarizing:

! the work accomplished

! the experience gained

! the outline of an execution process for the convergence towards increased semantic interoperability

[2] The delivering of a final report that updates the intermediate report with additional findings, including a proposal of a process to continue the execution of this work and make it sustainable.

Figure 2 Goal



The following figure summarizes the temporal perspectives of those objectives.

Figure 3 Milestones

The intermediate report objective includes as sub-objectives

! the outline of an execution process for the convergence towards increased semantic interoperability

! the development of a proof of concept for a fragments dashboard. This artefact, whose final scope is to enable users to capture in a glance the “maturity level” of each analyzed fragment, is developed in this initiative for testing the outlined process.

! the development of a proof of concept for a fragments tracker. This artefact, whose final scope is to enable users to get summarized information about the identified fragments (that is where and how this fragments is used, what are the known issues and how they are going to be resolved; what is available in term of models, specifications, value sets,… for using those fragments). This artefact is developed in this initiative for testing the outlined process.

Note: Is not in the scope of this project to develop and publish completed fragments dashboard and tracker. Those artifacts have been produced, as a proof of concept, for testing the outlined process.

Figure 4 Intermediate Report Sub-Objectives

More details about those objectives will be provided in the following sections.

Figure 5 Strategies



The strategies identified for channeling the efforts towards this goal have been:

! Nurture(this(initiative(with(a(small ,(well(focused,(sk i l led(team.(This(team(shall(be(not(too(

big(to(make(people(unable(to(interact(effectively(and(focus(on(the(goal;(nor(too(small(to(

prevent(the(ability(of(generating(new(ideas.(

! Privilege(a(pract ical ( incremental (approach(based(on(real (cases(

! Reduce,(as(far(as(possible(the(complexity(of(SIOp(problem,(breaking(it(out(into(small,(

coherent,(auto(consistent(and((above(all)(manageable(pieces(of(information((called(in(the(

position(paper(“bite5size(data(element”(and(in(this(document(“fragments”).(

(Fragmentation)(

! Do(not(try(to(resolve(all(the(possible(specific(requirements(associated(to(the(usage(of(the(

identified(fragments,(but(identify(a(process(that(could(fulfill(the(Semantic(Interoperability(

needs(of(most(the(widely(applicable(use(cases,(in(a(sort(of(Pareto’s(principle.((Widely (

appl ied(solut ions)(

! Learn(from(the(existing(projects,(without(repeating(what(have(been(already(done.((

Figure 6 Tactics

To realize the objectives and implementing the strategies defined the following tactics have been identified and are going to be accomplished3:

! Realize(focused(documents(outlining(only(the(essential(elements(needed(for(drawing(the(

target(process.((focused(essentia l (documents)(

! Schedule(intensive(recurr ing(v irtual (meetings:(with(cycles(of(two(2h5calls(per(month.(

! Consolidate(the(inputs(gathered(during(the(call,(thorough(off ( l ine(contr ibutions,(

leveraging((the(material(prepared(by(the(editor(according(to(the(decisions(taken(during(the(

meetings(

! Focus(on(the(data(exchange(more(than(on(the(workflow((focus(on(the(content(s ide)( 3 The diagrams evidence only part of the existing relationships between desired results and courses of actions.



! Consider(the(Patient(Summary(and(the(ePrescription(as(typical(use(cases(for(which(the(

fragments(will(be(discussed((Identif ied(Reference(Use(Cases).(This(means(that(those(

represent(the(kind(of(non5specialized(scopes(we(should(look(for,(but(it(doesn’t(imply(that(

other(use(cases(will(not(be(considered.(

! Provide(an(“horizontal (perspective”(about(the(usage(of(fragments.(Considering(that(in(

general(the(existing(projects(provide(solutions((methodology,(models,(…)(to(the(problem(of(

the(Semantic(Interoperability(in(the(perspective(of(those(projects,(the(capability(of(providing(

an(horizontal(overview(across(all(of(those(perspectives(has(been(evaluated(as(an(added(value(

of(this(initiative.(

! Introduce(metr ics (for (fragments: (the(implementation(of(the(horizontal(view(above(

mentioned(should(consider(specific(metrics(/(dimensions(to(be(associated(with(the(selected(

fragments(in(order(to(enable(the(measure(of(how(much(each(fragment(influences(the(

different(dimensions(and(allows(to(define(specific(scores(about(the(“implementation(

maturity”.(

(

3.3 Risks The team recognized a set of potential risks for this initiative:

1) To start “another project” specifying models, with possible overlapping with other SDO/projects activities already established.

2) To alienate existing initiatives.

3) To have a low engagement of key stakeholders/targets

In considering these risks, the team clarified that it is out of scope of this initiative to develop new models, and that the idea of learning from the existing initiatives and of facilitating the reuse of the created “products” is one of the baseline of the outlined process.

However, while this is explicitly intended to be out of scope, that does implies that there is not a risk that the project will not in practice create yet another place where sets of model fragments are described, curated and promoted – and in doing so add to the complexity of the environment that architects and suppliers are working in, and increase the number of choices that industry faces.

3.4 Targets

The potential users of the results of this initiative span over a wide range of stakeholders:

1) Persons working at implementations level (country/regional), Policy, Authorities,

2) Industry designing and deploying solutions (architect, project leader, technical / clinical dimension);

3) Practicing physicians with IT-interest

4) Standardisation groups incl. of IHE.



4 Outline of an execution process As described above the approach suggested for tackling semantic interoperability relies on a few simple concepts that could be summarized as:

1) Face(the(problem(of(the(SIOp((Sematic(Interoperability)((focusing(on(reusable(semantic(self5consistent(modules,(here(called(“fragments”,(having(well(defined(associated(data(structure,(data(elements(and(vocabulary(bindings.(

2) Allow(users(to(get(clearly(understandable,(simple(and(easily(browseable(information(about(those(fragments(in(term(of(:(a) use(cases,(including(usage(boundaries((in5out(of(scope),(and(context(of(use(

b) usable(artefacts((models,(specifications,(value(sets,…)((c) known(issues(and(status(/(process(of(resolution(d) level(of(maturity((usability)(

(

For achieving this approach, two steps have been identified:

1. A(step(1(in(which(–(following(a(bottom(up(approach(–(inputs(fragments,(including(their(

implementations,(and(related(experiences(will(be(collected.(Those(inputs(will(be(used(for(identify ing(and(select ing(the(fragments.((

2. A(step(2((not(analysed(in(this(document)(where(a(process(for(converging(towards(an(

harmonized(fragment(will(be(drawn,(determining(what(are(the(barriers(of(defining(the(converged(fragments.(

Figure 7 Approach Overview

ù (

In Figure 8 is outlined a possible process – subject of the activity of this Think Tank – for supporting, maintaining and self-sustaining this approach. It is an iterative, continuously improving process, whose participants are :

• The(Think(Tank(Core(team:(this(team(responsible(for(the(outline(of(this(process(and(its(

evaluation.((



• (Fragments) (Art i fact (Maintainer:(the(organization(responsible(for(the(maintenance(of(an(

input(fragment(related(artefact((a(implementable(specification,(a(conceptual(model,(a(value(

set,(and(so(on…..).(One(or(more(maintainers(may(exist(for(each(artefact;(a(maintainer(can(manage(artefact(related(to(one(or(more(fragments.(For(example,(the(EXPAND(Semantic(and(Specification(Maintenance(Shops(for(the(epSOS(CDA(specification.(

• (Fragments) ( Issue(Maintainer:(the(organization(responsible(for(resolving(a(specific(

fragment(issue.(One(or(more(maintainers(may(exist(for(each(fragment;(a(maintainer(can(manage(issues(related(to(one(or(more(fragments.(This(role(may(be((or(may(be(not)(played(by(the(same(organization(that(acts(as(Artifact(Maintainer.(

• Stakeholders:(any(person(or(organization(that(may(be(interested(in(a(specific(fragment.(

Note: in this intermediate report the role of who is driving the outlined process is labeled “Think Tank Core Team” because this is who will try to apply the process. But this is just a sort of placeholder waiting for a better identification of that role.

Note: this process doesn’t address in this phase how different fragments and associated artifacts should or may be managed and harmonized.



Figure 8 Process Overview

The process starts with the identification and the organization of the fragments (Figure 9 Manage Fragments). This sub-process may be realized through different tasks: the core team identifies possible fragments candidates selecting them basing on common usage and consistency propriety (scope, data structure, known issues,..) (Identify Candidate Fragments). Those candidates are therefore analysed for verifying the need of fragment merging, splitting,…; if needed they are therefore reorganized and prioritized.

How it has been applied

Starting from known use cases, the team identified an initial set of potential fragment candidates: including - for example - diagnosis, disease, condition and autonomy. After a first analysis the team evaluated that even if conceptually different those fragments share the same data structure and (except for the autonomy/invalidity) may share the same vocabulary binding. Basing therefore on this consideration it was agreed to consider diagnosis/disease/condition as a single fragment, considering “autonomy” as a separate fragment, in order to be able to pointing out the specific vocabulary issues that have been experienced for this fragment.



Therefore five fragments derived from the Patient Summary and ePrescription use cases were selected trying to cover different characteristics: e.g. fragment with a complex structure and with known critical issues (prescribed medication); quite simple data structure without very critical issues (diagnosis); fragment with non-defined common value set (autonomy); and so on.

Basing on this principle the selected fragments for the purpose of the Think-Tank team process definition and evaluation, have been:

1. Prescribed+Medication+(Product)+2. Diagnosis+/+Disease+/+Condition+3. Autonomy+/+Invalidity+4. Surgical+Procedure+5. Vital+Signs+

Note:

Extending the analysis of the fragments with additional inputs coming from the EHR4CR and the SALUS projects different needs in term of level of abstraction of fragments have been identified: Medical Procedure versus Surgical Procedure or “generic” Medication data instead of more specific Prescribed Medication. In this phase no changes have been applied in the selected fragments, and it has been decided not to introduce at this level inheritance mechanisms for fragments, however during the following iterations of the process the team might identify the need of changing the perspective for those fragments (e.g. considering a generic medication instead of prescribed medications).

Note:

Evaluating the outlined process with the prescribed medication fragment, the need of a clear specification of the “boundary” of the identified fragments has been experienced. In particular different perceptions about the shaping of this fragment came out: limited to the product description or extended to the whole prescribed item. Balancing the different pro and contra of the two choices the team agreed not to limit this fragment to the prescribed product.

Note:

As for the fragments, the way use cases are identified is a critical point in the global process, fragments and use cases being inter-related. Use case should not be too big (e.g. “secondary use” is for example a too wide-scoped use case), neither too narrow.

Note:

In the context of the discussion about the shaping of fragments two approaches were discussed : (1) collecting all point of care views for verifying if enough data elements have been combined in the fragments; (2) shape the fragment according to the needs of the care delivering point (i.e. where the fragment is born); then analyze if those fragments have been created in such a way that could address the needs of “secondary use” use cases . The second approach has been selected at this time.



Note:

Another point discussed has been the context of use of fragments that could be split into (at least) two different concepts (1) how a fragment is related to other fragments : in this sense fragments should be shaped in such a way to be as far as possible self-consistent (few external relationships needed). (2) The context of use of each fragment in the real word. The associated use cases and usage boundary are critical information for the understanding and reuse of fragments.

Figure 9 Manage Fragments

For each selected fragment the core team may perform the following actions (Figure 10 Analyse and Document Fragments Usage):

1. Collect(information(about(the(use(cases(in(which(this(fragment(is(used,(including(the(usage(boundary((in5out(of(scope)(and(if(they(refer(to(a(primary(or(a(secondary(usage.(

2. Identify,(analyse(and(classify(the(artefacts (that(document(this(fragment.(Different(types(of(artefacts(can(be(associated(to(a(fragment:(may(be(referred(to(conceptual(or(logical(models((with(or(without(vocabulary(constrains);(to(implementable(specifications((e.g.(a(CDA(

template);(to(value(set.(A(fragment(is(usually(defined(by(a(set(of(artefacts.(3. Identify,(analyse(and(classify(the(issues(that(are(known(for(this(fragment.(In(this(phase(the(

following(issue(types(has(been(identified:(Missing(Value(Set(s);(Unsatisfactory(Value(Set(s);(

Not(Complete(Data(Structure;(Unsatisfactory(Data(Structure;(Mapping(Issues;(Not(Availability(of(Data;(Different(Business(Cases.(

4. For(each(identified(issue(identify,(analyse(and(document(how(and(who(is(managing(this(issue,(

and(what(are(the(upcoming(solut ions(that(are(in(progress.(In(any(case,(identify(clearly(what(is(expected(to(be(solved(((

This information is recorded in the Fragment Tracker data store.



Figure 10 Analyse and Document Fragments Usage

In case the team is aware about any update concerning the published artifacts, or known issue, it updates the Fragment Tracker data store.


For each selected fragments an excel sheet for collecting project related data has been created.

For each fragment and for each project (when applicable) the range of use cases for which fragment is intended [In Scope / Out of Scope] is recorded together with references to deliverables in which conceptual and implementation specification are defined, with some explanation (see the attached excel file for example of details);

Then the main issues associated to each fragment and the short, medium and long term solution in progress are described (who and what).

One creates an “overview” sheet in which most of those information are summarized, reporting as distinct row the combination of Project, Fragment, Use case name, UC description and Issues For facilitating the search of information by the user. See example

Project( Fragment( Use(case(name( UC(description( Issues(

epSOS(

Prescribed(Medication((Product)( Patient(Summary(

epSOS(D3.1(In(scope:("medicinal(products(intended(for(human(use,(elaborated(from(an(industrial(process,(prescribed(for(outGpatients((not(to(be(dispensed(in(the(Hospital),(and(dispensed(in(Community(Pharmacies.("(Out(of(scope:("•(Sealed(prescriptions((or(information)[The(decision(of(a(patient(to(hide(information((e.g.(prescriptions(or(diagnosis(related(to(HIV)(is(part(of(each(country’s(process.(This(document(will(not(cover(or(solve(the(scenario(where(the(patient(goes(to(country(B(and(decides(to(authorise(the(HCP(in(that(country(to(consult(the(hidden(information.(](;(•(Pharmaceutical(care:(It(cannot(be(assured(that(for(the(epSOS(LSP(all(the(information(needed(for(correct(or(proper(Pharmaceutical(care(will(be(available.(It(is(assumed(

epSOS:('the(absence(of(a(EU(common(drugs(nomenclature(lead(to(the(choice(of(providing(a(set(of(attributes(describing(the(products.(Main(Issues:(G(country(are(not(often(able(to(provide(the(information(as(requested((due(to(the(lack(of(mapping(with(local(codes;(or(not(availability(of(structured(and(coded(information(G(ATC(is(not(suitable(for(describing(active(ingredients(G((scope:(registered(packaged(products(excluding(narcotics,("special"(products(,.(



that(medication(surveillance;(•(Narcotics:(•(Medicinal(products(which(are(prepared(in(a(pharmacy(in(accordance(with(a(medical(prescription(for(an(individual(patient(."(

When all those data have been collected a usage maturity scoring could be assigned to each fragment and made available for users in the fragment dashboard.

Note: This part of the process has not yet been investigated


A mock up sheet has been prepared. No rules for scoring assignment have been however specified yet.



5 Lessons Learned on basic features/ principles of robust process to identify, refine and share re-usable semantic fragments

This section summarizes the main lessons learnt in this phase:

1. For(the(outlined(process,(the(identification(of(use(cases(and(fragments(is(a(cr it ical (step. (

2. The(identification(of(fragments(shall(be(an(iterat ive(and(adaptive(process,(strictly(based(on(well(identified(use(cases.(The(link(with(use(cases(is(important(to(reduce(the(need(of(moving(the(discussion(about(fragments(to(the(ontology(level.(

3. To(be(useful,(fragments(should(be(“neutral”(and(reusable:(therefore(fragments(should(be(as(much(as(possible(self5consistent,((

4. Use(cases(–(as(well(5(should(be(carefully(selected(in(order(to(be(not(too(generic(neither(too(

narrowly(scoped.(Also(in(this(case(an(iterat ive(and(adaptive(process(should(be(established(for(a(continuous(refinement(of(use(cases.(

5. Fragments(should(be(shaped(according(to(the(needs(of(the(care(delivering(point((i.e.(where(

the(fragment(is(born);(then(it(needs(to(be(verified(if(those(fragments(have(been(created(in(such(a(way(that(could(address(the(needs(of(“secondary(use”(use(cases.(



6 Next Steps Using as baseline the process outlined, the team will proceed with the collection of evidences (input fragments) from existing experiences. Those evidences will be used to verify where gaps might be present in the outlined identification and selection of fragments process (step 1 of Figure 7).

Hence, the ‘open’ topics already identified (and hereafter summarized) will be analysed more in depth and these results, together further experiences gained, will be used by the team to improve, refine and specify more in detail the process, exploring how the convergence path toward “harmonized” fragments could be realized (step 2 of Figure 7).

6.1 Topics to be further analysed

6.1.1 Process representation and composition

Fragment harmonization The exploration of the convergence path toward “harmonized” fragments should consider a series of topics to be analysed in term of process including:

1) How(models(are(supposed(to(be(compared((e.g.(logical(vs(implementable(models)(when(they(refer(to(different(layers((conceptual,(logical,(implementable)(and(when(different(formalisms(are(used.(

2) If(will(this(team((or(in(future(the(actor(driving(the(process)(is(responsible(for(a(first(harmonization(3) In(general(who(should(take(care(of(this(issue(

4) What(need(to(be(done(if(non(coherent(artifacts((e.g.(conceptual(model(non(coherent(with(the(implemented(specs;(different(implementable(specifications;(different(vocabulary(bindings;()(are(collected(for(a(fragment.(

5) Which(kind(of(harmonization(actions(need(to(be(taken(and(by(who((

Decomposition of the process The current outlined process is designed as a single process composed by sub-processes.

There is a suggestion to explicitly split the current step 1 process into two distinct processes:

1) Fragment(management((ref(:(http://wiki.hl7.org/index.php?title=Templates_Registry_Pilot)(

2) Fragment(evaluation(and(scoring((ref(http://www.cdisc.org/cdisc5share).(

Identification of the actor driving the process In the current version the Think Tank core team is the actor that drives the process (see above the reasons of this choice).

The type of “entity and participants” playing this role needs to be further refined and identified.



Escalation The process needs to describe some escalation mechanisms (e.g. what happens a “well-known issue” is not assigned to any artifact issue manager).

Scoring assignment (Dashboard) The coring process for the fragments dashboard: e.g. who is assigning the score, needs to be analysed. Is it a subjective evaluation of the core team, or if it is an algorithm based on structured scores; which parameters should be considered (e.g. the impact of existing issues; actual availability of implementable specification and value sets).

Artefacts and issues maintainers There may be more than one Artefact and Issue Maintainer over time. There might be an interest in capturing some ‘evolutionary’ perspective of the process over time.

Moreover, we will need to considered if the activities of the Artefact and the Issue Maintenance are truly separate from each other.

6.1.2 Tool Box for the robust process to identify, refine and share re-usable semantic fragments.

Fragments Metadata To facilitate the identification and the reuse of fragments, each fragment should be correctly described and identified through appropriate metadata.

A set of candidate metadata derived from the CodeSystemVersion class of the HL7 CTS2 standard has been proposed (see hereafter) as an example

i. An(identifier(ii. A(version(identifier((versionId)(that(uniquely(identifies(each(version(of(a(fragment(

iii. The(start(date((effectiveDate)(when(the(version(is(deemed(to(be(valid(for(use.((iv. A(set(of(dates((releaseDates)(that(represent(the(date(when(the(version(of(the(fragment(

became(available(within(a(particular(domain((could(be(universal,(realm(specific(or(for(an(

organization)(v. The(formats((releaseFormats)(in(which(the(version(of(the(fragment(is(available(in.(vi. The(official(location((releaseLocation)(at(which(the(version(of(the(fragment(is(made(available(

vii. The(different(languages((supportedLanguages)(supported(by(the(fragment(in(this(version(viii. A(status((status)(to(identify(the(state(of(the(fragment((Version((mainly(for(curation)(

ix. A(status(date((statusDate)(to(identify(the(date(the(status(was(set(to(its(current(value((for(curation)(

x. A(description((description)(that(describes(the(fragment(Version.(

xi. Provenance(information((provenanceDetails)(relating(to(the(release((version)(of(the(fragment(xii. A(name((fullName)(that(is(the(official(name(of(the(fragment(as(assigned(by(the(provider(at(the(

time(of(the(version(being(issued.(

xiii. A(name((localName)(to(which(the(fragment(normally(referred(to(for(the(life(of(this(version.(



xiv. Copyright(information((copyright)(pertaining(to(the(release((version)(of(the(fragment(

xv. An(attribute((source)(that(identifies(the(authority(or(source(of(the(fragment(in(this(version.(i.e.(IHTSDO(

As well as a candidate lifecycle for the fragments

This topic should be further analysed including other possible options like the standard metadata identified for template registries (see e.g. § 2.9. Template Key Metadata HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 October 2014 ).

Fragment formalization According to the agreed definition, a fragment is represented at the logical layer (e.g. data type, optionality and binding with vocabulary specified) of a Model Driven Architecture and may have multiple implementations.

Even if it is out of scope of this initiative the specification of information models, the way (language, data types, ..) a fragment may, should or shall be represented (e.g. AML, ADL, other more or less formal solutions) needs to be analysed and agreed.

In this discussion, one should carefully consider the available information from real cases (e.g. in epSOS there are no formal fragments defined, they may however be derived from the agreed data sets [conceptual level] and from the implementation [CDA templates] ) and the impact of the choices done (e.g. CDA uses HL7 data type Release 1 and not the Release 2 (ISO21090), even if data type R2 are based on data type R1).

Reference information model underpinning the fragment definitions An interesting feature of this approach is that it doesn’t assume that all fragments are derived from a single reference model. However fragment definitions are sustained by reference information models and this could be a possible source of confusion / error. It should be analysed and explained how those risks could be minimised.

semantic!interoperability!for!health!network! - i~hd 288408 d6_1... · 2015-08-11 ·...

Documents