ISA Timeline and Comment Process


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 (    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 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,!/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 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 In interpreting variants, it is common practice to indicate potential therapeutic indications or counter-indications. Diagnostic implication 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.

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  ( 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: FHIR IG: USCDI: Veteran Status | Interoperability Standards Advisory (ISA) (

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. 


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.                

Patient Naming Policy

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

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 ( 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. 

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