Keywords

1 Introduction

Our industrialised societies are heavily dependent on standards. That we can safely assume that electric plugs of a certain kind, independently of their manufacturer, fit into certain sockets of certain types and not into sockets of other types is just one example how manufacturing is guided by standards. The benefit is obvious: complex technical artefacts can be assembled out of smaller components. Conformance to standards facilitates their exchange and substitutability, creates independence from manufacturers, eases competition and generates interoperability across borders. Standardisation of commodities and consumer goods makes them more easy to compare, to categorise and, consequently, to trade. In addition, compliance to safety standards will increase trust in the safe operation of components under predefined conditions. The authors of this chapter argue that standardisation is equally required for data in general and clinical data in particular, for which safety, exchangeability and interoperability is a superior aim, in particular with regard to the emerging field of data science.

There are many definitions of standards. Our approach is pragmatic and committed to the view that standards are information artefacts developed in community-driven consensus processes that specify uniform features, criteria, methods, processes and practices for a certain domain. Besides “de jure” standards, i.e. those developed by bodies endorsed by national or international legislation, we use “standard” also in a broader sense for specifications that adopt a “de facto” or “industry” standard status, due to acceptance by a large public or by market forces. Where real standards do not exist quasi-standards may fill the gap. They are often defined as compatibility with a reference product. Some of us may remember that after IBM launched its Personal Computer in 1981, other manufacturers sold their PCs as “IBM compatible”. It meant that they closely followed the technical features of the IBM PC, and users could assume that software devised for the “original” one would also function on the “compatible” machines. In the following we will use the term “standard” in the most general way.

This chapter will shed light on clinical data standards , i.e. standards that govern the way how information in healthcare is encoded by machine-processable symbolic representations. Such data standards address different aspects, from (i) single information artefacts, which may be huge (e.g. the full set of SNOMED Clinical Terms) or tiny ones (a single EN ISO-13606 or openEHR archetype), over (ii) processes for creating artefacts that connect into a larger whole, to (iii) shells or tools that support the creation of (i) by (ii) by numerous distributed parties.

1.1 Data and Reality

Most people share a tacit understanding of the meaning of the term “data”. Nevertheless it is helpful to elucidate what data are and what they denote. We here understand data as abstract entities in information systems, which normally denote (classes of) real objects. The notion of denotation – derived from basic ideas of semiotics [1] – is crucial for data communication and interoperability. Assuming a certain Universal Resource Identifier, URI p denotes a particular person P. First, this implies that URI p – the data item – is distinct from P – the referent. If an agent X uses URI p for passing information to agent Y, the latter one is supposed to refer to the same person P, as long as enough information is attached to this URI, which is sufficient to clearly identify that person. Knowledge is needed to further process that data: which other properties can this person P possess in reality and which inferences can we make from the data we can access on this person. Hence, knowledge is linked to a shared standard representation of reality, which enables a common interpretation of the data that describe the objects in a given domain. In natural science and engineering (including healthcare and biomedical research) such a consensus on (physical) reality is mostly uncontroversial.

1.2 Desiderata for Clinical Data Standards

Clinical data denote patients, their complaints, signs, diseases, operations, drugs, lab values, etc. Recorded in information systems of different genres (electronic health records, disease registries, clinical trial documentations, mortality databases) they are heterogeneous, context-dependent, often incomplete and sometimes incorrect [2]. Clinical data are shaped according to the specific needs for which they are collected, such as reporting, communicating, and billing. Wherever statistical analyses or case-based reimbursement are needed, data has to be in a structured form, with a trade-off regarding scope and granularity. Where communication between health professionals is paramount, poorly structured narratives tend to prevail over structured and coded data, because text is richer in detail and faster to create. As text just has to be understandable by humans, the use of a shared vocabulary and character set is sufficient, and tolerance regarding grammar and spelling variations and errors do not constitute major issues. Free text is semantically interoperable only if both parties use the words in exactly the same meaning and the same context. For instance, “Physical examination normal” allows the conclusion that all major neurological reflexes were examined and found normal only if documented by a neurologist, but not when it is found in a GP’s record. Full interoperability of clinical narratives would require that a specialist uses different languages, i.e. to the direct peers within the speciality, to other physicians, to other healthcare workers and finally to patients and their family. The transformation of textual sources into structured output is a main driver for human language technologies [3]. The application of such techniques, alone, does not, however, guarantee interoperability and standardisation. Further data processing, e.g. so-called secondary use scenarios for clinical data like computerised decision support, retrospective and predictive data analysis, tends to be hampered by local data dictionaries and missing contextual descriptions. This problem has for long been known of scholarly data, for which the deficit of data reusability has recently been addressed by the FAIR guiding principles for scientific data management [4], with FAIR being an acronym for “findability”, “accessibility”, “interoperability” and “reusability”. Regardless whether primary or secondary use scenarios for clinical data are aimed at, we advocate the FAIR principles for clinical data , too, which imply that clinical data must follow shared standards. Such standards should describe:

  • Data provenance, i.e. their originators, creation times and related processes;

  • Information templates in which data are embedded;

  • Vocabularies / terminologies / ontologies used to attach meaning to data;

  • The semantic descriptors or representational units (codes, labels) in these vocabularies;

  • Formal or textual definitions of these representational units;

  • The formal languages used for the above.

Up until now, the adoption of data standards for clinical data has been low. Clearing this backlog will be crucial for unleashing the potential of clinical data for diverse scenarios of (re-) use. This requires major efforts by all stakeholders involved, creators and maintainers of standards, as well as their users.

1.3 Aspects of Terminology, Syntax, Semantics and Pragmatics

The following concepts, borrowed from human language studies, also seem useful to describe different aspects of clinical data and, in consequence, different types of standards to address them. It requires that we see the application of data standards as governed by similar principles as are natural or synthetic languages:

  • Reference terminology : A set of symbols, both standardised terms from natural language and abstract symbols from coding systems. Symbols should be unique and follow Web standards (IRIs – International Resource Identifiers, URIs). Standardised terms should be human–understandable, unique, self–explaining and non–ambiguous labels. Ideally, terminology items carry formal or textual definitions. Example: The SNOMED CT fully specified name “Primary malignant neoplasm of lung (disorder)”, the semantically equivalent identifier SCTID:93880001, the URI http://snomed.info/id/93880001 and an ontological description that states that it equals a lung structure with a primary neoplasm morphology. However, it is rather unlikely to find “primary malignant neoplasm of lung” in a medical text. Physicians prefer shorter terms like “lung cancer”, “lung carcinoma”, “Bronchialkarzinom”, “Cáncer de pulmón” etc. This is the reason that, for practical considerations, reference vocabularies need to be linked to interface terminologies, i.e. collections of language expressions as used in clinical and scientific practice [5]. Interface terminologies describe dynamic language in use and are therefore not standards. Multilingualism, lexical ambiguity, change of meaning and synonymy have to be accounted for.

  • Syntax : the set of rules, principles, and processes that govern the structure of sentences in a given language [6]. In a data standard, syntactic rules determine how items in a vocabulary can be combined. As an example, a standard for anatomical entities and clinical findings has to provide syntactic rules how to combine laterality terms (right / left / bilateral) with anatomical terms. A standard for lab results has to define how analytes, values and units are combined. Advanced, ontology-based terminology standards like SNOMED CT come with a set of rules for term composition [7].

  • Semantics : the relation between symbols and what they stand for in reality (denotation) [8]. Here we have to take care not to mix up different artefacts, especially if they are similarly labelled. E.g., an information model standard on arterial blood pressure [9] standardises a data structure to be filled when arterial blood pressure is recorded. An ontology entry on arterial blood pressure (e.g. Arterial blood pressure (observable entity)), provides, instead, a definition of what a blood pressure is, viz. a physical measure in an arterial structure of the type pressure. The need of precisely distinguishing informational entities from domain entities is increasingly addressed by so-called (domain) upper-level ontologies like BFO [10], DOLCE [11], UFO [12] or BTL2 [13].

  • Pragmatics : The situational context in which symbols are used. A typical case is the embedding of a disease mention in a composed expression. “Suspected asthma” has a completely different meaning compared to “asthma prevention”, “check for asthma” or “severe asthma”. Only in the latter case it can be safely assumed that there is an instance of asthma; and this information can be safely used, e.g. for computerised decision support for asthma patients.

1.4 Representational Artefacts for Standardising Clinical Data

These categories are related to the following genres of clinical data standards . Probably the most relevant family of data standards are clinical terminology systems [14], which exhibit a broad range of characteristics. Their sheer number and content size is best seen when browsing meta-repositories like the Unified Medical Language System (UMLS) Metathesaurus [15, 16] and BioPortal [17]. We can roughly distinguish between (i) thesauri , which relate pre-existing terms using close-to-language semantic relations, (ii) aggregation terminologies or classifications, which use rules to pigeon-hole individual entities into non-overlapping classes [18], and (iii) ontologies , which categorize objects and describe their relations by logic-based axioms. Prominent examples are the Medical Subject Headings (MeSH) [19] for thesauri, ICD-10 [20] for aggregation terminologies, and SNOMED CT [21] or the Open Biomedical Ontologies (OBO) Foundry [22] for ontologies.

Roughly, thesauri provide the terminology and some simple semantic relations between terminology items like synonymy, whereas ontologies aim at giving precise mathematical formulations of the properties and relations of entities [23], i.e. they provide formal semantics together with syntactic rules for composition.

However, the use of a code from a terminology standard is not sufficient, as long as pragmatic or contextual aspects are missing. The asthma example in the previous section demonstrates that, like words in natural language need to be embedded in pieces of text, codes from terminology standards need to be embedded into information models in order to complete the picture. Unfortunately, many data sources lack exactly this. The default reading, viz. that a code in a clinical data set represents an existing instance at the time of creation of this dataset is often not sufficient. Take “fever” as simple example: Using just the SNOMED CT concept Fever (finding) leaves open whether the fever was reported by the patient or measured by a health professional. In addition, it does not specify the process of measurement.

The provision of such contextual and provenance information is the domain of (clinical) information models. Several standards for clinical models and their specifications have been proposed, in order to prevent data silos which, even if they are well structured, are buried in proprietary and non-interoperable formats. However, the adoption of such standards (e.g. detailed clinical models (DCMs [24], ISO/TS 13972:2015)) by manufacturers and the embedding of standardised terminologies within them has been low until now.

The difference between ontologies and information models has been phrased by Alan Rector as models of meaning vs. models of use [25]. Whereas ontologies express and define what is universally true for all members of a class (or, in other words the instances of a concept), clinical models express all kinds of contextual statements about the individuals who are the primary referents of the clinical information. The proper delineation between terminology / ontology standards and information model standards is known as the boundary problem. Whereas, in theory, this difference has been equated to the contrast between ontology and epistemology [26], the overlap between standards of either kind poses major challenges to prevent so-called iso-semantic models, which tend to arise e.g. when using terminologies and information models (e.g. SNOMED CT and HL7) together [27].

Table 3.1 gives an overview of the most important health data standards.

Table 3.1 Important medical data standards
Full size table

1.5 Quality and Usability of Standards

Standards for clinical data are better the more they support semantic interoperability . Data items are semantically interoperable [28] if the meaning intended by the creator is fully understood by the receiver of the data. Assuming two data items that describe age groups: D 1 consists of the English word “adolescent”, D 2 consists of the attribute – value pair: age in years: [14.0; 17.999]. As long as there is no agreement to which age interval D 1 maps to (according to different sources there are different intervals), misunderstandings may arise regarding of whether D 1 and D 2 are equivalent.

This case is very typical for human communication with natural language as the main vehicle of communication. Only if the creator and the receiver share the same vocabulary with the same underlying meaning of terms and within the same contexts, misunderstandings like the abovementioned can be avoided. The unification of meaning in healthcare is the main rationale for clinical data standards. In our example above, this should mean that there is a standard that attaches a definition to the word “adolescent” such as “human age 14 and more but less than age 18”. However, there is the problem that words do not belong to standards organisations, and that with the same right a second standard may define it otherwise. And finally, many language users may use the word “adolescent” in many other ways. This is why, in some clinical models, users are always obliged to provide not only the value (e.g. “adolescent”), but also a reference to the standard that attaches a specific definition to that value. Other clinical models prescribe the use of specific terminologies as part of their definition, which overcomes the burden of referencing that particular standard in each instance of that clinical model. But even in this case, standards often do not do their job if the meaning of values are not specified. For example, SNOMED CT’s transition from a nomenclature to an ontological standard is not yet completed, so that the concept Adolescent (person) with the SCTID 133937008 lacks both formal and textual definitions, which makes it insufficient for a standard because its interpretation by the users is only guided by their individual understanding of the term “adolescent”, which differs between languages and jurisdictions.

2 Implementation of Standards

Standards will only be implemented if they serve an agreed and observable purpose. Such a purpose can be derived from different sources, such as commercial benefits in the marketplace, economic benefits within an organization, or societal benefits as laid down in laws and regulations. For healthcare data the benefits of implementing standards is not always obvious to the individual user recording the data, which makes it hard to establish a common purpose.

In healthcare, implementation of data standards will take place with one (or a combination) of three very distinct purposes in mind:

  1. 1.

    To improve the outcome of the diagnostic and treatment process of the individual patient involving (a team of) healthcare professionals, e.g.: Computer-based clinical guidance based on patient characteristics has prompted the standardised recording of several parameters in breast cancer diagnostics to support the creation of optimal personal treatment plans.

  2. 2.

    To serve the purpose of the local/national health system (including reimbursement, quality reporting, public health, health technology assessment, clinical research, etc.), e.g.: Monitoring the quality of care provided to diabetes patients has led to structured recording of key process indicators, as well as proximal and distal outcomes.

  3. 3.

    To create an opportunity for enhanced commercial interest in investing in solutions needed by patients and/or professionals in health management and the delivery of healthcare services, e.g.: The diversity of equipment in a typical radiology department has led to the early and almost full implementation of DICOM standards for digital imaging, so that multiple vendors have access to the market for medical imaging modalities.

In practice, implementation of health data standards often requires changes to be made at various levels of the socio-technical system, consisting of people, processes and technology. Software (and sometimes hardware) needs to be developed in order to handle the recording, processing and exchange of standardised data. Developers need to demonstrate that their implementation conforms with the specification, which can range from a simple conformity statement in which conformance is claimed to specific (parts of) standards, up to a full-blown conformance audit. An intermediate form has been developed by IHE in so-called “Connectathons ” [29], face-to-face events in which the ability to connect a technology with components from other developers and vendors is demonstrated, using predefined scenarios and test data, assessed by independent monitors.

Processes may need to be changed because of a different workflow around the now structured recording, use and exchange of clinical data. E.g., in cases where discharge letters used to be produced by dictation and transcription and signed off days after the patient left the hospital, direct capture of findings will produce a structured discharge summary that can be signed off at discharge. This requires people to be educated both in the use of the system and in the purpose of the new requirements for structured data recording and the possibilities this brings to improving their own clinical performance.

Practical use of data standards often gives rise to questions, comments and suggestions and/or immediate needs for improvement. The dynamics can vary greatly, depending on the type of standard being implemented. The typical administrative details of a patient are not that much in flux, whereas the genetic markers for personalized medicine seem to change on a daily basis.

2.1 Tools and Standards for Standards

Interoperability tools play a critical role in this context as they hold promise of optimizing the entire interoperability standards lifecycle as introduced in the eHealth Interop report [30]:

  • Identification of a use case or set of requirements

  • Selection of supporting interoperability standards, with the selection of options

  • Implementation, conformance testing, certification

  • Deployment in projects, which closes the feedback loop from the real world.

In support of the standards development life-cycle (cf. Fig. 3.1), tools and data need to be shared across standards organizations and implementers. It is still common that standards bring their own tools, which is especially visible with browsing tools for terminologies where each terminology comes with its own browser. When standards sets and tooling provide software components for interoperability, an open source licensing model along with data is advised. Moreover, monitoring of the usage of standards sets in terms of implementation and adoption can be incorporated in the tooling to ensure quality and maturity of standards. In support of innovation, tools for standards require stakeholder involvement in continuous collaborative development, deployment, evaluation, and refinement of interoperability specifications. The current processes, publishing formats, and organisation of standardisation need to be revisited with a view to embracing open innovation, practice-driven improvement, and seamless integration with the tools employed in the development and deployment of eHealth solutions and services (Fig. 3.1).

Fig. 3.1
figure 1

The Health Informatics Standards Life Cycle

Full size image

Shared tools must be based on shared standards for standards: E.g. ISO/TC 37 defines principles, methods and applications relating to terminology, language and content resources. W3C standards specify languages for thesauri (SKOS) [31], ontologies (OWL) [32], based on other W3C standards like RDF and XML. Many clinical data standards have not yet adopted these standards, or are on the way to embrace at least fundamental concepts like URIs as mechanisms to create world-wide unique identifiers. Proprietary formats prevail, e.g. the SNOMED CT tabular format, despite increasing efforts to comply with the ontology standard OWL.

2.2 The eHealth Standards Roadmap

The eStandards initiative (2015–2017), was funded by the European Commission to develop a roadmap fostering the development and adoption of eHealth standards and specifications. Stakeholders in Europe and beyond joined forces to build consensus on how to advance interoperability across health-related data standards in order to accelerate knowledge sharing and to promote wide and rapid adoption of standards and profiles. Driven by the vision of a global eHealth ecosystem, where navigation tools lead to safer and more informed healthcare and interoperability assets fuel creativity, entrepreneurship, and innovation, a new generation of ‘live’ standards, called eStandards was proposed. eStandards aim to drive large-scale eHealth deployment and to support the digital transformation of health and care delivery.

In an evidence-based roadmap, the eStandards initiative elaborated clinical use cases for different paradigms and embedded a quality management system for interoperability testing and certification of eHealth systems [33].

Supported by a large community of stakeholders, the eStandards project team first collected evidence and provided guidance on the coexistence of competing or overlapping standards in large-scale eHealth deployments. Using this information, it articulated barriers and challenges for advancing implementation of interoperable health systems [34] and addressed the incorporation of clinical content in profiles [35]. This work fed into the eStandards roadmap aiming to bridge standards development with standards deployment, monitoring and improvement [36]. The proposed methodology targets the sustainable adoption and evolution of eStandards, embraces trust and flow as the basis of well-functioning health systems, and adopts an eStandards compass to respect the different perspectives of stakeholders. In addition, it introduces a model of co-creation, governance, and alignment in the design of eHealth systems, building upon a repository of standardised artefacts for refinement and reuse.

Trust is a prerequisite for all parties involved in a dynamic flow of data for general and personal health information, to be used safely at the point of care and throughout health systems. The eStandards compass reinforces that respect for the differing perspectives of the stakeholders that contribute to such trusted flow of data is a critical success factor. Furthermore, dynamic flow of data is enabled by a reusable set of standardised eHealth artefacts; otherwise data will not flow between eHealth solutions and the people and organisations that use them, at least not at a reasonable cost. Finally, stakeholders co-create, govern and align their solutions along the eStandards life cycle. The next sections describe these four core concepts in more detail.

2.2.1 Trust and Flow: The Basis of Well-Functioning Health Systems

The flow of trusted data is the basis of well-functioning health systems, driving healthcare delivery based on relevant information and knowledge at the point of need. The role of standards is here seen as core to achieving those dual needs.

Trust and flow are grounded in the acceptance of the following key changes future healthcare systems have to embrace:

  • Increasing need, expectation, and cost of healthcare resulting from ageing populations, increased medical competence, and high investment in new drugs and technologies;

  • Change in doctor-patient relationship, in which patients play a much more active role in their care, which requires better access to information about their health and the preferred options for care and treatment;

  • Increased demand for home-based and mobile care available ‘just in time’;

  • A pressing need to extend the capacity of the healthcare workforce as the numbers of those remaining in workforce or indeed entering the healthcare workforce reduce.

The role of eHealth in addressing these demands with judicious use of technology can be a core component of a health services change business case, as it can provide for better use of human resources, support greater patient compliance, reduce bed demand and prevent acute episodes. However, for such eHealth solutions to be more than local pilots and small home-grown solutions, a trusted flow of data is required so that services can interoperate, be scaled-up and remain sustainable within a healthcare system. This way, not only developers are able to bring solutions to the healthcare market that meet the needs of patients and the healthcare workforce, but also comply with regulations and good practice guidelines so as to fit into the governance structures of health systems.

2.2.2 eStandards Compass to Respect Different Perspectives of Stakeholders

If the development and full adoption of eHealth tools and solutions in healthcare delivery in Europe is described as a journey, it requires a map – hence the Roadmap. In this journey, the eStandards compass helps Standards Developing Organizations and their constituencies of eHealth stakeholders to actively consider the differing perspectives of the key players involved in production, regulation and use of standards. Thus, standards developers and users may orient themselves to the unique but interrelated perspectives of the health system, the workforce, the citizens, and the market for digital health solutions.

By serving and balancing the needs of the different perspectives, organisations that maintain standards engage directly or indirectly with a much richer set of activities forming productive relations with a broad set of stakeholders, as it plots the course of the standard’s life cycle. The compass is also integral to the roadmapping process, which helps organizations better understand the needs of the people who will ultimately use the standard. Keeping the compass up-to-date, calibrated to global trends and local needs, standards creators and end users must be supported to engage together with the four perspectives of the compass and the associated dynamics. Therefore the CGA model of co-creation, explained below, is important not only in standards development, but also in the constant evaluation of the tools (including the compass) used in standards lifecycle of development, testing, deployment and evaluation.

2.2.3 eStandards Roadmap Components: Reusing eHealth Artefacts

Reusable standards artefacts address how to meet the demands of the Refined eHealth European Interoperability Framework [37]. An overview of the state-of-the-art and development needs in specific areas of eHealth identified fifteen reusable roadmap components that matter in the collaborative development, deployment, and gradual refinement of standards sets, helping identify “waypoints” that mark an essential point of the journey. The proposed road mapping methodology is based on the understanding that to a certain extent these fifteen core component areas fulfil present needs from the four perspectives explored with the Compass. Several gaps need to be filled and standardised artefacts will be refined based on the changing realities of the users’ needs, the technological trends, the regulatory frameworks and the governance systems in which they operate.

2.2.4 CGA Model: Co-creation, Governance and Alignment

A compass and a set of waypoints is however of little use without a map. To start a successful journey, we need to understand not only the prevailing winds of demand (the often competing demands the four perspectives on the eStandards compass), but also to understand the key modes of travel needed along the journey. A model for inclusive and responsive standards life cycle favours efficient and dynamic use of standards with the goal to make best use of data at the point of care and to drive an efficient patient-centred healthcare system based on robust governance, trust and innovation.

The methodology for standards development – and for the creation of a specific roadmap for adopting a specific set of standards – is based upon the idea of continuous flow between three acts of design, development, and interaction: Co-creation, Governance and Alignment.

Co-creation involves notably all actors represented under the four primary perspectives of the eStandards Compass: citizens (including patients), the health workforce, the health system, and vendors. Co-creation includes:

  • Co-design of services – co-planning of health and social policy, co-prioritisation of services and co-financing of services, co-commissioning;

  • Co-delivery of services – co-managing and co-performing services

  • Co-assessment – co-monitoring and co-evaluation of services.

The concept of co-creation goes beyond “working together” to acknowledging the difficulties in healthcare to work together across a wide spectrum of players building provisions to address conflicts of interests and opinions up front. It does so by having the participants in the process learn to understand each other’s perspective in developing a product, work method, or indeed a standard [38].

Governance

Standards are very often closely linked to the governance of healthcare systems and healthcare workflows. ‘Governance’ is used in a wide sense, much as it is used by the WHO, who describes governance in the health sector as covering a wide range of steering and rule-making related functions carried out by governments and decisions makers as they seek to achieve national health policy objectives that are conducive to universal health coverage. Governance is therefore both a regulatory and a political process that involves balancing competing influences and demands. It includes:

  • Maintaining the strategic direction of policy development and implementation

  • Detecting and correcting undesirable trends and distortions

  • Articulating the case for health in national development

  • Regulating the behaviour of a wide range of health and care actors

  • Establishing transparent and effective accountability mechanisms.

The WHO notes that beyond the formal health system, governance means collaborating across the public, private and civil society sectors, to promote and maintain population health. Governance should also be concerned with managing resources in ways that promote leadership and contribute to agreed policy goals strengthening health systems through legislative support. Regulators should also be involved in the standards life cycle activities and standards developers be fully aware of the regulations, which impact upon the use of standards. Finally, governance assumes a constant process of monitoring and evaluation to gradually achieve the alignment needed with standards or regulatory and governance frameworks in the road towards interoperability.

The concept of alignment within the CGA model is the element, which drives the cyclical and flowing nature of CGA. It is the element that ensures that changes in the perceptions of stakeholders or changes in governance are accommodated into projects and initiatives already underway. Within standards development work, the alignment element requires activity principally on the part of the standards developing organisations which musts remain vigilant to potential changes in governance or stakeholder concerns and needs. A key requirement of including alignment activities is to ensure that appropriate monitoring and feedback systems have been set up to make sure that relevant changes can be captured and addressed. Alignment is arguably not a separate element of the CGA model , but defines the process as a whole, in which all relevant actors are able to bring their needs, desires and achievements to the table in order that solutions are identified and discussed, collectively and collaboratively. It is worth noting however that the alignment element may also be used to describe the negotiated relationships between actors, in which they seek to align to one another for best outcomes.

2.3 The eStandards Roadmap Methodology at Work

Figure 3.2 visualises three core steps of the application of the eStandards Roadmap Methodology:

  1. 1.

    Based on the eStandards Compass concept, the actors from across the healthcare spectrum are identified who may have an interest in the way in which a specific set of standards-based solutions is used. Appropriate ways of educating them about the value of standards are developed as well as suitable ways of capturing and addressing their needs. Feedback and acknowledgement is crucial, otherwise the well of co-operation may dry up.

  2. 2.

    Existing Use Cases, Roadmap Components, and standardised artefacts are assessed as well as the extent to which they are able to drive trust and flow of data, anticipating what is needed to move to the next stage and beyond.

  3. 3.

    Once the needs have been identified and the compass points calibrated, a co-creation-governance-alignment process is developed. This requires the development of co-creation tools, looking beyond the usual players to identify fields where lessons may be learned and finding ways of collaborative work and development. The validity of the governance frameworks on which an organisation is built and runs has to be examined. If no longer fit for purpose, they need to be challenged and rules have to be sought and adapted to fit needs and capacity in dynamic flexible ways. All this requires engagement in a constant flow of alignment, where the parties in co-creation are adapted to fit the needs, where governance structures are challenged and where new models of alignment can be embraced (Fig. 3.2).

Fig. 3.2
figure 2

Methodology for eStandards roadmap development

Full size image

3 Conclusion

Above all, clinical data have always been shaped by specific requirements like communication between healthcare professionals, billing, or quality management. As a result, interpretation of clinical data is highly dependent on – often implicit – contexts, is, to a large extent, unstructured and semi-structured, and even standardised data collected for a certain purpose e. g. billing, is difficult to repurpose, e. g. for clinical epidemiology, data analysis or decision support. Only recently, data interoperability has been given more attention due to great expectations regarding the value of large scale predictive data analysis.

This chapter highlighted the need of data standards for making clinical data interoperable and shareable in a virtuous cicle of continuous improvement. The different kinds of standards like terminologies, ontologies and information models were introduced. An overview of existing standards was given and quality and implementation issues were addressed.

The eStandards methodology combined the principles of trust and flow as the basis of well-functioning health systems, a compass of perspectives to inform the needs for trusted flow of data, roadmap components to identify supporting standardised artefacts, and the co-creation, governance, alignment (CGA) model to define the actions to be taken or supported by Standards Developing Organisations. It is expected that the application of the eStandards methodology in an iterative way, aligning reusable interoperability components, specification and tools, with dynamic governance, will advance health data interoperability at a lower cost.