Introduction to the ISA

The annual ISA Review and Comment period is now open, ending on September 23rd at 11:59pm ET. See the latest Health IT Buzz blog post for more details, and don't miss this year's questions for stakeholder feedback.

The Interoperability Standards Advisory (ISA) process represents the model by which the Office of the National Coordinator for Health Information Technology (ONC) will coordinate the identification, assessment, and public awareness of interoperability standards and implementation specifications that can be used by the healthcare industry to address specific interoperability needs including, but not limited to, interoperability for clinical, public health, and research purposes. ONC encourages all stakeholders to implement and use the standards and implementation specifications identified in the ISA as applicable to the specific interoperability needs they seek to address. Furthermore, ONC encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in the ISA. For historical background on the ISA please review prior ISA publications.

The 2019 ISA has been updated to include improvements made based on recommendations received from public comments and subject matter expert feedback. To learn more about major revisions of the ISA, please review recent ISA updates. Registered users may subscribe to change notifications to be alerted by e-mail of all revisions to individual interoperability needs or for ISA-wide changes. Anyone may become a registered user by submitting an account request. Once logged in, look for the blue “change notification” button at the bottom of the interoperability need page, or at the bottom of the home page to be notified of any changes across the ISA. An RSS Feed was also added in 2018, capturing more granular updates made to the ISA.

Scope

Starting with the 2017 ISA, the ISA’s focus expanded to more explicitly include public health and health research interoperability. Thus, its scope includes electronic health information created in the context of treatment, and subsequently used to accomplish a purpose for which interoperability is needed (e.g., a referral to another care provider, public health reporting, or research). Added in late 2017, the ISA now also includes interoperability needs related to Administrative functions within healthcare. These additions were made through coordination with CMS, and it is anticipated to include other administrative healthcare interoperability needs going forward.

The ISA is not exhaustive but it is expected to be incrementally updated to include a broader range of health IT interoperability needs. When more than one standard or implementation specification is listed it is intended to prompt industry dialogue as to whether one standard or implementation specification is necessary or if the industry can efficiently interoperate more than one. It may also reflect the fact that there is an ongoing transition from the use of one standard towards a new version or even next-generation approach.

As noted in previous ISA publications, a standard listed in one section is not intended to imply that it would always be used or implemented independent of a standard in another section. To the contrary, it will often be necessary to combine the applicable standards from multiple sections to achieve interoperability for a particular clinical health information interoperability need.

It is also important to note that the ISA is designed to inform standards and implementation specification choices for all types of health IT that support interoperability needs, not solely electronic health record (EHR) systems. Furthermore, the ISA is not intended to imply that health IT systems need to support all of the listed standards and implementation specifications. Rather, in the event that a health IT developer or healthcare provider seeks to address a particular interoperability need, the ISA should serve as the first resource consulted to inform the selection of standards and implementation specifications. Additionally, the ISA is designed to inform the “what” that could be used to address an interoperability need in order to assure industry consistency around standards selection and is not mean to explicitly direct “how” the standards and implementation specifications would be implemented to address an interoperability need (e.g., application programming interface or conversion tools).

The ISA is designed to be a coordinated catalog of standards and implementation specifications that can be used by different stakeholders to consistently address a specific interoperability need. However, a listed interoperability need (and its associated standard(s) and implementation specifications(s)) is not meant to universally apply to all stakeholders. Rather, if a listed interoperability need is relevant to a particular clinical specialty, for example, the ISA is designed to provide a consistent foundation from which these stakeholders can agree on applicable technical requirements. Similarly, in cases where a listed interoperability need is not applicable to a given stakeholder group, the ISA in no way compels such stakeholders to consider that interoperability need.

Purpose

The Interoperability Standards Advisory is meant to serve at least the following purposes:

To provide the industry with a single, public list of the standards and implementation specifications that can best be used to address specific clinical health information interoperability needs. Currently, the ISA is focused on interoperability for sharing information between entities and not on intra-organizational uses.
To reflect the results of ongoing dialogue, debate, and consensus among industry stakeholders when more than one standard or implementation specification could be used to address a specific interoperability need, discussion will take place through the ISA public comments process. The web-version of the ISA improves upon existing processes, making comments more transparent, and allowing for threaded discussions to promote further dialogue.
To document known limitations, preconditions, and dependencies as well as provide suggestions for security best practices in the form of security patterns for referenced standards and implementation specifications when they are used to address a specific clinical health IT interoperability need.

The ISA is designed to provide clarity, consistency, and predictability for the public regarding the standards and implementation specifications that could be used for a given clinical health IT interoperability purpose.

Stakeholders who administer government programs, procurements, and testing or certification programs with clinical health IT interoperability components are encouraged to look first to the ISA in order to more fully inform their goals. In that regard, standards and implementation specifications in the ISA and their associated informative characteristics are also available to help more fully inform policymaking. In this case, a standard or implementation specification’s reference in the ISA may serve as the initial basis for industry or government consideration and action. While the ISA itself is a non-binding document and meant to be advisory in nature, standards and implementation specifications listed in the ISA may be considered for rulemaking or other Federal requirements. However, those decisions would be made on a case-by-case basis by the administering organization.

This site contains numerous links to other federal agencies and to private organizations. You are subject to these sites’ privacy policies when you access them. HHS is not responsible for Section 508 compliance (accessibility) on other federal or private sites. HHS is not responsible for the contents of any "off-site" web page referenced from this site.

ISA Structure

The ISA is organized and structured into five sections.

Section I – Vocabulary/Code Sets/Terminology Standards and Implementation Specifications (i.e., “semantics”).
Section II – Content/Structure Standards and Implementation Specifications (i.e., “syntax”).
Section III – Standards and Implementation Specifications for Services (i.e., the infrastructure components deployed and used to address specific interoperability needs)
Section IV – Administrative Standards and Implementation Specifications (i.e., payment, operations and other "non-clinical" interoperability needs)
Questions and Requests for Stakeholder Feedback
Appendices

Within each section specific “interoperability need” subheadings are listed and followed by tables similar to the one illustrated below. Each interoperability need may have one or more standards and/or implementation specifications associated with it. Each standard and implementation specification has six informative characteristics attributed to it in order to provide added context.

When known, an “emerging” standard or implementation specification is also listed and is shaded in a lighter color and italicized for additional emphasis. In addition, for vocabulary standards, where there may be one standard used to represent the “observation” or question being asked, and one standard used for the “observation value” or answer these are listed in distinct rows. See Appendix III for educational information about observations and observation values.

The ISA also includes links within the limitations, dependencies and preconditions to ONC’s Interoperability Proving Ground (IPG) to showcase real-world implementations of standards listed within the ISA. Please note: when accessing links to the IPG, all projects for the selected standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs. In addition, IPG entries are self-reported by stakeholders, so the quality and accuracy of the data may vary across entries.

In Section I, the vocabulary standards with unspecified code sets or context may be further constrained by a more explicit standard named in a subsequent section. For example, Section I: Encounter Diagnoses specifies SNOMED-CT and ICD-10-CM but does not define the context of use. The Standard/Implementation Specification named for the “Interoperability Need: Ordering Labs for a Patient in Section II: Laboratory” further constrains the diagnosis for the patient in the context of a lab order to ICD-9CM or ICD-10CM since the lab order diagnosis is for billing/claims, not clinical diagnostics.

Interoperability need: [Descriptive Text]
Standard Implementation/Specification	Standards Process Maturity	Implementation Maturity	Federally Required	Cost	Test Tool Availability
Standard	Final	Production	No	Free	No
Standard for observations	Final	Production	Yes	Free	Yes
Standard for observation values	Final	Production	No	Free	Yes
*Emerging Standard*	Balloted Draft	Pilot	No	Free	No

Limitations, Dependencies, and Preconditions for Consideration:	Section I: Applicable Value Set(s) and Starter Set(s): Other Sections: Applicable Security Patterns for Consideration:
In the case where there is a need to reflect a conformance statement, the verbs “must” and “shall” will reflect an absolute requirement and the verbs “can” and “may” reflect optionality. Where standards listed for an interoperability need have active projects listed on ONC’s Interoperability Proving Ground, a link to that standard will be provided in this section. Please note, all projects for the standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs.	Descriptive text

Limitations, Dependencies, and Preconditions for Consideration:

Section I: Applicable Value Set(s) and Starter Set(s):

Other Sections: Applicable Security Patterns for Consideration:

In the case where there is a need to reflect a conformance statement, the verbs “must” and “shall” will reflect an absolute requirement and the verbs “can” and “may” reflect optionality.
Where standards listed for an interoperability need have active projects listed on ONC’s Interoperability Proving Ground, a link to that standard will be provided in this section. Please note, all projects for the standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs.

Descriptive text

The following describes the ISA’s six informative characteristics in greater detail. This detail is meant to better inform stakeholders about the maturity and adoptability of a given standard or implementation specification and provides definition for the terms and symbols used throughout the ISA. Stakeholders should consider all six characteristics together to gain insight into the level of maturity and adoptability of the standards and implementation specifications provided within the ISA.

#1: Standards Process Maturity
This characteristic conveys a standard or implementation specification’s maturity in terms of its stage within a particular organization’s approval/voting process.

“Final” – when this designation is assigned, the standard or implementation specification is considered “final text” or “normative” by the organization that maintains it. This also includes approved “ANSI Informative” specifications.
“Balloted Draft” – when this designation is assigned, the standard or implementation specification is considered to be a Draft Standard for Trial Use (DSTU), Standard for Trial Use (STU), or in a “trial implementation” status by the organization that maintains it and has been voted on or approved by its membership as such. This designation does not include standards and implementation guides that are unofficial drafts and early “works in progress”.
“In Development” – when this designation is assigned, the standard or implementation specification is currently in development. It also includes those that are in the midst of being balloted. These standards would generally benefit from lessons learned through development and pilots.

#2: Implementation Maturity
This characteristic conveys a standard or implementation specification’s maturity based upon its implementation state. Where available, a link to published maturity assessments based on known published criteria about the standards is also provided.

“Production” – when this designation is assigned, the standard or implementation specification is being used in production to meet a health care interoperability need.
“Pilot” – when this designation is assigned, the standard or implementation specification is being used on a limited scale or only as part of pilots to meet a health care interoperability need.

#3: Adoption Level
This characteristic conveys a standard or implementation specification’s approximate, average adoption level for that specific interoperability need in health care within the United States. The adoption level attempts to consider all implemented technology that would be used to address the identified interoperability need and is not limited to EHRs. Adoption means that the standard or implementation specification is being used in health IT in the field by end users to address the specific interoperability need. Presently, the adoption levels listed are based on ONC’s analysis of several factors, including, but not limited to: 1) whether and/or how long a standard or implementation specification has been included in regulation for health IT certification (if applicable) or another HHS regulatory or program requirement which is used only as a proxy for industry adoption; 2) feedback from subject matter experts and 3) public comments.

The adoption level also considers the variety of stakeholders and stakeholder groups that would use the standard and implementation specification to address the specified interoperability need and attempts to display it as such, with the understanding that the designation is a generality or "best guess" and not a pre-defined measured value. Where available, annotated references or links to publicly available documentation known about adoption levels for listed standards are also provided.

The following scale is used to indicate the approximate, average adoption level among the stakeholders that would use a standard or implementation specification to meet the specified interoperability need:

“Feedback Requested”	Indicates that we do not have a known status for the current level of adoption in health care.
	Indicates low adoption.
	Indicates low-medium adoption.
	Indicates medium adoption.
	Indicates medium-high adoption.
	Indicates high or widespread adoption.

#4: Federally Required
This characteristic (provided as a “Yes” or “No”) conveys whether a standard or implementation specification has been adopted in regulation, referenced as a federal program requirement, or referenced in a federal procurement (i.e., contract or grant) for a particular interoperability need. Where available, a link to the regulation has been provided. Please note this is meant to be provided as a reference only. Entities seeking to comply with federal regulations should look to any and all federal regulations that may apply to ensure adequate compliance.

#5: Cost
This characteristic conveys whether a fee is involved to purchase, license, or obtain membership for access or use of the recommended standard or implementation specification.

“$” – when this designation is assigned, it signifies that some type of payment needs to be made in order to obtain the standard or implementation specification. Where known, the estimated cost for access will be provided.
“Free” – when this designation is assigned, it signifies that the standard or implementation specification can be obtained without cost. This designation applies even if a user account or license agreement is required to obtain the standard at no cost, but is not meant to imply that there are no costs associated with implementation.

#6: Test Tool Availability
This characteristic conveys whether a test tool is available to evaluate health IT’s conformance to the standard or implementation specification for the particular interoperability need. Where available, a link will be provided to the publicly available test tool.

“Yes” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is free to use. Where available, a hyperlink pointing to the test tool will be included.
“Yes^$”– When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and has a cost associated with its use. Where available, a hyperlink pointing to the test tool will be included.
“Yes – Open” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is available as open source with rights to modify. Where available, a hyperlink pointing to the test tool will be included.
“No” – When this designation is assigned, it signifies that no test tool is available for a standard or implementation specification.
“N/A” – When this designation is assigned, it signifies that a test tool for the standard or implementation would be “not applicable.”

Comment

Submitted by sjonnaert on 2017-11-14

Dear Madam,…

Dear Madam,
Dear Sir,

On behalf of the IVD Industry Connectivity Consortium we are pleased to provide written comments to the Office of the National Coordinator for Health Information Technology (ONC) in response to the 2017 Interoperability Standards Advisory (ISA).

The IVD Industry Connectivity Consortium (IICC) is a global, nonprofit organization dedicated to creating and encouraging adoption of a unified connectivity standard to reduce the cost and variability of data exchange between IVD devices and healthcare informatics in clinical laboratories. This will improve healthcare efficiency and patient care.

The IICC has collaborated with several government bodies, including the US Food and Drug Administration (DMD/OIR/CDRH), US Centers for Disease Control and Prevention, and US Department of Health and Human Services (HHS) (ONC), National Institutes of Health (NIH), and industry organizations such as IHE International, HL7, Clinical & Laboratory Standards Institute, the College of American Pathologists, the Association of Public Health Laboratories (APHL), the Medical Device Innovation Consortium (MDIC), and the Regenstrief Institute to develop two standards that together allow for true Plug & Play connectivity of IVD instruments to Middleware and Laboratory Information Systems (LIS).

The IVD Industry Connectivity Consortium appreciates the opportunity to leverage our volunteers’ expertise in commenting on the Standards Advisory, and we look forward to continuing our dialogue with ONC on identifying, assessing, and determining the best available interoperability standards and implementation specifications. We feel that this effort will provide the necessary foundation for more rapidly advancing interoperability.

The IVD Industry Connectivity Consortium finds that it would be beneficial if ONC would add the LAW – Laboratory Analytical Workflow Profile and LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results standards to the following proposed new sections:

Section II: Content/Structure Standards and Implementation Specifications > Interoperability Need: Identify linkages between vendor IVD test results and standard codes

Type	Standard/Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally Required	Cost	Test Tool Availability
Standard	LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results	Final	Production	1	No	Free	No

Section II: Content/Structure Standards and Implementation Specifications > Interoperability Need: Connectivity between instruments, middleware, and LIS systems

Type	Standard/Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally Required	Cost	Test Tool Availability
Standard	LAW – Laboratory Analytical Workflow Profile	Final	Production	3	No	Free	Yes

LAW – Laboratory Analytical Workflow Profile – The LAW Profile defines the physical connection, message definitions (based on the HL7 Messaging Standard v2.5.1), and workflow definitions between instruments, middleware, and LIS systems in the laboratory. IICC collaborated with the IHE Pathology and Laboratory Medicine (PaLM) domain to develop the LAW Profile. LAW is already implemented by all major IVD companies, including Abbott Laboratories, Beckman Coulter, BD, bioMerieux, Data Innovations, Orchard Software, Ortho Clinical Diagnostics, Roche, Siemens Healthineers, Systelab, Sunquest, and Werfen Group.

For more information on LAW [ click here ]

LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results – Defines the digital publication of LOINC using vendor defined IVD tests associated with a set of predefined LOINC codes. LIVD assures that laboratory personnel select the appropriate LOINC codes for IVD test used by their laboratory. It also allows LIS systems to automatically map the correct IVD vendor test result to a LOINC code. LIVD was developed in collaboration with the members of the FDA IVD Semantic workgroup.

For more information on LIVD [ click here ]

Why are LAW and LIVD important for clinical laboratories?

The LAW Profile and LIVD specifications should have a significant positive impact on laboratory operations. Clinical laboratories are encouraged to ask their instrument, middleware, and LIS vendors about their current or planned support for the IICC/IHE Laboratory Analytical Workflow (LAW) and LIVD. The LAW Profile is currently being implemented by all major IVD companies.

LAW and LIVD will significantly reduce the time and cost involved with deploying, connecting, and updating instruments in the laboratory by eliminating the need for vendor customized connectivity implementations, favoring vendors that adopt the specifications and pass the savings to their customers.
Addresses all the shortcomings of outdated laboratory connectivity standards such as CLSI LIS1-A (ASTM 1391) and CLSI LIS2 (ASTM E1394).
LAW will be a global standard (CLSI AUTO16).
LAW and LIVD support federal guidelines on Meaningful Use.
Improves the integrity of patient data.
The LAW and LIVD specifications are available for download and do not require any licensing or fees for implementation.

The IVD Industry Connectivity Consortium (IICC) would also ask ONC’s support to make both standards “Federally Required” for federal agencies as well as commercial entities.

We appreciate the opportunity to submit comments on the 2017 ISA. Our comments are intended to recognize the importance of each stakeholder’s role in advancing standards-based interoperability and health information exchange, and ensuring that each domain is invested in overcoming the inherent challenges, while further enhancing health IT’s pivotal role in enabling healthcare transformation.

Please feel free to contact me if you have any questions or to obtain more information.

Sincerely,

Serge Jonnaert, BiD
President, IVD Industry Connectivity Consortium - https://ivdconnectivity.org/
serge.jonnaert@ivdconnectivity.org
+1.949.259.3807
/ Board Member, At-Large - IHE International - ihe.net
/ President, AERTWORKS® LLC – http://www.aertworks.com

Submitted by Meryl Bloomrosen on 2017-11-15

Premier healthcare alliance: Comments on ISA

Dear Dr. Rucker,

The Premier healthcare alliance is pleased to submit these comments in response to the Office of the National Coordinator’s (ONC) Request for Public Comments regarding the Interoperability Standards Advisory (ISA).

Premier is a leading healthcare improvement company, uniting an alliance of approximately 3,900 U.S. hospitals, hundreds of thousands of clinicians and more than 150,000 other provider organizations. Premier has one of the most comprehensive and largest healthcare databases in the industry. Premier works with its members on utilizing informatics, analytics, and data to improve care quality and patient safety, while achieving cost efficiencies. With integrated data and analytics, collaboratives, supply chain solutions, and advisory and other services, Premier enables better care and outcomes at a lower cost. Premier, a Malcolm Baldrige National Quality Award recipient, plays a critical role in the rapidly evolving healthcare industry, collaborating with members to co-develop long-term innovations that reinvent and improve the way care is delivered to patients nationwide. Specific comments in response to your questions are provided in the attached chart.

Premier shares the vision of achieving health information technology interoperability and the establishment and deployment of core standards and functions of health information technology (HIT) to enable an interoperable, learning health ecosystem. Premier appreciates ONC’s ongoing efforts to develop and enhance the ISA. However, the existence of standards and the publication of the ISA does not by itself ensure that application developers and HIT vendors implement and configure their software using the standards. Certainly, nationwide healthcare data exchange requires standards development and their timely adoption. Beyond exchange of data, however, interoperability requires data usability, understandability and development, recognition and adoption of common data sets, clinical terminologies and vocabularies and data definitions. Additionally, standards are needed for openly accessible electronic health record application program interfaces (APIs) to assure interoperability with other health information technologies and third party applications.

Premier hopes our comments (detailed in the attached letter) are helpful as you continue this important work. Premier stands ready to actively participate in ONC’s ongoing efforts to achieve nationwide interoperability. Please feel free to contact us for participation in your listening sessions, workgroups and other activities.

If you have any questions regarding our comments or need more information, please contact me or Meryl Bloomrosen, Senior Director, Federal Affairs, at meryl_bloomrosen@premierinc.com or 202.879.8012. We look forward to continued participation and dialogue. Thank you again for the opportunity to provide comments.

Sincerely,

Blair Childs

Senior vice president, Public Affairs

Premier healthcare alliance

Final Premier Comments on ONC 2017 Interoperability Standards Advisory_November 2017.pdf

Submitted by gdixon on 2017-11-19

Allscripts Comments on ONC 2017 Interoperability Standards

We thank you for the opportunity to review and provide as input perspectives gathered from our subject matter experts.

ISA Response Allscripts.xls

Submitted by pwilson@ncpdp.org on 2017-11-20

NCPDP - Scope Comments

Modify the first paragraph to the following: Starting with the 2017 ISA, the ISA’s focus has expanded to more explicitly include public health and health research interoperability. Thus, its scope includes electronic health information created in the context of treatment, and subsequently used to accomplish a purpose for which interoperability is needed (e.g., a referral to another care provider, public health reporting, or research).
ONC may want to consider adding verbiage around the addition of the administrative/payment oriented transactions.

Submitted by dididavis on 2017-11-20

IHE QRPH Domain Standard Addition Request

On behalf of the Integrating the Healthcare Enterprise (IHE) Quality, Research & Public Health (QRPH) Domain, I would like to submit the following for addition to the Section II: Content/Structure Standards and Implementation Specifications under the II-R: Public Health Reporting area as an emerging standard.

Interoperability Need: Requirement to submit data for the Title X Family Planning Annual Reporting process at an encounter level and in real time, in a standard format defined by OPA.

Type:               Emerging Standard

URL: http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_FPv2.pdf

Standards Process Maturity: Balloted Draft

Implementation Maturity:   Pilot

Adoption Level:       1

Federally Required:       No

Test Tool Availability:       Feedback Requested

Cost:               Free

Other Notes for Consideration: OPA is currently engaged in an overhaul of their Family Planning Annual Reporting system, to enable the reporting of encounter level data from all of their Title X sites in a standard format and via a standard methodology. OPA is currently piloting two interoperability standards through this project and is intending to begin collecting data according to this new system in 2019.

Submitted by mattreid on 2017-11-20

AMA's comments to ONC on proposed 2018 ISA

On behalf of American Medical Association (AMA) I appreciate the ability to comment on ONC's Interoperability Standards Advisory (ISA).

Section I: Vocabulary/Code Set/Terminology Standards and Implementation Specifications

Comment:

The AMA recommends that the ISA include a seventh characteristic to the interoperability need table to inform stakeholders of the presence and inclusion of the terminology’s guidelines. The use of a terminology’s guidelines is critical for consistent application of the codes and semantic interoperability of the data being exchanged through the terminology. Consistent use of codes further ensures comparability of data that can better quantify the value of care and determine outcomes. The following shows how this additional characteristic would be included in the table.

Representing Medical Procedures Performed

Type	Standard Implementation/Specification	Guidelines	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Standard	SNOMED CT®	Yes	Final	Production		Yes	Free	N/A
Standard	the combination of CPT-4 and HCPCS	CPT-4: Yes HCPCS: Yes	Final	Production		Yes	$	N/A
Standard	ICD-10-PCS	Yes	Final	Production		Yes	Free	N/A

Submitted by Mark Savage on 2017-11-20

UCSF Center for Digital Health Innovation's Comments on 2018 ISA

Dear Dr. Rucker,

UC San Francisco’s Center for Digital Health Innovation submits these comments on the 2018 Reference Edition of the Interoperability Standards Advisory. We thank you for the opportunity to provide these comments.

Very truly yours,

Mark Savage

Mark Savage

Director, Health Policy

Center for Digital Health Innovation

University of California, San Francisco

E. Mark.Savage@ucsf.edu

C. 415.225.1676

O. 415.502.1997

UCSF Center for Digital Health Innovation comment letter on 2018 ISA (11-20-2017).pdf

Submitted by lbecnel on 2017-11-20

CDISC Requests from 2018 ONC ISA

Thank you for the opportunity to provide input on the 2018 Interoperability Standards Advisory (ISA) online document. Although the catalog focuses on the implementation needs of healthcare, it will play a role in ONC’s programs that support the 21st Century Cures Act. The Clinical Data Interchange Standards Consortium (CDISC) has engaged in projects with our fellow standards development organizations such as the Regenstrief Institute, IHE and HL7 over the past year to also help support 21st Century Cures Act and other initiatives at the intersection of care and research.

CDISC believes that, in order to realize the full impact of the bill, we as a society must invest in interoperation between existing healthcare and biomedical research standards and infrastructure. We thank the ONC for recognizing the importance of research as part of a learning health system through the inclusion of CDISC standards in the ISA. Our standards provide a consensus-based global language for protocol-driven clinical and translational research. They are also part of a larger tapestry of common research standards.

Many, if not most, major components of cancer-related research infrastructure in the United States are assets of or are being/have been funded by the United States National Cancer Institute (NCI). Their Enterprise Vocabulary Services (EVS) team manages dozens of commonly used semantic structures for research, including but not limited to CDISC terminology, and health. The following recommendations and requests are in support of expanding the ISA to include appropriate semantics to support ONC’s activities toward the 21st Century Cures Act. We recommend the following updates in support of cancer, and broader, research as it pertains to the coordination of multiple agencies involved with human health and research-based evolution:

Section 1-Q Representing Analytic Data for Research Purposes: We request that the existing Clinical Data Interchange Standards (CDISC) Controlled Terminology for Regulatory Standards Hosted by NCI-EVS be updated to Clinical Data Interchange Standards Consortium (CDISC) Controlled Terminology for Data Collection (CDASH, QRS) and Aggregation (SDTM) Standards Hosted by NCI-EVS. This update refers to the specific controlled terminology packages rather than the overview page to all CDISC controlled terminologies. We also request the addition of the CDISC Controlled Terminology for Data Collection for Protocol Hosted by NCI-EVS, as these terms include semantics from academic, federal and industry projects and would support semantic interoperability of research study concepts among systems.
Section 1-Q Representing Analytic Data for Research Purposes: In order to support precision medicine, we recommend that CDISC Controlled Terminology for SDTM Pharmacogenomics Data Aggregation Hosted by NCI-EVS (Enterprise Vocabulary Services) be added to the standard. These terminologies are final and have had modest adoption by the regulated research community. We further recommend that the ISA consider the addition of longstanding and newer ‘omics and phenotype standards that are being adopted by the global genomics community through the Global Alliance for Genomics and Health (GA4GH). HL7's Clinical Genomics group is also very involved in developing standards in this area, coordinating with GA4GH and CDISC. These standards have also been utilized by many diverse genomics efforts funded by the NCI. These include, but are not limited to the Human Phenotype Ontology, HGNC gene (and other molecular) identifiers and other ontologies hosted by the NCI Metathesaurus. These terminologies and ontologies are final, not required by the FDA and have moderate to high adoption.
Section 1-Q Representing Analytic Data for Research Purposes: Many additional terminologies have been utilized by researchers from Cooperative Groups, research consortia and investigator-initiated trials. Cancer-related terminologies from these resources and others are found within the NCI-EVS. The cancer terminologies are bound to common data elements within the NCI caDSR, and these elements can help researchers to construct conformant data capture mechanisms linking data from health systems to research. These terminologies are final, not required by FDA and have moderate to high levels of community adoption.
Section 1-Q Representing Analytic Data for Research Purposes: Terminology also exist for analysis datasets that are submitted to the United States Food and Drug Administration. As such we recommend the addition of the CDISC Controlled Terminology for Analysis Dataset Model (ADaM) Hosted by NCI-EVS. The terminologies are final, required by the FDA and have had high levels of community adoption.
Section II-S: Research - Integrate Healthcare and Clinical Research by Leveraging EHRs and other Health IT Systems while Preserving FDA’s Requirements: We request the addition of required, open and highly adopted CDISC standards – the CDISC Study Data Tabulation Model (SDTM) and the CDISC Study Data Tabulation Model Implementation Guide. These standards have been utilized by diverse research teams from academia, patient advocacy groups, government and industry worldwide to aggregate data from many different real world data sources. In support of the 21st Century Cures Act and other indication-specific areas of integration of healthcare and clinical research data, we also request the inclusion of the implementation specification CDISC Therapeutic Area User Guides, which include multiple solid tumors along with dozens of other indications and conditions. There are multiple projects within the PhUSE, CDISC and other communities to map these implementation specifications to HL7 FHIR and other healthcare standards. These specifications are included in the FDA Technical Conformance Guide, but are not required, and their overall adoption is modest to moderate. Finally, we request the addition of the implementation specification CDISC Pharmacogenomics/genetics (PGx) Implementation Guide, a provisional standard with modest adoption, the maturation of which is occurring in collaboration with HL7 Clinical Genomics Working Group to bridge semantics among clinical genomicists and trialists.
Section II-S: Research - Submission of Clinical Research Data to FDA to Support Product Marketing Applications. We request that the adoption level of the CDISC SEND standard be updated from low to moderate. This required standard is being utilized for submissions to regulators for all pre-clinical genetic toxicology information. We also request the addition of the freely available, non-required standard CDISC Questionnaires, Ratings and Scales (QRS) and the implementation specification CDISC Pharmacogenomics/genetics (PGx) Implementation Guide, a provisional standard with modest adoption.

We appreciate the ONC’s consideration of these requests and suggestions.

Lauren Becnel, Ph.D.

VP Strategy & Innovation

Clinical Data Interchange Standards Consortium (CDISC)

Submitted by wgsuarez on 2017-11-20

Kaiser Permanente Comments on ONC's Proposed 2018 ISA

Please see attached document

KP Comments on the ONC proposed 2018 Interoperability Standards Advisory Reference Edition - Final - Nov 20 2017.pdf

Submitted by chills on 2017-11-20

DoD / VA Interagency Program Office (IPO) comments on 2017 ISA

Thank you for allowing us an opportunity to provide comments on the 2017 as you prepare for the 2018 version. Included within our comments are comments we also received from VHA representatives. If there are any questions regarding our comments, please let me know. This document is key to help move the Industry towards a more open and standard's based approach in exchanging Health information.

Very Respectfully,

Chris Hills

CRM_Advance Review 2018 ISA Reference Document_final.pdf