ITC - Information technology

This standard specifies a set of Participant Key Purposes (PKPs) pertaining to metric data exchange for the Service-oriented Device Connectivity (SDC) series of standards. PKPs are role-based sets of requirements for products in order to support safe, effective, and secure interoperability in medical IT networks at point-of-care environments such as the intensive care unit (ICU), operating room (OR) or other acute care settings. This standard specifies both product development process and technical requirements.

This standard specifies the base set of Participant Key Purposes (PKPs) for the Service-oriented Device Connectivity (SDC) series of standards. PKPs are role-based sets of requirements for products in order to support safe, effective, and secure interoperability in medical IT networks at point-of-care environments such as the intensive care unit (ICU), operating room (OR) or other acute care settings. This standard specifies both product development process and technical requirements.

The management of electronic transport regulations (METR) provides trustworthy, authoritative, machine-interpretable, transport-related rules for using the road network.
This document describes the operational concept (ConOps) for METR in a format that is consistent with ISO/IEC/IEEE 29148.

Within the context of the ISO/IEEE 11073 family of standards for device communication, this standard establishes a normative definition of the communication between medication monitoring devices 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 appropriate portions of existing standards, including ISO/IEEE 11073 terminology, information models and application profile. It specifies the use of specific term codes, formats, and behaviors in telehealth environments restricting ambiguity in base frameworks in favor of interoperability. This standard defines a common core of communication functionality for medication monitors. In this context, medication monitors are defined as devices that have the ability to determine and communicate (to a manager) measures of a user’s adherence to a medication regime.

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 extends the base nomenclature provided in ISO/IEEE 11073-10101:2020  to support terminology for implantable cardiac devices. Devices within the scope of this nomenclature are implantable devices such as pacemakers, defibrillators, devices for cardiac resynchronization therapy, and implantable cardiac monitors. This nomenclature defines the terms necessary to convey a clinically relevant summary of the information obtained during a device interrogation. The nomenclature extensions may be used in conjunction with other IEEE 11073 standard components (e.g., ISO/IEEE 11073-10201 [B2] ) or with other standards, such as Health Level Seven International (HL7).

Within the context of the ISO/IEEE 11073 family of standards for device communication, this standard establishes a normative definition of the communication between independent living activity hubs and managers (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 and information models. It specifies the use of specific term codes, formats, and behaviors in telehealth environments restricting ambiguity in base frameworks in favor of interoperability. This standard defines a common core of communication functionality for independent living activity hubs. In this context, independent living activity hubs are defined as devices that communicate with simple situation monitors (binary sensors), normalize information received from the simple environmental monitors, and provide this normalized information to one or more managers. This information can be examined, for example, to determine when a person’s activities/behaviors have deviated significantly from what is normal for them such that relevant parties can be notified. Independent living activity hubs will normalize information from the following simple situation monitors (binary sensors) for the initial release of the proposed standard: fall sensor, motion sensor, door sensor, bed/chair occupancy sensor, light switch sensor, smoke sensor, (ambient) temperature threshold sensor, personal emergency response system (PERS), and enuresis sensor (bed-wetting).

This document specifies requirements and provides guidance for bodies providing audit and certification of a privacy information management system (PIMS) according to ISO/IEC 27701, in addition to the requirements contained within ISO/IEC 17021-1.
The requirements contained in this document are demonstrated in terms of competence and reliability by bodies providing PIMS certification. The guidance contained in this document provides additional interpretation of these requirements for bodies providing PIMS certification.
NOTE       This document can be used as a criteria document for accreditation, peer assessment or other audit processes.

This document defines terms within the field of electronic fee collection (EFC).
This document defines:
—     terms that are used in standards related to electronic fee collection;
—     terms of a more general use that are used more specifically in standards related to electronic fee collection.
This document does not define terms related primarily to other fields that operate in conjunction with EFC, such as terms for intelligent transport systems (ITS), common payment systems, the financial sector, etc.

This document defines the core data set for a concise international patient summary (IPS), which supports continuity of care for a person and assists with coordination of their care.
This document provides an abstract definition of a patient summary from which derived models are implementable.
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, skills and competences, 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. Representation by various coding schemes, additional structures and terminologies are not part of this document.

This document specifies requirements for establishing, implementing, maintaining and continually improving a privacy information management system (PIMS).
Guidance is also provided to assist in the implementation of the requirements in this document.
This document is intended for personally identifiable information (PII) controllers and PII processors holding responsibility and accountability for PII processing.
This document is applicable to all types and sizes of organizations, including public and private companies, government entities and not-for-profit organizations.

This document defines the end-to-end requirements for the entire management of electronic traffic regulations (METR) system of systems (SoS). This document introduces the reference architecture used by subsequent parts.
NOTE            The operational concept for METR is provided in ISO/TR 24315-2.[9]

This document describes how trading partners may extend the Core Invoice Model and the related business rules and code lists, to support business cases that are specific to their trading environment, while at the same time maintaining semantic interoperability with the Core Invoice Model.
This document does not define a methodology for creation of a Core Invoice Usage Specification, nor does it describe the detailed process of syntax binding.

All parts of EN 16931 with a specific focus on CEN/TR 16931-5 (Electronic invoicing - Part 5: Guidelines on the use of sector or country extensions in conjunction with EN 16931-1, methodology to be applied in the real environment).

This document specifies a publication sub-model within the DATEX II model that supports the publication of electronic traffic regulations and controlled zones.
This publication is intended to support the exchange of informational content from road traffic authorities issuing traffic regulation orders and organizations implementing these orders to other organizations providing ITS services or onward information exchange.

This choreographies document describes the exchange of information in the Fulfilment phase between seller and buyer where the seller wants to announce delivery of the ordered goods or services. The purpose of the fulfilment it is to monitor the executions of the contract. This process is the process between the ordering process and the billing process. The billing process can start when fulfilment has been initiated. The business value for this is:
—   To prepare the buyers organization for the physical delivery;
—   To enabling an automatic check of delivery for the buying organization before paying the received invoice;
—   To match the ordered products with the physical deliveries, such as serial numbers, lot identifiers and other information that might not be present at the time the goods were ordered;
—   The assist in getting an accurate calculation of the environmental footprint of the goods by including the emission during the transport;
—   To feed data into the logistic process, so no retyping is needed during the transport of the goods.
The identifier of this set of choreographies is EN 17017-1:2025
How to claim conformance to a choreography variant defined in this document is described in 4.2.3.

This document:
—    describes and specifies globally unique addresses and identifiers (ITS-S object identifiers) that are both internal and external to ITS stations and are used for ITS station management;
—    describes how ITS-S object identifiers and related technical parameters are used for classification, registration and management of ITS applications and ITS application classes;
—    describes how ITS-S object identifiers are used in the ITS communication protocol stack;
—    introduces an organizational framework for registration and management of ITS-S objects;
—    defines and specifies management procedures at a high functional level;
—    specifies an ASN.1 module for the identifiers, addresses and registry records identified in this document; and
—    specifies an ASN.1 module for a C-ITS data dictionary containing ASN.1 type definitions of general interest.
This document is based on the architecture of an ITS station specified in ISO 21217 as a bounded secured managed domain (BSMD).

The scope of this document is constrained to the content of the electronic prescription (ePrescription) itself, the digital document which is issued by a prescribing healthcare professional and received by a dispensing healthcare professional. The prescribed medicinal product is to be dispensed through an authorized healthcare professional with the aim of being administered to a human patient. The ePrescription in the administrative workflow of reimbursement is not covered in this document.
This document specifies the requirements that apply to ePrescriptions. It describes generic principles that are considered important for all ePrescriptions.
This document is applicable to ePrescriptions of medicinal products for human use. Although other kinds of products (e.g. medical devices, wound care products) can be ordered by means of an ePrescription, the requirements in this document are aimed at medicinal products that have a market authorization and at pharmaceutical preparations which are compounded in a pharmacy.
This document does not limit the scope to any setting (community, institutional) and leaves it to the national bodies to decide on this matter.
This document specifies a list of data elements that can be considered as essential for ePrescriptions, depending on jurisdiction or clinical setting (primary healthcare, hospital, etc.). Ensuring the authenticity of these data elements is in scope and will have impact on the requirements of information systems.
Other messages, roles and scenarios (e.g. validation of a prescription, administration, medication charts, EHR of the patient, reimbursement of care and dispensed products) are not covered in this document, because they are country-specific or region-specific, due to differences in culture and in legislation of healthcare. However, requirements and content of ePrescriptions within the context of jurisdictions have a relationship with these scenarios. This document also does not cover the way in which ePrescriptions are made available or exchanged, and the process of prescribing itself.
The logistic process of prescribing itself is not part of the scope. A prescription can either be sent (pushed) to a dispenser or either be retrieved (pulled) at the dispenser. However, the requirement for the prescription is described, that it will be able to function in both environments.

1.1   Objective
This document is intended for the use of breeder document issuing authorities both policymakers and technical, for having uniform formats that conform to printed as well as digital requirements of CEN member and associated states (including EU member states).
The objectives are:
a)   provision of a common set of formats of breeder documents – printed and digital to be implemented by CEN member and associated states (including EU member states), with the extended objective of their acceptance internationally;
b)   the focus is on having common recognizable formats as well as prevention of identity fraud, particularly related to the use of breeder documents to obtain national and international ID documents, such as passports, and residence permits.
1.2   Human dimension of identity management
Each country’s identity management system also provides a framework for observing and protecting many of the human rights embodied in international declarations and conventions. Depending on the provisions in place, the system can ensure that citizens can exercise a wide range of rights, such as rights to property, privacy, freedom of movement and free choice of place of residence, as well as access to social services such as education, healthcare and social security. In states with more advanced technological infrastructure, population registration provides the basis for the establishment of a number of citizen-oriented computerized services, also known as e-services and e-government. Identity management is also central to prevention of discrimination in exercising guaranteed rights.
The identity management infrastructure provides the backbone for a functioning and viable state by securing civil, population and tax registers, as well other systems such as healthcare benefits, voter lists and the issuance of travel and identity documents based on verifiable identities. Such flaws may become visible during elections, where shortcomings in voter lists can affect confidence in the election process. In essence, a secure identity management system can be seen as the foundation, a root level, that is able to then feed into and help numerous other branches of key state services function effectively and accurately (OSCE, 2017, p.13) [27].
1.3   Security dimension of identity management
One of the key elements of a secure environment for cross-border travel is that the travel documents used by visitors meet international standards in terms of security of the document itself and security in that the document reflects the genuine identity of its holder. Similarly, the systems for issuing travel documents need to be linked to identity management systems to streamline decision-making processes, preferably through modernized systems that reflect developments in document security technology. As entries in registers or officially issued identification documents provide access to specific services, criminal networks are constantly looking for possible gaps in identity management systems to obtain genuine documents under fabricated or stolen identities. Documents obtained as result of gaps in identity management have enabled criminals to target business entities and cause significant financial losses through the use of genuine documents issued to non-existent identities (OSCE, 2017, p.14) [27].
Both legal and illegal immigration breeder docs are regularly used to determine an identity if no MRTD or eMRTD is presented. An identity which will be printed on an eRP, Foreigners ppt, Refugees travel doc etc. unless other supportive evidence of identity is provided.
Organized crime has not overlooked this and fraudulently obtained or falsified travel documents are regularly presented to hide the true identity.
Since a significant portion of the world’s population cannot reliably prove their identity, they rely on verbally presented identities and/or supportive breeder documents when registering in another country.
Asylum applicants who...

The HL7 EHR System Functional Model provides a reference list of functions that may be present in an Electronic
Health Record System (EHR-S). The function list is described from a user perspective with the intent to enable
consistent expression of system functionality. This EHR-S Functional Model, through the creation of Functional
Profiles for care settings, realms, services and specialties, enables a standardized description and common
understanding of functions sought or available in a given setting (e.g., intensive care, cardiology, office practice
in one country or primary care in another country).
The HL7 EHR-S Functional Model defines a standardized model of the functions that may be present in EHR
Systems. From the outset, a clear distinction between the EHR as a singular entity and systems that operate on
the EHR – i.e., EHR Systems is critical. This Standard makes no distinction regarding implementation - the EHRS
described in a Functional Profile may be a single system or a system of systems. Within the normative sections
of the Functional Model, the term “system” is used generically to cover the continuum of implementation options.
This includes “core” healthcare functionality, typically provided by healthcare-specific applications that manage
electronic healthcare information. It also includes associated generic application-level capabilities that are
typically provided by middleware or other infrastructure components. The latter includes interoperability and
integration capabilities such as location discovery and such areas as cross application workflow. Interoperability
is considered both from semantic (clear, consistent and persistent communication of meaning) and technical
(format, syntax and physical connectivity) viewpoints. Further, the functions make no statement about which
technology is used, or about the content of the electronic health record. The specifics of 'how' EHR systems are
developed or implemented is not considered to be within the scope of this model now or in the future. This EHRS
Functional Model does not address or endorse implementations or technology, nor does it include the data
content of the electronic health record.
Finally, the EHR-S Functional Model supports research needs by ensuring that the data available to researchers
follow the required protocols for privacy, confidentiality, and security. The diversity of research needs precludes
the specific listing of functions that are potentially useful for research.
This Functional Model is not:
• a messaging specification
• an implementation specification
• a conformance specification
• an EHR specification
• a conformance or conformance testing metric
• an exercise in creating a definition for an EHR or EHR-S
It is important to note that the EHR-S Function Model does not include a discussion of clinical processes or the
interaction of the healthcare actors. However, ISO 13940 Health Informatics – System of Concepts to Support
Continuity of Care, is an international standard that does outline key principles and processes in the provision of
healthcare. It is recommended that users of the EHR-S FM refer to this standard for clinical processes that EHR
systems support.
This EHR-S Functional Model package includes both Reference and Normative sections. Table 1 explains the
differences between Reference and Normative sections.Each section within this document is clearly labeled "Normative" if it is normative. For example, in section 5
(Overview) section 5.3 is normative. In section 7, Conformance Clause; sections 7.1 through 7.6 are normative.
In the external Annex A, Function List, the Function ID, Function Name, Function Statement, and Conformance
Criteria components are Normative in this Functional Model.

This document reviews the structural changes that have been precipitated by the COVID-19 pandemic in Remote Connected Care and Mobile Health (RCC-MH). The impact of the COVID-19 pandemic on care settings such as home and community care, acute care and outpatient care are reviewed discussing how well these healthcare environments were prepared to address the encountered connectivity challenges from a standards point of view. The current standards landscape is reviewed and gaps are identified leading to recommendations for future standards work.

The main objective of this WI is to define a SIRI Passenger Real-Time Information European profile:
•   To identify a minimum subset of SIRI with codification rules and constraints for a European level plug and play exchange of real-time passenger information data between organisations at a European level
•   To reflect already existing NeTEx profiles defined at national level (Norway, France, Sweden, etc.).
•   To maintain a relevant real-time information dataset, as small and simple as possible, to ensure interoperability is maximised while at the same time enabling exchange of supplementary national real-time data that will not interfere with the core international dataset
•   To complement the EPIP (NeTEx European Passenger Information Profile) with real-time passenger information
•   To establish quality assessment procedures for implementing validation and quality assessment tools - including compliance checking rules - necessary to fulfil the requirement of the Commission
This profile will complement the NeTEx Passenger information profile and NeTEx Accessibility profile (under drafting) in order to get a set of consistent European profiles fulfilling the requirements of the Priority Action "A" of the ITS Directive.

This document specifies the test suite structure (TSS) and test purposes (TP) to evaluate the conformity of on-board equipment (OBE) and roadside equipment (RSE) to ISO 13141.
It provides a basis for conformance tests for dedicated short-range communication (DSRC) equipment to support interoperability between different equipment supplied by different manufacturers.
ISO 13141 specifies requirements for the localization augmentation communication (LAC) interface level, but not for the OBE or RSE internal functional behaviour. Consequently, tests regarding OBE and RSE functional behaviour remain outside the scope of this document.

This part 8 specifies the physical layer of an onboard data transmission bus between the different equipment for service operations and monitoring of the fleet. This applies to equipment installed on board vehicles that are operating as part of a public transport network, i.e. in operation under public service contracts. This equipment includes operation aid systems, automatic passenger information systems, fare collection systems, etc.
The use of IEEE 802.11 Wireless LAN communications is excluded from the scope of this Technical Specification; its use is not recommended for the service-based approach of CEN/TS 13149.
Equipment directly related to the safety-related functioning of the vehicle (propulsion management, brake systems, door opening systems, etc.) are excluded from the scope of this Technical Specification and are dealt with in other standardization bodies. Interfaces to such equipment or safety-critical networks can be provided through dedicated gateways.
This document covers the following:
—   The link between equipment inside vehicles consisting of one carriage only, e.g. buses and trolleybuses, as well as a set of carriages, e.g. trams and trains;
—   The Physical Layer for IP-communication networks onboard PT vehicles;
—   The cables, connectors and other equipment including pin assignment and environmental requirements.
This document specifies wired communication networks onboard PT vehicles which are based on the Ethernet specification ISO/IEC/IEEE 8802-3-10 Base T, 100 Base Tx and 1000 Base T.

This document specifies:
—    the interfaces between electronic fee collection (EFC) back-office systems for vehicle-related transport services, e.g. road user charging, parking and access control;
—    an exchange of information between the back-office system of the two roles of service provision and toll charging, e.g.:
—   charging-related data (toll declarations, billing details, payment claims, payment announcements),
—   administrative data (trust objects, EFC context data, etc.), and
—   confirmation data;
—    transfer mechanisms and supporting functions;
—    information objects, data syntax and semantics.
This document is applicable for any vehicle-related toll service and any technology used for charging.
The data types and associated coding related to the data elements described in Clause 6 are specified in Annex A, using the abstract syntax notation one (ASN.1) according to ISO/IEC 8824-1.
This document specifies basic protocol mechanisms over which implementations can specify and perform complex transfers (transactions).
This document does not specify, amongst others:
—    any communication between TC or TSP with any other involved party;
—    any communication between elements of the TC and the TSP that is not part of the back-office communication;
—    interfaces for EFC systems for public transport;
—    any complex transfers (transactions), i.e. sequences of inter-related ADUs that can possibly involve several APDU exchanges;
—    processes regarding payments and exchanges of fiscal, commercial or legal accounting documents;
—    definitions of service communication channels, protocols and service primitives to transfer the APDU.

This document:
—     specifies communication service parameters presented by ITS station (ITS-S) application processes to the ITS-S management in support of automatic selection of ITS-S communication profiles in an ITS station unit (ITS-SU);
—     specifies related procedures for the static and dynamic ITS-S communication profile selection processes at a high functional level;
—     provides an illustration of objectives used to estimate an optimum ITS-S communication profile.

This document:
—     describes the functionality of a "local dynamic map" (LDM) in the context of the "bounded secured managed domain" (BSMD);
—     specifies:
—    general characteristics of LDM Data Objects (LDM-DOs) that can be stored in an LDM, i.e. information on real objects such as vehicles, road works sections, slow traffic sections, special weather condition sections, which are as a minimum requirement location-referenced and time-referenced;
—    service access point functions providing interfaces in an ITS station (ITS-S) to access an LDM for:
—     secure add, update and delete access for ITS-S application processes;
—     secure read access (query) for ITS-S application processes;
—     secure notifications (upon subscription) to ITS-S application processes;
—     management access:
—     secure registration, de-registration and revocation of ITS-S application processes at LDM;
—     secure subscription and cancellation of subscriptions of ITS-S application processes;
—    procedures in an LDM considering:
—     means for maintaining the content and integrity of the data store;
—    mechanisms supporting several LDMs in a single ITS station unit.

This document defines requirements and provides guidance on:
•   capturing of facial images to be used for verification or identification purposes in applications based on reference images in identity or similar documents and traveller or visa databases;
•   capturing of fingerprint images to be used for verification or identification purposes in applications based on reference images in identity or similar documents and traveller or visa databases;
•   data quality maintenance for biometric data captured by/for verification or identification applications;
•   data authenticity maintenance for biometric data captured by/for verification or identification ap-plications.
This document addresses the following aspects which are specific for biometric data capturing:
•   biometric data quality and interoperability assurance;
•   data authenticity assurance;
•   morphing and other presentation attacks and biometric data injection attacks;
•   accessibility and usability;
•   recognition algorithms and their evaluation;
•   privacy and data protection;
•   optimal process design.
The following aspects are out of scope:
•   other aspects of IT security;
•   data capturing for ID document enrolment purposes, e.g. passport or ID card enrolment.

This document specifies the test suite structure (TSS) and test purposes (TPs) for evaluation of on-board equipment (OBE) and roadside equipment (RSE) to EN 15509.
Normative Annex A presents the test purposes for the OBE.
Normative Annex B presents the test purposes for the RSE.
Normative Annex C provides the protocol conformance test report (PCTR) proforma for OBE.
Normative Annex D provides the PCTR proforma for RSE.

This TS provides requirements and ISO/IEC 17065 interpretations for Conformity Assessment Bodies (CABs) assessing Cloud Services
This TS is intended to be used by the National Accreditation Bodies (NABs), as well as CABs.

ISO/IEC 15459-3:2014 specifies the common rules applicable for unique identification that are required to ensure full compatibility across different identities.

ISO/IEC 15459-1:2014 specifies a unique string of characters for the identification of individual transport units. The character string is intended to be represented in a bar code label or other AIDC media attached to the entity to meet management needs. To address management needs, different types of entities are recognized in the various parts of ISO/IEC 15459, which allows different requirements to be met by the identities associated with each type.
The rules for the unique identification for individual transport units, to identify physical logistical transfers, with the identity relevant for the duration of one or more items in the load being held or transported as part of that load, are defined and supported by example.

ISO/IEC 15459-5:2014 specifies a unique string of characters for the identification of individual returnable transport items (RTIs). The character string is intended to be represented in a bar code label or other automatic identification and data capture (AIDC) media attached to the item to meet management needs. To address management needs, different classes of identities are recognized in the various parts of ISO/IEC 15459, which allows different requirements to be met by the identities associated with each class.  
The rules for the identification of RTIs, with the identity being relevant for the complete lifecycle of the item, are defined and supported by example.

ISO/IEC 15459-6:2014 specifies a unique string of characters for the identification of groupings of products, product packages, transport units and items. The character string is intended to be represented in a linear bar code symbol and two-dimensional symbol or other automatic identification and data capture (AIDC) media attached to the entity to meet management needs and/or regulatory needs (e.g. customs clearance). To address these needs, different types of identifiers are recognized in the various parts of ISO/IEC 15459, which allows different requirements to be met by the unique identifiers associated within the context of the specific parts of ISO/IEC 15459.
The unique identifiers for grouping of products, product packages, transport units and items enables grouping by type, characteristics, order, manufacturing, quality, location, movement, etc. to be uniquely identified. It is possible to use with other unique individual identifiers defined in other parts of ISO/IEC 15459. Encoding these unique identifiers in a data carrier enables information about the item processing to be clearly identified.

ISO/IEC 15459-4:2014 specifies a unique string of characters for the identification of individual products and product packages. The character string is intended to be represented in a linear bar code symbol or two-dimensional symbol or other automatic identification and data capture (AIDC) media attached to the entity to meet management needs. To address management needs, different classes of identities are recognized in the various parts of ISO/IEC 15459, which allows different requirements to be met by the identities associated with each class.  
The rules for the identification of an individual occurrence of a product or product package, understood to mean the layers zero and one defined in ISO 17367 and ISO 17366, respectively, are defined and supported by examples.

This document specifies the test suite structure (TSS) and test purposes (TPs) for evaluating the conformity of on-board equipment (OBE) and roadside equipment (RSE) to ISO 12813.
It provides a basis for conformance tests for dedicated short-range communication (DSRC) OBE and RSE to support interoperability between different equipment supplied by different manufacturers.
ISO 12813 specifies requirements for the compliance check communication (CCC) interface level, but not for the OBE or RSE internal functional behaviour. Consequently, tests regarding OBE and RSE functional behaviour remain outside the scope of this document.

ISO/IEC 15459-2:2015 specifies the procedural requirements to maintain identities and outlines the obligations of the Registration Authority and Issuing Agencies.
ISO/IEC 15459-2:2015 excludes those entities where ISO has designated Maintenance Agencies or Registration Authorities to provide identity and/or identifier schemes. It does not apply to:
freight containers, because their unique coding is specified in ISO 6346, Freight containers - Coding, identification and marking;
vehicles, because their unique identification is specified in ISO 3779, Road vehicles - Vehicle identification number (VIN) - Content and structure;
car radios, because their unique identification is specified in ISO 10486, Passenger cars - Car radio identification number (CRIN).  
The exclusion also applies to ISO 2108, Information and documentation - International standard book number (ISBN), and ISO 3297, Information and documentation - International standard serial number (ISSN).

The management of electronic transport regulations (METR) provides a means for METR users to obtain trustworthy, authoritative, machine-interpretable, publicly available and transport-related information for the use of the road network, in order to provide safer and more efficient, sustainable, comfortable, and equitable transport services.
The scope of METR includes both rules that are relatively static (e.g. static speed limits) as well as those that are dynamic (e.g. variable speed limits, signalized intersections). Where appropriate, METR incorporates existing documents (e.g. ISO/TS 19091 for signalized intersections).
This document defines terms specific to the ISO 24315 series on the management of electronic transport regulations.

This document specifies a unified logical data model based on available existing dynamic information standards. The data has precise relative location references to be linked with ISO/TS 22726-1 which specifies the architecture and the logical data model of static map data for connected and automated driving applications. Dynamic event data comes from external systems and has been defined and specified independently by existing standards. Therefore, the logical data model in this document is formed to synthesize contents referring to other standards.

In respect of operating requirements specified in EN 16072, this document specifies adaptations to enable the provision of eCall for powered two-wheel vehicles.
As with the existing provisions for eCall for category M1/N1 vehicles, these are specified within the paradigm of being OEM-fit equipment supplied with new vehicles.
This document includes only the requirements for category L1 and L3 P2WV (vehicle based) with the exception of L1e-A (powered cycle), although other documents can subject other ‘L’ subcategories to use this document. Other documents can be prepared for other UNECE category ‘L’ variants.
The requirements herein relate only to the provision of pan-European eCall and does not provide requirements for third party service provision of eCall. Other than in the 112-eCall using IMS over packet switched networks paradigm, which involves a direct call from the vehicle to the most appropriate PSAP, third party service provision involves the support of an intermediary third-party service provider before the call is forwarded to the PSAP.
The provision of eCall for vehicles via the aftermarket (post sales and registration), and the operational requirements for any such aftermarket solution, will be the subject of other work.

The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate the notification of a traffic accident, wherever in Europe, with the same technical standards and the same quality of services objectives by using ‘Public Land Mobile Networks’(PLMN), which supports the European pre-assigned emergency destination address (see normative references) and to provide a means of manually triggering the notification of an incident.
This document specifies the general operating requirements and intrinsic procedures for in-vehicle emergency call (eCall) services in order to transfer an emergency message from a vehicle to a Public Safety Answering Point (PSAP) in the event of a crash or emergency, via an eCall communication session and to establish a voice channel between the in-vehicle equipment and the PSAP.
Private third party in-vehicle emergency supporting services can also provide a similar eCall function by other means. The provision of such services are defined in EN 16102, and are outside the scope of this document.
The communications protocols and methods for the transmission of the MSD are not specified in this document.
This document specifies the operating requirements for an eCall service. An important part of the eCall service is a Minimum Set of Data (MSD). The operating requirements for the MSD are determined in this document, but the form and data content of the MSD is not defined herein. A common European MSD is determined in EN 15722.
This document does not specify whether eCall is provided using embedded equipment or other means (for example in the case of aftermarket equipment).

The proposed Part 13 will specify a DATEX II platform-independent model for expression of intelligent transport system device status and fault data. It will follow the EN 16157-1 methodology and reuse common concepts from EN 16157-2 and EN 16157-7.
It will define a UML model with a corresponding data dictionary and XML Schema.
The model will define a device publication which identifies static data, a device status publication, and a device faults publication.
Devices in scope are any that participate in intelligent transport systems.
This specification may be used in system-to-system exchanges about device status and faults, for example a traffic management system that performs operational control of devices may provide information about the status and faults of those devices to a separate technology status and fault management system.

This document contains guidelines to be used in the process of drafting requirements of cybersecurity certification schemes for sectoral ICT services and systems. It includes all steps necessary to define, implement and maintain such requirements.

This document specifies requirements for the integration of industrial robot applications and industrial robot cells. The following are addressed:
—     the design, integration, commissioning, operation, maintenance, decommissioning and disposal;
—     integration of machines and components;
—     information for use for the design, integration, commissioning, operation, maintenance, decommissioning and disposal.
This document is not applicable to the following uses and applications of industrial robots:
—     underwater;
—     law enforcement;
—     military (defence);
—     airborne and space, including outer space;
—     medical;
—     healthcare of a person;
—     prosthetics and other aids for the physically impaired;
—     service robots, which provide a service to a person and as such the public can have access;
—     consumer products, as this is household use to which the public can have access;
—     lifting or transporting people;
—     multi-purpose lifting devices or machinery, e.g. cranes, forklift trucks.
NOTE            Applications for the automation of laboratories are not considered as medical or healthcare of a person.
This document deals with the significant hazards, hazardous situations or hazardous events when used as intended and under specified conditions of misuse which are reasonably foreseeable by the integrator.
This document provides basic requirements for industrial robot applications, but does not cover the hazards related to the following:
—     emission of airborne noise;
—     severe conditions (e.g. extreme climates, freezer use, strong magnetic fields) outside of manufacturer’s specifications;
—     underground use;
—     use that has hygienic requirements;
—     processing of any material (e.g. food, cosmetics, pharmaceutical, metal);
—     use in nuclear environments;
—     use in potentially explosive environments;
—     mobility when robots or manipulators are integrated with driverless industrial trucks;
—     mobility when robots or manipulators are integrated with mobile platforms;
—     use in environments with hazardous ionizing and non-ionizing radiation levels;
—     hazardous ionizing and non-ionizing radiation;
—     handling loads the nature of which could lead to dangerous situations (e.g. molten metals, acids/bases, radiating materials);
—     when the public or non-working adults have access.
Emission of acoustic noise could be identified to be a significant hazard, but emission of noise is not covered in this document.

This document describes:
-   the rationale for building customisation supporting business cases that are specific to their business environment while maintaining organisational and semantic interoperability with the TC 440 specifications;
-   the difference between Usage specification and Extension specification;
-   a methodology on how to define customisations on:
-   BII Transaction specification,
-   Business rules,
-   Code lists;
-   how to claim compliance or conformance to a customisation of a TC 440 specification;
-   the connection to the eProcurement Ontology project.
This specification does not describe the detailed process of building an extension.

This document specifies requirements for the inherently safe design, risk reduction measures and information for use of robots for an industrial environment.
This document addresses the robot as an incomplete machine.
This document is not applicable to the following uses and products:
—     underwater;
—     law enforcement;
—     military (defence);
—     airborne and space robots, including outer space;
—     medical robots;
—     healthcare robots;
—     prosthetics and other aids for the physically impaired;
—     service robots, which provide a service to a person and as such where the public can have access;
—     consumer products, as this is household use to which the public can have access;
—     lifting or transporting people.
NOTE 1        Requirements for robot integration and robot applications are covered in ISO 10218-2:2025.
NOTE 2        Additional hazards can be created by robot applications (e.g. welding, laser cutting, machining). These hazards are addressed during robot application design. See ISO 10218-2:2025.
This document deals with the significant hazards, hazardous situations or hazardous events when used as intended and under specified conditions of misuse which are reasonably foreseeable by the manufacturer.
This document does not cover the hazards related to:
—     severe conditions (e.g. extreme climates, freezer use, strong magnetic fields) outside of manufacturer’s specifications;
—     underground use;
—     use that has hygienic requirements;
—     use in nuclear environments;
—     use in potentially explosive environments;
—     mobility when robots or manipulators are fixed to or part of driverless industrial trucks;
—     mobility when robots or manipulators are fixed to or part of mobile platforms;
—     use in environments with ionizing and non-ionizing radiation levels;
—     hazardous ionizing and non-ionizing radiation;
—     handling loads the nature of which can lead to dangerous situations (e.g. molten metals, acids/bases, radiating materials);
—     handling or lifting or transporting people;
—     when the public, all ages or non-working adults have access (e.g. service robots, consumer products).
Noise emission is generally not considered a significant hazard of the robot alone, and consequently noise is excluded from the scope of this document.
This document is not applicable to robots that are manufactured before the date of its publication.

The Technical Specification will be adapted in the following way:
•   OJP will be realigned with the latest Transmodel version and NeTEx issues, where appropriate (e.g.
        New Modes)
•   The integration of new modes especially the conceptual equivalency to major multi-modal standards
        shall be studied and if necessary, adaptions to OJP occur. The idea is to study OSDM, TOMP, TRIAS
        and GBFS/GOFS. The interactions should be smooth. Interaction between OJP and distribution
        features will be settled.
•   OJP is extended as far into the distribution area as it is considered a good idea. For the actual
        booking and purchase steps, OSDM, TOMP, TRIAS and/or GOFS are to be used. The line we think to
        draw is: booking. OJP should not transfer personalized information. This results in the following
        proposed adaptions to fit OJP into a full MaaS roaming environment:
o   An availability request (with response)
o   Token/id handling for trips and trip legs (for hand-over) and pushed information during trips. We will
        need to model bookable items on some level.
o   OJPFare needs to be extended/adapted.
o   TripInfoRequest and -Response need to be updated to reflect, information about trips and trip legs
        and not only vehicle and journey.
•   All work prepared under the heading OJP 1.1 will be finalised.
•   EPIAP (Accessibility) minimal profile will be used to verify that the trip planning can make use of it.
•   The provision of an OpenAPI and REST/JSON derived directly from the XSD shall be studied
        (eventually using a converter).

This document specifies the syntax and semantics of data objects in the field of electronic fee collection (EFC). The definitions of data types and assignment of semantics are provided in accordance with the abstract syntax notation one (ASN.1) technique, as specified in ISO/IEC 8824-1. This document defines:
—     ASN.1 (data) types within the field of EFC;
—     ASN.1 (data) types of a more general use that are used more specifically in standards related to EFC.
This document does not seek to define ASN.1 (data) types that are primarily related to other fields that operate in conjunction with EFC, such as cooperative intelligent transport systems (C-ITS), the financial sector, etc.

This document specifies the abstract data model for breeder document data and the specific encodings of this abstract data model used in the CEN breeder document framework.
The abstract data model is a semantic description of the birth, marriage / partnership, and death certificate data, independently from their specific encoding. This abstract data model is extensible for further standardized and proprietary data of birth, marriage / partnership, and death certificates as well as for other types of breeder documents.
This abstract data model is technology agnostic, i.e. it is applicable for paper-based, server-based, and hardware-based breeder documents as well as further breeder document designs and technologies.
The specific encodings of this abstract data model comprise the encodings to be used for the machine readable technologies specified in part 3 of the framework as well as the encoding of human readable breeder document data. These encodings are used in the birth, marriage / partnership, and death certificate profiles specified in part 4 of the framework.