CEN/TC 251 - Medical informatics

This document establishes the Reference Standards Portfolio (RSP) for the clinical imaging domain (as defined in Clause 4).
An RSP lists the principle health information technology (HIT) standards that form the basis of implementing and deploying interoperable applications in the target domain.
An RSP includes a description of the domain, a normative list of standards, and an informative framework for mapping the standards to example deployment use cases.
The lists do not include standards that are specifically national in scope.
The primary target audience for this document is policy makers (governmental or organizational), regulators, project planners and HIT managers. This document will also be of interest to other stakeholders such as equipment and HIT vendors, clinical and health information management (HIM) professionals and standards developers.
The intended usage of this document is to inform decisions about selecting the standards that will form the basis of integration projects in geographic regions or healthcare organizations. For example:
—     What standards to use for capturing/encoding/exchanging certain types of information
—     What standards to use for interfaces between the devices and information systems that support information capture, management, exchange, processing and use
—     What standards to use for specific use cases/deployment scenarios
The selected standards, and/or corresponding RSP clauses, might be useful when drafting project specifications.

This document applies to situations in which such data is recorded on or transported by patient healthcards compliant with the physical dimensions of ID-1 cards defined by ISO/IEC 7810.
This document specifies the basic structure of the data contained within the medication data object, but does not specify or mandate particular data sets for storage on devices.
The purpose of this document is for cards to provide information to other health professionals and to the patient or its non-professional caregiver.
It can also be used to carry a new prescription from the prescriber to the dispenser/pharmacy in the design of its sets.
Medication data include the following four components:
—     medication notes: additional information related to medication and the safe use of medicines by the patient such as medication history, sensitivities and allergies;
—     medication prescriptions: to carry a new prescription from the prescriber to the dispenser/pharmacy;
—     medication dispensed: the records of medications dispensed for the patient;
—     medication references: pointers to other systems that contain information that makes up medication prescription and the authority to dispense.
The following topics are beyond the scope of this document:
—     physical or logical solutions for the practical functioning of particular types of data cards;
—     how the message is processed further “downstream” of the interface between two systems;
—     the form which the data takes for use outside the data card, or the way in which such data is visibly represented on the data card or elsewhere.
NOTE            Not only does the definition of “medicinal products” differ from country to country, but also the same name can relate to entirely different products in some countries. Therefore, it is important to consider the safety of the patient when the card is used across borders.
This document describes and defines the Medication data objects used within or referenced by patient-held health data cards using UML, plain text and Abstract Syntax Notation (ASN.1).
This document does not describe nor define the common objects defined within ISO 21549-2.

The objective of this document is to establish common principles for the creation, assessment, selection and maintenance of maps between terminological resources used to describe and code IDMP therapeutic indications for investigational and medicinal products, medical devices, combination products, biologics and companion diagnostics. Core maintenance principles, such as reliability, reproducibility and quality assurance of the maps for future indication terminology use, are also discussed. The intended audience for this document includes:
a)       Global regulators, pharmaceutical/biopharmaceutical companies, Clinical Research Organizations (CROs) and universities/scientific institutes involved in the development, authorization and marketing of medicinal products
b)       Implementers of IDMP seeking more information about coding of Therapeutic Indications
c)        Healthcare providers
d)       Standards Organizations
e)       Implementers and software vendors developing and implementing terminology map sets
f)         Patients

This document defines a set of high-level categories of purposes for which personal health information can be processed: collected, used, stored, accessed, analysed, created, linked, communicated, disclosed or retained. This is in order to provide a framework for classifying the various specific purposes that can be defined and used by individual policy domains (e.g. healthcare organisation, regional health authority, jurisdiction, country) as an aid to the consistent management of information in the delivery of health care services and for the communication of electronic health records across organisational and jurisdictional boundaries.
Health data that have been irreversibly de-identified are outside the scope of this document, but since de-identification processes often includes some degree of reversibility, this document can also be used for disclosures of de-identified and/or pseudonymised health data whenever practicable.
This classification, whilst not defining an exhaustive set of purposes categories, provides a common mapping target to bridge between differing national lists of purpose and thereby supports authorised automated cross-border flows of EHR data.

This document specifies the characteristics of categorial structures, representing nursing practice. The overall aim of this document is to support interoperability in the exchange of meaningful information between information systems in respect of nursing diagnoses, nursing actions and nurse sensitive outcomes. Categorial structures for nursing diagnoses, nursing actions, nurse sensitive outcomes and associated categories support interoperability by providing common frameworks with which to
a)       analyse the features of different terminologies, including pre- and post-coordinated expressions, those of other healthcare disciplines, and to establish the nature of the relationship between them,[3][4][5][6][7][8]
b)       develop terminologies for representing nursing diagnoses, nursing actions,[9][10][11][12] and nurse sensitive outcomes,
c)        develop terminologies that are able to be related to each other,[3][8][13] and
d)       establish relationships between terminology models, information models, including archetypes, and ontologies in the nursing domain.[14][15][16][45]
There is early evidence that the categorial structures can be used as a framework for analysing nursing practice,[17] for developing nursing content of electronic record systems,[18][19] document the value of nursing services provided and to make nursing’s contribution visible[16][36][47][50].

This document describes and defines the basic structure of the identification data objects held on healthcare data cards, but it does not specify particular data sets for storage on devices.
This document does not apply to the detailed functions and mechanisms of the following services (although its structures can accommodate suitable data objects elsewhere specified):
—    security functions and related services that are likely to be specified by users for data cards depending on their specific application, e.g. confidentiality protection, data integrity protection and authentication of persons and devices related to these functions;
—    access control services;
—    the initialization and issuing process (which begins the operating lifetime of an individual data card, and by which the data card is prepared for the data to be subsequently communicated to it according to this document).
Therefore, this document does not cover:
—    physical or logical solutions for the practical functioning of particular types of data card;
—    the forms that data take for use outside the data card, or the way in which such data are visibly represented on the data card or elsewhere.

This standard establishes a normative definition of communication between personal telehealth insulin pump devices (agents) and managers (e.g., cell phones, personal computers, personal health appliances, set top boxes) in a manner that enables plug-and-play interoperability. It leverages work done in other ISO/IEEE 11073 standards including existing terminology, information profiles, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments, restricting optionality in base frameworks in favor of interoperability. This standard defines a common core functionality of personal telehealth insulin pump devices.
In the context of personal health devices (PHDs), an insulin pump is a medical device used for the administration of insulin in the treatment of diabetes mellitus, also known as continuous subcutaneous insulin infusion (CSII) therapy.
This standard provides the data modeling according to ISO/IEEE 11073-20601 and does not specify the measurement method.

This document specifies:
—     the data elements, structures and relationships between the data elements required for the exchange of information, which uniquely and with certainty identify pharmaceutical dose forms, units of presentation, routes of administration and packaging items (containers, closures and administration devices) related to medicinal products;
—     a mechanism for the association of translations of a single concept into different languages, which is an integral part of the information exchange;
—     a mechanism for the versioning of the concepts in order to track their evolution;
—     rules to help regional authorities to map existing regional terms to the terms created using this document, in a harmonized and meaningful way.

This document describes data elements and structures for the unique identification and exchange of regulated information on pharmaceutical dose forms, units of presentation, routes of administration and packaging.
Based on the principles outlined in this document, harmonised controlled terminologies will be developed according to an agreed maintenance process, allowing users to consult the terminologies and locate the appropriate terms for the concepts that they wish to describe. Provisions to allow for the mapping of existing regional terminologies to the harmonised controlled terminologies will also be developed in order to facilitate the identification of the appropriate terms. The codes provided for the terms can then be used in the relevant fields in the PhPID, PCID and MPID in order to identify those concepts.
This document is intended for use by:
—    any organization that might be responsible for developing and maintaining such controlled vocabularies;
—    any regional authorities or software vendors who want to use the controlled vocabularies in their own systems and need to understand how they are created;
—    owners of databases who want to map their own terms to a standardized list of controlled vocabularies;
—    other users who want to understand the hierarchy of the controlled vocabularies in order to help identify the most appropriate term to describe a particular concept.
This document does not specify a particular terminology for the implementation of ISO 11239.

This document specifies the business requirements for the structured content of structured or semi-
structured dose instructions for recording dose instructions in the electronic health record (EHR),
supporting clinical decision support, and in exchanging medication orders, as applicable to primary,
secondary and tertiary care.
This document is focused on the dose instructions as will be presented to the individual subject of care
or caregiver. Comprehension of dose instructions by the subject of care or caregiver is an overarching
consideration for subject of care safety and the best outcomes. Related factors are discussed but are not
part of the primary scope.
This document does not define an information model, except to the extent that those information model
concepts are necessary to define business requirements.
Outside the scope of this document are:
— The implementation of dose instructions, i.e. assembling the structured elements into a form
appropriate for the patient or caregiver;
— The content of a medication order (see ISO 17523) beyond content related to dose instructions;
— The content of a record of dispense of a medicinal product (see ISO/TS 19293);
— The functionality of health, clinical and/or pharmacy systems;
— Other kinds of content of health, clinical or pharmacy systems that are needed to support the whole
process of health care providers, such as:
— A drug knowledge database (see ISO/TS 22756);
— A decision support system (see ISO/TS 22756 and ISO/TS 22703);
— A complete medical record (EHR);
— A medicinal product dictionary (see ISO/TS 19256);
— Verification of the medicinal product and dose being administered.
— Some concepts from Identification of Medicinal Products are referenced, but not defined, in this
document. See Clause 4 for discussion of the relationship of this document with IDMP.

Within the context of the ISO/IEEE 11073 family of standards for device communication, this document establishes a normative definition of communication between personal telehealth thermometer devices and compute engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments restricting optionality in base frameworks in favor of interoperability. This document defines a common core of communication functionality for personal telehealth thermometer devices.

Within the context of the ISO/IEEE 11073 personal health device standard family, this document defines an optimized exchange protocol and modeling techniques to be used by implementers of personal health devices to create interoperability between device types and vendors. This document establishes a common framework for an abstract model of personal health data available in transport-independent transfer syntax required to establish logical connections between systems and to provide presentation capabilities and services needed to perform communication tasks. The protocol is optimized to personal health usage requirements and leverages commonly used methods and tools wherever possible.

Within the context of the ISO/IEEE 11073 family of standards for device communication, this document establishes a normative definition of communication between personal telehealth blood pressure monitor devices and compute engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments restricting optionality in base frameworks in favor of interoperability. This document defines a common core of communication functionality for personal telehealth blood pressure monitors.

Within the context of the ISO/IEEE 11073 family of standards for device communication, this document establishes a normative definition of communication between personal telehealth weighing scale devices and compute engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments restricting optionality in base frameworks in favor of interoperability. This document defines a common core of communication functionality for personal telehealth weighing scales.

Within the context of the ISO/IEEE 11073 family of standards for device communication, this document establishes a normative definition of communication between personal telehealth pulse oximetry devices and compute engines (e.g., cell phones, personal computers, personal health appliances, set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments restricting optionality in base frameworks in favor of interoperability. This document defines a common core of communication functionality for personal telehealth pulse oximeters.

Within the context of the ISO/IEEE 11073 family of standards for device communication, a normative definition of the communication between personal body composition analyzer agents and managers (e.g., cell phones, personal computers, personal health appliances, set-top boxes) is established by this document in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments to restrict optionality in base frameworks in favor of interoperability. This document defines a common core of communication functionality for personal telehealth body composition analyzers. In this context, the phrase “body composition analyzer” is used broadly to cover analyzing devices that measure body impedances and compute the various body components including body fat from the impedance.

This document provides processes that can be used to analyze the risks to the quality and safety of healthcare and continuity of care when telehealth services are used to support healthcare activities. Using risk management processes, quality objectives and procedures are derived which provide guidelines for the operations of telehealth services. These include but are not limited to the following domains:
—    management of telehealth quality processes by the healthcare organization;
—    strategic and operational process management relating to regulations, knowledge management (best practice) and guidelines;
—    healthcare processes relating to people such as healthcare activities, planning, and responsibilities;
—    management of financial resources to support telehealth services;
—    management of information management and security used in telehealth services;
—    processes related to the planning and provision of human resources, infrastructure, facilities and technology resources for use by telehealth services.
This document provides a set of example guidelines containing quality objectives and procedures for each domain. Organizations can apply the quality and risk management processes described in Clauses 5 and 6 to develop quality objectives and procedures appropriate to the telehealth services they provide.
This document does not provide guidance for the manufacture, assembly, configuration, interoperability or management of devices, products or technical systems.
Annex A provides procedures for the implementation of telehealth services by a large organization. Annex B provides use cases for the application of quality planning guidelines in different types of real-world telehealth services.

This document specifies a number of metadata elements that describe resources containing medical knowledge, primarily digital documents provided as web resources, accessible from databases or via file transfer, but can be applicable also to paper documents, e.g. articles in the medical literature.
The metadata elements
—    support unambiguous and international understanding of important aspects to describe a resource, e.g. purpose, issuer, intended audience, legal status and scientific background,
—    are applicable to different kinds of digital resources, e.g. recommendation from consensus of a professional group, regulation by a governmental authority, clinical trial protocol from a pharmaceutical company, scientific manuscript from a research group, advice to patients with a specific disease, review article,
—    are possible to present to human readers including health professionals as well as individuals/patients, and
—    are potentially usable for automatic processing, e.g. to support search engines to restrict matches to documents of a certain type or quality level.
The metadata elements defined in this document are not intended to
—    describe documents about a single patient, such as medical records,
—    describe details of the medical content of the resource (but some idea of the content can be described via keywords or codes), or
—    prescribe criteria for the quality of the resource content.

Within the context of secure plug-and-play interoperability, cybersecurity is the process and capability of preventing unauthorized access or modification, misuse, denial of use, or the unauthorized use of information that is stored on, accessed from, or transferred to and from a PHD/PoCD. The capability part of cybersecurity is information security controls related to both digital data and the relationships to safety and usability.
For PHDs/PoCDs, this standard defines a security baseline of application layer cybersecurity mitigation techniques for certain use cases or for times when certain criteria are met. This standard provides a scalable information security toolbox appropriate for PHD/PoCD interfaces, which fulfills the intersection of requirements and recommendations from National Institute of Standards and Technology (NIST) and the European Network and Information Security Agency (ENISA). This standard maps to the NIST cybersecurity framework [B15]; IEC TR 80001-2-2 [B8]; and the Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE) classification scheme. The mitigation techniques are based on the extended CIA triad (Clause 4) and are described generally to allow manufacturers to determine the most appropriate algorithms and implementations.

Within the context of secure plug-and-play interoperability, cybersecurity is the process and capability of preventing unauthorized access or modification, misuse, denial of use, or the unauthorized use of information that is stored on, accessed from, or transferred to and from a PHD/PoCD. The process part of cybersecurity is risk analysis of use cases specific to a PHD/PoCD.
For PHDs/PoCDs, this standard defines an iterative, systematic, scalable, and auditable approach to identification of cybersecurity vulnerabilities and estimation of risk. This iterative vulnerability assessment uses the Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE) classification scheme and the embedded Common Vulnerability Scoring System (eCVSS). The assessment includes system context, system decomposition, pre-mitigation scoring, mitigation, and post-mitigation scoring and iterates until the remaining vulnerabilities are reduced to an acceptable level of risk.

This document defines the core data set for a patient summary document that supports continuity of care for a person and coordination of their healthcare. It is specifically aimed at supporting the use case’ scenario for ‘unplanned, cross border care’ and is intended to be an international patient summary (IPS). Whilst the data set is minimal and non-exhaustive, it provides a robust, well-defined core set of data items. The tight focus on this use case also enables the IPS to be used in planned care. This means that both unplanned and planned care can be supported by this data set within local and national contexts, thereby increasing its utility and value.
It uses the European Guideline from the eHN as the initial source for the patient summary requirements, then takes into consideration other international patient summary projects to provide an interoperable data set specification that has global application.
This document provides an abstract definition of a Patient Summary from which derived models are implementable. Due to its nature therefore, readers should be aware that the compliance with this document does not imply automatic technical interoperability; this result, enabled by this document, can be reached with the conformity to standards indicated in the associated technical specification and implementation guides.
This document does not cover the workflow processes of data entry, data collection, data summarization, subsequent data presentation, assimilation, or aggregation. Furthermore, this document does not cover the summarization act itself, i.e. the intelligence/skill/competence that results in the data summarization workflow.
It is not an implementation guide that is concerned with the various technical layers beneath the application layer. Implementation guidance for specifically jurisdictional concerns, e.g. Directives, terminologies, formats, etc., an example is specified in the associated Technical Specification[3].
In particular, representation by various coding schemes, additional structures and terminologies are not part of this document. Terminology and its binding are addressed in Reference [3]. The Identification of Medicinal Products standards (abbreviated to IDMP) are the recommended target for the Medication Summary related to this document but, prior to IDMP’s full implementation in practice, this IPS standard cannot insist in its use at this point in time and recognizes that interim schemes might be necessary until IDMP becomes established as a norm.

This document:
—    Specifies clinical information models (CIMs) as health and care concepts that can be used to define and to structure information for various purposes in health care, also enabling information reuse;
—    Describes requirements for CIMs content, structure and context and specification of their data elements, data element relationships, meta-data and versioning, and provides guidance and examples;
—    Specifies key characteristics of CIMs used in conceptual and logical analysis for use cases such as (reference) architectures, information layers, EHR and PHR systems, interoperability, systems integration in the health domain, and secondary use of data including for public health reporting;
—    Defines a Quality Management System (QMS) for a systematic and effective governance, quality management, and measurement of CIMs through their lifecycle of development, testing, distribution, application and maintenance;
—    Provides principles for the transformation and application of clinical information models through the wide variation of health information technology.
This document excludes:
—    Requirements on the content or application of any particular clinical information model or clinical information modelling methodology;
—    Specific applications of clinical information models such as for dynamic modelling of workflow;
—    Specifications for modelling entire domains or aggregates of many CIMs such as complete assessment documents or discharge summaries. It does not specify CIMs compositions;
—    Specification of how to involve specific clinicians, how to carry out governance including information governance, or how to ensure patient safety.

ISO 17117-1:2018 defines universal and specialized characteristics of health terminological resources that make them fit for the purposes required of various applications. It refers only to terminological resources that are primarily designed to be used for clinical concept representation or to those parts of other terminological resources designed to be used for clinical concept representation.
ISO 17117-1:2018 helps users to assess whether a terminology has the characteristics or provides the functions that will support their specified requirements. The focus of this document is to define characteristics and functions of terminological resources in healthcare that can be used to identify different types of them for categorization purposes. Clauses 4 and 5 support categorization according to the characteristics and functions of the terminological resources rather than the name.
NOTE       Categorization of healthcare terminological systems according to the name of the system might not be helpful and has caused confusion in the past.
The target groups for this document are:
a)    organizations wishing to select terminological systems for use in healthcare information systems;
b)    developers of terminological systems;
c)    developers of terminology standards;
d)    those undertaking independent evaluations/academic reviews of terminological resources;
e)    terminology Registration Authorities.
ISO 17117-1:2018 contains general characteristics and criteria with which systems can be evaluated.
The following considerations are outside the scope of this document.
-      Evaluations of terminological resources.
-      Health service requirements for terminological resources and evaluation criteria based on the characteristics and functions.
-      The nature and quality of mappings between different terminologies. It is unlikely that a single terminology will meet all the terminology requirements of a healthcare organization: some terminology providers produce mappings to administrative or statistical classifications such as the International Classification of Diseases (ICD). The presence of such maps would be a consideration in the evaluation of the terminology.
-      The nature and quality of mappings between different versions of the same terminology. To support data migration and historical retrieval, terminology providers can provide maps between versions of their terminology. The presence of such maps would be a consideration in the evaluation of the terminology.
-      Terminology server requirements and techniques and tools for terminology developers.
-      Characteristics for computational biology terminology. Progress in medical science and in terminology science will necessitate updating of this document in due course.

This document specifies a common framework for audit trails for electronic health records (EHR), in terms of audit trigger events and audit data, to keep the complete set of personal health information auditable across information systems and domains.
It is applicable to systems processing personal health information that create a secure audit record each time a user reads, creates, updates, or archives personal health information via the system.
NOTE       Such audit records at a minimum uniquely identify the user, uniquely identify the subject of care, identify the function performed by the user (record creation, read, update, etc.), and record the date and time at which the function was performed.
This document covers only actions performed on the EHR, which are governed by the access policy for the domain where the electronic health record resides. It does not deal with any personal health information from the electronic health record, other than identifiers, the audit record only containing links to EHR segments as defined by the governing access policy.
It does not cover the specification and use of audit logs for system management and system security purposes, such as the detection of performance problems, application flaw, or support for a reconstruction of data, which are dealt with by general computer security standards such as ISO/IEC 15408 (all parts)[9].
Annex A gives examples of audit scenarios. Annex B gives an overview of audit log services.

This document is applicable to the data exchange format that is designed to facilitate exchanging omics data around the world without forcing changes of any database schema.
This document specifies the characteristics of OML from the following perspectives.
From an informatics perspective, OML defines the data exchange format based on XML. This document gives guidelines for the specifications of the data exchange format, but this document excludes the database schema itself.
From a molecular side of view, this document is applicable to all kinds of omics data, while this document excludes the details of the molecules (e.g., details of genomic sequence variations or whole genomic sequence). This document is also applicable to the molecular annotations including clinical concerns and relations with other omics concerns.
From an application side of view, this document is applicable to the clinical field including clinical practice, preventive medicine, translational research, and clinical research including drug discovery. This document does not apply to basic research and other scientific fields.
From a biological species side of view, this document is applicable to the human health-associated species as human, preclinical animals, and cell lines. This document does not apply to the other biological species.

This document enables the advancement of interoperability from the data/information exchange paradigm to knowledge sharing at decreasing level of abstraction, starting at IT concept level (semantic coordination) through business domain concept level (agreed service function level cooperation), domain level (cross-domain cooperation) up to individual context (skills-based end-user collaboration). The document defines a model and framework for a harmonized representation of existing or intended systems with a specific focus on ICT-supported business systems. The Interoperability and Integration Reference Architecture supports ontology harmonization or knowledge harmonization to enable interoperability between, and integration of, systems, standards and solutions at any level of complexity without the demand for continuously adapting/revising those specifications. The approach can be used for analysing, designing, integrating, and running any type of systems. For realizing advanced interoperability, flexible, scalable, business-controlled, adaptive, knowledge-based, intelligent health and social ecosystems need to follow a systems-oriented, architecture-centric, ontology-based and policy-driven approach.
The languages for representing the different views on systems such as ontology languages like Common Logic (CL) (ISO/IEC 24707[24]) and Web Ontology Language (OWL)[25] – specifically OWL 2[26] (World Wide Web Consortium (W3C®), languages for modeling and integrating business processes like Business Process Modeling Language (BPML) (OMG®), but also OMG’s Unified Modeling Language (UML, also specified as ISO/IEC 19505[27]) based representation styles for the different ISO/IEC 10746 (all parts) views are outside the scope of this document.

This document specifies the requirements for medication safety alert systems and the topics which are relevant to alert system vendors. This document applies to clinical decision support systems (CDSSs) whether or not these are medical devices.
This document addresses:
—    requirements for terminology used in medication safety alerts;
—    requirements for choosing a knowledge base for medication safety alert systems;
—    requirements for the proper functionality of CDSSs as related to medication safety alert systems;
—    requirements for medication safety alert display;
—    requirements for quality measurements to improve the effectiveness of medication safety alerts.
The following are out of the scope of this document:
—    the development of content (rule-based knowledge base) for CDSS;
—    the development of algorithms for generating medication safety alerts in CDSS;
—    the development of alert processors for medication safety alerts in CDSS.

This document outlines the standards needed to identify and label the Subject of Care (SoC) and the Individual Provider on objects such as identification (wrist) bands, identification tags or other objects, to enable automatic data capture using data carriers in the care delivery process.
It provides for a unique SoC identification that can be used for other purposes, such as recording the identity of the SoC in individual health records.
This document serves as a reference for any organization which plans to implement or improve Automatic Identification and Data Capture (AIDC) in their delivery of care process. It is based on the use of the GS1® system of standards. Other solutions, such as using other identification systems (for example, systems based on ISBT 128), are possible but not addressed by this document.
This document describes good practices to reduce/avoid variation and workarounds which challenge the efficiency of AIDC at the point of care and compromise patient safety[5][6].
This document specifies how to manage identifiers in the AIDC process, and completes the information found in ISO/TS 22220 and ISO/TS 27527.

This document provides quality requirements for health apps and defines a health app quality label in order to visualize the quality and reliability of health apps.
This document is applicable to health apps, which are a special form of health software. It covers the entire life cycle of health apps.
This document is intended for use by app manufacturers as well as app assessment organizations in order to communicate the quality and reliability of a health app. Consumers, patients, carers, health care professionals and their organizations, health authorities, health insurers and the wider public can use the health app quality label and report when recommending or selecting a health app for use, or for adoption in care guidelines, care pathways and care contracts.
NOTE 1   Health apps can be subject to national legislation, such as for medical devices.
NOTE 2   See Annex C for additional details on the scope.
Outside the scope of this document are guidelines to comply to the medical device regulation.

This document specifies the fundamental characteristics of the information model implemented by a specific architectural layer (i.e. the service architecture) of the information system to provide a comprehensive and integrated storage of the common enterprise data and to support the fundamental business processes of the healthcare organization, as defined in ISO 12967‑1.
The information model is specified in this document without any explicit or implicit assumption on the physical technologies, tools or solutions to adopt for its physical implementation in the various target scenarios. The specification is nevertheless formal, complete and non-ambiguous enough to allow implementers to derive an efficient design of the system in the specific technological environment that will be selected for the physical implementation.
This document does not aim at representing a fixed, complete, specification of all possible data that can be necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics, in terms of overall organization and individual information objects, identified as fundamental and common to all healthcare organizations, and that is satisfied by the information model implemented by the service architecture.
Preserving consistency with the provisions of this document, physical implementations are allowed extensions to the standard information model in order to support additional and local requirements. Extensions include both the definition of additional attributes in the objects of the standard model, and the implementation of entirely new objects.
Also, this document specification is extensible over time according to the evolution of the applicable standardization initiatives.
The specification of extensions is carried out according to the methodology defined in ISO 12967-1:2020, Clause 7.

This document provides guidance and requirements for the description, planning and development of new systems, as well as for the integration of existing information systems, both within one enterprise and across different healthcare organizations, through an architecture integrating the common data and business logic into a specific architectural layer (i.e. the middleware), distinct from individual applications and accessible throughout the whole information system through services, as shown in Figure 2.

This document specifies the fundamental characteristics of the computational model implemented by a specific architectural layer of the information system (i.e. the service architecture) to provide a comprehensive and integrated interface to the common enterprise information and to support the fundamental business processes of the healthcare organization, as defined in ISO 12967‑1. The computational model is specified without any explicit or implicit assumption about the physical technologies, tools or solutions to adopt for its physical implementation in the various target scenarios. The specification is nevertheless formal, complete and non-ambiguous enough to allow implementers to derive an efficient design of the system in the specific technological environment which will be selected for the physical implementation.
The computational model specified in this document provides the basis for ensuring consistency between different engineering and technology specifications (including programming languages and communication mechanisms) since they are intended to be consistent with the same computational object model. This consistency allows open inter-working and portability of components in the resulting implementation.
This document does not aim at representing a fixed, complete, specification of all possible interfaces that might be necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics — in terms of overall organization and individual computational objects, identified as fundamental and common to all healthcare organizations, and that are satisfied by the computational model implemented by the service architecture.
Preserving consistency with the provisions of this document, physical implementations of the computational model specified in this document can allow extensions in order to support additional and local requirements. Extensions can include both the definition of additional properties of the objects of the computational model specified in this document and the implementation of entirely new objects.
Also, the computational model specified in this document can be extendable over time according to the evolution of the applicable standardization initiatives, in accordance to the methodology defined in ISO 12967‑1:2020, Clause 7, which identifies a set of healthcare common information services, describing the requirements behind them and the methodology through which they will be used.
The information services specified in this document are only the minimal set identifiable according to the identified requirements of the healthcare enterprise, and constituting the service architecture (i.e. the integration platform) to serve as the basis for healthcare applications, e.g. EHR or patient administration.

This document defines a nomenclature for communication of information from point-of-care medical devices. Primary emphasis is placed on acute care medical devices and patient vital signs information. The nomenclature also supports concepts in an object-oriented information model that is for medical device communication.

This document specifies the common conventions required for the cart-to-host as well as cart-to-cart interchange of specific patient data (demographic, recording, ...), ECG signal data, ECG measurement and ECG interpretation results.
This document specifies the content and structure of the information which is to be interchanged between digital ECG carts and computer ECG management systems, as well as other computer systems where ECG data can be stored

The scope of this project is to define a general object-oriented information model that may be used to structure information and identify services used in point-of-care (POC) medical device communications. The scope is primarily focused on acute care medical devices and the communication of patient vital signs information.

The scope of this standard is a service-oriented medical device architecture and communication protocol specification for distributed system of Point-of-Care (PoC) medical devices and medical IT systems that need to exchange data or safely control networked PoC medical devices. It identifies the functional components, their communication relationships as well as the binding of the components and communication relationships to protocol specifications.

This document provides guidelines on identification and labelling of medicinal products from the point of manufacture of packaged medicinal product to the point of dispensing the product.
This document outlines best practice for AIDC barcoding solutions for applications. Users can, however, consider the coding interoperability requirements for other AIDC technologies, e.g. Radio Frequency Identification (RFID).

This document specifies the requirements for developing a knowledge base for drug-related problems that cohere with the intended drug use, to be used in rule-based clinical decision support systems (CDSS), such as the criteria for selecting a raw data source and the quality criteria for the development and maintenance for the rules or clinical rules for drug safety. It also describes the process of how to develop a knowledge base, the topics to be considered by the developers of a knowledge base, and it gives guidance on how to do this.
This document gives guidelines for the development of a knowledge base:
—     with rules to enhance decisions and actions in drug-related problems that cohere with the intended drug use;
—     which can be used by all kinds of healthcare professionals, such as those who prescribe, dispense, administer or monitor medicines;
—     which can be used in every care setting, including chronic and acute care, primary and specialized care;
—     which is a repository of evidence/practice bases rules, assessed by experts;
—     which is meant to be used in conjunction with a medicinal product dictionary;
—     whose knowledge is structured in rules and therefore to be used in the type of rule-based CDSS.
This document does not:
—     describe the exact content of a knowledge base i.e. the outcome of the process of developing rules.
—     provide the requirements for a clinical decision support system, the software that uses the knowledge base combined with the patient's data, and presents the outcome of the rules to the healthcare professional. These requirements are described in ISO/DTS 22703[1].
—     give the requirements for non-medication knowledge bases. Some aspects of the requirements in this document are general in nature and applicable to other kinds of knowledge bases, but this document does not address all of the requirements of non-medication knowledge bases.
[1] Under preparation. Stage at the time of publication: ISO/DTS 22703.

This Technical Specification (TS) provides implementation guidance to support the use of the International Patient Summary dataset in a European context. The focus of this technical specification takes into consideration European specific jurisdictional requirements, needs and contexts that Europe requires to be satisfied for effective implementation. It addresses both functional and non-functional requirements for the dataset’s interchange. As part of the usability of the International Patient Summary, European perspectives, directives and regulations contextualise and add value to generic reference implementations for use by Member States.
The TS applies the refined European Interoperability Framework (ReEIF), which describes legal, organisational, semantic and technological considerations for interoperability. These considerations highlight the eHealth Network’s (eHN) guidance for cross-border care and underpin the care process. The TS formalises principles to support the safe and legitimate use of patient summary data and afford protection for efficient cross-border data interchange within scenarios for unscheduled care.
This Technical Specification gives selection criteria and provides examples of various transport formats and terminologies shown to be suitable for interchanging the International Patient Summary dataset. Compliance, deployment & migration Guidance are also included. The TS distinguishes between cross-border only requirements for interchanging the dataset and those that are generally applicable within national borders.

This document specifies a set of representational primitives and semantic relations needed for an unambiguous representation of explicit time-related expressions in health informatics. This document does not introduce or force a specific ontology of time, nor does it force the use of a fixed representation scheme for such an ontology. Rather this document provides a set of principles for syntactic and semantic representation that allow the comparability of specific ontologies on time, and the exchange of time-related information that is expressed explicitly.
This document applies to both the representation of actual phenomena occurring in the real world (e.g. registrations in medical records) and to the description of concepts (e.g. medical knowledge bases).
This document is applicable to
a)    developers of medical information systems where there might be a need for explicit time-related concepts for internal organization (e.g. temporal data bases, temporal reasoning systems),
b)    information modellers or knowledge engineers building models for the systems mentioned in a),
c)    experts involved in the development of semantic standards on precise subdomains in health care where time-related information needs to be covered, (e.g. in the study of pathochronology, i.e. the discipline dealing with the time course of specific diseases), and
d)    developers of interchange formats for messages in which time-related information is embedded.
This document is not intended to be used directly for
—          representing what is true in time,
—          reasoning about time, or
—          representation of metrological time.

This document specifies a means for communicating part or all of the electronic health record (EHR) of one or more identified subjects of care between EHR systems, or between EHR systems and a centralised EHR data repository.
It can also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components), or personal health applications and devices, that need to access or provide EHR data, or as the representation of EHR data within a distributed (federated) record system.
This document will predominantly be used to support the direct care given to identifiable individuals or self-care by individuals themselves, or to support population monitoring systems such as disease registries and public health surveillance. Uses of health records for other purposes such as teaching, clinical audit, administration and reporting, service management, research and epidemiology, which often require anonymization or aggregation of individual records, are not the focus of this document but such secondary uses might also find the document useful.
This Part 1 of the multipart series is an Information Viewpoint specification as defined by the Open Distributed Processing ? Reference model: Overview (ISO/IEC 10746-1). This document is not intended to specify the internal architecture or database design of EHR systems.

This document specifies the information architecture required for interoperable communications between systems and services that need or provide EHR data. This document is not intended to specify the internal architecture or database design of such systems.
The subject of the record or record extract to be communicated is an individual person, and the scope of the communication is predominantly with respect to that person's care.
Uses of healthcare records for other purposes such as administration, management, research and epidemiology, which require aggregations of individual people's records, are not the focus of this document but such secondary uses could also find the document useful.
This document defines a set of interfaces to request and provide:
—          an EHR_EXTRACT for a given subject of care as defined in ISO 13606-1;
—          one or more ARCHETYPE(s) as defined in ISO 13606-2;
—          an EHR_AUDIT_LOG_EXTRACT for a given subject of care as defined in ISO 13606-4.
This document defines the set of interactions to request each of these artefacts, and to provide the data to the requesting party or to decline the request. An interface to query an EHR or populations of EHRs, for example for clinical audit or research, are beyond its scope, although provision is made for certain selection criteria to be specified when requesting an EHR_EXTRACT which might also serve for population queries.
This document defines the Computational Viewpoint for each interface, without specifying or restricting particular engineering approaches to implementing these as messages or as service interfaces.
This document effectively defines the payload to be communicated at each interface. It does not specify the particular information that different transport protocols will additionally require, nor the security or authentication procedures that might be agreed between the communicating parties or required by different jurisdictions.

This document specifies a means for communicating part or all of the electronic health record (EHR) of one or more identified subjects of care between EHR systems, or between EHR systems and a centralised EHR data repository.
It can also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components) that need to access or provide EHR data, or as the representation of EHR data within a distributed (federated) record system.
This document will predominantly be used to support the direct care given to identifiable individuals, or to support population monitoring systems such as disease registries and public health surveillance. Uses of health records for other purposes such as teaching, clinical audit, administration and reporting, service management, research and epidemiology, which often require anonymization or aggregation of individual records, are not the focus of this standard series but such secondary uses might also find it useful.
This document defines an Archetype Model to be used to represent Archetypes when communicated between repositories, and between archetype services. It defines an optional serialised representation, which may be used as an exchange format for communicating individual archetypes. Such communication might, for example, be between archetype libraries or between an archetype service and an EHR persistence or validation service.

This document specifies a means for communicating part or all of the electronic health record (EHR) of one or more identified subjects of care between EHR systems, or between EHR systems and a centralised EHR data repository.
It can also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components), or personal health applications and devices, that need to access or provide EHR data, or as the representation of EHR data within a distributed (federated) record system.
This document defines term lists that each specify the set of values for the particular attributes of the Reference Model defined in ISO 13606-1. It also defines normative and informative Reference Archetypes that enable frequently-occurring instances of EHR data to be represented within a consistent structure when communicated using this document.

This document describes a methodology for specifying the privileges necessary to access EHR data. This methodology forms part of the overall EHR communications architecture defined in ISO 13606-1.
This document seeks to address those requirements uniquely pertaining to EHR communications and to represent and communicate EHR-specific information that will inform an access decision. It also refers to general security requirements that apply to EHR communications and points at technical solutions and standards that specify details on services meeting these security needs.
NOTE       Security requirements for EHR systems not related to the communication of EHRs are outside the scope of this document.

The main purpose of ClaML is to formally represent the content and hierarchical structure of healthcare classification systems in a markup language for the safe exchange and distribution of data and structure between organizations and dissimilar software products.
The scope of healthcare classification systems covered by this document encompasses terminologies, and is constrained to traditional paper-based systems (like ICD-10) and systems built according to categorial structures and a cross thesaurus (like ICNP)[2]. ClaML is intended for representation of healthcare classification systems in which classes have textual definitions, hierarchical ordering, named hierarchical levels (such as "chapter", "section"), inclusion and exclusion criteria, and codes. It is not intended to cover any formal representation, neither for definition or composition of concepts, nor for specification of classification rules. Systems with such formal specifications can at best be partially represented using ClaML, and are hence out of scope. Most of the notes and examples in this document relate to ICD. This is because ICD is the most common classification system in the scope of this document. As a highly complex classification system it is an inexhaustible source for examples of nearly any kind. But all these notes and examples represent also other similar classification systems, if applicable, which are usually less complex. An overview of currently known classification systems using ClaML is provided in a separate document which is electronically available (see 7.3).
This document is not intended to:
a)    provide a normative syntax on how a healthcare classification system is to be constructed;
b)    define link types between elements in a healthcare classification system (this is left to the developers of healthcare classification systems);
c)    provide a representation for direct viewing or printing.

This standard establishes a normative definition of communication between personal health continuous glucose monitor (CGM) devices (agents) and managers (e.g., cell phones, personal computers, personal health appliances, set top boxes) in a manner that enables plug-and-play interoperability. It leverages work done in other ISO/IEEE 11073 standards including existing terminology, information profiles, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments, restricting optionality in base frameworks in favor of interoperability. This standard defines a common core of communication functionality of CGM devices. In this context, CGM refers to the measurement of the level of glucose in the body on a regular (typically 5 minute) basis through a sensor continuously attached to the person.

This document provides an information model to define and identify substances within medicinal products or substances used for medicinal purposes, including dietary supplements, foods and cosmetics. The information model can be used in the human and veterinary domain since the principles are transferrable. Other standards and external terminological resources are referenced that are applicable to this document.

ISO/IEEE 11073-10427:2018 establishes a normative defi nition of communication between devices containing a power source (agents) and managers (e.g., cell phones, personal computers, personal health appliances, set-top boxes) in a manner that enables plug-and-play interoperability. Using existing terminology, information profi les, applica-tion profi le standards, and transport standards as defi ned in other ISO/IEEE 11073 standards, this standard de-fi nes a common core of communication functionality of personal health devices (PHDs) containing a battery, including: 1) current device power status (e.g., on mains or on battery); 2) power charge status (e.g., percent of full charge); and 3) estimated time remaining (e.g., minutes).