HITSP Public Health Case Reporting Interoperability Specification

Evaluation: The Technical Committee evaluates the standards using the Tier 2 Readiness Criteria.

Selection: Based on the Tier 2 evaluations, named standards are selected and listed in the table of selected standards below. It is important to understand that the standards selected here are within the context of the specific Use Case requirements and do not necessarily reflect selection in other contexts

Gap and Overlap Analysis and Recommendations: The Technical Committee also identifies and analyzes gaps and overlaps within the standards industry as they relate to the specific Use Case. The Technical Committee provides a description of the gaps, including missing or incomplete standards, a description of all overlaps, or competition among standards for the relevant Use Cases, and recommendations for resolving these gaps and overlaps

It is HITSPs policy to incorporate only standards that have been approved according to the formal policy of the standards organization, as defined by HITSP, which publishes the standard. HITSP interprets approval to include Draft Standards for Trial Use. The objective is to incorporate only standards that are managed within a formal life cycle process as defined by the standards organization. In some cases, where we believe a standard that is not yet approved may best meet the requirements of an Interoperability Specification, HITSP may provide a roadmap of its future intent conditional on future actions by either or both the standards organization and the HITSP Technical Committee. Thus there are four classes of HITSP-committed standards.

Approved for Use standards included for unconditional use within a HITSP construct

Interim standards included for use now within a HITSP construct but for a defined time period or conditional on future actions, e.g., Intended for Use standard is available

Provisional standards that are not yet but are expected to be approved by the standards organization at the time the Interoperability Specification is released by HITSP. A Provisional standard becomes an Approved for Use standard only if:

- It is approved by the Standards Organization by the time that the Interoperability Specification is released by HITSP and

Intended for Use proposed standards that are roadmapped for future use pending actions by the Technical Committee and/or the standards organization. Therefore a standard is defined as Intended for Use if it will not be approved by the standard organization at the time that the HITSP construct is released, but is sufficiently defined to enable detailed evaluation of how well it will meet technical and information exchange requirements.

HITSP may continue to use Provisional or Interim standards as they existed when incorporated into the HITSP construct if the expected conditions are not satisfied until such time as HITSP can replace it with a more suitable standard. In this circumstance, the standards organization would have no responsibility to maintain or correct this artifact. If a standard Intended for Use is not developed and approved in terms of time frame or content as expected by the Technical Committee at the time of its initial selection, it may be replaced. All standards used by HITSP must meet the HITSP selection criteria. The use of Interim and Intended for Use standards will be weighed against the alternative of simply declaring a gap for HITSP and the standards organizations to resolve.

4.1 Standards

It is important to understand that the standards selected here are within the context of the specific Use Case requirements and do not necessarily reflect selection in other contexts. In addition, adherence to the selected standards alone is not sufficient to ensure interoperability. In order to ensure interoperability for the Use Case, and to claim conformance to the specification, an implementation must satisfy all the requirements and mandatory statements listed in the HITSP Interoperability Specification, its associated construct specifications, as well as conformance criteria from the selected base and composite standards. A conformant system must also be constrained as specified in Table 3-3 Constraints, and implement all of the required technical actors from Table 3-8 Business-Technical Actor Mapping to Transaction and/or Content, within the scope and implementation subset that is selected.

The standards used by this Interoperability Specification fall into the following categories:

Regulatory guidance is a legal or other authoritative declaration that HITSP must abide by in standards selection (see Section 4.1.1)

Selected standards are necessary for interoperability. These are standards that are used to meet information exchange requirements of associated constructs. For example, they are used to realize direct information exchange, to provide the transport mechanism, to specify the content, or to address security (see Section 4.1.2)

Informative reference standards provide additional background information or guidance, and are not required for interoperability. These standards are not required to implement the Interoperability Specification (see Section 4.1.3)

4.1.1 Regulatory Guidance

The following table provides a list of legal or other authoritative guidelines that HITSP must abide by, or has agreed to use as guidance in the selection of standards. Note that only the referenced sections of the regulations are relevant to this Interoperability Specification.

Regulation	Description
Clinical Laboratory Improvement Amendments (CLIA) of 1988	Establishes quality standards for all laboratory testing to ensure the accuracy, reliability, and timeliness of patient test results regardless of where the test is performed. The Centers for Medicare and Medicaid Services (CMS) regulates all laboratory testing (except research) performed on humans in the U.S. based on CLIA. For more information visit http://www.fda.gov and http://www.cms.hhs.gov
Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification	A listing of national standards plus rules adopted by federal regulation for electronically communicating specified administrative and financial healthcare transactions, and protecting the security and privacy of healthcare information, as applied to the three types of defined covered entities: health plans, healthcare clearinghouses, and healthcare providers who conduct any of the specified healthcare transactions. See the Code of Federal Regulations, Title 45, Parts 160, et. Seq. for more information

4.1.2 Selected Standards

The following table provides a list of standards that are used to meet information exchange requirements of the Interoperability Specification, and the HITSP constructs that use each standard. A detailed description of each standard is also provided in the Appendix.

Note that the standards selected for this Interoperability Specification are approved for use except as cited in the Scope of Design section of this document as defined in Section 4.0 above.

Standard	HITSP Construct	Remarks/ Minor Gaps
Accredited Standards Committee (ASC) X12 Standards Release 004010	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32
American Medical Association (AMA) Current Procedural Terminology (CPT) Fourth Edition (CPT-4); CPT Evaluation and Management Codes	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48
ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E1762-95(2003)	HITSP/C26 Nonrepudiation of Origin
CDC Race and Ethnicity Code Sets	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Centers for Disease Control and Prevention Implementation Guide for Immunizations Data Transaction using Version 2.3.1 of the Health Level Seven (HL7) Standard Protocol. Implementation Guide Version 2.2 June 2006	HITSP/C80 Clinical Document and Message Terminology
Digital Imaging and Communications in Medicine (DICOM) Part 3.12: Media Formats and Physical Media for Media Interchange	HITSP/T33 Transfer of Documents on Media
European Telecommunications Standards Institute (ETSI) Technical Specification TS 101 903: XML Advanced Electronic Signatures (XadES)	HITSP/C26 Nonrepudiation of Origin
Federal Information Processing Standards (FIPS) Codes for the Identification of the States, the District of Columbia and the Outlying Areas of the United States, and Associated Areas Publication # 5-2, May, 1987	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Federal Medication Terminologies	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII)	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Food and Drug Administration (FDA) - National Drug Code (NDC)	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Health Level Seven (HL7) Common Terminology Services (CTS) Release 1	HITSP/ T66 Retrieve Value Set
Health Level Seven (HL7) HL7 Version 3 Standard: Clinical Document Architecture (CDA), Release 2	HITSP/C48 Encounter Document Using IHE Medical Summary (XDS-MS) HITSP/C75 Healthcare Associated Infection (HAI) Report HITSP/C37 Lab Report Document HITSP/C83 CDA Content Modules
Health Level Seven (HL7) Implementation Guide for CDA Release 2: NHSN Healthcare Associated Infection (HAI) Reports, Release 1	HITSP/C75 Healthcare Associated Infection (HAI) Report
Health Level Seven (HL7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes	HITSP/C83 CDA Content Modules
Health Level Seven (HL7) Implementation Guide for CDA Release 2: Consultation Note	HITSP/C83 CDA Content Modules
Health Level Seven (HL7) Implementation Guide: CDA Release 2 Continuity of Care Document (CCD), April 01, 2007	HITSP/C32 Summary Documents Using HL7 Continuity of Care Document (CCD) HITSP/C83 CDA Content Modules
Health Level Seven (HL7) Standard Code Set CVX - Vaccines Administered	HITSP/C80 - Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32 and HITSP/C76
Health Level Seven (HL7) Standard Code Set MVX - Manufacturers of Vaccines	HITSP/C80 - Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32 and HITSP/C76
Health Level Seven (HL7) U.S. Realm Interoperability Specification: Lab Result Message to EHR (ORU^R01) (HL7 Version 2.5.1) September, 2007	HITSP/C36 Lab Result Message
Health Level Seven (HL7) V3 RBAC, R1-2008, HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008	HITSP/ TP20 Access Control
Health Level Seven (HL7) Version 2.3.1 Chapter 2 Control, Chapter 3 Patient Administration	HITSP/TP22 Patient ID Cross-Referencing
Health Level Seven (HL7) Version 2.5, Chapter 2 Control, Chapter 3 Patient Administration, Chapter 5 Query	HITSP/T23 Patient Demographics Query HITSP/TP22 Patient ID Cross-Referencing
Health Level Seven (HL7) Version 2.5.1	HITSP/C35 Lab Result Terminology HITSP/C36 Lab Result Message HITSP/C76 Case Report Pre-Populate HITSP/ T14 Send Laboratory Result Message
Health Level Seven (HL7) Version 2.5.1 Vocabularies and Value Sets	HITSP/C80 Clinical Document and Message Terminology
Health Level Seven (HL7) Version 3.0	HITSP/C76 Case Report Pre-Populate
Health Level Seven (HL7) Version 3.0 Vocabularies and Value Sets	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Health Level Seven (HL7) Version 3.0 Context-Aware Information Retrieval Specification: URL Implementation Guide	HITSP/ T81 Retrieval of Medical Knowledge
Health Level Seven (HL7) Version 3.0 Infrastructure Management Query Infrastructure, Release 2 DSTU Ballot 1 September 2008	HITSP/TP21 Query for Existing Data
Health Level Seven (HL7) Version 3.0 Privacy Consent related specifications RCMR_RM010001 Data Consent	HITSP/ TP30 Manage Consent Directives
Health Level Seven (HL7) Version 3.0 Standard: Transport Specification Web Services Profile, Release 2 Committee Ballot 1 May 2008	HITSP/TP21 Query for Existing Data
HUGO Gene Nomenclature Committee at the European Bioinformatics Institute Gene Names	HITSP/C80 Clinical Document and Message Terminology
Human Genome Variation Society (HGVS) Description of Sequence Variants February, 20, 2008	HITSP/C80 Clinical Document and Message Terminology
Integrating the Healthcare Enterprise (IHE) Exchange of Personal Health Record Content (XPHR)	HITSP/C32 Summary Documents Using HL7 Continuity of Care Document (CCD)
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Volume 2 Supplement 2007 2008 Cross-Enterprise User Assertion (XUA)	HITSP/C19 Entity Identity Assertion
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Supplement Volume 3 Document Digital Signature (DSG) Content Profile	HITSP/C26 Nonrepudiation of Origin
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 5.0 or later, Cross Enterprise Sharing of Scanned Documents (XDS-SD) Integration Profile	HITSP/C62 Unstructured Document
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 or later, Audit Trail and Node Authentication Profile (ATNA)	HITSP/T15 Collect and Communicate Security Audit Trail
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 or later, Audit Trail and Node Authentication (ATNA) Integration Profile, Section 9.1 Authentication	HITSP/T17 Secured Communication Channel
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 or later, Consistent Time (CT) Integration Profile	HITSP/ T16 Consistent Time
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 5.0 or later, Patient Demographics Query (PDQ) Integration Profile	HITSP/T23 Patient Demographics Query
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Supplement 2008 2009, Pediatric Demographics, Draft for Trial Implementation (August 22, 2008)	HITSP/T23 Patient Demographics Query HITSP/TP22 Patient ID Cross-Referencing
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (TF) Supplement 2007 2008, Notification of Document Availability Integration Profile, Draft for Trial Implementation, October 10, 2008	HITSP/ T29 Notification of Document Availability
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) 2007-2008 Trial Implementation Supplement Cross-enterprise Document Reliable Interchange (XDR) Release 3	HITSP/ T31 Document Reliable Interchange
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework, Revision 4.0 or later, Personnel White Pages profile	HITSP/ T64 Identify Communication Recipients
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Supplement 2008-2009 Sharing Value Sets (SVS)	HITSP/ T66 Retrieve Value Set
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0, Section 10 Cross-Enterprise Document Sharing (XDS.a)	HITSP/TP13 Manage Sharing of Documents HITSP/TP30 Manage Consent Directives
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 Registry Stored Query Transaction for XDS Profile Supplement [ITI-18]	HITSP/TP13 Manage Sharing of Documents HITSP/TP30 Manage Consent Directives
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 XCA Supplement	HITSP/TP30 Manage Consent Directives
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Supplement 2008-2009, Cross-Community Access (XCA), Trial Implementation, October 10, 2008	HITSP/TP13 Manage Sharing of Documents
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Volume 2 Supplement 2007 2008 Cross-Enterprise Document Sharing-B (XDS.b)	HITSP/TP13 Manage Sharing of Documents HITSP/TP30 Manage Consent Directives
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0 or later, Patient Identifier Cross-Referencing Integration Profile (PIX)	HITSP/TP22 Patient ID Cross-Referencing
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Supplement 2007 2008 Basic Patient Privacy Consents (BPPC) Trial Implementation	HITSP/TP30 Manage Consent Directives
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (TF) Supplement, Retrieve Form for Data Capture (RFD), Draft for Trial Implementation, October 10 2008	HITSP/TP50 Retrieve Form for Data Capture
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 5.0 or later, Cross-Enterprise Document Media Interchange (XDM) Integration Profile	HITSP/T33 Transfer of Documents on Media
Integrating the Healthcare Enterprise (IHE) Laboratory Technical Framework Volume 3 (LAB TF-3) Document-based Transactions, Revision 2.0 For Trial Implementation, August 16, 2007	HITSP/C37 Lab Report Document
Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC), Revision 4.0	HITSP/C83 CDA Content Modules
Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC), Revision 4.0, 2008 2009, Cross-Enterprise Sharing of Medical Summaries (XDS-MS) Integration Profile	HITSP/C48 Encounter Document Using IHE Medical Summary (XDS-MS)
Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC) Technical Framework Supplement 2008 2009, Draft for Trial Implementation, August 22, 2008	HITSP/TP21 Query for Existing Data
Integrating the Healthcare Enterprise (IHE) Quality, Research and Public Health (QRPH) Technical Framework Supplement 2008 2009, Drug Safety Content (DSC) Profile, Public Comment, Version 10	HITSP/C76 Case Report Pre-Populate
International Classification of Functioning, Disability and Health (ICF)	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C48
International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)	HITSP/C35 Lab Result Terminology HITSP/C36 Lab Result Message HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
International Organization for Standardization (ISO) Health Informatics Pseudonymisation, Unpublished Technical Specification # 25237	HITSP/C87 Anonymize Public Health Case Reporting Data HITSP/T24 Pseudonymize
International Organization for Standardization (ISO) Health Informatics 9660 Level 1	HITSP/T33 Transfer of Documents on Media
International Organization for Standardization (ISO) ISO 3166-1	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
International Organization for Standardization (ISO) PDF/A ISO 19005-1b. Document management Electronic document file format for long-term preservation Part 1: Use of PDF (PDF/A)	HITSP/C62 Unstructured Document
Internet Engineering Task Force (IETF) Network Time Protocol (Version 3) Specification, Implementation and Analysis, Request for Comment (RFC) #1305, March, 1992	HITSP/T16 Consistent Time
Internet Engineering Task Force (IETF) Simple Network Time Protocol (SNTP) Version 4, Request for Comment (RFC) #2030, October, 1996	HITSP/T16 Consistent Time
Internet Engineering Task Force (IETF) Tags for Identifying Languages, "Request for Comment" (RFC) # 4646, September, 2006	HITSP/C80 - Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Logical Observation Identifiers Names and Codes (LOINC)	HITSP/C35 Lab Result Terminology HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
National Cancer Institute (NCI) Thesaurus	HITSP/C80 Clinical Document and Message Terminology
National Cancer Institute (NCI) Thesaurus: Route of Administration	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
National Center for Biotechnology Information (NCBI) Genetic Reference Sequences	HITSP/C80 Clinical Document and Message Terminology
National Center for Biotechnology Information (NCBI) Single Nucleotide Polymorphisms	HITSP/C80 Clinical Document and Message Terminology
National Library of Medicine (NLM) Unified Medical Language System (UMLS) RxNorm	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
National Uniform Billing Committee (NUBC) Uniform Bill Version 2007 (UB-04) Current UB Data Specification Manual Field 22, Patient Discharge Status, Codes	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
Organization for the Advancement of Structured Information Standards (OASIS) Common Alerting Protocol (CAP) V1.1, October 2005	HITSP/C82 Emergency Common Alerting Protocol
Organization for the Advancement of Structured Information Standards (OASIS) Emergency Data Exchange Language (EDXL) Distribution Element (DE) Version 1.0	HITSP/T63 Emergency Message Distribution Element
Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) Core v2.0 OASIS Standard; ITU-T X.1141	HITSP/TP20 Access Control
Organization for the Advancement of Structured Information Standards (OASIS) WS-Trust Version 1.3, March 2007	HITSP/TP20 Access Control
Organization for the Advancement of Structured Information Standards (OASIS) eXtensible Access Control Markup Language (XACML), ITU-T Recommendation X.1142, February 2005	HITSP/TP20 Access Control
Organization for the Advancement of Structured Information Standards (OASIS) Simple Object Access Protocol (SOAP) Version 1.1	HITSP/TP21 Query for Existing Data
Organization for the Advancement of Structured Information Standards (OASIS) Simple Object Access Protocol (SOAP) Version 1.2	HITSP/TP21 Query for Existing Data
U.S. National Uniform Claims Committee Health Care Provider Taxonomy Code Set	HITSP/C80 Clinical Document and Message Terminology
Unified Code for Units of Measure (UCUM)	HITSP/C35 Lab Result Terminology HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
United States Postal Service (USPS) Postal Codes	HITSP/C80 Clinical Document and Message Terminology
USB Removable Device Type 2.0 (USB Implementers Forum)	HITSP/T33 Transfer of Documents on Media
VHA National Drug File Reference Terminology (NDF-RT) Formulary	HITSP/C80 Clinical Document and Message Terminology	Vocabularies are enabled via HITSP/C32, HITSP/C48, and HITSP/C76
VHA National Drug File Reference Terminology (NDF-RT) Formulary	HITSP/C80 Clinical Document and Message Terminology

4.1.3 Informative Reference Standards

The following table lists standards that provide additional background information or guidance; however, they are not required for the implementation of the Interoperability Specification.

Standard	Description
American National Standards Institute (ANSI) International Committee for Information Technology Standards (INCITS), #359-2004	This standard describes RBAC features that have achieved acceptance in the commercial marketplace. It includes a reference model and functional specifications for the RBAC features defined in the reference model. It is intended for (1) software engineers and product development managers who design products incorporating access control features; and (2) managers and procurement officials who seek to acquire computer security products with features that provide access control capabilities in accordance with commonly known and understood terminology and functional. For more information visit http://www.ansi.org
ASTM International Standard Guide for Privilege Management Infrastructure (PMI) Guidelines: #E2595-07	Defines interoperable mechanisms to manage privileges in a distributed environment. This standard is oriented towards support of a distributed or service-oriented architecture (SOA) where security services are themselves distributed and applications are consumers of distributed services. This standard incorporates privilege management mechanisms alluded to in a number of existing standards (e.g., E1986, E2084). The privilege mechanisms in this standard support policy-based access control (including role, entity and contextual-based access control) including the application of policy constraints, patient requested restrictions and delegation. Finally, the standard supports hierarchical, enterprise-wide privilege management. The mechanisms defined in this standard may be used to support a privilege management infrastructure (PMI) using existing public key infrastructure (PKI) technology. This standard does not specifically support mechanisms based on secret-key cryptography. Mechanisms involving privilege credentials are specified in International Organization for Standardization (ISO) 9594-8:2000 (attribute certificates), and Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) (attribute assertions); however, this standard does not mandate or assume the use of such standards. Many current systems require only local privilege management functionality (on a single computer system). Such systems frequently use proprietary mechanisms. This standard does not address this type of functionality; rather, it addresses an environment where privileges and capabilities (authorizations) must be managed between computer systems across the enterprise, and with business partners. For more information visit www.astm.org http://www.astm.org/
American Society for Testing and Materials (ASTM) Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems: # E2147-01	E2147-01 is for the development and implementation of security audit/disclosure logs for health information. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of health information to external users for use in manual and computer systems. The process of information disclosure and auditing should conform, where relevant, with the Privacy Act of 1974 (1). For more information visit www.astm.org
Assessing interoperability in emergency management standards Pack, D. Coleman, C., United States Navy, Charleston; This paper appears in: Southeastcon, 2008. IEEE Publication Date: 3-6 April 2008; On page(s): 334-339	Paper identifies the contributions that OASIS EDXL-DE standard will have on interoperability in emergency management, and provides a case study for evaluation purposes
Council for Affordable Quality Health Care (CAQH) Committee on Operating Rules for Information Exchange (CORE) Phase I Operating Rules	Provide agreed-upon business rules and guidelines for using and processing eligibility inquiry and response transactions between providers and health plans; in particular those that have been adopted under HIPAA. For more information visit www.caqh.org
Digital Imaging and Communications in Medicine (DICOM) Attribute Level Confidentiality Supplement: # 55	Adds a mechanism for selective protection of individual attributes within arbitrary DICOM service-object pair (SOP) instances. It may be used to achieve protection of identifying information, e.g. a reversible anonymization or pseudonymization of DICOM SOP instances while continuing to use unmodified lower level message and protocol services for network transfer, storage, and media exchange of composite image information objects. For more information visit http://medical.nema.org
Federal Medication Terminologies	A set of controlled terminologies and code sets developed and maintained as part of a collaboration between the Food and Drug Administration, National Library of Medicine, Veterans Health Administration, National Cancer Institute and Agency for Healthcare Research and Quality related to medications, including medication proprietary and nonproprietary names, clinical drug code (RxNorm); ingredient names and Unique Ingredient Identifiers (UNII); routes of administration, dosage forms, and units of presentation from the NCI Thesaurus (NCIt); and certain pharmacological drug classes from the National Drug File Reference Terminology (NDF-RT). The Federal Medication Terminology leverages medication models maintained by the Food and Drug Administration (ex. UNII, NDC Codes), National Library of Medicine (RxNorm), the Veterans Health Administration (NDF-RT), and the National Cancer Institute (NCIt). For more information visit www.cancer.gov/cancertopics/terminologyresources/page4.
Health Level Seven (HL7) Clinical Document Architecture Release 2 (CDA R2)	The HL7 Clinical Document Architecture is an XML-based document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA is one instantiation of HL7s Version 3.0 Reference Information Model (RIM) into a specific message format. Of particular focus for HITSP Interoperability Specifications are message formats for Laboratory Results and Continuity of Care (CCD) documents. Release 2 of the HL7 Clinical Document Architecture (CDA) is an extension to the original CDA document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA R2 includes a prose document in HTML, XML schemas, data dictionary, and sample CDA documents. CDA R2 further builds upon other HL7 standards beyond just the Version 3.0 Reference Information Model (RIM) and incorporates Version 3.0 Data Structures, Vocabulary, and the XML Implementation Technology Specifications for Data Types and Structures. For more information visit www.hl7.org.
Health Level Seven (HL7) Consent related vocabulary including Confidentiality Codes	HL7 concept domains, including ConfidentialityCodes, ActInformationCategoryCode, ActInformationAccessType, ActInformationAccessContextCode, AuthorizedParticipationFunctionCode, ActPolicyType, ActConsentType, and ActMaskableCode For more information visit www.hl7.org
Health Level Seven (HL7) Minimal Lower Layer Protocol (MLLP) Release 2	This document specifies Release 2 of the Minimal Lower Layer Message Transport protocol (MLLP, a.k.a. MLP). The goal of the MLLP Message Transport protocol is to provide an interface between HL7 Applications and the transport protocol that uses minimal overhead. MLLP is based on a minimalistic OSI-session layer framing protocol. It is assumed that MLLP will be used only in a network environment. For more information visit www.hl7.org
Health Level Seven (HL7) V3 RBAC, R1-2008, HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008	The Healthcare Permission Catalog provides the necessary content for creating interoperable roles facilitating inter-organizational communications and information sharing among healthcare organizations and their business partners. For more information visit www.hl7.org
Health Level Seven (HL7) Version 2.5	The HL7 Version 2.5 Messaging Standard is an application protocol for electronic data exchange in healthcare. It and prior versions have widespread use in the U.S. and internationally. Both message formats and value sets/code tables (e.g., diagnosis type, gender, patient class, result status, specimen collection method, abnormal flags, observation result status codes interpretation, timestamp format) are contained in the standard. Of particular focus for HITSP Interoperability Specifications are message formats described in Chapters 2, 3, 5, and 7 including patient demographic (ADT) and lab result reporting. These are also used within composite standards from IHE for Patient Identity Cross-Referencing and Feed (PIX), Patient Demographics Query (PDQ), and Acknowledgements. For more information visit www.hl7.org
Health Level Seven (HL7) Version 3.0	The HL7 Version 3.0 Messaging Standard is an application protocol for electronic data exchange in healthcare. Version 3.0 is based on a Reference Information Model (RIM); which is used to instantiate various message formats. Value sets/code tables are contained in the standard. For more information visit www.hl7.org
Health Level Seven (HL7) Version 3.0 Clinical Document Architecture (CDA/CDA R2)	The HL7 Clinical Document Architecture is an XML-based document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA is one instantiation of HL7s Version 3.0 Reference Information Model (RIM) into a specific message format. Of particular focus for HITSP Interoperability Specifications are message formats for Laboratory Results and Continuity of Care (CCD) documents. Release 2 of the HL7 Clinical Document Architecture (CDA) is an extension to the original CDA document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA R2 includes a prose document in HTML, XML schemas, data dictionary, and sample CDA documents. CDA R2 further builds upon other HL7 standards beyond just the Version 3.0 Reference Information Model (RIM) and incorporates Version 3.0 Data Structures, Vocabulary, and the XML Implementation Technology Specifications for Data Types and Structures. For more information visit www.hl7.org
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0, Volume 2 Transactions, Appendix C	Section 2.1 of Appendix C in the framework provides network guidelines for the network communications protocol for the HL7 message. For more information visit www.ihe.net
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0, Volume 2 Transactions, Appendix M Using Patient Demographics Query in a Multi-Domain Environment	Appendix M Using Patient Data Query (PDQ) in a Multi-Domain Environment, provides an architectural discussion of how Query Parameter Definition, QPD-8 is processed For more information visit www.ihe.net
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0	The IHE IT Infrastructure Technical Framework defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of health information to support optimal patient care. IHE Integration Profiles offer a common language that healthcare professionals and vendors may use in communicating requirements for the integration of products. The current version of the ITI-TF, rev. 4.0 for Final Text, specifies the IHE transactions defined and implemented as of August 22, 2007. The latest version of the IHE Technical Framework is available at www.ihe.net
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0	The IHE IT Infrastructure Technical Framework defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of health information to support optimal patient care. IHE Integration Profiles offer a common language that healthcare professionals and vendors may use in communicating requirements for the integration of products. The current version of the ITI-TF, rev. 4.0 for Final Text, specifies the IHE transactions defined and implemented as of August 22, 2007. The latest version of the IHE Technical Framework is available at www.ihe.net
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0, Audit Trail and Node Authentication (ATNA) Integration Profile	Audit Trail and Node Authentication (ATNA) establishes the characteristics of a Basic Secure Node. It describes the security environment (user identification, authentication, authorization, access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments. It defines basic auditing requirements for the node. It defines basic security requirements for the communications of the node using TLS or equivalent functionality. It establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information. This integration profile has been designed so that specific domain frameworks may extend it through an option defined in the domain specific technical framework. Extensions are used to define additional audit event reporting requirements, especially actor specific requirements. The latest version of the IHE Technical Framework is available at www.ihe.net
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0	The IHE IT Infrastructure Technical Framework defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of health information to support optimal patient care. IHE Integration Profiles offer a common language that healthcare professionals and vendors may use in communicating requirements for the integration of products. The current version of the ITI-TF, rev. 4.0 for Final Text, specifies the IHE transactions defined and implemented as of August 22, 2007. The latest version of the IHE Technical Framework is available at www.ihe.net
Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Revision 4.0	The IHE IT Infrastructure Technical Framework defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of health information to support optimal patient care. IHE Integration Profiles offer a common language that healthcare professionals and vendors may use in communicating requirements for the integration of products. The current version of the ITI-TF, rev. 4.0 for Final Text, specifies the IHE transactions defined and implemented as of August 22, 2007. The latest version of the IHE Technical Framework is available at www.ihe.net
Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC) Technical Framework Revision 1.0	The IHE Patient Care Coordination Technical Framework (PCC TF) defines specific implementations (called Integration Profiles) of established standards to deal with integration issues that cross providers, patient problems or time. The Cross-Enterprise Document Sharing of Medical Summaries (XDS-MS) Integration Profile enables sharing of health information between enterprises of a regional health network, and further describes how to map content in a CDA medical document into registry metadata. In the registry, healthcare providers publish pointers to documents stored in distributed repositories. Other healthcare providers may search and retrieve these and other documents. For more information visit www.ihe.net
Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC), Revision 3.0, 2007 2008	The IHE Patient Care Coordination Technical Framework (PCC TF) defines specific implementations (called Integration Profiles) of established standards to deal with integration issues that cross providers, patient problems or time. The Cross-Enterprise Document Sharing of Medical Summaries (XDS-MS) Integration Profile enables sharing of health information between enterprises of a regional health network, and further describes how to map content in a CDA medical document into registry metadata. In the registry, healthcare providers publish pointers to documents stored in distributed repositories. Other healthcare providers may search and retrieve these and other documents. For more information visit www.ihe.net
International Organization for Standardization (ISO) Health informatics Directory services for security, communications and identification of professionals and patients, Technical Specification #21091	Defines minimal specifications for directory services for health care using the X.500 framework. This Technical Specification provides the common directory information and services needed to support the secure exchange of health care information over public networks. It addresses the health directory from a community perspective in anticipation of supporting inter-enterprise, inter-jurisdiction and international health care communications. ISO/TS 21091:2005 also supports directory services aiming to support identification of health professionals and organizations and the patients/consumers. The latter services include aspects sometimes referred to as master patient indices. The health care directory will only support standard LDAP Client searches. Specific implementation guidance, search criteria and support are out of scope of this document. For more information, visit www.iso.org
International Organization for Standardization (ISO) Health informatics Information technology Open Systems Interconnection Systems Management: Security alarm reporting function, Technical Specification #10164Part 7: Security Alarm Reporting Function, 1992	Establishes user requirements for the service definition needed to support the security alarm reporting function, defines the service provided by the security alarm reporting function, specifies the protocol that is necessary in order to provide the service, defines the relationship between the service and management notifications, defines relationships with other systems management functions, specifies conformance requirements. The security alarm reporting function is a systems management function which may be used by an application process in a centralized or decentralized management environment to exchange information for the purpose of systems management. For more information visit www.iso.org
International Organization for Standardization (ISO) Health informatics Information technology Text and office systems Office Document Architecture (ODA) and interchange format, Technical Report on ISO 8613 implementation testing, Technical Specification # ISO/IEC CD 10183 Part 3: Testing procedure.	Specifies a general framework for the provision of access control. The purpose of access control is to counter the threat of unauthorized operations involving a computer or communication system. For more information visit www.iso.org
International Organization for Standardization (ISO) Health informatics Privilege management and access control(PMAC), Technical Specification #22600 Part 1: Overview and policy management, July 2006	Supports the needs of healthcare information sharing across unaffiliated providers of healthcare, healthcare organizations, health insurance companies, their patients, staff members and trading partners. It is also intended to support inquiries from both individuals and application systems. For more information visit www.iso.org
International Organization for Standardization (ISO) Health informatics Functional and Structural Roles (ISO SF Roles), Technical Specification #21298 , Draft May, 2007	This document contains a specification for encoding information related to roles for health professionals and consumers. At least four areas have been identified where a model for encoding role information is needed. Privilege management and access control: role-based access control is not possible without an effective means of recording role information for healthcare actors. Directory services: structural roles are usefully recorded within directories of health care providers (see for example, ISO TS 21091 Health Informatics Directory services for security, communications, and identification of professionals and patients). Audit trails: functional roles are usefully recorded within audit trails for health information applications. Public key infrastructure (PKI): The three part ISO standard 17090 Health Informatics Public Key Infrastructure (PKI) allows for the encoding of healthcare roles in certificate extensions, but no structured vocabulary for such roles is specified. This technical specification identifies such a coded vocabulary. For more information visit http://www.iso.org/ www.iso.org
Internet Engineering Task Force (IETF) Tags for the Identification of Languages, Request for Comment (RFC) # 3066, January, 2001	Describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. For more information visit www.ietf.org
Internet Engineering Task Force (IETF) The application/pdf Media Type (RFC 3778)	PDF, the Portable Document Format, is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of application/pdf. For more information visit www.ietf.org
Internet Engineering Task Force (IETF), HTTP HyperText Transfer Protocol HTTP/1.1 (RFC 2616)	The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol, which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. For more information visit www.ietf.org
Internet Engineering Task Force (IETF), MIME Multipurpose Internet Message Extensions (RFC 2045 to RFC 2049)	The first and second documents in this set define MIME header fields and the initial set of MIME media types. The third document describes extensions to RFC 822 formats to allow for character sets other than US-ASCII. The fourth document describes what portions of MIME must be supported by a conformant MIME implementation. It also describes various pitfalls of contemporary messaging systems as well as the canonical encoding model MIME is based on. For more information visit www.ietf.org
Internet Engineering Task Force (IETF), SMTP Simple Mail Transfer Protocol (RFC 2821)	The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. For more information visit www.ietf.org
Internet Engineering Task Force (IETF), The MIME Multipart/Related Content-type (RFC 2387)	The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. For more information visit www.ietf.org
Internet Engineering Task Force (IETF), Transmission Control Protocol (TCP), DARPA Internet Program Protocol Specification (RFC 793)	The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks. This document describes the functions to be performed by the Transmission Control Protocol, the program that implements it and its interface to programs or users that require its services. For more information visit www.ietf.org
Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) Core v2.0 OASIS Standard; ITU-T X.1141	SAML, developed by the Security Services Technical Committee of OASIS, is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) Web Services Security SOAP Message Security Version 1.0	Describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. This specification also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible (i.e.. support multiple security token formats. Additionally, this specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) Simple Object Access Protocol (SOAP) Version 1.1	SOAP is a protocol specification for invoking methods on servers, services, components and objects. SOAP codifies the existing practice of using XML and HTTP as a method invocation mechanism. The SOAP specification mandates a small number of HTTP headers that facilitate firewall/proxy filtering plus an XML vocabulary that is used for representing method parameters, return values, and exceptions. {DevelopMentor} SOAP consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) ebRIM OASIS ebXML Registry Information Model v2.1	The Registry Information Model provides a blueprint or high-level schema for the ebXML Registry. Its primary value is for implementers of ebXML Registries. It provides these implementers with information on the type of metadata that is stored in the Registry as well as the relationships among metadata Classes. The Registry information model: a) Defines what types of objects are stored in the Registry; b) Defines how stored objects are organized in the Registry. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) ebMS OASIS/ebXML Messaging Services Specifications v2.1	Defines a Message Service protocol for reliable Business-to-Business data interchange. ebMS v2.1 adds quality of service features on top of transfer protocols such as HTTP and SMTP. Key qualities of service features include guaranteed delivery and nonrepudiation of receipt. ebMS v2.1 can reliably transfer any data type including XML, X12, EDIFACT, or binary data between two parties over the Internet. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) ebRS OASIS ebXML Registry Services Specifications v2.1	The ebXML Registry provides a set of services that enable sharing of information between interested parties for the purpose of enabling business process integration between such parties based on the ebXML specifications. The shared information is maintained as objects in a repository and managed by the ebXML Registry Services defined in this document. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) ebXML Registry Information Model (3.0)	The Registry Information Model provides a blueprint or high-level schema for the ebXML Registry. Its primary value is for implementers of ebXML Registries. It provides these implementers with information on the type of metadata that is stored in the Registry as well as the relationships among metadata Classes. The Registry information model: a) Defines what types of objects are stored in the Registry; b) Defines how stored objects are organized in the Registry. For more information visit www.oasis-open.org
Organization for the Advancement of Structured Information Standards (OASIS) ebXML Registry Services Specification (3.0)	The ebXML Registry provides a set of services that enable sharing of information between interested parties for the purpose of enabling business process integration between such parties based on the ebXML specifications. The shared information is maintained as objects in a repository and managed by the ebXML Registry Services defined in this document. For more information visit www.oasis-open.org
VHA National Drug File Reference Terminology (NDF-RT) Formulary	Provides standard names for (1) mechanism of action, (2) Physiologic Effect and (3) Structural Class. NDF-RT is part of the Federal Medication Terminologies. For more information visit www.cancer.gov/cancertopics/terminologyresources/page5

4.2 Gaps Where There Are No Standards

This section describes gaps in standards. Gaps occur in the following two cases, where HITSP has:

Identified requirements derived from the context that have no standards that meet all tiers of HITSP criteria to merit selection for that context

Identified a single standard that encompasses and singly fulfills a set of tightly-coupled standards from the given context, yet is lacking in fulfilling one or more of the tightly-coupled requirements

The gap is only relative to the specific Use Case requirement. Recommended resolutions were developed through a series of steps including the Technical Committees initial recommendations, cross Technical Committee validation of the gap, provisional recommendations and peer review by the Technical Committee.

The table below identifies the Use Case requirements and known associated gaps, along with the recommended resolutions.

Requirement Number	Summary Description	Identified Gaps	Recommended Resolution
DR17	Decision	8.1.1.1 Action: Request information from submitters of reports/information. In the PH side an attempt is made to enumerate as much of the notifiable conditions possible the opposite exists in AE reporting, but for AE the case is inverted for PH it is doable, but for AE, it is not easily doable without tremendous human intervention to automate the classification; Alert may be programmable by class trigger certain reporting events, but this is after the determination that this is an event	Work with SDOs to create a minimum number of standards for PH case reporting requests and AE reporting requests
DR17	Decision	8.1.1.2 Action: Request information from submitters of reports/information. Gap in identifying supplemental detail needed from standards (e.g. using patient anti-TB drug as an indication of active TB to compare to known TB patients) what standardized questions to ask	Work with SDOs to create a minimum number of standards for PH case reporting and AE reporting
DR17	Decision	8.1.1.2 Action: Request information from submitters of reports/information GAP in the specifics of what should be requested	Leave to local definition via TP50
DR25	Case Report Content	Facility Identifier, Send Report to: Federal Project under way to used DUNS number for companies that import products global business Not sufficient for this Use Case doesnt cover: PH Agency requesting information back PH Clinic may not have one, manufacturers wont , food importers DUNS Satellite clinic may not have a separate ID from Hospital May need to be more than one data element to distinguish the concept	Pending policy and assigning authority recommendations
DR25	Case Report Content	Event Device Problem Code : Not using a structured terminology; MedDRA/CDRH discussion to align terminologies; Overlap: Codelist GAP: Reconcile structured terminology for device AE reporting	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Type of Reportable Event It should represent the coded adverse event term. Events/incidents for internal reporting (e.g. falls) Reportable events for non-FDA; WHO taxonomy Joint Commission list CDC FDA (form) VAERS vaccine injury CMS Never list Terminology Service opportunity; Broadest list may reflect a GAP Multiple lists reflect OVERLAP It is a vocabulary issue to be addressed with ICSR 3.	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Type of Follow-Up MedWatch form follow-up info corrected, etc no structured vocabulary	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Type of Remedial Action Not coded today; could be coded depending on type of report (e.g. medical device refurbished);	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Occupational Risk FactorsGAP for detail some in, but not all in SNOMED-CT Y/N/U/Not Asked null flavor options	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Contact with confirmed or suspect HBV case Need contact type coded	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Frequency of direct blood or body fluid exposure Frequent, several times/week, infrequent	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to Public Health. 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications. 8.1.1 2 Action: Receive additional information to assist in investigation activities. 8.2.1.2 Action: Send information to Public Health related to previously reported PH Cases and/or other information. 7.1.1.2 Action: Incorporate PH trigger data and reporting specifications. 7.1.1.3 Action: Incorporate AE trigger data and reporting specifications. 7.1.6.1 Action: Information related to possible PH Cases or Aes that is not available through an EHR is manually gathered. 7.1.6.2 Action: Information related to possible PH Cases or Aes that is not available through an EHR may be gained through electronic information exchanges. 8.1.1.1 Action: Request information from submitters of reports/information. 8.2.1.1 Action: Receive request for additional information from Public Health. Need to refer maintenance of common data elements and harmonization effort	Recommend that a body to maintain this be identified
DR25	Case Report Content	Concomitant Medical Products & Therapy Dates: Other medical products and treatment used proximal to the event: Non-medication product terms are to be represented with ICSR 3 and therefore, these are a GAP for this release. In the user interface, the user will need to select one or more (n) of a list.	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Type of Reporter: The role of the reporter with respect to the patient (e.g., treating or consulting clinician, case manager, etc.)	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Suspect Product Name: Product name - Medications should reference NDC and RxNorm as identified in C80. Vaccines are represented by CVX codes (also identified in C80). Non-medication product terms are to be represented with ICSR 3 and therefore, these are a GAP for this release. In the user interface, the user will need to select one or more (n) of a list.	Work with SDOs to update the standards to conform to the data requirements
DR25	Case Report Content	Patient Recovered Diagnosis: Final determination of reaction diagnosis; Captures reported signs and symptoms that have been combined into a succinct diagnosis that captures the patient state at the end of the adverse event	Recovery terminology will be determined as part of the ICSR 3 effort. Some terms are identified in ICH which will be reviewed for ICSR 3. Some harmonization is also required with Public Health reporting for other uses of the term recovered. For now, the vocabulary is a GAP.
DR25	Case Report Content	Name of Treatment	Medications should reference NDC and RxNorm as identified in C80. Vaccines are represented by CVX codes (also identified in C80). Non-medication product terms and actions are to be represented with ICSR 3 and therefore, these are a GAP for this release. In the user interface, the user will need to select one or more (n) of a list.
DR25	Case Report Content	7.1.1.2, 7.1.1.3 Incorporate PH/AE trigger data and reporting specifications. Not sufficient support yet	HL7 EDCI standard under ballot in progress
DR25	Case Report Content	7.1.1.3 Incorporate AE trigger data and reporting specifications. FDA forms for SPL; Form structure is there, but not the logic behind it	Work with SDOs to create a minimum number of standards for PH case reporting and AE reporting
DR25	Case Report Content	7.1.1.2, 7.1.1.3 Incorporate PH/AE trigger data and reporting specifications. Forms section- HITSP the industry recognized need for development of standardized forms, but the forms development is an area of gaps. Forms sections have some things to start with. LOINC is not complete for this	Work with SDOs to create a minimum number of standards for PH case reporting and AE reporting
DR25	Case Report Content	8.2.2.2 Action: Communicate case or patient specific information. No Standards for structure Clinical Reports sent from PH to HC Provider	Work with SDOs to create a minimum number of standards for PH case reporting and AE reporting
DR25	Case Report Content	8.2.2.3 Action: Receive specific clinically relevant Public Health information No Standards for structure Reports sent from PH to Public	Work with SDOs to create a minimum number of standards for PH case reporting and AE reporting.
DR25	Case Report Content	8.3.1.2a Alternate Action: Send information related to previously reported PH Cases and/or other information may be sent to Public Health No standards for supplemental information reports	Work with SDOs to create a minimum number of standards for PH case reporting and AE reporting
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case 7.2.1.4 Reports or AE Reports to Public Health. 8.1.1 2 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications. 8.2.1.2 Action: Receive additional information to assist in investigation activities. Action: Send information to Public Health related to previously reported PH Cases and/or other information. No consolidation of overlapping methods for Case reporting and AE reporting	Better harmonize the data elements across the Use Case which will make the generation of the standards easier. AHRQ in partnership with FDA, CDC, DOD, IHS, and VA is developing and will publish a set of data safety data elements in common format for use by the PSOs to exchange data. This should be reconciled with the dataset that will inform the development of a construct for communication of the adverse event data. Support efforts currently underway to create within the SDOs harmonized standards for the adverse event reports. Recommend that the SDOs prepare standards for the transmission of this payload
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to public health. 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications. 8.1.1 2 Action: Receive additional information to assist in investigation activities. 8.2.1.2 Action: Send information to public health related to previously reported PH Cases and/or other information There are gaps for standards for AE reporting Vocabularies to describe the event for regulatory domain are MedDRA, but not used by EHR It is not clear what organization is the owner of non-drug, device, HAI or previously defined events	Refer to AHIC and ONC or other appropriate bodies to identify some organization within this group to help deal with the policy and data and reporting requirements. Evaluate harmonized cross-agency data set to determine whether the result will support these data and reporting requirements. Listed Never Events: the category to capture falls, sores, non-infectious surgical complications; criminal events. Incident categories are not fully defined efforts with WHO patient safety taxonomy, NQF NOTE: Messaging do not see the point of introducing another AE message deferring because there are discussions under way to address this issue
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to public health. 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications. 8.1.1 2 Action: Receive additional information to assist in investigation activities. 8.2.1.2 Action: Send information to Public Health related to previously reported PH Cases and/or other information. Vocabularies used across the models are not standardized in HL7	HL7 is looking to standardized the vocabularies across HL7 internal and external Adopt SDO-defined vocabularies where possible
IER26	Identify communication recipients	8.1.5.1 Action: Receive additional information to assist in investigation activities. Possible gap for identifying party to whom to communicate this information; Policy consideration	Refer to policy specifications

4.3 Standard Overlaps

This section describes the instances where there are overlaps among standards for the Use Case requirements. The overlap is only relative to the specific Use Case requirement. Overlaps refer to instances wherein some of the requirements are met by multiple standards. Recommended resolutions were developed through a series of steps including the Technical Committees initial recommendations, cross Technical Committee validation of the overlap, provisional recommendations and peer review by the Technical Committees.

The table below presents the identified overlaps and the respective resolution plans.

Requirement Number	Summary Description	Standard Overlap	Recommended Resolution
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to public health. 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications. 8.1.1 2 Action: Receive additional information to assist in investigation activities. 8.2.1.2 Action: Send information to Public Health related to previously reported PH Cases and/or other information. 7.1.1.2 Action: Incorporate PH trigger data and reporting specifications. 7.1.1.3 Action: Incorporate AE trigger data and reporting specifications. 7.1.6.1 Action: Information related to possible PH Cases or Aes that is not available through an EHR is manually gathered. 7.1.6.2 Action: Information related to possible PH Cases or Aes that is not available through an EHR may be gained through electronic information exchanges. 8.1.1.1 Action: Request information from submitters of reports/information. 8.2.1.1 Action: Receive request for additional information from Public Health. CDISC Anatomical Site List Overlap SNOMED	Refer to Foundations
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to Public Health. 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications. 8.1.1 2 Action: Receive additional information to assist in investigation activities. 8.2.1.2 Action: Send information to Public Health related to previously reported PH Cases and/or other information. There is an active migration/harmonization to enable the adoption of the same standards across multiple organizations for Patient Safety: ISO ICSR : HL7 ICSR 3 HL7 ICSR 2 ICH-E2B Notifiable Disease Condition Generic Incident Notification (GIN) Root cause and Underlying factors Message (RUM) ICSR 2 flavors: 1) International conference of Harmonization E2B; does not cover vaccines, devices or food; does not include combination products (e.g. drug/device, drug/biologic) only supports use of MEDRA; extends use of MEDRA to code surgical, disease conditions; discussion using to code lab; MEDRA has incorporated some of the lab code test names; AE; 2) HL7 ICSR developed as a broader Use Case next release is what FDA is trying to get international consensus; HL7 includes food, devices and medications, and vaccines	Harmonization effort is under way Version 3 is expected to expand version 2 to include food, cosmetics, devices, drugs, and possibly veterinary. Work may be informed by ISO TR22224 Once SDO harmonization is complete, we should incorporate the resulting work into a HITSP construct to communicate the payload
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to Public Health 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications 8.1.1 2 Action: Receive additional information to assist in investigation activities 8.2.1.2 Action: Send information to Public Health related to previously reported PH Cases and/or other information Healthcare Associated Infections (HAI), CDC, CMS, AHRQ States dont necessarily align with the same definition and list of HAIs than those required by CDC Over the last decade, difficulty on agreeing on standards for harmonizing adverse event reporting	Request harmonization of state and federal definitions for HAIs from the CSTE HHS/PSOs may become appropriate bodies for managing standardization of reporting for Hospital/Institutional Acquired Infections
DR25	Case Report Content	7.1.6.3 Action: Update PH Case Report or AE Report. 7.1.7.2 Action: Transmit confirmed PH Case Reports or AE Reports to Public Health 7.2.1.4 Action: Communicate reporting criteria for both PH Cases and Aes. Reporting criteria include: trigger data and reporting specifications 8.1.1 2 Action: Receive additional information to assist in investigation activities 8.2.1.2 Action: Send information to public health related to previously reported PH Cases and/or other information. PH Case Reporting No official standard, but there are numerous attempts to create one See Appendix 6.2 for details	standardization workgroup within CSTE body to adjudication PHCS reporting standards Case Reporting WG reports to Surveillance Coordination Group which in turn reports to PH Informatics Team. The PH Informatics team passes it on to CSTE membership for approval This should be reconciled with the dataset that will inform the development of a construct for communication of the public health case event data Recommend that the SDOs prepare standards for the transmission of this payload. Monitor and contribute to these efforts
DR25	Case Report Content	CDISC has started a list of ~300 anatomical sites; Looking for 100 +/- sites (e.g. upper right arm) Overlap possible HL7 Bodysite/CDISC Want major gross anatomical sites involved with clinical procedures	Recommend harmonization between CDISC and HL7 (RCRIM, OO referral)
DR25	Case Report Content	Patient County: The county of the address of the subject of the case report - US-GNIS; 3166-2 or -3?	Selection deferred pending further analysis from CMHR