ISA Timeline and Comment Process

Comments on the ISA are accepted year-round, and changes are made to the web version of the ISA frequently throughout the year, based on comments and other changes to the health IT standards environment as ONC becomes aware of them. An annual Review and Comment period also occurs each summer-fall, when a majority of comments are received. See the process timeline below for more details. 

Annual ISA Process Timeline

  • January: Current Year Reference Edition is published, web version of ISA is available for ongoing review and comments.
  • Winter/Spring/Summer: Changes may be made to the web-version of the ISA throughout the year, while the ISA Reference Edition remains static.
  • Late Summer/Early Fall: Annual Review and Comment Period opens for sixty days - site changes are on hold so all reviewers are seeing the same content. 
  • Fall: ONC and HHS staff review comments received, make site updates and prepare the following year's Reference Edition for publication by early January. 

How to Comment on the ISA

  • An ISA site account is required in order to comment on the ISA.
    • If you have an account already, click the "Login" button at the top right of the ISA. 
    • To create an account, click the "Login" button, then "Create new account" tab above the login window. Account approval is required, and is generally completed within 1 - 24 hours. 
  • Once you're authenticated to the ISA site, you can submit comments on most ISA pages - just scroll to the bottom of the relevant page, enter the text of your comment (or provide attachments, if needed) and submit. Your comment will be reviewed by ONC or other HHS subject matter experts, and changes will be considered for publication to the ISA. 
  • While comments by topic (posted to individual Interoperability Need pages) are preferred, and allow greater visibility to your comments by other industry stakeholders, consolidated comment letters are also accepted. You may provide these comments on general information pages, and ONC staff will triage them, and assign them to subject matter experts. 

 

Comment

Submitted by bheale on 2023-09-16

Support of including genetic data elements and recommendations

The opportunity to provide input to streamline interoperability is much appreciated; thank you. My background extends from molecular biology and bioinformatics research to practical operational implementation within a hospital system (including clinical decision support). Computable accessibility of genetic data is a requirement for accurate use in processes such as clinical decision support, discovery, operational intelligence, and business intelligence and for use in the care of patients who are moving away from traditional one-on-one relationships with their providers to more complex relationships with multiple systems. This is especially true in the case of patients with multiple chronic conditions. For utility in receiving more discrete genetic data, look no further than the TIER 1 conditions as a prime example of what can be done today (https://www.cdc.gov/genomics/implementation/toolkit/index.htm).    From an operational perspective, genetic data is largely being sent in a non-discoverable way through PDFs. As such, the data is typically lost to further use or clinical decision support. And, the data is very easy to miss during clinical care.  Only the ordering provider is likely to know that a genetic test includes a specific region of genetic variation. And the ordering provider will find the data difficult to return to.   As part of GenomeX (within CodeX), pilots are providing implementation lessons in genomic data implementation of the HL7 FHIR Genomics Reporting Implementation Guide and FHIR Genomics Operations for exchange between systems. Additionally, both the HL7 FHIR Genomics Reporting Implementation Guide and FHIR Genomics Operations have been used in the Sync for Genes pilots. To close, EPIC is an example of a system receiving genetic data as more discrete data elements today, in line with the recommendations below. Please consider these recommendations, and thank you for your time. Recommendations: Variant data -  Further clarify constituent parts in the definition or break into fields as indicated in sections 4.2.1, 4.2.2, and 4.4 of http://hl7.org/fhir/uv/genomics-reporting/sequencing.html. The HL7 FHIR Genomics Reporting standard is a product of decades and thousands of hours of input by experts in healthcare systems, laboratories, bioinformatics, and clinical practice. It is the vehicle used in the Sync4Genes ONC pilots. The data elements identified provide a discrete representation of genetic positional data. Gene Studied – note that the gene symbol is not sufficiently unique to disambiguate between genes. The HGNC provides a gene ID# (e.g HGNC:3236 for EGFR, https://www.genenames.org/data/gene-symbol-report/#!/hgnc_id/HGNC:3236. E.g of overlap HGNC:1325 and HGNC:1328), which is unique and positively identifies a gene. Using the symbol alone risks confusion between genes whose previous or alias symbols match an approved symbol (this comes from the historical use in publications). Variant Interpretation – This has been modeled by the HL7 FHIR Clinical Genomics working group to parse out several types of interpretation. Recommend review and determine how to incorporate in the definition or consider breaking into sub-elements.  Molecular implication http://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-molecular-consequence.html In interpreting variants, it is common practice to indicate ‘feature-consequence’ (change to a molecular component of gene expression) or ‘functional-effect’ (higher-level functional outcome on the functional aspects of the gene product). Therapeutic implication http://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-therapeutic-implication.html In interpreting variants, it is common practice to indicate potential therapeutic indications or counter-indications. Diagnostic implication  http://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-diagnostic-implication.html In interpreting variants, it is common practice to indicate a potential diagnosis or the effect the variant has on a possible diagnosis. This includes the important concept of ‘clinical significance.’ Variant Type – consider renaming to Molecule type. Typically, the type of molecule sequenced (amino-acid, RNA, DNA, polysaccharide, etc…) appears within reports. It is a very useful atomic data element. Sometimes, the phrase variant type is used to mean the structural type of the change. The current element name could be confusing.

Submitted by Chris Shawn on 2022-09-29

USCDI Data Element to Level 2: Veteran Status

Based on our recent work completed by the VHA Knowledge Based Systems (KBS), Clinical Informatics and Data Management Office (CIDMO) in collaboration with the Department of Defense, the Federal EHR Modernization, CDC NIOSH, and HL7 it is timely to promote the Veteran Status  (https://www.healthit.gov/isa/uscdi-data/veteran-status) to Level 2. Veteran Status as well as combat history are relevant to assessing certain health risks. The  proposed change is supported  by approved HL7 FHIR Implementation Guide and Connectathon activities illustrating the use of this data element to support Social Determinants of Health and the Gravity Project HL7 accelerator. Connectathon reference: https://confluence.hl7.org/display/FHIR/CMS2021-07+Military+and+Veteran+SDOH FHIR IG:  https://hl7.org/fhir/us/military-service/2021sep/index.html. USCDI: Veteran Status | Interoperability Standards Advisory (ISA) (healthit.gov)

Submitted by MeganBoyd_Invitae on 2022-09-27

Support including Genomics in USCDI v4

Invitae comments in support of elevating the Genomics Data Class to Level 2 and including in USCDI v4. Please find our comments attached. 

Invitae_USCDIv4_Sept2022.pdf

Submitted by Ralph O'Connor on 2022-09-14

Sharing race/ethnicity data between systems

Is there a requirement that race/ethnicity be shared along with other medical information?         The clinic where I volunteer has an EHR interface with the state's immunization registry that seems to only upload data on the immunization but race/ethnicity have to be entered manually. Is this not an interoperability requirement?       I have also volunteered with our local health department's COVID-19 data quality team for almost two years. Most of the Electronic Health Records for positive COVID-19 PCR tests that labs send to the state's online notifiable disease system do not include race and ethnicity. In addition, about 10 % of the ELRs don't have a valid phone number (no phone or area code repeated etc.) and about 5 % do not have a valid residential address for the person (no address or the address of the testing facility etc.). Is there a way to fix this on the front end? We spend most of our time tracking down this missing data. Thanks.                

Submitted by mxenakis@virtua.org on 2022-08-16

Patient Naming Policy

I support AHIMA's Patient Naming Policy to improve patient safety.

Submitted by mbkurilo@immre… on 2022-05-06

AIRA Comments

On behalf of the American Immunization Registry Association (AIRA) we are pleased to submit comments on the Office of the National Coordinator’s (ONC’s) updated Interoperability Standards Advisory. These comments are a compilation of the input of our members which include over 80 organizations representing Public Health Immunization Information Systems (IIS), IIS implementers and vendors, non-profit organizations and partners. Immunization Information Systems interface with a broad range of stakeholders, including providers, pharmacists, schools, child care facilities, health plans and payers, among others. Most of AIRA's comments were uploaded on specific pages, but the comment below likely needs a new page: AIRA proposes the addition of a new HL7-balloted Implementation guide for Immunization Decision Support Forecast (http://hl7.org/fhir/us/immds/). This emerging FHIR R4 standard has been balloted through HL7, published, and is in use in several pilots and/or proof of concepts. AIRA is happy to discuss in greater detail how to represent this new standard on the ISA. We believe this should fit nicely within Content/Structure or Services/Exchange Standards within their respective Clinical Decision Support sections. Thank you for the opportunity to provide comments, and please let us know if there are any follow up questions. 

Submitted by Kelly Gwynn on 2021-09-30

DirectTrust's Comments on ISA

Thank you for the opportunity to comment on the Interoperability Standards Advisory.  See attached. 

ISA Updates 2021 0930 v2.xls