ISA Timeline and Comment Process

Comments on ISA : Case Reporting to Public Health Agencies

Email: POC(s): Laura Conn lbk1@cdc.gov

URL in ISA:  http://www.healthit.gov/isa/case-reporting-public-health-agencies

The comments for case reporting to public health agencies are included in the attached word document. 

eCR-Comments_ONC_Interoperability_Standards_Advisory_(ISA) 10 2 2023.docx

Comments on the ISA and USCDI

The Washington State Medicaid Agency, the Health Care Authority (HCA), appreciates the opportunity to submit comments to the Office of the National Coordinator for Health IT (ONC) on the Interoperability Standards Advisory (ISA) and the United States Core Data for Interoperability (USCDI).  The HCA submits comments in the attached letter on the following topics:

• Advance Directives/Mental Health Advance Directives
• Patient Demographic Record Matching and Patient Identity/Identification Management
• Patient Preference/Consent
• Race/Ethnicity
• Publish and Subscribe Message Exchange

SHCAPRCSP5523100414530 WA State HCA Comments ISA and USCDI.pdf

Academy of Nutrition and Dietetics comments on 2023 ISA

On behalf of the Academy of Nutrition and Dietetics, thank you for the opportunity to provide feedback on the Interoperability Standards Advisory. We have attached our comments for your consideration.

Academy of Nutrition and Dietetics ISA Comments_2023.pdf

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.

ePOLST Advanced Care Planning standard

The ePOLST: Portable Medical Orders about Resuscitation and Initial Treatment is listed as "In Development".  Actually, it was 

successfully balloted and was published in early October 2022:

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=600

ISA 2022_FEHRM Formal Comment Coordination (Final) 20221007_v2.0

Please see attached for FEHRM comments. 

ISA 2022_FEHRM Formal Comment Coordination (Final) 20221007_v2.0.xls

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)

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

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.