ISO/TC 215 - Health informatics

This document specifies the categorial structure within the field of traditional Chinese medicine clinical decision support system by defining a set of domain constraints of sanctioned characteristics, each composed of a relationship and an applicable information model. This document is not applicable to Western medicine and Japanese Kampo medicine. It is not applicable to the design and management of artificial intelligence diagnosis and treatment.

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

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

This document defines the components (benchmarks) of capability of terminological resources implementation in healthcare software products, including electronic health record systems. It is intended that these benchmarks form the basis of a maturity model. The document will support analysis of requirements to meet use cases in the implementation of terminological resources in healthcare. This document does not specify requirements for any specific terminological resource. It is intended to provide a basis from which requirements for terminological resources capabilities can be specified in the future. The tooling being used can impact the level of maturity reached but is not covered in detail in this document. Terminological resources include code systems of all types, terminologies, classifications, value sets, and value domains. The impact of tooling (computer–assisted coding, speech recognition, template development) on the capability of the terminological resources is not covered in detail in this document.

This document provides details of the metadata and requirements for quality terms and definitions in health informatics for inclusion in health informatics glossaries. This document does not cover specification of terminological content in systems, such as that represented in terminological resources, such as SNOMED CT, or, ICD. It is limited to concepts represented as terms and definitions included in standards. This document is applicable to the following groups: — Health informatics standards developers and standards development organizations. — Developers, implementers, and managers of health information systems, clinical information systems, and clinical decision support systems. — All users of health information systems clinical data, such as health statisticians, researchers, public health agencies, health insurance providers, health risk organizations, data analysts, and data managers.

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

This document describes a core set of cloud service agreements for customer-oriented health cloud services. This document covers a customer-oriented cloud service agreement that can be used in healthcare organizations and public health centers that use health cloud services. This document defines key characteristics in the health cloud service agreement that are indispensable in providing optimal health/healthcare management functionalities. Privacy and security features are considered outside the scope of this document and are covered in ISO/TR 21332. The purpose of this document is to present matters to be considered (e.g., cloud type, components, key characteristics) by stakeholders involved in the implementation of cloud computing in hospitals or healthcare organizations. The potential users of this document are mainly 1) IT managers of hospitals, 2) hospital management, and 3) cloud service providers and cloud partners that provide services to healthcare institutions.

This document specifies a numbering system and registration procedure for identifying both healthcare application providers and health card holders in order to exchange information through the use of cards issued for healthcare services. This document focuses on the machine-readable cards of ID-1 type defined in ISO/IEC 7810 that are issued for healthcare services provided in a service area that crosses the national borders of two or more countries/areas. This document applies to healthcare data cards where the issuer and the application provider are the same party. This document applies directly, or refers, to existing International Standards for physical characteristics and recording techniques. Security issues follow the requirements of each healthcare data card system.

This document specifies how medical waveforms, such as electrocardiogram, electroencephalogram, spirometry waveform, etc., are described for interoperability among healthcare information systems. This document can be used with other relevant protocols, such as HL7, DICOM®, the ISO/IEEE 11073 series, and database management systems for each purpose. This is a general specification, so specifications for particular waveform types and for harmonization with DICOM®, SCP-ECG, X73, etc. are not given. This document does not include lower layer protocols for message exchange. For example, a critical real-time application such as a patient monitoring system is out of scope and this is an implementation issue.

This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1 – taking the specific needs for HEALTH SOFTWARE into account. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes a common framework for secure HEALTH SOFTWARE LIFE CYCLE PROCESSES. The purpose is to increase the CYBERSECURITY of HEALTH SOFTWARE by establishing certain ACTIVITIES and TASKS in the HEALTH SOFTWARE LIFE CYCLE PROCESSES and also by increasing the SECURITY of SOFTWARE LIFE CYCLE PROCESSES themselves. It is important to maintain an appropriate balance of the key properties SAFETY, effectiveness and SECURITY as discussed in ISO 81001-1. This document excludes specification of ACCOMPANYING DOCUMENTATION contents.

This document defines the configuration rules required for a hierarchical structure, directory naming rules, and content identifiers for files and documents containing healthcare information. Content can be expressed as ISO/HL7 27931:2009 (also known as HL7 Ver2.5) as the data format to store clinical data such as prescriptions, lab results, and disease classifications, but can also include other types of file-type such as XML, CDA, DOC/DOCX, PDF, XLS/XLSX, JPEG, MP4, etc. This document does not address the security and privacy attributes of the healthcare information being stored; these are considered implementation-specific.

This document specifies reliability assessment criteria for high-throughput gene-expression data. It is applicable to assessing the accuracy, reproducibility, and comparability of gene-expression data that are generated from microarray, next-generation sequencing, and other forms of high-throughput technologies. This document identifies the quality-related data for the process of the next-generation sequencing of RNA (RNA-seq). The sequencing platform covered by this document is limited to short-read sequencers. The use of RNA-seq for mutation detection and virus identification is outside of the scope of this document. This document is applicable to human health associated species such as human, cell lines, and preclinical animals. Other biological species are outside the scope of this document. From a biological point of view, expression profiles of all genetic sequences including genes, transcripts, isoforms, exons, and junctions are within the scope of this document

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

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

This document specifies general requirements for ORGANIZATIONS in the application of RISK MANAGEMENT before, during and after the connection of a HEALTH IT SYSTEM within a HEALTH IT INFRASTRUCTURE, by addressing the KEY PROPERTIES of SAFETY, EFFECTIVENESS and SECURITY whilst engaging appropriate stakeholders. IEC 80001-1:2021 cancels and replaces the first edition published in 2010. This edition constitutes a technical revision. This edition includes the following significant technical changes with respect to the previous edition: a) structure changed to better align with ISO 31000; b) establishment of requirements for an ORGANIZATION in the application of RISK MANAGEMENT; c) communication of the value, intention and purpose of RISK MANAGEMENT through principles that support preservation of the KEY PROPERTIES during the implementation and use of connected HEALTH SOFTWARE and/or HEALTH IT SYSTEMS.

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

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

The document defines the data elements and their necessary metadata to implement a structured clinical gene fusion report whose data are generated by next generation sequencing technologies. This document — describes the reporting guideline for RNA sequencing approaches focusing on detecting novel and known fusion partners, — defines the required data fields and their metadata for a structured clinical gene fusion report, — defines the optional data fields and their metadata, — covers the fusion gene from human specimen using whole transcriptome sequencing by next generation sequencing technologies for clinical practice and translational research, — does not cover the fusion gene detection using DNA sequencing methods, — does not cover the basic research and other scientific areas, — does not cover the other biological species, — does not cover the Sanger sequencing methods, and — does not cover the other structural variations. This document only defines the data elements and their metadata for the structured clinical sequencing report in electronic health records. Therefore, its layout can be designed based on the institutional decision if all elements are included as in this document.

This document describes the high-level concepts required for representation of 3D data in health information systems from a terminological perspective. It is intended to be used in analysing, developing and managing terminologies in HBPS. The use cases include clinical findings, disorders, problem lists and procedures. Topics considered in the scope of this document: — description of terminological concepts for representation of 3D data for human body; — establishing of the relationships needed for 3D data in terminological systems; — use cases. Topics considered outside the scope of this document: — 3D data structure, implementation and software functionality.

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

This document specifies the data element content and exchange format for tokens used in token-based health information sharing. It includes a) the data items that may be contained in a health information token (HI-TOKEN), b) the value representation for each data item, c) the exchange formats allowed for HI-TOKEN sharing (electronic, machine-readable symbol, print), and d) considerations when establishing governance policies specifying how HI-TOKENs can be used within a specific group of healthcare organizations. Provision is made for both physical media and electronic exchange media. This document addresses the overall conceptual architecture and process for token-based health information sharing, as well as the role of patients, referring healthcare facilities, referred healthcare service providers, and health research institutions. Provision is made for pseudonymization of patient data. This document only defines the specification of the HI-TOKEN used in token-based health information sharing. Data exchange / transport architectures, encryption methods, and specific governance policy requirements are outside the scope of this document.

This document specifies a heterogeneous format of neurophysiological waveform signals to support recording in a single persistent record package as well as interoperable exchange. The document focuses on electroencephalography (EEG) waveforms created during EEG examinations. Specific provision is made for sleep polysomnography examinations (PSG), brain death determination, evoked potentials (EP), and electromyography (EMG) studies. This document is intended for neurophysiology.

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

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

This document provides an overview of security and privacy considerations for Electronic Health Records (EHR) in a cloud computing service that users can leverage when selecting a service provider.

This document provides the principles, concepts, terms and definitions for health software and health IT systems, key properties of safety, effectiveness and security, across the full life cycle, from concept to decommissioning, as represented in Figure 1. It also identifies the transition points in the life cycle where transfers of responsibility occur, and the types of multi-lateral communication that are necessary at these transition points. This document also establishes a coherent concepts and terminology for other standards that address specific aspects of the safety, effectiveness, and security (including privacy) of health software and health IT systems. This document is applicable to all parties involved in the health software and health IT systems life cycle including the following: a) Organizations, health informatics professionals and clinical leaders designing, developing, integrating, implementing and operating health software and health IT systems – for example health software developers and medical device manufacturers, system integrators, system administrators (including cloud and other IT service providers); b) Healthcare service delivery organizations, healthcare providers and others who use health software and health IT systems in providing health services; c) Governments, health system funders, monitoring agencies, professional organizations and customers seeking confidence in an organization’s ability to consistently provide safe, effective and secure health software, health IT systems and services; d) Organizations and interested parties seeking to improve communication in managing safety, effectiveness and security risks through a common understanding of the concepts and terminology used in safety, effectiveness and security management; e) Providers of training, assessment or advice in safety, effectiveness and security risk management for health software and health IT systems; f) Developers of related safety, effectiveness and security standards.

This document lists examples of and defines categories of use cases for machine learning in medicine for clinical practice. The developments and applications of machine learning technologies for artificial intelligence consist of 1) data collection and curation, 2) pre-processing, 3) model training and validation, and 4) medicine depending on various kinds of specialty including radiology, pathology, emergency medicine, dermatology, ophthalmology, anaesthesia, surgery, etc., and clinical settings including repeated detection and/or diagnosis, real-time monitoring, and treatment prediction. This document covers categories applications of medicine in (4). It also defines the clinical usages and necessities of the artificial intelligence in medicine. (1) to (3) are not the scope of this document This document also excludes — basic research and other scientific areas, — use cases related to artificial intelligence methods other than machine learning (for example, symbolic artificial intelligence, expert systems), and — non-human results such as veterinary medicine.

This document gives guidelines for certificate management issues involved in deploying digital certificates in healthcare. It specifies a structure and minimum requirements for certificate policies, as well as a structure for associated certification practice statements. This document also identifies the principles needed in a healthcare security policy for cross-border communication and defines the minimum levels of security required, concentrating on aspects unique to healthcare.

This document defines the basic concepts underlying the use of digital certificates in healthcare and provides a scheme of interoperability requirements to establish a digital certificate-enabled secure communication of health information. It also identifies the major stakeholders who are communicating health-related information, as well as the main security services required for health communication where digital certificates can be required. This document gives a brief introduction to public key cryptography and the basic components needed to deploy digital certificates in healthcare. It further introduces different types of digital certificates — identity certificates and associated attribute certificates for relying parties, self-signed certification authority (CA) certificates, and CA hierarchies and bridging structures.

This document gives a guideline for implementation of an ISMS by showing practical examples of risk analysis on remote maintenance services (RMS) for information systems in healthcare facilities (HCFs) as provided by vendors of medical devices or health information systems in order to protect both sides' information assets (primarily the information system itself and personal health data) in a safe and efficient (i.e. economical) manner. This document consists of: — application of ISMS to RMS; — security management measures for RMS; — an example of the evaluation and effectiveness based on the "controls" defined in the ISMS.

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 presents a methodology which supports and enables the development of standards based business and information architectures that contribute to good quality of healthcare and patient safety. The methodology is used to develop descriptions of healthcare enterprises from different aspects. Those aspects are covering what, how, where, who, when, why[1] and are based on standards.

This document provides a referenced entry-level implementation template for traditional Chinese medicine decoction piece prescriptions based on HL7 CDA® Release 2.0 to support the data collection, transmission, storage and exchange of decoction piece prescriptions for electronic records. This document focuses on the description of core data of traditional Chinese medicine decoction piece prescriptions which constitute the 'medication administration' section of the clinical document body. This document does not specify the detailed content of the clinical document header or other sections and entries of the clinical document body.

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

This document 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 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 supports interchangeability of digital signatures and the prevention of incorrect or illegal digital signatures by providing minimum requirements and formats for generating and verifying digital signatures and related certificates. This document describes the common technical, operational, and policy requirements that need to be addressed to enable digital certificates to be used in protecting the exchange of healthcare information within a single domain, between domains, and across jurisdictional boundaries. Its purpose is to create a platform for global interoperability. It specifically supports digital certificate enabled communication across borders but could also provide guidance for the national or regional deployment of digital certificates in healthcare. It defines the provable compliance with a PKI policy necessary in the domain of healthcare. This document specifies a method of adopting long-term signature formats to ensure integrity and non-repudiation in long-term electronic preservation of healthcare information. This document provides Healthcare specific PKI (HPKI) profiles of digital signature based on the ETSI Standard and the profile of the ISO/ETSI Standard specified in CAdES, XAdES, and PAdES.

This document identifies quality metrics for the detection of DNA variants using next generation sequencing (NGS) technology. It also defines the data types, relationships, optionality, cardinalities and terminology bindings of the data. This document provides a basis for sharing and for the application of "high quality" genomic data and contributes to the realization of the precision medicine and the development of relevant industries. This document is intended to serve as a catalogue of sequencing data elements used to address quality metrics for various clinical, industrial and commercial applications. The exchange of these data allows researchers, commercial entities, and regulatory bodies to assess for the purpose of selective utilization of the data by setting application-specific quality criteria This document is not intended for — sequencing methods other than NGS, such as the Sanger sequencing, — targets other than genome, such as transcriptome or proteome, or — specimens of species other than humans.

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

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

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

This document provides an environmental scan of common data elements that are captured through various modalities such as cell phones, smart phones, mobile applications and remote monitoring devices that are combined with EHRs, patient portals and PHR systems which can ultimately be applicable to a variety of healthcare service environments. The Health-related data can be used to supplement existing clinical data, filling in gaps in information and providing a more comprehensive picture of ongoing patient healthcare.

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

The document gives guidance for managing healthcare service security using connectable personal health devices. This document considers unidirectional data uploading from the PHD to the gateway (manager device), however, there are many clinical use cases for bidirectional data exchange. This document is applicable to identification and authentication between the bidirectionally connected PHDs and gateway by providing possible use cases and the associated threats and vulnerabilities. Since some smart devices with mobile healthcare apps and software might connect to the healthcare service network, these devices will be considered connectable PHDs in this document. This document addresses those devices used in a homecare setting, where the knowledge and capabilities regarding the use of PHDs might not be as advanced as in other healthcare settings. This document excludes specific protocols, methods and technical solutions for identification and authentication.

The purpose of this document is to a) define a set of basic concepts required to describe formal concept representation systems, especially for health sciences, b) describe representation of concepts and characteristics, for use especially in formal computer-based concept representation systems, c) describe the characteristics which synthetically describe the organisation and content of a terminological system in health, d) support the development of specific standards on categorial structures for particular healthcare subject fields with the minimum requirements to support meaningful exchange of information. This document is not suitable for, or intended for use, by individual clinicians or hospital administrators. It is not the purpose of this document to standardize the end user classification or to conflict with the concept systems embedded in national practice and languages. Topics considered outside the scope of this document include — enumeration of axiomatic concepts and semantic links, and — detailed content of health terminology systems (classifications, nomenclatures or reference terminology of health concepts).

This document specifies the application, in the context of traditional Chinese medicine practice, of medical waveform format encoding rules (MFER) to pulse condition waveform as measured in physiological laboratories, hospitals, bed-wards, pharmacies, clinics, community health centres and home care check-ups using pulse condition devices.

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

This document specifies an information model within the field of Chinese materia medica processing. It defines a set of domain constraints of sanctioned characteristics, each composed of a relationship and an applicable information model. This model aims at representing the concepts applicable to Chinese materia medica processing in the making of decoction pieces. This document is not applicable to Japanese traditional Kampo medicine.

This document specifies the whole manufacturing process of Chinese materia medica products by defining a set of domain constraints of sanctioned characteristics, each composed of a relationship and an applicable categorial structure. It includes three process categories: processing, extracting and preparation. This document is not applicable to Japanese traditional KAMPO medicinal products.