ITC - Information technology

This International Standard provides a model and framework for integrating different standards as well
as systems based on those specifications by supporting the use case specific identification and
consistent, formal representation including constraints of necessary components and their
relationships. It facilitates analysis and improvement of specifications under revision as well as the
design of new projects. The approach is future proof due to its scientific soundness, based on systems
theory, knowledge representation and knowledge management via ontology development and
harmonization, that way supporting advanced interoperability between dynamic, multi-domain systems
through knowledge and skills sharing in the context of intelligent cooperation. The approach is
successfully deployed in several standards such as ISO 22600, ISO 21298, ISO 13606, ISO 12967,
ISO 13940 and ISO 13972 (both under way), but also in most of the HL7 security specifications. The
intended International Standard adopts objectives, content and presentation style used in other
foundational standards such as ISO/IEC 10746, this way qualifying for a potential ISO/IEC 10746-6.

This document specifies requirements and provides guidance for establishing, implementing,
maintaining and continually improving a Privacy Information Management System (PIMS) in the form
of an extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy management within the context of the
organization.
This document specifies PIMS-related requirements and provides guidance for 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, which are PII controllers and/or PII
processors processing PII within an ISMS.

The ALERT-C protocol is designed to provide mostly event-oriented road end-user information
messages.
This document specifies the messages which are presented to the user in accordance with a set of
general requirements. It defines the message structure and content and its presentation to the end-user.
The message management component of this document describes the message management functions
of RDS-TMC. The ALERT-C protocol distinguishes between user messages and system messages. User
messages are those potentially made known to the end-user, as defined in Clause 5. System messages
are of use only to the RDS-TMC terminal, for message management purposes.
RDS-TMC information comprises both ‘system information’ and ‘user messages’. System information
relates to the TMC service and details the parameters that the terminal needs to be able to find,
identify and decode the TMC information. System information is transmitted in type 3A groups and in
type 8A groups.
User messages contain the details of the traffic events; these may use one or more type 8A groups. Most
messages may be transmitted using a single type 8A group, however messages with more detail (e.g.
diversion advice) may use up to a total of five, type 8A groups.
The transmission component of this document conveys the messages over-air. The ALERT-C protocol,
used by RDS-TMC, has the fundamental approach of aiming to code most messages entirely within a
single RDS group.
The ALERT-C Event List, which contains all event descriptions, is described in ISO 14819‑2.

This document describes tests which verify on-board unit (OBU) conformance of functions and data
structures implementations, as defined in the implementation conformance statement (ICS) based on
ISO 14906 for EFC applications.
This document defines tests for assessing OBU conformance in terms of :
— basic dedicated short-range communication (DSRC) L7 functionality,
— EFC application functions,
— EFC attributes (i.e. EFC application information),
— the addressing procedures of EFC attributes and (hardware) components,
— the EFC transaction model, which defines the common elements and steps of any EFC transaction, and
— the behaviour of the interface so as to support interoperability on an EFC-DSRC application
interface level.
After the tests of isolated data items and functions (C.2 to C.4), an example is given for testing a
complete EFC transaction (C.3). Although this document defines examples of test cases for DSRC
and EFC functionality (see Annex C), it does not intend to specify a complete test suite for a certain
implementation. To compose a test suite for a specific EFC implementation, the test cases can be
modified and new test cases can be defined and added in order for the conformance test suite to be
complete. It can be useful to consider the following when defining a complete test suite:
— small range: “exhaustive testing” of critical interoperability/compatibility features,
— large range: testing of boundaries and random values, and
— composite types: testing of individual items in sequence or parallel.
This document does not define tests which assess:
— performance,
— robustness, and
— reliability of an implementation.
NOTE 1 ISO 14907-1 defines test procedures that are aimed at assessing performance, robustness and
reliability of EFC equipment and systems.
NOTE 2 The ISO/IEC 10373 series defines test methods for proximity, vicinity, integrated circuit(s) cards and
related devices that can be relevant for OBUs which support such cards.
Annex D provides an informative overview of Japanese on-board equipment (OBE) conformance tests
which are based on the ISO 14907 series, in order to illustrate how these can be applied in practice.

This document specifies a global transport data management (GTDM) framework composed of
— global transport basic data model,
— global transport access control data model,
— global transport function monitor data model, and
— sensor and control network data model
to support data exchange between applications.
This document defines standardized data classes in a Global Transport Data Format (GTDF), and the
means to manage them.
Application and role-based access control to resources in GTDF are specified in accordance with
IEEE 1609.2 certificates.
This document specifies GTDM as an ITS-S capability which is an optional feature (ITS-capabilities are
specified in ISO 24102-6).
The GT access control (GTAC) data model specifies access permissions to data and function control by
defining role-based mechanisms.
The GT function monitor (GTFM) data model specifies a configuration method to generate a flow logic
for monitoring purposes, e.g. observing data parameters with respect of a defined limit.

ISO 14819-1 describes the ALERT-C protocol concept and message structure used to achieve densely
coded messages to be carried in the RDS-TMC feature. This document specifies the ‘Events List’ to be
used in coding those messages.

This European Standard (EN 16157 series) specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the modelling approach, data content, data structure and relationships.
This European Standard is applicable to:
-   Traffic and travel information which is of relevance to road networks (non-urban and urban),
-   Public transport information that is of direct relevance to the use of a road network (e.g. road link via train or ferry service),
-   Traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).
This European Standard establishes specifications for data exchange between any two instances of the following actors:
-   Traffic Information Centres (TICs),
-   Traffic Control Centres (TCCs),
-   Service Providers (SPs),
Use of this European Standard may be applicable for use by other actors.
This European Standard series covers, at least, the following types of informational content:
-   Road traffic event information – planned and unplanned occurrences both on the road network and in the surrounding environment,
-   Operator initiated actions,
-   Road traffic measurement data, status data, and travel time data,
-   Travel information relevant to road users, including weather and environmental information,
-   Road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 series specifies the informational structures, relationships, roles, attributes and associated data types required for publishing variable message sign information within the Datex II framework. This is specified in two publications, a DATEX II VMS Table Publication sub-model and a VMS Publication sub-model, which are part of the DATEX II platform independent model, but this part excludes those elements that relate to:
-   location information which are specified in EN 16157-2,
-   common information elements, which are specified in EN 16157-7,
-   situation information which are specified in EN 16157-3.
The VMS Table Publication supports the occasional exchange of tables containing generally static reference information about deployed VMS which enable subsequent efficient references to be made to pre-defined static information relating to those VMS. The VMS Publication supports the exchange of the graphic and textual content of one or several VMS plus any status information on device configuration that aid the comprehension of the informational content. This content is potentially subject to rapid change.
These publications are not intended to support the control or configuration of VMS equipment. Each is part of the DATEX II platform independent model.

This document specifies location referencing rules to address the specific requirements of Traffic Message Channel (TMC) systems, which use abbreviated coding formats to provide traffic and travel information (TTI) messages over mobile bearers (e.g. GMS, DAB) or via exchange protocols like DATEX
II. In particular, the rules address the Radio Data System-Traffic Message Channel (RDS-TMC), a means
of providing digitally-coded TTI to travellers using a silent data channel on FM radio stations, based on the ALERT-C protocol.

This document serves as a guideline explaining the concept of hybrid communications and support
functionalities for Cooperative ITS services deployed in conformance with the ITS station architecture
and related Cooperative ITS standards.

This document specifies a methodology to define ITS-S communication profiles (ITS-SCPs) based on standardized communication protocols to interconnect trusted devices. These profiles enable secure information exchange between such trusted devices, including secure low-latency information exchange, in different configurations. The present document also normatively specifies some ITS-SCPs based on the methodology, yet without the intent of covering all possible cases, in order to exemplify the methodology.
Configurations of trusted devices for which this document defines ITS-SCPs include:
a) ITS station communication units (ITS-SCU) of the same ITS station unit (ITS-SU), i.e. station-internal communications;
b) an ITS-SU and an external entity such as a sensor and control network (SCN), or a service in the Internet;
c) ITS-SUs.
Other ITS-SCPs can be specified at a later stage.
The specifications given in this document can also be applied to unsecured communications and can be applied to groupcast communications as well.

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 guidelines on security applicable in Intelligent Transport Systems (ITS) related
to communications and data access.
In particular, this document provides analyses and best practice content for secure ITS connectivity
using ISO/TS 21177.
This document analyses and identifies issues related to application security, access control, device
security and PKI for a secure ITS ecosystem.

This document
— describes standardization activities related to C-ITS on a global level by major standard development
organizations (SDOs);
— explains the various purposes of deliverables from SDOs and introduces a classification scheme of
such documents;
— describes methods on how C-ITS services are presented and performed;
— identifies an approach for C-ITS releases and exemplifies this approach;
— presents a list of standards (Bibliography) with special relevance for C-ITS.

This Recommendation | International Standard gives guidelines for information security controls applicable to the
provision and use of cloud services by providing:
– additional implementation guidance for relevant controls specified in ISO/IEC 27002;
– additional controls with implementation guidance that specifically relate to cloud services.
This Recommendation | International Standard provides controls and implementation guidance for both cloud service
providers and cloud service customers.

This document gives guidelines for the development of multi-operator/multi-service interoperable
public surface (including subways) transport fare management systems (IFMSs) on a national and
international level.
This document is applicable to bodies in public transport and related services which agree that their
systems need to interoperate.
This document defines a conceptual framework which is independent of organizational and physical
implementation. Any reference within this document to organizational or physical implementation is
purely informative.
This document defines a reference functional architecture for IFMSs and establishes the requirements
that are relevant for ensuring interoperability between several actors in the context of the use of
electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as:
— management of media,
— management of applications,
— management of products,
— security management, and
— certification, registration, and identification.
This document defines the following main elements:
— identification of the different sets of functions in relation to the overall IFMS and services and media
from non-transport systems which interact with fare management systems;
— a generic model of an IFMS describing the logical and functional architecture and the interfaces
within the system, with other IFMSs and with services and media from non-transport systems;
— use cases describing the interactions and data flows between the different sets of functions;
— security requirements.
In its annexes, this document provides a framework for mobility platforms that integrate fare
management and travel information for inter- and multimodal travel (see Annex A). It also elaborates
on specific subjects covered in document and offers some national examples with regard to IFMS
implementations (see Annex B, Annex C, Annex D and Annex E).
This document does not define:
— the technical aspects of the interface between the medium and the medium access device;
— the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the medium and the medium access device are proposed by other
standardization committees.
— the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).

This standard 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 International Standard specifies requirements and provides guidance for bodies providing
audit and certification of an information security management system (ISMS), in addition to the
requirements contained within ISO/IEC 17021-1 and ISO/IEC 27001. It is primarily intended to support
the accreditation of certification bodies providing ISMS certification.
The requirements contained in this International Standard need to be demonstrated in terms of
competence and reliability by any body providing ISMS certification, and the guidance contained in
this International Standard provides additional interpretation of these requirements for any body
providing ISMS certification.
NOTE This International Standard can be used as a criteria document for accreditation, peer assessment or
other audit processes.

ISO/IEC 4909:2006 establishes specifications for financial transaction cards using track 3 and is intended to permit interchange based on the use of magnetic stripe encoded information. It specifies the data content and physical location of read/write information on track 3 and is to be used in conjunction with the relevant parts of ISO/IEC 7811 and ISO/IEC 7812.
ISO/IEC 4909:2006 recognizes the need for formats of track 3 which can be used independently of, or in conjunction with, track 2 as defined in ISO/IEC 7813. This approach is intended to permit the greatest degree of flexibility within the financial community in facilitating international interchange.
Using track 3 in conjunction with track 2 is a mode of operation in both on-line and off-line interchange environments. This mode of operation requires that the original encoded data on track 2 be read; the data on track 3 be read; and, if update is required, all the data on track 3 be rewritten.
Independent use of track 3 is an alternative mode of operation permitting both on-line interchange and off-line interchange based on mutual agreement between interested parties. It requires reading only of the data on track 3 and, if update is required, the rewriting of all the data on track 3.

The RFID tag location, tag data content and functional requirements have been developed for application on the main line railway networks. Other networks (such as metro) may apply this standard but are outside of its scope.
This document contains:
-   a description of the RFID tag installation location;
-   a description of the RFID tag data content;
-   a description of the functional requirements in relation to the RFID tag track side reading performance.

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 is also independent from, and does not imply either explicitly or implicitly, any specific
technological solution or product for its deployment. Accordingly, the formalization of the architecture
according to two lower levels of the ODP reference model, the engineering and technology viewpoints,
is outside the scope of this document.
The language and notations used here for specifying the architecture are based on UML (Unified
Modeling Language) complemented by case studies and other paradigms widely utilized by other
standards in health informatics. The level of the specification is complete and non-ambiguous enough to
allow its implementation into the specific physical and technological scenarios adopted by the various
healthcare organizations and vendors. Accordingly, methodology formalized by the Engineering and
Technology viewpoints of the RM ODP Reference Model can be followed for the implementation.

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 provides an EETS gap analysis with the aim to identify the need for new or updated standards to provide an enhanced support of the recast of the EU EETS legislation [29], [31], [32].

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 defines requirements on the compliance check communication (CCC) interface level, but
not for the RSE or OBE internal functional behaviour. Consequently, tests regarding OBE and/or RSE
functional behaviour remain outside the scope of this document.

This document specifies the in-vehicle information (IVI) data structures that are required by different
intelligent transport system (ITS) services for exchanging information between ITS Stations (ITS-S).
A general, extensible data structure is specified, which is split into structures called containers to
accommodate current-day information. Transmitted information includes IVI such as contextual
speed, road works warnings, vehicle restrictions, lane restrictions, road hazard warnings, locationbased
services, re-routing. The information in the containers is organized in sub-structures called data
frames and data elements, which are described in terms of its content and its syntax.
The data structures are specified as communications agnostic. This document does not provide the
communication protocols. This document provides scenarios for usage of the data structure, e.g. in case
of real time, short-range communications.

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 specifies a generic position, velocity and time (PVT) service. It further specifies
the PVT service within the ITS station (ITS-S) facilities layer (ISO 21217) and its interface to other
functionalities in an ITS-S such as:
— ITS-S application processes (ITS-S-APs), defined in ISO 21217;
— the generic facilities service handler (FSH) functionality of the ITS station facilities layer, defined in
ISO/TS 17429.
This document specifies:
— a PVT service which, dependent on a specific implementation, uses a variety of positioning-related
sources such as global navigation satellite systems (GNSSs, e.g. GALILEO, GLONASS and GPS),
roadside infrastructure, cellular infrastructure, kinematic state sensors, vision sensors;
— a PVT service which merges data from the above-mentioned positioning-related sources and
provides the PVT output parameters (carrying the PVT information) including the associated
quality (e.g. accuracy);
— how the PVT service is integrated as an ITS-S capability of the ITS station facilities layer;
— the interface function calls and responses (Service Access Point – service primitives) between the
PVT ITS-S capability and other functionalities of the ITS station architecture;
— optionally, the PVT service as a capability of the ITS-S facilities layer; see ISO 24102-6;
— an ASN.1 module C-itsPvt, providing ASN.1 type and value definitions (in Annex A);
— an implementation conformance statement proforma (in Annex B), as a basis for assessment of
conformity to this document.
NOTE It is outside the scope of this document to define the associated conformance evaluation test
procedures.

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 227031).
— 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.

This document defines an information security framework for all organizational and technical entities
of an EFC scheme and for the related interfaces, based on the system architecture defined in ISO 17573-1.
The security framework describes a set of security requirements and associated security measures.
Annex D contains a list of potential threats to EFC systems and a possible relation to the defined
security requirements. These threats can be used for a threat analysis to identify the relevant security
requirements for an EFC system.
The relevant security measures to secure EFC systems can then be derived from the identified security
requirements.

This project specifies the fifth part of the DATEX II European Standard which deals with the one or more publication sub-model(s) within the DATEX II model that support the exchange of measured and elaborated information.
These publications are intended to support the exchange of informational content from the organisation having the measures and creating elaborated data to other organisations providing ITS services or onward information exchange. It also includes the exchange of static information about measurement sites.
This is specified in three submodels, a DATEX II Measurement Site Table Publication submodel, a DATEX II Measured Data Publication submodel and a DATEX II Elaborated Data Publication submodel.

This document provides an overview of a framework on breeder documents. It introduces the document structure of FprCEN/TS 17489 (all parts) that specifies how citizens retain the control of breeder document data and how they can use them to support identity proofing and verification. Moreover, the framework provides methodologies to assess and increase the level of trust in breeder documents.
This framework specifies methods for:
-   defining physical and logical/digital representations of a secure breeder document (hardware based, paper-based, server-based),
-   securing breeder document processes,
-   linking the document to its legitimate holder.
The following types of breeder documents are in the scope of the framework:
-   birth certificates,
-   marriage and partnership certificates,
-   death certificates.
The following breeder documents management processes including first-time application, later-in-life registration of an identity, and content update (e.g. name-changing) are in the scope of this framework:
-   registration,
-   issuance,
-   renewal,
-   inspection/verification,
-   revocation.
The specification of policies is out of scope.

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

This document defines an additional data concept that may be transferred as an ‘optional additional data concept’ as defined in EN 15722 eCall MSD, that may be transferred from a vehicle to a PSAP in the event of a crash or emergency via an eCall communication session.
The purpose of this document is simply to enable the existing MSD to house multiple OADs. This is achieved by providing a short optional additional data concept, which facilitates the inclusion of multiple additional datasets within the currently defined MSD of 140 bytes (Every OAD still requires its own specification).
This document can be seen as an addendum to EN 15722; it contains as little redundancy as possible.
NOTE 1   The communications media protocols and methods for the transmission of the eCall message are not specified in this document.
NOTE 2   Additional data concepts can also be transferred, and it is advised to register any such data concepts using a data registry as defined in EN ISO 24978. See www.esafetydata.com for an example.

This document specifies the standard data concepts that comprise the "Minimum Set of Data" (MSD) to be transferred from a vehicle to a 'Public Safety Answering Point' (PSAP) in the event of a crash or emergency via an 'eCall' communication transaction.
Optional additional data concepts may also be transferred.
The communications media protocols and methods for the transmission of the eCall message are not specified in this document.

This document specifies the test procedures of electronic fee collection (EFC) roadside equipment (RSE) and on-board equipment (OBE) with regard to the conformance to standards and requirements for type approval and acceptance testing which is within the realm of EFC application specifically.
The scope of this document is restricted to systems operating within the radio emission, electromagnetic
compatibility (EMC) regulations, traffic, and other regulations of the countries in which they are operated.
This document identifies a set of suitable parameters and provides test procedures to enable the proof of a complete EFC system, as well as components of an EFC system, e.g. OBE, related to the defined requirements of an application. The defined parameter and tests are assigned to the following groups of parameters:
— functionality;
— quality;
— referenced pre-tests.
An overview of the tests and parameters provided by this document is given in 5.1 and 5.2.
This document describes procedures, methods and tools, and a test plan which shows the relation between all tests and the sequence of these tests. It lists all tests that are required to measure the performance of EFC equipment. It describes which EFC equipment is covered by the test procedures; the values of the parameters to be tested are not included. It also describes how the tests are to be performed and which tools and prerequisites are necessary before this series of tests can be undertaken.
It is assumed that the security of the system is inherent in the communications and EFC functionality tests, therefore they are not addressed here. All tests in this document provide instructions to evaluate the test results.
This document defines only the tests and test procedures, not the benchmark figures that these are to be measured against. The test procedures defined in this document can be used as input, e.g. by scheme owners, for prototype testing, type approvals, tests of installations and periodic inspections.
Related to a conceptual model of an EFC system, this document relates only to the equipment of the user and the service provider. Any other entities are outside the scope of document.
EFC systems for dedicated short-range communication (DSRC) consist, in principle, of a group of technical components, which in combination fulfil the functions required for the collection of fees by electronic automatic means. These components comprise all, or most, of the following:
— OBE within a vehicle;
— OBE containing the communications and computing sub-functions;
— optional integrated circuit card which may carry electronic money, service rights, and other secured information;
— communication between OBE and RSE based on DSRC;
— equipment for the fee collection at the RSE containing the communications and computing subfunctions;
— equipment for the enforcement at the roadside;
— central equipment for the administration and operation of the system.
The scope of this document relates solely to OBE and RSE and the DSRC interface between OBE and RSE including its functions to perform the fee collection. All the equipment used for enforcement (e.g. detection, classification, localization, and registration) and central equipment are outside the scope of this document.

This European Standard covers the ergonomic layout and usability of keypads. The keypad may consist of numeric, command and function keys and alphanumeric characters. On the basis that keypad layout impacts performance (keying speed, and errors), this European Standard aims to:
-   enhance usability;
-   ensure ease of use through consistency;
-   increase customer confidence;
-   reduce customer error;
-   improve operating time;
-   ensure ergonomic data entry.
This European Standard specifies the arrangement, the number and location of numeric, function and command keys, including placement of alphabetic characters on numeric keys. Design requirements and recommendations are also provided.
This standard applies to all identification card systems with a numeric keypad for use by the public for stationary or non-stationary devices. This standard also covers keypads on touch sensitive devices.

This CEN Technical Specification (TS) contains the mapping between the semantic data model of an electronic invoice (EN 16931-1)
and the following syntax: UN/CEFACT XML Industry Invoice D16B. For each element in the semantic model (including sub-elements
or supplementary components such as Code List identifiers) it is defined which element in the syntax is to be used to contain its
information contents. Any mismatches between semantics, format, cardinality or structure are indicated.
Any rules to be followed when using the specific syntax are stated informally in this TS. Together with this TS a set of validation
artefacts is published, including formalisation of the rules.
In addition, the deliverable shall unambiguously define the code lists and, where applicable, the subset of codes to be used for each
coded element in the model of EN 16931-1 when using the UN/CEFACT XML Industry Invoice D16B syntax as defined in CEN/TS
16931-3-3. The deliverable must guide the user how and where to apply for additions to these code lists. It will be issued as an annex
to the existing text of CEN/TS 16931-3-3:2017

This European Standard establishes a semantic data model of the core elements of an electronic invoice. The semantic model includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross sector and for domestic trade. The semantic model may be used by organizations in the private and the public sector for public procurement invoicing. It may also be used for invoicing between private sector enterprises. It has not been specifically designed for invoicing consumers.
This European Standard complies at least with the following criteria:
-   it is technologically neutral;
-   it is compatible with relevant international standards on electronic invoicing;
-   the application of this standard should comply with the requirements for the protection of personal data of Directive 95/46/EC, having due regard to the principles of privacy and data protection by-design, data minimization, purpose limitation, necessity and proportionality;
-   it is consistent with the relevant provisions of Directive 2006/112/EC [2];
-   it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic invoicing systems;
-   it takes into account the special needs of small and medium-sized enterprises as well as of sub-central contracting authorities and contracting entities;
-   it is suitable for use in commercial transactions between enterprises.

This document provides requirements and recommendations to vendors on the disclosure of
vulnerabilities in products and services. Vulnerability disclosure enables users to perform technical
vulnerability management as specified in ISO/IEC 27002:2013, 12.6.1[1]. Vulnerability disclosure helps
users protect their systems and data, prioritize defensive investments, and better assess risk. The goal
of vulnerability disclosure is to reduce the risk associated with exploiting vulnerabilities. Coordinated
vulnerability disclosure is especially important when multiple vendors are affected. This document
provides:
— guidelines on receiving reports about potential vulnerabilities;
— guidelines on disclosing vulnerability remediation information;
— terms and definitions that are specific to vulnerability disclosure;
— an overview of vulnerability disclosure concepts;
— techniques and policy considerations for vulnerability disclosure;
— examples of techniques, policies (Annex A), and communications (Annex B).
Other related activities that take place between receiving and disclosing vulnerability reports are
described in ISO/IEC 30111.
This document is applicable to vendors who choose to practice vulnerability disclosure to reduce risk
to users of vendors’ products and services.

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 CEN Technical Specification (TS) contains the mapping between the semantic data model of an electronic invoice (EN 16931-1)
and the following syntax: UBL 2.1. For each element in the semantic model (including sub-elements or supplementary components
such as Code List identifiers) it is defined which element in the syntax is to be used to contain its information contents. Any
mismatches between semantics, format, cardinality or structure are indicated.
Any rules to be followed when using the specific syntax are stated informally in this TS. Together with this TS a set of validation
artefacts is published, including formalisation of the rules.
In addition, the deliverable shall unambiguously define the code lists and, where applicable, the subset of codes to be used for each
coded element in the model of EN 16931-1 when using the UBL 2.1 syntax as defined in CEN/TS 16931-3-2. The deliverable must
guide the user how and where to apply for additions to these code lists. It will be issued as an annex to the existing text of CEN/TS
16931-3-2:2017

This document provides requirements and recommendations for how to process and remediate reported potential vulnerabilities in a product or service.
This document is applicable to vendors involved in handling vulnerabilities.

This document specifies the fast service announcement protocol (FSAP) for general purposes in ITS.
It references and supports all features of ISO/TS 16460, especially supporting the service response
message (SRM) and related features in addition to the service announcement message (SAM), which
enables only very basic features.
FSAP supports locally advertised ITS services uniquely identified by an ITS application identifier
(ITS-AID).
This document specifies message formats and related basic protocol procedures by reference to
ISO/TS 16460, and further related protocol requirements for operation of FSAP in the context of an ITS
station specified in ISO 21217.
This document illustrates its relations to service announcement protocols specified by ETSI TC ITS
and IEEE.

This International Standard provides a privacy framework which
- specifies a common privacy terminology;
- defines the actors and their roles in processing personally identifiable information (PII);
- describes privacy safeguarding considerations; and
- provides references to known privacy principles for information technology.
This International Standard is applicable to natural persons and organizations involved in specifying,
procuring, architecting, designing, developing, testing, maintaining, administering, and operating
information and communication technology systems or services where privacy controls are required
for the processing of PII.

The scope of this Recommendation | International Standard is to define guidelines supporting the implementation of
information security controls in telecommunications organizations.
The adoption of this Recommendation | International Standard will allow telecommunications organizations to meet
baseline information security management requirements of confidentiality, integrity, availability and any other relevant
security property.

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.

This document establishes commonly accepted control objectives, controls and guidelines for
implementing measures to protect Personally Identifiable Information (PII) in line with the privacy
principles in ISO/IEC 29100 for the public cloud computing environment.
In particular, this document specifies guidelines based on ISO/IEC 27002, taking into consideration
the regulatory requirements for the protection of PII which can be applicable within the context of the
information security risk environment(s) of a provider of public cloud services.
This document is applicable to all types and sizes of organizations, including public and private
companies, government entities and not-for-profit organizations, which provide information processing
services as PII processors via cloud computing under contract to other organizations.
The guidelines in this document can also be relevant to organizations acting as PII controllers. However,
PII controllers can be subject to additional PII protection legislation, regulations and obligations, not
applying to PII processors. This document is not intended to cover such additional obligations.

This CEN Technical Specification (TS) contains the mapping between the semantic data model of an electronic invoice (EN 16931-1) and the following syntax: UN/EDIFACT INVOIC D16B. For each element in the semantic model (including sub-elements or supplementary componentts sucha as Code List identifiers) it is defined which element in the syntax is to be used to contain its information contents. Any mismatches between semantics, format, cardinality or structure are indicated. Any rules to be followed when using the specific syntax are stated informally in this TS. Together with this TS a set of validation artefacts is published, including formalisation of the rules.

The CEN 13149 series of products concerns on-board data communication systems on public transport vehicles. This series provides for data services that enable open and managed sharing of relevant information.
This document, being Part 11 of the series, specifies a publication service for data provided by the vehicle platform, enabling all on-vehicle services to share a common understanding of the operational activity of the vehicle, based on inputs taken from chassis systems such as the J1939 CAN bus. It covers:
-   the functional scope, i.e. which data the service provides, why, when and how often.
-   the transport protocol, i.e. how the data are transmitted.
-   the service publication, i.e. how the service can be found by other modules or applications
-   the structure of the data, i.e. how the data are structured and how the data elements are named.
This document implements the service framework described in FprCEN/TS 13149-7.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V6 (EN 12896 series) and SIRI (CEN/TS 15531-4/-5 and EN 15531-1/-2/-3) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   Many NeTEx concepts are taken directly from Transmodel; the definitions and explanation of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptions in order to fit the NeTEx context.
Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.
1.3   Compatibility with existing standards and recommendations
Concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train composition and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) - TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (The Netherlands) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.