Toggle comment Display

ISA Single page with Comment


This file is created on 2024-03-18 07:02:44pm

About the ISA

Comment

Over recent years, the…

Over recent years, the healthcare industry has undergone a huge digital transformation due to the need to completely update its existing infrastructure.

ISA Comments from Washington State Department of Health

Please refer to the attached comments from the Washington State Department of Health. Thank you for the opportunity to comment.

WA_DOH_Comments_ONC_ISA_2023.pdf

AMIA's Comments on the ONC ISA 2024 Reference Edition

Please see attached the American Medical Informatics Association's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.

AMIA-ONC-ISA-Public-Comment-Letter.pdf

AMIA's Comments on the ONC ISA 2024 Reference Edition

Please see attached the American Medical Informatics Association's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.

 

AMIA-ONC-ISA-Public-Comment-Letter.pdf

AMIA's Comments on the ONC ISA 2024 Reference Edition

Please see attached the American Medical Informatics Association's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.

AMIA-ONC-ISA-Public-Comment-Letter.pdf

HL7's Feedback on the 2024 ISA Reference Edition

Please see attached Health Level Seven International's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.

HL7 Response ISA Letter 10.05.23 Final.pdf

APHL Comments on ISA 2022

APHL strongly supports the mission of the Interoperability Standards Advisory (ISA) and thus is respectfully submitting the following comments on the current version of the ISA

Vocabulary/Code Set/Terminology Standards and Implementation Specifications

General comment for this section:

In several sections the ISA lists implementation guides rather than linking to the explicit vocabulary defined in those guides (for example HL7 FHIR (v4.0.1) Situational Awareness for Novel Epidemic Response (SANER) IG 0.1.0 Continuous Build and the Logica COVID-19 (FHIR v4.0.1) Implementation Guide CI Build under COVID-19 Novel Coronavirus Pandemic , or in the referenced FHIR resources NutritionIntake  and NutritionProduct under Representing Nutrition Assessment, Diagnosis, Interventions and Monitoring/Evaluation).

#1: Suggest to review and update with the respective code systems (or value sets, if appropriate to constrain to that level).

 

- Representing Non-imaging and Non-laboratory Clinical Tests:

Currently the section under “Limitations, Dependencies, and Preconditions for Consideration” includes a bullet explaining that this attribute really consists at minimum of 2 elements,

#1 Suggest to split attribute into “Clinical Test performed” and “Clinical Test Result Value” as a main section to avoid confusion when different code systems are suggested. That way it is clear that LOINC is the coding system to identify the “Clinical Test performed”, while SNOMED CT, mostly drawn from the clinical finding hierarchy, should be used when codifying results under “Clinical Test Result Value”. Other code systems useful in this context are Unified Units of Measure (UCUM) when numeric results are reported – this is described as its own attribute (Representing Units of Measure (For Use with Numerical References and Values), but the association to result values should be pointed out here.

 

- Laboratory

-- Representing Laboratory Test Ordered

This section is missing a separate category for Specimen, which should point to SNOMED CT (from the specimen hierarchy).

#1 Suggest to add a new attribute “Specimen information” which should have the following sub-attributes, some of which are mentioned in the USCDI:

Specimen Type – referencing SNOMED CT (from the specimen hierarchy)

Specimen source site – referencing SNOMED CT (from the body structure and physical object hierarchies)

Source site modifier – referencing SNOMED CT (from the qualifier hierarchy)

Specimen collection method – referencing SNOMED CT (from the procedure hierarchy)

 

The reference to CPT is confusing as the goal is to order lab tests using LOINC wherever possible (as further defined in the Laboratory Order Interface (LOI) Implementation Guide in the Ordering Laboratory Tests for a Patient section) and the use of CPT is uncommon in this use case.  CPT codes are commonly used for billing, which should be a separate section under laboratory to accommodate the administrative use case.

#2 Suggest to remove CPT from this section and create a separate section “Representing Laboratory Test in Billing” where CPT should be listed – with the same attributes as currently in this section.

 

Content/Structure

- Laboratory

-- Exchanging InVitro Diagnostics (IVD) Test Orders & Results

LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results :

#1 Suggest to remove the ‘$’ in the “Cost” column as there is no cost associated with accessing or using this implementation guide.

 

-- Ordering Laboratory Tests for a Patient

#1Suggest to update HL7 Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 3 - US Realm to the latest version of LOI version (will provide updated name and hyperlink once published in October 2022)

#2 Suggest to update the HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm HL7 Standard for Trial Use to the latest version (will provide updated name and hyperlink once published in October 2022) in support of LOI

#3 Suggest to add this Implementation Guide from Jan 2021: HL7 Version 2.5.1 Implementation Guide: Standards & Interoperability (S&I) Framework Laboratory Test Compendium Framework (eDOS) Ask at Order Entry (AOE) Release 2, STU Release 3.1 - US Realm because it provides guidance on using the most common Ask at Order Entry questions; “Adoption Level” Emerging Standard. Of note is that this IG is not explicitly implemented, but rather used as a resource by laboratories when setting up their catalog and order messages.

 

-- Receive Electronic Laboratory Test Results

#1 Suggest to update HL7® Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Release 1, STU Release 3 - US Realm to the latest version of LOI version (will provide updated name and hyperlink once published in October 2022)

#2 Suggest to HL7® Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm, June 2018 to the latest version (will provide updated name and hyperlink once published in October 2022) in support of LRI

#3 Suggest to add the following text into “Limitations, Dependencies, and Preconditions for Consideration”: While the HL7® Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1—US Realm [HL7 Version 2.5.1: ORU_R01] Draft Standard for Trial Use, July 2012 was named in Meaningful Use and may thus be implemented at a few sites, the recommended standard for new implementations is <the new version of  HL7® Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Release 1, STU Release 3 - US Realm> because that is the specification that is actively being maintained and updated with new use cases, when needed.

 

-- Support the Transmission of a Laboratory’s Directory of Services to Provider’s Health IT or EHR System

#1 Suggest to HL7® Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm, June 2018 to the latest version (will provide updated name and hyperlink once published in October 2022) in support of eDOS

#2 Suggest to add HL7 Version 2.5.1 Implementation Guide: Standards & Interoperability (S&I) Framework Laboratory Test Compendium Framework (eDOS) Ask at Order Entry (AOE) Release 2, STU Release 3.1 (US Realm), because prior to this release this content was published as Appendix A in a single document as part of HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3 (US Realm). In 2021, the AOE content was published separately for greater visibility and because it is standard agnostic, except for the data types which may be different for HL7 V2 vs. HL7 FHIR. There is an HL7 project (1634) to publish an update in the future to also reference FHIR datatypes.

 

-- Unique Device Identification

#1 Suggest to update HL7 Cross-Paradigm Implementation Guide: UDI Pattern, Release 1 to the latest release: HL7 Cross Paradigm Implementation Guide: UDI Pattern, Release 2  for all sub-points in this section (Defining a Globally Unique Device Identifier, Representing Unique Implantable Device Identifiers and Transmitting a Unique Device Identifier); its adoption level should be increased since this is being used as building blocks for implementation of other IGs in certified systems across the US.

CAQH CORE Comments on the ONC ISA Annual Update

  • CAQH CORE appreciates the opportunity to provide content updates for the 2023 ISA Reference Edition and web version.
  • CAQH CORE has proposed several substantive updates including the addition of two new Operating Rule Sets supporting value-based payment and requirements to ensure secure and consistent connectivity between trading partners. Details surrounding these Operating Rules, including the language that is proposed for entry into the 2023 ISA Reference Edition and web version, are in the attached document on pages 4-5.
  • Non-substantive updates include edits to address consistency in naming conventions, the order that CAQH CORE Operating Rules appear on the web version of ISA and the 2023 ISA Reference Edition, and other grammar and syntax corrections. These changes are interspersed throughout the attached document highlighted in gray. Proposed deletions are highlighted gray and shown with strikethrough text.
  • Additional comments have been entered into the web version of the ISA for each CAQH CORE Operating Rule directing the reader to the pages in the attached document where changes have been made.

CAQH CORE ISA Letter 2022.pdf

ACLA ISA comment re: Annual Reference Edition

We appreciate the annual Reference Edition .pdf, but Is it also possible to get a revision marked version of the annual draft for comment and reference edition ISA in future? Narrowing the review to content that has changed will allow us greater focus on future comments.

ISA Structure

Comment

Greater Emphasis on Testing Tools

HIMSS encourages ONC to determine how best to incorporate information on the testing of standards into ISA.  When the community looks at any standard, no matter how well the standard is written, it is the actual implementation of that standard where there is interpretation variability.  Overall, the community spends a significant amount of time talking about standards and implementation guides, but if those standards and guides are not tested once embedded into products and systems, there are questions about whether stakeholders are making the progress needed to propel broader interoperability efforts forward.    

 

HIMSS would like ISA to include more quantitative data to support the assessment of standards adoption/maturity.  For example, one helpful approach would be to include more information about testing, test tools, testing events, as well as how and where particular standards can be tested and advanced.  We encourage ONC to work with Integrating the Healthcare Enterprise (IHE) and Health Level Seven International (HL7) to investigate whether the upcoming connectathon events that each organization sponsors would be the appropriate setting to provide additional quantitative data in support of this effort.  HIMSS would be interested in working with ONC to ascertain whether this idea is best suited for more references within ISA or to build out more robust testing standards as part of the Interoperability Proving Ground

 

It is also important to note ONC’s reference to testing in the preamble to ISA, and how the agency encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in ISA.  HIMSS would like to be helpful resource to ONC on this type of project. 

 

ISA Timeline and Comment Process

Comment

Integration of Continuous Glucose Monitor Data into the EHR

A consensus group of 130 stakeholders (organized by Diabetes Technology Society) from academia, government, and industry developed iCoDE with data standards and workflow processes for integrating the wearable device Continuous Glucose Monitors into the EHR. The iCoDE standard contained 54 recommendations when it was completed in November 2022.  Many of its terms for expressing results of CGM testing are worthy of adoption by the (next) USCDI 5.  The link to the iCoDE standard is here: <https://www.diabetestechnology.org/icode/>

DirectTrust ISA Updates - 2023

Updates to links for permanence. Updates to adoption levels. Inclusion of Context IG now that it is in use in the Notifications Standard.  ANSI Naming added to ANSI approved standards.

ISA Updates 2023 0 DirectTrust.xlsx

CORE Response to the 2024 ISA Open Comment Period

Thank you for the opportunity to provide substantive recommendations that promote consistency and update the content of the ISA. Comprehensive responses from CORE can be found at this link: CORE Submission for the 2024 ISA Open Comment Period. This link has also been posted to relevant pages throughout the ISA, referencing page numbers where edits can be found.

Please note, on page 2 of the linked letter, CORE has made several recommendations that ensure consistency of Operating Rule nomenclature across all pages of the ISA.

Please do not hesitate to contact us with questions.

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.

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)

FAQs

Comment

Incomplete demographic data in COVID-19 reports

Is anyone monitoring the completeness of data that is being exchanged? During COVID-19, many states published summaries of their data including demographic information. Some have been very transparent in reporting missing data e.g. Florida. Is there a national effort to monitor the completeness of the data that is being exchanged and to look for ways to improve it. 

Here is a summary of one of Florida's recent COVID-19 reports showing missing data from page 8: https://tinyurl.com/3vnmn6vy 

       Cumulative COVID-19 cases:

                    Unknown gender: 83,415 of 7,646,882 or 1.1 %

                    Unknown race: 545,211 of 7,646,882 or 7.1 %

           

     Cumulative COVID-19 vaccinated:

                    Unknown gender: 24,910 of 16,259,122 or 0.1 %

                    Unknown race: 1,717,175 of 16,259,122 or 10.6 %

    How can we improve health equity if the basic demographic data are incomplete? Are there standards that systems are trying to meet? 0.1 % missing gender sounds pretty good but 10.6 % missing race does not sound good at all. My personal experience with our EHR (Athenanet) and its data exchange with our state's immunization registry is that immunization data is exchanged but patient demographic information is not. Is that a requirement for a system to be ONC certified? Thanks.


Vocabulary/Code Set/Terminology

Allergies and Intolerances

Representing Patient Allergic Reactions

Comment

Testing comment for basic registered user

Testing only, please discard.

NCPDP Comments

NCPDP supports ONC’s recommendations.

NCPDP Comment

This comment should be applied universally across the 2020 ISA Reference Edition. All hyperlinks for the NCPDP Standards should be updated to reflect: https://standards.ncpdp.org/Access-to-Standards.aspx?

NCPDP Commnet

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Allergic Reactions. The Allergy and Clinical Immunology CPT codes (95004 – 95199) identify patient assessment and intervention for allergy testing, ingestion challenge testing, and allergen immunotherapy.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

NCPDP Comment

NCPDP supports ONC’s recommendations.

Either or both value sets are large

Either or both value sets are large, establish a core commonly charted values list for implementation. Support outliers.

ONC response to comments

"Problem" VS extremely broad, recommend removal and suggest using "Adverse Clinical Reaction" and "Allergic and Intolerance Type" VSs as starter set.  Links added to VSAC.  Validation of comprehensiveness is difficult, although second VS is stewarded by HL7 Terminology workgroup.

Links to value sets

Links to value sets in VSAC, PHINVADS or elsewhere would be very helpful.  A URN or OID means NOTHING to about 98% of the affected parties.

The value sets are a start, but the first represents about 1/3 of all SNOMED CT codes. This is not a useful reduction to something that represents value to the community.

The second appears to be useful, but without a way to understand the process by which the codes were selected, it is difficult to validate it. That would require a rather deep analysis.  It would be helpful if VSAC value sets included something more than a one line description of the value set.  Without further information about the value set, and considering its source from a federal group rather than a standards organization, it is hard to judge whether this valueset is viable.

 

Representing Patient Allergies and Intolerances; Environmental Substances

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Allergies and Intolerances; Environmental Substances. The Allergy and Clinical Immunology CPT codes (95004 – 95199) identify patient assessment and intervention for allergy testing and allergen immunotherapy, including environmental substances.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

SNOMED CT value needs…

SNOMED CT value needs further restriction for Environmental Substances

UNII is really not all that helpful for clinical use.

Representing Patient Allergies and Intolerances; Food Substances

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Allergies and Intolerances; Food Substances. The Allergy and Clinical Immunology CPT codes (95004 – 95199) identify patient assessment and intervention for allergy testing, ingestion challenge testing, and allergen immunotherapy, including food substances.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Should use the American Allergy and Immunology list

It is short (but longer than the one below), uncluttered by special forms of food and is authoritative. While any food can cause an adverse reaction, eight types of food account for about 90% of all reactions:

http://acaai.org/allergies/types/food-allergy

Eggs, Milk, Peanuts, Tree nuts, Fish, Shellfish, Wheat, Soy 

What is the state of UNII, its not listed

What is the state of UNII, its not listed? UNII has been problematic when implementing related to the volume of choices.  SNOMED has a similar issue.  Establish a top used list for Food Substances as core implementation list. Allow outliers where needed, this will improve implementation and interoperability.  

Food substances too broad

There are over 4000 of these codes in SNOMED CT. It is still way to broad to be useful. Would suggest that a value set that would be useful would cover top 100 food items.  Avoid repetition like

256349002 Peanut - dietary (substance)      
229889003 Peanut brittle (substance)      
102260001 Peanut butter (substance)      
412047006 Peanut containing products (substance)

 

How many different ways do we need to say an interpret Peanut containing products?  Would you feed peanuts to someone with a peanut butter allergy?  That kind of clinical decision making needs to go into the making of these value sets.

 

UNII code system and value set is specific to FDA Product labeling and is not all that helpful for clinical use.  SNOMED CT is much better suited for this purpose.

UNII has broad coverage and…

UNII has broad coverage and connections to many other code systems and to chemical structures. Also includes what food and/or allergens. Would not dismiss it out of hand.

Representing Patient Allergies and Intolerances; Medications

Comment

NCPDP Comments

  1. NCPDP recommends ONC add the National Drug Code (NDC). The NDC distinctly identifies the product and is critical for capturing specific drug allergies including active and inactive ingredients (e.g., dyes, flavorings) as well as reporting adverse drug events to the FDA. RxNorm does not identify the specific packaged product that was dispensed and would not be as useful in these situations.
  2. Add the following:

Type-Standard

Standard/Implementation Specification- National Drug Code (NDC)

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 5

Federally Required – Yes

Cost – $

Test Tool Availability – N/A

NCPDP Comments

NCPDP supports ONC’s recommendations.

Tighten up the applicable starter sets

The various identified "starter value sets" in this section presents a confusing overlapping collection. The three items listed as "representing drug classes" are not equivalent and only the SNOMED CT (SCT) Product hierarchy is actually aligned with actual drug class concepts. SNOMED CT Drug product class concepts are uniquely valuable because NLM links SCT product class concepts to the appropriate RXNorm drug ingredients to support Drug class to RxNorm or even NDC codes identification via available APIs at RxClass. The other two suggested sets (Common Drug Classes for Allergy and Intolerance documentation and Common Drug Substances for Allergy and Intolerance documentation) do not represent useful drug classes and should not be listed in the Drug Classes for Allergy and Intolerance documentation section.

For the Representing Medication section, the listed set Clinical Drug Ingredient (2.16.840.1.113762.1.4.1010.7) (RxNorm ingredient codes) is a subset of all potential drug ingredient RxNorm codes that was based on a historical review of common drug ingredients listed as causes of allergy or intolerance in clinical records done a number of years ago. While this list has not been updated, it is useful. I suggest adding to the suggestions in this section the set you will remove from the "class" set as it is the list of every ingredient or related code type in RxNorm - over 25,000 codes. This is the Common Drug Substances for Allergy and Intolerance documentation (2.16.840.1.113762.1.4.1186.1) set.

NCPDP Commnet

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Allergies and Intolerances; Medications. The Allergy and Clinical Immunology CPT codes (95004 – 95199) identify patient assessment and intervention for allergy testing, ingestion challenge testing, and allergen immunotherapy, including medications.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

NCPDP Comment

  1. Add the following:

Type-Implementation Specification

Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – N/A

Federally Required – No

Cost – $

Test Tool Availability – Yes

Test Tool Link: https://tools.ncpdp.org/erx/#/home

 

  1. NCPDP SCRIPT Standard Version 2017071 allows for transmission of all the data sets.

Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

The Pharmacy HIT Collaborative supports using RxNorm and SNOMED CT; however, we ask for clarification as to why MED-RT (formerly NDF-RT) has been removed as a standard/implementation specification, as it was included in the final 2017 ISA and is currently included under “Representing Patient Medications.” We recommend that it be returned.   

Class Medication Allergen - Suggest SNOMED CT Substance Hierarch

Strong support SNOMED CT as replacement to NDF-RT which is no longer supported.  In past modeling, have recommended the "substance" domain in lieu of the listed "product" domain as the "class" substance contains relationships to related medication ingredient substances.  For example, current NDF-RT N0000011281 "Penicillins" spans RXCUI 7986 within RxNorm.  RXCUI 7986 also spans SNOMED CT 373270004 "Penicillin -class of antibiotic- (substance)," and 6369005 "Penicillin -class of antibiotic- (product)" - the "substance" value has links to the ingredient "children" that would be expected to span the class, such as "amoxicillin". The "product" hierarchy does not have a direct path to member "ingredient" based concepts.. instead, it links to a product concept such as "product containing amoxicillin".

Consider including MED-RT to represent classes of medications

MED-RT is an emerging standard that allows for representing classes of medications.  This has already been added under "Representing Patient Medications".  Shouldn't this also be added here for representing allergies to a class of medication? 

Biologics

Representing Biological Products

Comment

Clinical Notes

Representing Clinical Notes

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

Representing Clinical Tests Ordered/Performed

Comment

Comment for Representing Non-imaging and Non-laboratory Clinical

Comment for Representing Non-imaging and Non-laboratory Clinical Tests

The American Medical Association requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Non-imaging and Non-laboratory Clinical Tests. The CPT code set contains numerous codes for non-imaging and non-laboratory clinical tests, including, but not limited to:

  • Electroencephalography (EEG)
  • Echocardiography (EKG)
  • Cardiovascular and exercise stress tests
  • Pulmonary function tests
  • Electromyography (EMG)
  • Electroretinography (ERG)
  • Audiologic function tests
  • Evoked potential tests
  • Intraocular pressure measurement
  • Visual acuity and function tests
  • Allergy challenge tests
  • Fetal monitoring
  • Sleep studies

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, laboratory, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Representing Clinical Tests Result/Value

Comment

ACLA Comments on Representing Clinical Test Result/Value

American Clinical Laboratory Association Comment:
This new section is confusing because it appears to blend other use cases for Laboratory and Imaging tests as clinical testing.   Please clarify the intent.  

We recommend this statement be removed from Clinical Tests; Representing a Clinical Test Result/Value. Section and only include the Clinical Tests:  Representing Non-Laboratory and Non-Laboratory Clinical Tests.

Clinical Tests, like Laboratory and Diagnostic Imaging, should be represented by at least two components, the test, and the results. For Clinical Tests, these components are:
     • Clinical Test - The coded name of the non-imaging or non-laboratory test performed on a patient.
     • Clinical Test Result/Report - Interpreted results of clinical tests that may include study performed, reason, findings, and impressions. Includes both structured and unstructured (narrative) components.

 

Cognitive Status

Representing Patient Cognitive Status

Comment

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Cognitive Status. The CPT code set contains Evaluation and Management code 99483, which identifies a comprehensive cognitive assessment and care planning for a patient with a known cognitive impairment.  The services performed include:

  • Cognition-focused evaluation with pertinent history and examination,
  • Functional assessment for ability to perform various activities and decision-making capacity,
  • Use of standardized tests for staging of dementia,
  • Medication review for high-risk medications,
  • Evaluation for neuropsychiatric and behavioral symptoms using standardized screening tests,
  • Evaluation of environmental safety,
  • Evaluation of caregivers and their knowledge, needs, and supports,
  • Development, revision, or review of a care plan,

 

While the LOINC codes that assess cognitive status and the FHIR use case used to support the exchange of functional and cognitive status assessment information are still in development, the CPT code 99483 is an adopted standard. The CPT code conveys the same or similar information as the LOINC codes for cognitive function (11333-2, 75275-8, and 11332-4), which is currently listed as a standard for this interoperability need.

 

 

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Cognitive Status. The CPT code set contains Evaluation and Management code 99483, which identifies a comprehensive cognitive assessment of the patient, including, but not limited to:

  • Cognition-focused evaluation,
  • Functional assessment, including decision-making capacity,
  • Use of standardized instruments for staging of dementia,
  • Evaluation of safety,
  • Identification of caregivers, and
  • Creation of a written care plan.

CPT codes 96105-96146 identify neuro-cognitive assessments and tests, including cognitive performance testing, interactive feedback, neurobehavioral status examination, and neuropsychological testing evaluation services.

Cognitive skills are also identified in the Occupational Therapy Evaluations codes, 97165 – 97167, and Therapeutic Procedures, 97129.

In addition, CPT Category II codes 3720F and 3755F identify assessment and screening for cognitive impairment or dysfunction within the treatment of other clinical conditions.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

COVID-19 Novel Coronavirus Pandemic

COVID-19 Novel Coronavirus Pandemic

Comment

NCPDP Comments

  1. NCPDP recommends adding reference to the NCPDP Emergency Preparedness Guidance document under the first bullet point in “Limitations, Dependencies, and Preconditions for Consideration”.
    1. NCPDP Emergency Preparedness Guidance document – NCPDP created guidance in response to the COVID-19 pandemic. This document provides guidance to the pharmacy industry for resources available during the pandemic. The intended audience is healthcare providers who would need resource information for assisting patients in accessing products and services provided by pharmacies during the pandemic. This information can be found in section 10 of the document and will be updated as new information is available.
    2. For details, refer to the NCPDP EMERGENCY PREPAREDNESS GUIDANCE document on the Resources page of the NCPDP website.

Adoption Level for HL7 2.5.1 IG

We believe the adoption level for the HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 to be at a 5 for high or widespread adoption, given there are over 120,000 active HL7 interfaces exchanging immunization data using this standard (CDC 2020 IIS Annual Report). 

IG on Vocabulary Page

Given this page is focused on vocabulary, we recommend removing the HL7 IG 2.5.1 reference. If it stays, however, we believe it should reference the same HL7 IG 2.5.1 guide referenced on the ISA content page: www.healthit.gov/isa/exchanging-immunization-data-immunization-registries. 

Inclusion of IGs in the vocabulary list

It seems odd to include IG references in the list of vocabulary resources. After discussion with the HL7 Public Health Work Group, we recommend moving the IG references to the Content/Structure section (not that the immunization IG is already in that section).

SANER FHIR IG is an interoperability specification

We're not sure why the SANER FHIR IG is listed under terminology.  It's not a terminology IG but makes use of other terminology sets.  I would likely be better to be placed under Services/Exchange under Public Health.

WA State Department of Health SANER Comments

Washington State Department of Health fully supports the listing of the emerging standard Situational Awareness for Novel Epidemic Response (SANER). It is vital to ensuring public health and others can effectively monitor supplies, patient capacity and counts of patient’s being cared for during an outbreak or pandemic.

ACLA request to update content

Please revise both hyperlinks for Logica (https://covid-19-ig.logicahealth.org/index.html) to reference the official HL7 Logica webpage: http://hl7.org/standards/hsp-marketplace/index.html. The current ISA LOGICA hyperlink is to a non-HL7 website; HL7 projects must be hosted on an HL7 website per HL7 policy.

  • Justification statement: We believe HL7 will maintain their website supporting HL7 standards perpetually so an HL7.org hyperlink is preferable.

 

The SANER specification was published by HL7. Please update the hyperlink to the published version at: HL7 FHIR® Implementation Guide: Situational Awareness for Novel Epidemic Response (SANER) STU 1: http://hl7.org/fhir/uv/saner/STU1/

The current hyperlink is to HL7 FHIR’s ‘build’ environment which is preparatory to balloting and publication. (build.fhir.org/ig/HL7/fhir-saner/)

  • Justification statement: We believe HL7 will maintain their website supporting HL7 standards perpetually so an HL7.org hyperlink is preferable.

 

Please remove the June 4, 2020 date from the following reference: it has been updated twice since original publication:

CARES Act Section 18115 require laboratories to report results of SARS-CoV2 or COVID-19 testing to the Secretary of HHS in the form and manner outlined in this memo "COVID-19 Pandemic Response, Laboratory Data Reporting: CARES Act Section 18115 June 4, 2020"

 

 

WA State Department of Health SANER Comments

Washington State Department of Health fully supports the listing of the emerging standard Situational Awareness for Novel Epidemic Response (SANER). It is vital to ensuring public health and others can effectively monitor supplies, patient capacity and counts of patient’s being cared for during an outbreak or pandemic.

NCPDP Comments

  1. Request ONC to add NDC as a value where NDC is used.
  2. Add the following:

Type-Standard

Standard Implementation/Specification- National Drug Code (NDC)

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 5

Federally Required – Yes

Cost – $

Test Tool Availability – N/A

  1. NCPDP Emergency Preparedness Guidance document - Declared emergencies, such as weather-related events (e.g., hurricanes, fires, floods, etc.), natural disasters (e.g., earthquakes) or pandemics (e.g., H1N1, COVID-19), have led NCPDP to create this document. This document provides guidance to the pharmacy industry for resources available during a declared emergency. The intended audience is healthcare providers who would need resource information for assisting patients in accessing their products and services provided by pharmacies during declared emergencies. This document will be updated as new information is available.

 

Additionally, this document addresses certain emergency preparedness processes and procedures that could be established as daily occurrences to be invoked at a moment’s notice, mitigating urgent training for emergency situations. For example:

        1. Payers/pharmacy benefit managers should have declared emergency criteria established within standard plan benefit templates.
        2. Pharmacy systems should support declared emergency plan billing rules and claim routing information as part of their normal procedures.
        3. Enrollment files and product history are routinely updated and should be accessible during a declared emergency.

 

For details, refer to the NCPDP EMERGENCY PREPAREDNESS GUIDANCE document on the Resources page of the NCPDP website.

Opportunity to Better Highlight the Specialty Care and Settings

HIMSS appreciates the addition of the new “Specialty Care and Settings” section of ISA, which includes information about COVID-19 needs.  However, it may be beneficial to find other approaches to highlight this section as an opportunity to help address the pandemic.  For example, when you click on the ISA Content tab, it does not include this new section.  We ask ONC to create a new tab for the “Interoperability for COVID-19 Novel Coronavirus Pandemic” Section that makes it more visible to ISA users.  Given the importance of federal guidance to respond to the pandemic, it seems like a missed opportunity to not highlight critical public health interoperability needs on COVID-19 in an easily accessible way.  As an initial step, ONC should also include an overview of this section and link on the main ISA webpage to enhance its overall visibility. 

We also ask that ONC consider “Telehealth/Remote Patient Monitoring” an additional specialty care/setting for inclusion in this section.  There is a growing need to consider data exchange for home settings and considerations around device interoperability.  There are a number of applications in use and this setting requires work across a number of systems (emergency medical services, hospital electronic health records, telemedicine system (synchronous and asynchronous) and, remote patient monitoring and device management).  ISA should provide guidance on specific standards to assist in exchange with this setting. 

In addition, HIMSS asks ONC to describe what the process is to determine inclusion in the Specialty Care and Setting section, including certain criteria that must be met.  A better overview of this section and how additional inclusions are determined would be beneficial and further highlight the information included there. 

Demographics

Representing Patient Contact Information for Telecommunications

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

Representing Nutrition Assessment, Diagnosis, Interventions and Monitoring/Evaluation

Comment

The CPT Category II codes…

The CPT Category II codes are intended to be used in the quality measure sets for which they were developed and not independent of the measure set. The AMA asks ONC to remove the following bullet under “Applicable Value Set(s) and Starter Set(s)”:

  • CPT Category II  3759F and 3760F: identify assessment and screening for nutrition within the treatment of another clinical condition

The AMA requests that the…

The AMA requests that the following bullet under “Applicable Value Set(s) and Starter Set(s)” be deleted:

 

  • CPT Category II  3759F and 3760F: identify assessment and screening for nutrition within the treatment of another clinical condition

 

Use of CPT Category II codes are limited to the quality measures for which they were developed.

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Nutrition Assessment, Diagnosis, Interventions and Monitoring/Evaluation. CPT codes 97802 – 97804 identify patient assessment and intervention of medical nutrition therapy.

In addition, CPT Category II codes 3759F and 3760F identify assessment and screening for nutrition within the treatment of another clinical condition.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Emergency Medical Services

Representing Health Care Data for Emergency Medical Services

Comment

NCPDP Comment

  1. NCPDP recommends that ONC add NDC as a value since this identifier is used when Emergency Medication is being administered to a patient.
  2. NCPDP recommends that ONC add the following:

Type-Standard

Standard Implementation/Specification- National Drug Code (NDC)

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 5

Federally Required – Yes

Cost – $

Test Tool Availability – N/A

Pharmacy HIT Collaborative (PHIT) comment

PHIT supports NCPDP’s recommendation that NDC should be added as a value for use when emergency medication is being administered, NDC be used.  This request was also made for the 2023 Edition.

NCPDP Comments

  1. When emergency medication is being administered, NDC could be used. NCPDP requests ONC add NDC as a value.
  2. Add the following:

Type-Standard

Standard/Implementation Specification- National Drug Code (NDC)

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 5

Federally Required – Yes

Cost – $

Test Tool Availability – N/A

WA State Department of Health EMS Comments

Washington State Department of Health supports the listing of the National Emergency Medical Services Information System (NEMSIS) standards for EMS data and only has one recommended change at this time. Washington State Department of Health recommends adding NEMSIS 3.5 as an emerging standard for emergency medical services data exchange, with implementation having began in Summer 2022. NEMSIS standards are an important collector of data for EMS in various contexts including public health, quality assurance and traffic safety.

WA State Department of Health EMS Comments

Washington State Department of Health supports the listing of the National Emergency Medical Services Information System (NEMSIS) standards for EMS data and only has one recommended change at this time. Washington State Department of Health recommends adding NEMSIS 3.5 as an emerging standard for emergency medical services data exchange as it likely could start being used in Spring of 2022. NEMSIS standards are an important collector of data for EMS in various contexts including public health, quality assurance and traffic safety.

NCPDP Comments

  1. When Emergency Medication is being administered, NDC and RxNorm could be used. Request ONC to add NDC and RxNorm as a value.
  2. Add the following:

Type-Standard

Standard Implementation/Specification- National Drug Code (NDC)

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 5

Federally Required – Yes

Cost – $

Test Tool Availability – N/A

  1. Add the following:

Type-Standard

Standard Implementation/Specification- RxNorm

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 4

Federally Required – Yes

Cost – Free

Test Tool Availability – N/A

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Health Care Data for Emergency Medical Services. CPT codes 99281 – 99285 identify patient evaluation, examination, and medical decision making for emergency department services. CPT code 99288 identifies the direction of emergency care to emergency medical services personnel by a physician or other qualified health care professional.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Regenstrief - Comment

We concur that the NEMSIS data set is an important collector of variables in the EMS context. In addition, we note that LOINC contains terms for observations and observation values for the complete NEMSIS data set (see panel 84428-2). Additionally, HL7 has developed the HL7 Version 3 Implementation Guide for CDA Release 2 - Level 3: Emergency Medical Services; Patient Care Report, Release 2 - US Realm, which uses the LOINC observation and observation values codes. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=438

Further, it may also be worth mentioning that there is correlation between the NEMSIS (pre-hospital) data elements and the National Trauma Data Bank (NTDB) data dictionary, with the idea that the trauma registry could be “auto-populated” with the subset of relevant prehospital data. The National Trauma Data Standard data dictionary (2018 version) is also represented in LOINC (see panel 87825-6). HL7 has developed the HL7 CDA® R2 Implementation Guide: Trauma Registry Data Submission, Release 1 - US Realm, which uses LOINC. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=355.

Last, the German Interdisciplinary Association of Intensive Care and Emergency Care Medicine defined a data set to enable efficient exchange from EMS pre-hospital services to receiving institutions. This complete data set of variables in the rescue service protocols are represented in LOINC (see panel 88677-0). This further supports the use of LOINC as a code system for use in this context.

Encounter Diagnosis, Assessment and Plan

Representing Assessment and Plan of Treatment

Comment

Current Procedural Terminology (CPT) code set be added

The American Medical Association (AMA) requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Assessment and Plan of Treatment. Currently LOINC and SNOMED CT are listed as standards for this interoperability need with no explanation about which codes to consider or how they are used to identify a patient’s assessment and plan of treatment.

 

The CPT Evaluation and Management codes communicate to other providers that the assessment and plan of treatment have been completed on a patient, as well as specific clinical information about the assessment, plan, and setting in which the assessment occurred. The complexity of the patient assessment, data analyzed, and patient management are conveyed in these codes. They support continuity of care for the patient throughout their health care journey. They also support the requirement for hospitals to share Admit, Discharge and Transfer data to improve patients’ transitions of care. In addition to the CPT Evaluation and Management codes that capture assessment and plan of treatment for individual encounters, additional CPT codes address the unique considerations in assessments and treatment plans across broader care episodes, such as Case Management Services – Medical Team Conferences, Care Plan Oversight Services, Cognitive Assessment and Care Plan Services, Care Management Services, and Psychiatric Collaborative Care Management Services. 

 

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Assessment and Plan of Treatment. This request was made in 2020 during which time the CPT code set was added and then removed.

 

The CPT Evaluation and Management codes specifically address multiple categories and subcategories for the broad range and levels of assessing and treatment planning for the patient, including:

  • Office or other outpatient services
  • Hospital observation services
  • Hospital inpatient services
  • Consultations
  • Emergency department services
  • Critical care services
  • Nursing facility services
  • Domiciliary, rest home, or custodial care
  • Home services
  • Case management services
  • Non-face-to-face services

 

The CPT codes convey the types of information that is required to alert providers and will empower them to proactively monitor their patients throughout the care continuum, improving patient outcomes and enhancing care continuity, while reducing preventable readmissions. In addition, the need for hospitals to share Admit, Discharge and Transfer data throughout the care community is critical, and now required, from improving interoperability and transitions of care for patients. These types of alerts to providers will empower them to proactively monitor their patients throughout the entire continuum of care, significantly improving patient outcomes and care continuity, while reducing preventable readmissions.

 

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Assessment and Plan of Treatment. The CPT Evaluation and Management codes specifically address multiple categories and subcategories for the broad range and levels of assessing and planning treatment for the patient.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Representing Patient Dental Encounter Diagnosis

Comment

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

SNODENT free cost?

per link to snodent - the entry 'free' in cost is incorrect.

 

See the text on the website.

SNODENT is owned, maintained and distributed by the American Dental Association (ADA). The SNODENT code set is available under license at no cost for non commercial use. The license agreement terms also permit licensees to use SNODENT in the development of non-commercial, academic, scholarly articles and presentations for publication. For inquires about SNODENT licenses, use the contact information below.

 

 

Consider describing the license details in the preconditions section.

Representing Patient Medical Encounter Diagnosis

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

NCPDP Comment

While use of ICD-10 is limited, when transmitting diagnosis information it is required. HIPAA mandates the use of ICD-10 for pharmacy claims using NCPDP standards. SNOMED is optional. Adoption level for ICD-10 for the pharmacy is 5.

Family Health History

Representing Patient Family Health History

Comment

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Family Health History. The CPT Evaluation and Management codes specifically address capturing the patient’s family health history. The E/M codes specifically provide information about:

  • The health status or cause of death of parents, siblings, and children;
  • Specific diseases related to problems identified in the chief complaint or history of the present illness, and/or system review
  • Diseases of family members that may be hereditary or place the patient at risk

Also, CPT code 96040 identifies medical genetics and genetic counseling services.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Wrong code system referenced for Problem Type

2.16.840.1.113883.3.88.12.3221.7.2 - this code system is not LOINC as referenced above...it is SNOMED.

feedback

Consider adding the following info to starter set

OMOP common data model is using SNOMED CT concepts (descendants of SNOMED CT term 125677006 (http://snomed.info/id/125677006))  to standardize family relationships (reference: https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP#conventions  ). 

Standard for observation…

Standard for observation values: should probably be Standard for observation values that are represented as codes (won't apply if they are free text or numbers).

Many of the details of Family Genomic History are not capturable by SNOMED CT. They will require the code systems provided by NCBI such as ClinVar, dbSNP, etc.

This is a greatly exaggerated assessment in the CMS Assessments. A large provider of IHE interfaces see SNOMED CT codes for 5% or fewer variables with multiple choice answers. Most are either text and/or local codes. 

Are the value sets in ISA accounting for the decisions and imple

  • Personal Relationship Role Type”  Personal Relationship Role Type urn:oid:2.16.840.1.113883.1.11.19563
  • There is a discrepancy between this value set and FHIR 4.0.  More generally are the value sets in ISA accounting for the decisions and implementations being made with FHIR?
    • Definition:          
      • A relationship between two people characterizing their "familial" relationship
      • OID:       2.16.840.1.113883.1.11.19579 (for OID based terminology systems)
    • Title:      V3 Value SetFamilyMember
    • Name:  v3.FamilyMember
    • Defining URL:     http://terminology.hl7.org/ValueSet/v3-FamilyMember

NCBI genomic data resources

NCBI resources for sequences, including RefSeq, dbVar, and dbSNP,  can be found here:

https://www.ncbi.nlm.nih.gov/guide/all/

Need code system for family…

Need code system for family relationships, SNOMED CT and HL7 V3 Personal Relationship have good value sets for this.

Functional Status/Disability

Representing Patient Functional Status and/or Disability

Comment

Comments from the Alliance for Nursing Informatics

Thank you for the opportunity to provide comments on the Interoperability Standards Advisory (ISA) and the Standards Version Advancement Process (SVAP). The ANI strongly supports further development to include Functional Status standards in regulations and as federal program requirements.

Please see attachment for our full comments

ANI COMMENTS on ISA-SVAP _FINAL.pdf

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Functional Status and/or Disability. CPT codes 99455 and 99456 identify the completion of medical history, examination, diagnosis, development of a treatment plan, and completion of necessary documents for a patient with a work related or medical disability. 

Functional status and disability are also identified in the Physical Therapy Evaluations codes, 97161 – 97164, and Occupational Therapy Evaluations codes, 97165 – 97167, which include patient history, examination, clinical decision making, and development of a treatment plan.

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

The use of OIDs alone is a…

The use of OIDs alone is a bad way to suggest a value set. Readers need some way to see the actual content of the value set, either via URL or, if it is short, as an actual enumeration.

The adoption level is…

The adoption level is greatly exaggerated. Only IRFPAI of the CMS assessments provides SNOMED CT options in addition to LOINC LA answer lists. All of the categorical answers have LA codes of which there are about 100 unique codes. Some of the answers also have SNOMED CT codes (about  50 unique such codes). The names of the SNOMED Codes are often approximates of the CMS string name for the codes.  All of the other CMS assessments include LOINC LA codes or all of their categorical answers and very few SNOMED CT codes except for yes/no. See https://del.cms.gov/DELWeb/pubDownloadHitCodesForm to verify.

Regenstrief - Comment

It would be worthwhile to clarify what the ISA means by functional status and/or disability. These words mean different things to different audiences. We recommend anchoring the ISA notion to the WHO-developed ICF conceptual framework for describing functioning and disability. The ICF has a biopsychosocial model of disability, based on an integration of the social and medical models of disability.

In this model, functioning is an umbrella term for body function, body structures, activities and participation. It denotes the positive or neutral aspects of the interaction between a person’s health condition(s) and that individual’s contextual factors (environmental and personal factors).

Disability is an umbrella term for impairments, activity limitations and participation restrictions. It denotes the negative aspects of the interaction between a person’s health condition(s) and that individual’s contextual factors (environmental and personal factors).

So, what we believe the ISA to be referring to in this interoperability need is the “middle” part of the ICF: the activities of people (functioning at the level of the individual) and the activity limitations they experience; plus the participation or involvement of people in all areas of life, and the participation restrictions they experience (functioning of a person as a member of society). Such clarifications are important for knowing whether something like “cognitive function” is in or out of this domain.

We propose that it would exclude the notion of functioning at the level of the body, that is, impairments of body functions and structures (e.g. measurement of deep tendon reflex of biceps). It would also exclude the notion of environmental factors (e.g. physical geography), whether facilitators or barriers, that affect a person’s experiences.

With that as the framing, we concur with the identification of the terminologies listed in this domain (LOINC and SNOMED CT) as the most appropriate for the observations and observation values related to functioning. In post-acute care settings, functional status is a required component (e.g. Section GG) of the CMS assessment instruments (e.g. MDS, LCDS, IRF-PAI, and OASIS). Through close collaboration between CMS and Regenstrief, all of the variables in these instruments are represented in LOINC. There are other sets of relevant patient reported variables (such as the PROMIS physical function short form, Hip Dysfunction and Osteoarthritis Outcome Score, etc) and clinical assessments of function represented in LOINC. The American Physical Therapy Association identified all of the variables for its national outcomes registry (including items related to functioning) with LOINC.

It is worth noting that LOINC represents the strings of the observation values for standardized assessments as LOINC Answer codes, but these answers for many standardized assessments of functioning are not well represented in SNOMED CT due to their specialized nature. So, just like standardized nursing assessments, LOINC Answer codes should be used to reflect the precise responses on these functional status assessments. The “Adoption Level” for SNOMED CT in this context should be one star at best. There are very few functional status observation values that are even represented in SNOMED CT, and their deployment in this context is very limited.

Last, the NMMDS reference in “Applicable Value Set(s) and Starter Set(s)” should be removed because the NMMDS is about administrative and management information for the provision of nursing care. It doesn’t have variables related to an individual’s functioning/disability.

 

AMA's comments to ONC on proposed 2018 ISA

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

Comment:

The AMA recommends adding the “Guides to the Evaluation of Permanent Impairment, Sixth Edition” (“Guides”) as an additional resource for this interoperability need in the Limitations, Dependencies, and Preconditions for Consideration.  The Guides are a standardized, objective approach to conducting impairment ratings that result in detailed documentation of functional outcomes, physical findings, and clinical test results and have been shown to improve the overall consistency, transparency, and precision of impairment ratings.  Users include physicians, other health care providers, attorneys, employers, and claims professionals.  The Guides are adopted by U.S. Department of Labor’s Division of Federal Employees’ Compensation for schedule award entitlement determinations.  They are also adopted in 19 states and used internationally in Canada, Australia, New Zealand, Hong Kong, Korea, South Africa, and The Netherlands.

The standards named in this…

The standards named in this domain (LOINC and SNOMED CT) are appropriate and we concur with their inclusion here. However, a couple of clarifications are needed. The first bullet should be removed as it suggests that the CMS-required MDS should be used more widely and in different settings than for which it is designed. The IMPACT Act requires that CMS make certain assessment data elements standardized and interoperable so that this data may be exchanged and used by post-acute care and other providers to support care coordination and improved outcomes. CMS is working directly with the Regenstrief Institute to represent all data elements in the assessment instruments they require in different care settings (e.g. MDS, LCDS, IRF-PAI, and OASIS) in LOINC. This work includes current versions of these instruments, as well as their intended harmonization over time. 

In addition, many clinical assessments of functional status are well represented in LOINC and SNOMED CT.

None of the three existing…

None of the three existing CMS assessment tools for functional status assessment (MDS, OASIS, IRF-PAI) adequately covers all patients.  We need a uniform assessment instrument.

Goals

Representing Patient Goals

Comment

Functional goals for physical therapy

Why is writing goals based on the client’s priorities and in a consistent and easily understood format important? The answer is rooted in motor learning theory, reimbursement practices and health care policy. (Randall, McEwen, 2000) The goals communicate with your client, colleagues, referral source and other stakeholders about the intent and focus of the intervention. 

Improved patient participation and setting expectations.  

Current motor learning theory suggests that patient engagement in treatment is enhanced when personally meaningful goals are prioritized. Setting goals is collaborative.  For clients with the ability to articulate goals, this process progresses smoothly. For other clients, determining realistic, achievable, yet challenging goals requires more negotiation. This presents the opportunity to set expectations for short and long term outcomes for patients with chronic problems. Regardless of the process, involvement of the client in goal setting has been demonstrated to improve participation and achievement. (Sugavanam, Et.al., 2013) 

Medical necessity and reimbursement 

Demonstrating achievement to all stakeholders necessitates clear parameters to determine if goals have been met or not met. Achievement of the client’s goals for the intervention is the primary criterion for discharge from rehabilitation services. (APTA Guide to Physical Therapist Practice 4.0) On a clinical level, quantification of current function and determination of change in that function to achieve the intended outcome is the basis. A client walking at 0.80 m/s will be unable to clear the crosswalk on a city street within the “pedestrian time” of traffic lights. Increasing velocity to 1.10 m/s will be a goal that is needed to achieve the outcome of safely walking to the market. (USDOT, 2023) Third party review for reimbursement also uses goals as an indication of individualization of the POC. (Snyder, 2009) Goals that are specific to the client’s self-identified needs coupled with an appropriate intervention avoid denial for medical necessity. Additionally, the ability to simply and specifically measure the progress toward, and achievement of the goals supports appropriate progression and discharge recommendations. 

Health care policy 

The CMS National Quality Strategy (2022) places the patient at the center of care. Embedding Quality and Increasing Alignment are 2 of the 8 goals for the plan. The use of patient centered functional goals and Patient Reported Outcomes measures are two of the many ways to participate with these important regulatory changes. Patient reported functional outcomes tools and performance-based tools can be included in goals as they indicate a change in function. The MCID of the tool, threshold scores for performance-based tests or prior level of function scores from the client history provide the benchmarks for writing goals. 

  1. The patient will score 15 or lower on Oswestry Disability Index to indicate a decreased level of impairment related to lower back pain. (If the initial score was 27) 
  2. The patient will score 50 or higher on the Berg to indicate a decrease in risk of falling.  
  3. The patient will score 24 or lower on QDASH to indicate return to presurgical level of function with lifting and carrying for home management. (Based on a prior level of funciton score.) 

Our Current State 

Despite efforts to improve this portion of the Plan Of Care, challenges still exist. Many documented goals are not stated in terms that are measurable or functional. Performance of the home program is frequently cited as a goal when it is actually the treatment to achieve the goals. When the desired goal is for return to previous leisure or cardiovascular exercise, or prevention of regression through exercise prescription, the goal should be stated as such. A strategy for developing goals can be initiated based on the purpose of patient centered functional goals.     

Plan for improving goal writing 

Goals are the intended impact on functioning as a result of implementing the management plan to meet the unique needs of each client. Goals are measurable, functionally driven, and time limited. (APTA Guide to Physical Therapist Practice 4.0) 

Goals can be found in the following domains: self-care, home management, work (play for a child), leisure activity and prevention. Documentation will be included in the “Subjective” or “Patient Goals” portion of the Evaluation. This is followed by a focused examination to identify and quantify contributing factors. In organizing the data derived from the examination, the ICF model is helpful to categorize affected body structures and functions. These initial measures are necessary to validate the need for a goal.    

After deciding on the general outcomes, the goals that lead to those outcomes are identified. The recommended format includes: Who will do What, under what Conditions, how Well, Why by When?

Who is always the client. This also includes situations where physical assist or set up is needed. The goals focus on the client performing and activity and level of assist, not on the effort expended by the caregiver.  

Will do what is an observable activity that has a beginning and an end. Walking, lifting, climbing are discreet examples of these. They may be components of the Outcome. 

Under what conditions is the measurable portion of the goal and is unique to the client and may include distance or time. Achievement verses failure of a task can also be the implied measure, like standing from an 18” chair w/o UE support verses being unable to complete that activity under those conditions. Range of motion or strength measures are rarely appropriate as metrics to determine performance of an activity. The activity is the goal and the associated functional parameters. 

How Well includes presence or absence of assistance needed, extended time, success rate or adapted techniques. Pain free or pain tolerated could also be indicated. Terms like “proper posture” would be more professionally described as “neutral spine positioning.”  

Why returns to the intended outcome. This identifies the larger construct: Return to work or independent grocery shopping. Prevention of disease progression or mitigation of safety risk can also be addressed. 

We also use the acronym SMART (Doran, 1981) to describe goal writing. This paradigm integrates with the same elements listed above: 

Specific - What 

Measurable - Conditions 

Assignable - Who 

Realistic – How well 

Time-related – When 

Regardless of the method used to format the information, the goals for the intervention should be stated in concise language that allows any stakeholder to clearly understand the intended direction and criteria for conclusion of the intervention.   

 

Search | APTA Guide to Physical Therapist Practice 

ICF Browser (who.int)  

Writing patient-centered functional goals - PubMed (nih.gov) 

The CMS National Quality Strategy: A Person-Centered Approach to Improving Quality | CMS 

'Finding a balance' in involving patients in goal setting early after stroke: a physiotherapy perspective - PubMed (nih.gov) 

The Relationship Between Client-Centered Goal-Setting and Treatment Outcomes | Perspectives on Neurophysiology and Neurogenic Speech and Language Disorders (asha.org) 

Navigating patient-centered goal setting in inpatient stroke rehabilitation: how clinicians control the process to meet perceived professional responsibilities - PubMed (nih.gov) 

Recognizing potential barriers to setting and achieving effective rehabilitation goals for patients with persistent pain: Physiotherapy Theory and Practice: Vol 32, No 5 (tandfonline.com) 

Goal setting and strategies to enhance goal pursuit for adults with acquired disability participating in rehabilitation - Levack, WMM - 2015 | Cochrane Library 

Full article: Goal-setting in physiotherapy: exploring a person-centered perspective (tandfonline.com) 

Poster 96: Successful Medical Necessity Documentation Improvement Strategies - ClinicalKey (liblynxgateway.com) 

(PDF) Analysis of Physical Therapy Goals in a School-based Setting: A Pilot Study (researchgate.net) 

Traffic Signal Timing Manual: Chapter 5 - Office of Operations (dot.gov) 

NCPDP Comments

Modify LOINC and SNOMED CT adoption levels to 1.

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The AMA requests that the…

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Goals. CPT Category II codes for Health and Well-Being Coaching (0591T – 0593T) identify services for goal setting, education, and monitoring related to those goals.  

CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

Health Care Providers, Family Members and Other Caregivers

Representing Health Care Providers

Comment

NCPDP Comments

Modify Adoption level of NPI to 5.

NCPDP Comment

Modify Adoption level of NPI for pharmacy to 5

NCPDP Comment

  1. NPI is mandated in HIPAA transactions however not all prescribers (for example veterinarians) are able to obtain an NPI.)
  2. Adoption level of NPI for pharmacy is 5

NCPDP Comment

NPI is mandated in HIPAA process however not all prescribers (for example veterinarians) are able to obtain an NPI.

Good choice of coding system…

Good choice of coding system but doubt it is used much. Some empirical data from an IHE or even a illustrative EHR could help settle. 

Regenstrief - Comment

We should clarify that there are two purposes subsumed by this current interoperability need. The first is to uniquely identify the person (provider). That need is addressed by the NPI. It is an “instance” identifier. The second need is to categorize or identify the type of provider they are. That is addressed by the NUCC Health Care Provider Taxonomy. But, there is already a “Representing Provider Role in Team Care Settings” section, so it seems more appropriate for the NUCCPT to be listed as a standard there rather than here.

NCPDP - Comment

The NPI is mandated in HIPAA named standard transactions; however other identifiers are used as needed (e.g.: State PDMP, state government programs)

Should NUCC Provider Taxonomy be used here?

Given that there is also a Representing Provider Role in Care Setting section that presumably is used to represent a care setting specific role, then some clarification is needed for how the NUCC PT code system would be used here, particularly when the NPI is not a role, it is an identifier. These are two very different kinds of concepts and I suspect they should not both be used here. Perhaps NUCC PT should only be used in the Representing Provider Role in Care Setting section.

Value set link and OID for NUCC Provider Taxonomy

  1. Please change the NUCC standard to "National Uniform Claim Committee (NUCC) Health Care Provider Taxonomy" Or you can just use NUCC Health Care Provider Taxonomy if you want it shorter. The provider taxonomy is the main thing people get from the NUCC, but NUCC provides other code sets so just saying NUCC is not specific. 
  2. The link you should use for the taxonomy is http://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40
  3. VSAC provides a value set for the provider taxonomy. The OID is 2.16.840.1.114222.4.11.1066.
  4. VSAC has a direct link to the latest expansion for this value set here: https://vsac.nlm.nih.gov/valueset/2.16.840.1.114222.4.11.1066/expansion.
    1. This syntax will work for every value set VSAC has. I would suggest you use it for all VSAC value sets so users can click and directly go to the value set expansion view
  5. It would be good to standardize on how to represent OIDs. In some places you just list the OID, in others you list it as a URI (urn:oid:2.16.840.1.114222.4.11.1066)

Representing Provider Role in Team Care Settings

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

NCPDP Comment

  1. NUCC does not represent all providers, such as Assistant Physician. NCPDP worked with the appropriate provider organizations to request a new taxonomy code for Assistant Physicians. However, the request was not supported by NUCC because it is a license type versus a provider type. While CMS does not allow Assistant Physicians to enroll, CMS agreed to research internal processes to determine if a distinct taxonomy identifier could improve the process.

NUCC is too precise

NUCC is too precise, combining specialty and setting. Providers or care team members may have more than one role or more than one care setting. The precision of NUCC essentially decreases accuracy.  

NUCC Taxonomy is challenging…

NUCC Taxonomy is challenging.  SNOMED CT is better for this purpose, as it references ONLY the singular aspect of provider role and does not merge three separate aspects (role, setting and specialty).

NCPDP - Comment

Taxonomy codes should be added as a standard. The pharmacy industry uses this value set to determine covered practice settings.

Use of the NUCC Provider Taxomony

I commented on how to properly reference the NUCC Provider Taxonomy code system and a value set that represents it in the Representing Health Care Providers section. The value set has an old name that perhaps should be changed to remove the "(HIPAA)". Noting that this element exists and is the proper use of the NUCC Provider Taxonomy, there can be confusion about how those concepts should also be used in the Representing Health Care Providers section. 

Representing Relationship Between Patient and Another Person

Comment

NCPDP Comments

NCPDP supports ONC’s recommendations.

Health Concerns

Representing Patient Health Concerns

Comment

NCPDP Comments

Modify LOINC and SNOMED CT adoption levels to 1.

Imaging (Diagnostics, Interventions and Procedures)

Representing Imaging Diagnostics, Interventions and Procedures

Comment

Preserving Clinical Context

General Comments:

USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider and determine/resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

The American Medical…

The American Medical Association requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Imaging Diagnostics, Interventions and Procedures. The CPT code set contains a comprehensive and regularly curated list of diagnostic and interventional radiology procedures. Because of the federal and private initiatives to provide patients access to their health care data using claims data, including CPT as a standard would support the exchange of this information. CPT was created over 50 years ago and is a uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set.  Use of the CPT code set is federally required under HIPAA.

Recommendations for Section II: Content/Structure & Imp Specs

Recommendations for Section II:  Content/Structure Standards and Implementation Specifications

  1. Break this into two blocks – the new block would be titled: Interoperability Need: Format of Medical Images for Exchange and Distribution

In that block insert the:

(See image 1 from uploaded file)

followed by a row:

Implementation Specification,  PS3.3 Digital Imaging and Communications in Medicine (DICOM) Standard – Part 3: Image Object Definitions,  Final,  Production,  5 black circles, No, Free, Yes

  1. For now, keep the 2nd block as is (same as the original block)

Recommendations for Section II_DICOM.docx

Regenstrief - Comment

Please correct the typo of Regenstreif to Regenstrief. Also, there are two relevant value sets that should be listed here. The first is the “LOINC/RSNA Radiology Playbook”. This set is identified by the OID 1.3.6.1.4.1.12009.10.2.5.1 and the URI is http://loinc.org/vs/loinc-rsna-radiology-playbook. The current FHIR R4 Mixed Normative/Trial Use Ballot #2 binds to this collection as code set for the ImagingStudy.procedureCode.

The second is the collection of terms in LOINC representing imaging procedures/reports. This set is called “LOINC Imaging Document Codes” and includes all radiology procedures as well as terms from some other imaging specialties. It is identified by the OID 1.3.6.1.4.1.12009.10.2.5 and the URI http://loinc.org/vs/loinc-imaging-document-codes. This is the value set named in C-CDA’s Diagnostic Imaging Report template and DICOM’s standard for Imaging Reports using HL7 CDA.

We concur with the…

We concur with the recommendation of LOINC as the vocabulary standard for this domain. The Regenstrief Institute and the RSNA have created a unified terminology standard for radiology procedures that builds on the strengths of LOINC and the RadLex Playbook. The LOINC/RSNA Radiology Playbook File now contains a unified representation of all existing LOINC and RadLex Playbook content, connecting LOINC radiology terms to a rich set of attributes represented with Radlex terms. The LOINC/RSNA Radiology Playbook File is now jointly published as part of the main LOINC release and it's Maturity should be listed as Production (it is actively being used by radiology centers, in health information exchanges, etc).

In addition, Regenstrief curates a value set of LOINC Imaging Document Codes (OID: 1.3.6.1.4.1.12009.10.2.5) that contains terms for imaging procedures/reports from Radiology, Endoscopy, Cardiology, and other imaging specialties. This is the value set named in C-CDA’s Diagnostic Imaging Report template and DICOM’s standard for Imaging Reports using HL7 CDA.

RadLex seems to be the way…

RadLex seems to be the way to go, LOINC is nonspecific wrt to Radiology.  Need value set identified from whichever standard is selected.

Some misunderstanding: there…

Some misunderstanding: there is a LOINC code for every RSNA/Radlex study and vice versa (RSNA used LOINC codes).

Representing Immunizations

Comment

Representing Immunizations

The American Immunization Registry Association (AIRA) appreciates the structure and organization of this section. We do have one formatting recommendation; both “Immunization Information System (IIS)” and “State Registry” are used above and throughout the ISA to refer to IIS. We prefer the term Immunization Information System as it is more inclusive of the broad functionality encompassed within these systems. Additionally, some IIS are operated at the city level, rather than the state level, so state registry would be better referred to as jurisdictional IIS.

AIRA Comments - Administered and Historical Immunizations

The "Representing Immunizations - Historical" page is very similar to the administered page. It includes the same 5 code sets and mostly the same considerations (in blue). AIRA proposes these be consolidated into a single page and deal with the nuanced differences in the blue Considerations section rather than retain and maintain two nearly identical pages.

NCPDP Comments

RxNorm – is not utilized for reporting of previous dispensing.

NCPDP Comment

NCPDP supports ONC’s recommendations.

Preserving Clinical Context

 

General Comments: USCDI specifies lots of clinical data classes and data elements

  • Resolving to myriad de-coupled fragments
  • With vanishingly little focus on:
    • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
    • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost. 

    The American Medical…

    The American Medical Association requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Immunizations - Historical. The CPT code set is identified as a terminology standard for Representing Immunizations – Administered, so therefore, it should be included as a standard for historical immunizations. CPT was created over 50 years ago and is a uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    NCPDP Comment

    1. Request ONC to add NDC as a value. NDC has historically been used by pharmacy to report immunizations.
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- National Drug Code

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 5

    Federally Required – Yes

    Cost – Free

    Test Tool Availability – N/A

    Agree, it should not be…

    Agree, it should not be required because it can't be obtained from a patient's history.

    RxNorm and Immunizations?

    These are the correct value sets to represent Historical immunizations. 

    RxNorm is included in list of value and starter sets. (RxNorm Vaccine Clinical Drug 2.16.840.1.113762.1.4.1010.8)

    If CVX and MVX have it covered what is the use case for RxNorm?  

    Laboratory

    Representing Laboratory Result Values

    Comment

    ACLA Comments on Representing Result Values

    The American Clinical Laboratory Association comments pertain to the burden of using the Unified Code for Units of Measure (UCUM).

    ACLA agrees that the vocabulary standard, UCUM, should not be required, but may be represented. Laboratories should be allowed to use units of measure other than UCUM. The unit of measure provided by the instrument manufacturers, including FDA authorized, cleared, or approved method, is the standard that laboratories need to adhere to for result reporting. We recommend conversations and adoption from instrument manufacturers is incumbent for the adoption of UCUM to be viable.

    The UCUM can be a preferred standard, but it should not be required for all tests. Currently, there is a large base of units of measure that are in use across trading partners. To convert these units to UCUM would be problematic, difficult to achieve and time consuming.

    While ACLA acknowledges UCUM as an option for standardized vocabulary for units of measure it is crucial to recognize and understand the limitations of the UCUM coding system and the impact of key issues identified by ACLA prior to universal adoption.

    • UCUM has codes for ALL US customary units (e.g., UCUM guide §35 U.S. survey lengths, and §37 U.S. volumes). However, these will not necessarily have the same string representation that a given laboratory uses (see UCUM GUIDE http://unitsofmeasure.org/ucum.html). It also includes codes for all non-arbitrary unit of measure (UoM), includes many arbitrary UoM such as Somogyi units, and has a way to include strings (which will not be computable for any arbitrary units -- but arbitrary units are never computable in the sense that they can be interconverted).
    • There are issues with transmission of unusual or unrecognizable characters (e.g. ‘*’ or ‘^’, and descriptions sometimes use ‘#’ and ‘&’) which cause errors in some sending and receiving systems. These are restricted characters that cause issues in data exchanges including HL7.
    • Some recommended UCUM units exceed the HL7 prescribed field lengths for the coded element of 20 characters (e.g. nmol{BCE}/mmol{creat}, %{normal_pooled_plasma}). For example, some state public health systems are unable to accept more than 20 characters in the unit of measure HL7 field.
    • The mandate to report all units of measure in a UCUM format could impact patient safety. 
      • There may be a potential for discrepancies between the units of measure directed by instrument and/or reagent vendors in their package insert/operator’s manual for result reporting of a particular test vs. the UCUM units identified for that test. 
      • The instruments that process the specimens may or may not use UCUM standard units. There is a risk in converting results into a unit of measure that is different than the original unit of measure. 
        • Conversions cannot always be achieved to equivalency.
        • Even if it is accurately converted, it does not ensure that providers will always interpret it correctly.
        • It is common for conversion algorithms to encounter errors. While the problem with that is self-explanatory, a second issue may not be.  The value and the units of message occupy two separate HL7 fields.  Should a numeric value encounter an error, and the translation process choses to handle the issue by leaving the value as it was received but incorrectly modifies the units of measure (assuming the value algorithm performed correctly), there could be a disconnect between the value and units of measure that could greatly impact the interpretation of the results, and by extension, the health of the patient.
      • At present, units can be very confusing and unpredictable and almost impossible to use for computer purposes like decision support and quality assessment. We have seen more than 30 different representations of units for the number RBCs e.g.  10^12/Lit  bill/liter,  10*12/liter., etc.

     

     

     

    ACLA ISA comment re: clarification to section title, ‘actors’, a

    The title of this section is more limited than what is covered in this section; please clarify the actors this section applies to, e.g., Electronic Health Record (EHR) systems, Laboratory Information Systems (LIS), laboratories, exchanges, etc.  Refer to the IHE LAW and LTW profiles “Intended Audience”; is the target audience the same for this section?

    Some of these statements should be in the “Content/Structure” section of the ISA, not the “Vocabulary/Code Set/Terminology” section; there is overlap with the “Exchanging InVitro Diagnostics (IVD) Test Orders & Results” Content /Structure section of the ISA.

    Please clarify the term “harmonization status”.  We suggest this term be removed until it can be further clarified for expected implementation, clearly measured, etc.  It is too nebulous as currently stated.  For example, can it be measured and if so, how is it validated and how does it relate to the laboratory values/results or provider’s EHR system laboratory values/results?

    Do these terms, such as “standard scales” or “grading schemes” represent the end result of using of standard terminology such as LOINC or SNOMED CT? Please clarify.

     

     

    Preserving Clinical Context

    General Comments: USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Representing Laboratory Test Ordered

    Comment

    ACLA Comment on Representing Laboratory Test Ordered

    The American Clinical Laboratory Association (ACLA) comments pertain to the Interoperability Standards Advisory (ISA) addition of CPT codes. The ISA added CPT Proprietary Laboratory Analyses (PLA) Codes Representing Laboratory Test Ordered. The PLA codes are listed in Appendix O of the American Medical Association (AMA) 2023 Professional Codebook. The ISA added CPT codes which represent the entire pathology/laboratory code section, codes 80047 – 89398, including Multianalyte Assays with Algorithmic Analyses (MAAA) codes 81490-81599, and MAAA administrative codes (0002M-0013M), which are not PLA codes. ACLA comments pertain to the ISA addition of the CPT pathology/laboratory, including MAAA and administrative MAAA and PLA codes, as a Standard for Representing Laboratory Test Ordered.

    ACLA reiterates its comment that CPT codes and Proprietary Laboratory Analysis codes should be removed as a Standard for Representing Laboratory Test Ordered.  We agree with comments made on 9-30-2022 by APHL that the reference to CPT is confusing, as the Laboratory Order Interface (LOI) Implementation Guide calls for orders for lab tests to use LOINC wherever possible.  It states: “LOINC shall be used as the standard vocabulary to identify the ordered test in OBR-4 (Universal Service Identifier) when an applicable LOINC code is available and provided by the laboratory. When no valid orderable LOINC code exists, the local code may be the only code sent.” (Emphasis added.) “Shall” is a modal verb equivalent to “required” or “must” per HL7 conformance guidance.  The inclusion of CPT as a standard may give the erroneous impression that they are coequal with LOINC for purposes of Representing Laboratory Test Ordered.

    CPT codes are used commonly for billing, which should be a separate section under Laboratory to accommodate that administrative use case.  In contrast, it is exceedingly rare for CPT codes to be used to order tests, even if the AMA is “aware of at least one large academic health system that uses PLA codes in their ordering of lab tests.” One entity, or only a handful of entities, using CPT codes for ordering does not warrant introducing this novel standard for identifying an ordered test. 

    We do not believe there is sufficient justification at this time to introduce a new vocabulary for Representing Laboratory Test Ordered, especially when it would be additional expense for EHR systems/providers/and laboratories, which have designed their interfaces to support LOINC for order codes, and LOINC codes are better suited for laboratory test orders. 

    Request that PLA and MAAA codes be maintained

    The American Medical Association (AMA) requests that CPT codes, specifically the Proprietary Laboratory Analyses (PLA), Multianalyte Assays with Algorithmic Analyses (MAAA), and MAAA administration M codes, be maintained as a terminology standard for Representing Laboratory Test Ordered as they are currently listed. We are aware of over a dozen academic medical centers that use CPT and PLA codes in their laboratory test menus and catalogs. Our understanding of the general lab ordering process is that tests are initially ordered using the facility’s assigned unique test identifier, which is in turn mapped to LOINC, CPT codes, PLA codes, or other codes. These codes provide additional intelligence about the test ordered for the lab’s internal processing system. PLA codes provide information on all analytical services required for the analysis (e.g., cell lysis, nucleic acid stabilization, extraction, digestion, amplification, hybridization, and detection). Several health systems have requested PLA codes for genetic tests they perform and find clinical value in using these codes. CPT and PLA codes provide relevant clinical information about the test ordered and are not just for billing purposes. We believe this use case should continue to be recognized in Representing Laboratory Test Ordered.

    Clarification of CPT Terminology in ORC-16

    References in the comments on the use of ORC-16 do not accurately reflect the use of that field.  We refer the reader to the HL7 implementation guides for laboratory orders clarifying that ORC-16 represents the reason for the order, not a code such as LOINC, SNOMED, or CPT-PLA.  Further guidance on how and when to communicate LOINC and/or CPT-PLA codes would be identified in that guide as well.

    Retain listing the CPT code set for Representing Laboratory Test

    The CPT Editorial Panel created the Proprietary Laboratory Analyses (PLA) codes in 2016 in direct response to the Protecting Access to Medicare Act (PAMA) of 2014. PAMA enabled the creation of codes for advanced diagnostic laboratory tests (ADLTs) and clinical diagnostic laboratory tests (CDLTs) that are cleared and approved by the Food and Drug Administration (FDA). PLA codes describe proprietary clinical laboratory analyses that can be provided either by a single (“sole source”) laboratory or licensed or marketed to multiple providing laboratories (e.g., cleared or approved by the FDA). Any clinical laboratory or manufacturer can request a PLA code to specifically identify their tests. The tests included in the PLA section must be commercially available in the U.S. Current uses of PLA codes include ordering, billing, and reporting for various purposes. PLA codes can be used for recognizing, tracking, and ordering of specific tests, not just billing. We are aware of at least one large academic health system that uses PLA codes in their ordering of lab tests. PLA codes are used in the health care system to order lab tests and those workflows should be supported in health IT systems.

     

    In 2012, the CPT Editorial Panel effected a significant expansion of molecular pathology codes to accommodate cutting edge medical needs and provide the flexibility and specificity to address both current and future expansion. A new subsection was added to the CPT code set in 2015 for Multianalyte Assays with Algorithmic Analyses (MAAA) and other molecular pathology tests. MAAAs are procedures that incorporate multiple results derived from assays of various types in an algorithmic analysis to report a numeric score(s) or probability. MAAAs are typically unique to a single clinical laboratory or manufacturer, and the resulting risk score or other value in itself represents a new and distinct medical property that is of independent medical significant relative to the individual component test results in clinical context in which the assay is performed. The results of individual component procedure(s) that are inputs to the MAAAs may be provided on the associated laboratory report.

    ACLA ISA comment re: ISA clarifications and AMA CPT code proposa

    Please clarify the term “harmonization status”.  We suggest this term be removed until it can be further clarified for expected implementation, clearly measured, etc.  It is too nebulous as currently stated.  For example, can it be measured and if so, how is it validated and how does it relate to the laboratory order or provider’s EHR system laboratory order?

    Does “numerically or categorically” mean/refer to “quantitative or qualitative”?  If so, we suggest using the terms “quantitative or qualitative” to avoid confusion. (These terms were used in the 2022 ONC’s LOINC survey so also for consistency.)

    Currently SNOMED CT codes are not used for ordering laboratory tests.  We suggest removing the 1st bullet entirely or move it the “Representing Test Performed” category which does address the laboratory results where SNOMED CT codes may be used. 

    Also remove the 3rd bullet since SNOMED CT is not pertinent to laboratory orders.

    We suggest you move the last bullet to the “Representing Test Performed” since it pertains to laboratory results.  It is confusing to have references to laboratory results (test performed) in the same category as the test ordered.

    Re: AMA’s suggestion to use CPT codes for laboratory orders, we suggest that AMA first work with HL7 to determine if CPT codes are approved by HL7 for laboratory test orders and if yes, how messaged. This must be done in conjunction with the HL7 Orders & Observations Work Group for maintenance of the LOI guide.  There are several issues:

    • ORC-16 suggested by AMA is the Order Control Code Reason, defined as: “This field contains the explanation (either in coded or text form) of the reason for the order event described by the order control code (HL7 Table 0119). Whereas an NTE after the order-specific segment (e.g., RXO, ORO, OBR) would provide a comment for that specific segment, the purpose of the order control code reason is only to expand on the reason for the order event.” 

    OBX-16 field uses HL7 controlled vocabulary (HL7 Table 0119) and is NOT the code for the test ordered. Per HL7 rules, you cannot use CPT codes in this field.

    • The LOI IG requires use of LOINC for order codes:

    “LOINC shall be used as the standard vocabulary to identify the ordered test in OBR-4(Universal Service Identifier) when an applicable LOINC code is available and provided by the laboratory. When no valid orderable LOINC code exists, the local code may be the only code sent.”

    “shall” is a modal verb equivalent to “required” or “must” per HL7 conformance

    “local code” is used by laboratories, for example, pending assignment of a LOINC code by Regenstrief or identified by the IVD equipment manufacturer

    • Currently the only mention of AMA in the HL7 LOI is “Following is a non-exhaustive list of third-party terminologies that may require a separate license:”
      • What is justification to introduce a new vocabulary, which would be additional expense for EHR systems/providers/and laboratories when there is already significant effort supporting LOINC for order codes, and LOINC codes are better suited for laboratory test order codes.
      • Typically, CPT codes are used by laboratories for billing/claims, not clinical laboratory test orders.  CPT typically indicates the procedure performed.  Multiple different tests are performed the same way, and therefore would have the same CPT code for multiple clinical laboratory tests.
      • CPT codes are too general for many laboratory clinical tests and might perpetuate many to one mapping issues as shown in CPT Code examples below:
        • CPT 80305 is drug screening by dipsticks, cups, cards or cartridges read visually
        • CPT 80306 is drug screening by dipsticks, cups, cards or cartridges read on an instrument reader
        • CPT 80307 is drug screening on a chemistry analyzer
        • Each code is only reported once per date of service regardless of the number of drugs tested
        • The codes include sample validation testing such as pH, specific gravity, nitrites, etc.

     

     

     

    AMA ISA comment re: ISA clarifications and AMA CPT code set

    The AMA’s understanding of the Interoperability Standards Advisory is that it provides a catalogue of available standards that inform developers’ choices for meeting interoperability needs, and not just for EHR systems. We do not believe current implementations for representing laboratory orders should limit developers’ coding system options for new solutions.

    The ONC ISA Content/Structure section for Laboratory identifies HL7 Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 3 - US Realm as the implementation specification for “Ordering Laboratory Tests for a Patient.” Within this implementation guide, OBR-4 (Universal Service Identifier) does include a note stating that LOINC is to be used to identify the ordered test. There are other areas in the implementation guide that open the potential for other coding systems, including:

    • Section 1.4.4 references LOINC and SNOMED CT as examples of vocabulary standards but does not limit the guide to their usage only.
    • Section 5.1 includes the data for common order (ORC). ORC.16 Order Control Reason Code includes ORC.16.3 Name of Coding System and it points to Table 0396 – Coding System. CPT is included in this table of coding systems.
    • Observation/Result (OBX) also includes Name of Coding System (OBX.3.3) with the same Table 0396.

    Because CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, laboratory services, and diagnostic services, it should be included as a coding and terminology option for Representing Laboratory Tests Ordered. CPT has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders.

    Again, the AMA’s understanding of the Interoperability Standards Advisory is that it provides a catalogue of available standards that inform developers’ choices for meeting interoperability needs, and not just for EHR systems. The inclusion of CPT is justified by the fact that implementations for representing laboratory orders should not limit developers’ coding system options for new solutions, but instead provide them a choice. CPT codes are used to represent lab test orders in the health care community. As such, developers should benefit from ONC's curation of available coding terminologies that reflects codes as they are used. Creating successful digital health products requires that developers are aware of the coding systems their customers use, have insight into available options and choices, and can leverage the ISA to help meet their customers' needs. CPT, as a comprehensive and regularly curated uniform language, is a viable terminology and coding option for developers to consider when developing solutions for representing laboratory orders interoperability needs.

    The AMA is requesting the…

    The AMA is requesting the Current Procedural Terminology (CPT) code set be added to the standards listed in the Vocabulary/Code Set/Terminology Section: Representing Laboratory Tests. The implementation specification named in the Content/Structure Section of the ISA is the HL7 Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 3 - US Realm, which defines the specifications and standards and provides implementation guidance for the electronic ordering of lab tests. Included in the LOI guide is the trigger event OML_O21 for sending the lab order and the ORC segment for Common Order. The CPT code set is a valid terminology for ORC.16 where the lab order code set is identified.

     

    Based on the content standard of LOI supporting the use of the CPT code set for sending a lab order, we believe CPT should be included as an additional terminology for “Representing Laboratory Tests” in the Vocabulary/Code Set/Terminology Section. Since “the ISA should serve as the first resource consulted to inform the selection of standards and implementation specifications,” it would be reasonable for terminologies supported by a named content implementation specification be named in the ISA’s corresponding terminology interoperability need.

    Representing Laboratory Test Performed

    Comment

    ACLA ISA comment re: clarifications to laboratory test performed

    Please clarify that “laboratory test performed” refers to the result(s) reported by the laboratory.

    Please clarify the 1st bullet; are you trying to state that additional information, such as the IVD equipment (Abbott, etc.), the way the test is resulted, etc. is the level of granularity necessary? We suggest this bullet should be removed.

    Please clarify the term “harmonization status”?  We suggest this term be removed until it can be further clarified for expected implementation, clearly measured, etc.  It is too nebulous as currently stated.  For example, can it be measured and if so, how is it validated and how does it relate to the laboratory test performed or provider’s EHR system laboratory test performed.

     

     

    Representing Laboratory Test Specimen

    Comment

    ACLA Comment on Representing Laboratory Test Specimen

    SNOMED CT U.S. appears to be the best option available today, but there is not widespread usage.

    Medications

    Representing Patient Medications

    Comment

    Medication route

    C-CDA specifies medication routes from NCIT/FDA, with an SCT translation; FHIR US Core leaves route unspecified. I recommend including medication route in ISA to support coordination. I recommend avoiding terms that precoordinate other dimensions (IV bolus, IV drip), or, if they are to be included, clarifying the scope and use of the value set.  

    NCPDP Comments

    While RxNorm is useful for communication of clinical data for clinical care, the NDC is critical for specific product identification in research, dispensing and administrative workflows. The NDC is the key, unique, product identifier and is the standard of practice used throughout the pharmacy industry to identify the specific product. The industry heavily relies on the NDC in all aspects of its business, including, but not limited to, drug ordering, medication dispensing, reporting, billing, rebates, adverse event reporting and patient safety. RxNorm lacks the specificity required to uniquely identify a product.

    Preserving Clinical Context

    General Comments: USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    NCPDP Comment

    1. Please remove previous NCPDP comments from 2017, as they no longer apply.
    2. NDC Adoption level is 5 since it is mandated by HIPAA.

    Compounded products will not…

    Compounded products will not have an NDC code. Herbal products do... good point.

    RxNorm is a good choice…

    RxNorm is a good choice. Hadn't realized that NDC was federally required. Ideally there would not be a choice of sending either RxNorm OR NDC because that would break interoperability. If both are sent that would be OK.

    UOM and VSAC

    Medications category should include code system for unit of measure to be complete (UCUM).  A defined and limited value set of medication units of measure should be identified and available in VSAC

    NCPDP - Comments - Not applicable to 2018 edition

    The National Drug Code (NDC) should have an Adoption Level of 5 and Federally Required should be a Yes. It is mandated under HIPAA.

    SNOMED is not currently used. NCPDP Standards would need to be modified to support SNOMED.

    Medication Reference Terminology (MED-RT) is not currently used.  NCPDP Standards would need to be modified to support MED-RT.

    NDC Federally Required and Adoption level

    Thank you for your comments.  We acknowledge the federal requirement to include NDC on CMS 1500 claim form.  With respect to adoption level, we would appreciate  your comments on level of adoption and use of NDC within existing health IT systems.

    Nursing

    Representing Clinical/Nursing Assessments

    Comment

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    May be underestimating the…

    May be underestimating the adoption level. Vital signs are nursing variables and they are required by Meaningful Use. Other nursing variables like Braden scores are also common - so maybe two bubbles.

    Regenstrief - Comment

    We concur with the recommended standards here (LOINC and SNOMED CT). The second sentence in Limitations, Dependencies, and Preconditions for Consideration should be amended because it only applies to SNOMED: Concepts for observation values from SNOMED CT should generally be chosen from two axes: Clinical finding and Situation with explicit context.

    Question / Answer Pairs

    Question / Answer pairs are valuable, supporting context of the assessment.  The assessment should not be limited to Q/A pairs. Full question with answer must be included in communication.

    We strongly approve of Nursing practice being included in ISA.  

    Agree with use of name/value pairs

    The Joint Commission agrees with the use of name/value pairs to represent clinical assessments.  This is the current structure used in electronic clinical quality measures (eCQMs).

    Representing Nursing Interventions

    Comment

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Should clarify what is meant…

    Should clarify what is meant by a nursing intervention and provide a definition and examples. If a request for vital signs is a nursing intervention then it will be hard to know when the request is fulfilled. if the code doesn't match it will be hard to manage the process from request to fulfillment

    We are delighted to see the…

    We are delighted to see the addition of Nursing content in the 2017 ISA and concur with all of the recommendations for use of LOINC and SNOMED CT.

    Representing Outcomes for Nursing

    Comment

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Regenstrief - Comment

    We concur with the recommendations for use of LOINC and SNOMED CT.

    Representing Patient Problems for Nursing

    Comment

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Representing Patient Clinical “Problems” (i.e., Conditions)

    Comment

    NCPDP Comment

    1. Request ONC add ICD-10 as a value. In NCPDP SCRIPT Standard Version 2017071 when clinical problems are reported, ICD-10 is required and SNOMED CT® is optional.
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- ICD-10

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 4

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Post-coordination

    • The 2nd and 3rd bullets both describe post-coordination and could be combined into one.
    • 'left leg fracture' now has a single SNOMED CT code; ‘left kidney stone’ could be used instead as an example of post-coordination.

    Agree with Rob McClure,…

    Agree with Rob McClure, LOINC does NOT seem appropriate in this context.

    Use of LOINC needs more explanation

    Not sure how LOINC would be used. You should explain how that code system is appropriate here.

    Preferred Language

    Representing Patient Preferred Language (Presently)

    Comment

    Adding Cantonese to preferred language set

    I serve a large population of Cantonese speaking Chinese patients in Northern California. The prior EHR version of Centricity allowed me to pick Cantonese as a preferred language so as to facilitate identification of those patients in verbal communications from the office. Now they have adopted the list from ONC, Cantonese is no longer an option. Please add Cantonese to the list. Thank you.

    NCPDP Comment

    1. NCPDP supports ONC’s recommendation.

    I believe this is a very…

    I believe this is a very large set of languages that includes dead language and many variants. There are smaller and more reasonable subsets. If users take this as being the required menu to present for all questions about language use, it adds a burden and time cost to filling out the required language field.

    Believe there should be a required subset (and an optional extended set as is the case for racial categories) to reduce the time and burden of patient registration.

    Yeah, you finally got this…

    Yeah, you finally got this one right ;-) !!!

    Pregnancy Status

    Representing Patient Pregnancy Status

    Comment

    ACOG Comments RE: Proposed Representing Pregnancy Status

    For full formatted version, please see the attached word document.

     

    Pregnancy Status Class

    Comment on the class: ACOG supports the comment already made supporting HL7s CCDA “Pregnancy Status” as it is comprehensive in this area and would better support both clinical research and public health use cases. https://www.hl7.org/implement/standards/product_brief.cfm?product_id=494

     

    1. PREGNANCY STATUS

    1A. Requirement Level: Must Have

    1A. Value set: Yes, No, Unknown, currently pregnant or confirmed pregnant, not currently pregnant or pregnancy refuted, recently pregnant, possibly pregnant.

    1A. Comments

    • Values have unnecessary overlap.  Clinically the importance is around confirmation of pregnancy.  ACOG recommends five values in this value set:  
    • Yes, confirmed pregnant;
    • No, confirmed not pregnant;
    • Unknown, possibly pregnant;
    • Recently pregnant within the last 12 months

    ACOG recommends that “recently pregnant” be defined as within the last 12 months to capture pregnancy related complications. Importantly, pregnancy-related deaths may occur well beyond the early postpartum period. 

    Per the CDC: 

    “A pregnancy-related death is defined as the death of a woman while pregnant or within 1 year of the end of a pregnancy –regardless of the outcome, duration or site of the pregnancy–from any cause related to or aggravated by the pregnancy or its management, but not from accidental or incidental causes.”

    • ACOG supports a new data class called “Pregnancy Episode” of which pregnancy status would be a data element.  Pregnancy Episode would have data elements that include a start and end date, pregnancy status, postpartum period, and a lactation period if relevant. End date of pregnancy would be defined both by an actual known date and be defined by a calculation off EDD such that the Pregnancy Episode would automatically close at a specified period of time post the EDD.

    1A. Use Case: The Use Case for Pregnancy Episode is to ensure that a status of pregnancy is accurate and not reflective of a pregnancy that took place in the past.  It is also important to ensure that multiple pregnancies within a given time period are accurately reflected. This is important for clinical care as well as for both research and public health use cases.

    1A. ACOG Related MaterialsCO736 | Optimizing Postpartum Care (05/2018)

     

    1B. Requirement Level: Nice to Have

    1B. Value set: Patient reported, pregnancy test, urine-based pregnancy test, serum-based pregnancy test, ultrasound, clinical impression, history of hysterectomy other.

    1B. Comments: ACOG questions the need for these ‘nice to have’ values under pregnancy status as they are duplicative of values that exist elsewhere. Pregnancy tests and ultrasound are already covered in the Laboratory and Procedures Class and thus do not have a need to be restated here. History of hysterectomy more appropriately belongs with a designation of medically unable to conceive. Patient reported is a general health concern.  Clinical impression is covered by yes, confirmed pregnant.

     

     

     

    2. DATE PREGNANCY STATUS

    Requirement Level: Must Have

    Value Set: Date

    No ACOG comments.

     

     

     

    3. ESTIMATED DELIVERY DATE (EDD)

    Requirement Level: Must Have if pregnant, preferred

    Value Set: Date

    Comments

    • The correct clinical terminology is Estimated Due Date, not Estimated Delivery Date
    • EDD and GA are calculations of one another and thus appropriately belong together as in that if you have one, you have the other.  As such they need to be treated the same by USCDI in terms of “must have”/”nice to have”, the difference being that they have two different value sets.  EDD is a “Must Have” as an alternative to GA; GA is a “Must Have” as an alternative to EDD. 

    ACOG Related Materials (ReVITALize): Obstetrics Data Definitions: Estimated Due Date (EDD): The best EDD is determined by last menstrual period if confirmed by early ultrasound or no ultrasound performed, early ultrasound if no known last menstrual period or the ultrasound is not consistent with last menstrual period, or known date of fertilization (e.g., assisted reproductive technology).

     

     

     

    4. EDD DETERMINATION METHOD

    Requirement Level: Nice to have if EDD used

    Value Set: LMP, ultrasound first trimester, ultrasound second trimester, ultrasound third trimester, ultrasound, Ovulation date, Embryo transfer, Other.

    Comments

    • The determination method is a “Must Have” for both EDD and GA.  The method reflects on the accuracy of the resulting date and is critical information to capture.  Being able to assess the reliability of the EDD/GA directly impacts clinical management of a pregnant individual; being unable to assess reliability represents a patient safety issue for both the mother and fetus.

    Value set comments:

    • ACOG recommends the following value set for EDD determination method:
      • LMP
      • Earliest ultrasound date and gestation age in weeks/days
      • First trimester ultrasound
      • Second trimester ultrasound
      • Third trimester ultrasound
      • Ultrasound, unknown trimester
      • Ovulation date
      • Embryo transfer date
      • Intrauterine insemination date
      • Other

    ACOG Related Materials

    • ACOG Committee Opinion #700 Methods for Estimating the Due Date (05/2017)
    • ACOG Committee Opinion #688 Management of Sub-optimally Dated Pregnancies (03/2017)
    • ACOG Committee Opinion #671 Perinatal Risks Associated with Assisted Reproductive Technology (09/2016)

     

     

     

    5. GESTATIONAL AGE

    Requirement Level: Must Have if Pregnant alternative to EDD

    Value Set: Number with units = weeks or days

    Comments: Should be weeks AND days, not weeks OR days

    ACOG Related Materials (ReVITALize): Obstetrics Data Definitions:  Gestational age  (written with both weeks and days; e.g., 39 weeks and 0 days) is calculated using the best obstetrical EDD based on the following formula: gestational age = (280 - (EDD - Reference Date))/ 7  

     

     

     

    6. DATE GESTATIONAL AGE DETERMINED

    Requirement Level: Must have if GA is used

    Value Set: Date

    No ACOG comments.

     

     

     

    7. GESTATIONAL AGE DETERMINATION METHOD

    Requirement Level: Must have if GA is used

    Value Set: Ultrasound, EDD, ovulation date, OTHERS?

    Comments: Dates should be supplied with the determination method as done with EDD determination method.  The same value set may be used as EDD determination method:  Embryo transfer, Ovulation date, ultrasound, ultrasound third trimester, ultrasound second trimester, ultrasound first trimester, LMP, Other, with the same comment above with dates added (embryo transfer date, ultrasound dates).  Intrauterine Insemination needs to be added to the value set.

     

     

     

    8. PREGNANCY OUTCOME

    Requirement Level: Nice to have if postpartum status is yes

    Value Set: Molar pregnancy, elective termination, spontaneous termination <20 weeks gestation, still birth, ectopic/tubal, live birth, unknown, other, not a live birth

    Comments

    • This should be a “Must Have” as pregnancy outcome impacts care both in the short term and management of future pregnancies
    • ACOG proposes the current proposed value set be replaced with: Live birth, Gestational Trophoblastic Disease, elective termination, early pregnancy loss (<13 weeks), early second trimester loss[1] (loss <20 weeks), stillbirth/fetal death (20 weeks or greater), ectopic/tubal, term birth, preterm birth, unknown, other. Justification:
      • Molar pregnancy should be replaced with Gestational Trophoblastic Disease as the more correct clinical terminology.
      • “Not a live birth” should be removed as other values cover this value.
      • In the first trimester, the terms miscarriage, spontaneous abortion, and early pregnancy loss are used interchangeably; ACOG prefers the term ‘early pregnancy loss’ to reflect these events, and recommends it be added to the value set.  “Spontaneous termination < 20 weeks gestation” should be removed.
      • Fetal death is widely used and thus ACOG recommends that the value be stillbirth/fetal death to reflect this.
      • The value set should add premature delivery and term birth as both are important to clinical care, research and public health use cases.
    • The Pregnancy Outcome must have the outcome date associated with it as metadata.  A stand-alone Outcome Date risks not associating the correct pregnancy episode with that outcome.  As such they must be linked together.

    ACOG Related Materials

    • ACOG Practice Bulletin #200 | Early Pregnancy Loss (08/2018): Early pregnancy loss is defined as a nonviable, intrauterine pregnancy with either an empty gestational sac or a gestational sac containing an embryo or fetus without fetal heart activity within the first 12 6/7 weeks of gestation.
    • ACOG Obstetric Care Consensus #10 | Management of Stillbirth (03/2020): The U.S. National Center for Health Statistics defines fetal death as the delivery of a fetus showing no signs of life as indicated by the absence of breathing, heartbeats, pulsation of the umbilical cord, or definite movements of voluntary muscles. There is not complete uniformity among states with regard to birth weight and gestational age criteria for reporting fetal deaths. However, the suggested requirement is to report fetal deaths at 20 weeks or greater of gestation (if the gestational age is known), or a weight greater than or equal to 350 grams if the gestational age is not known. The cutoff of 350 grams is the 50th percentile for weight at 20 weeks of gestation. To promote the comparability of national data by year and state, U.S. vital statistics data are collected for fetal deaths with a stated or presumed period of gestation of 20 weeks or more. Terminations of pregnancy for life-limiting fetal anomalies and inductions of labor for previable premature rupture of membranes are specifically excluded from the stillbirth statistics and are classified as terminations of pregnancy
    • ACOG Practice Bulletin #143 | Medical Management of First-Trimester Abortion (03/2014)
    • ReVITALize: Gynecology Data Definitions  

    [1] The term ‘early’ second trimester loss is being used to reflect the time period of 13 weeks to 19 6/7 weeks during the second trimester.  Prior to 13 weeks ‘early loss’ should be used and after 20 weeks ‘stillbirth/fetal death’ applies.

     

     

     

    9. PREGNANCY OUTCOME DATE

    Requirement Level: Must have if postpartum status is yes

    Value Set: Date

    Comments

    • The Pregnancy Outcome Date must have the Pregnancy Outcome linked to it. A standalone Outcome Date risks not associating the correct pregnancy episode with that outcome.  As such they must be linked together.
    • Pregnancy Outcome Date must also include the level of certainty in the date {certain, estimated, unknown} as some outcomes, particularly with ectopic and early pregnancy loss, may not have a known outcome date.  
    •  The requirement level is a “Must Have” when there is any “Pregnancy Outcome”, not just postpartum status of yes.  Not all pregnancies result in a postpartum state, such as an ectopic pregnancy.

     

     

     

    10. ANT PREGNANCY OUTCOME WITHIN THE LAST 42 DAYS?

    Requirement Level: Must have if not pregnant

    Value Set: Yes, no, unknown

    Comments

    • ACOG proposes that the data element of “Any pregnancy outcome within the last 42 days?” be replaced with the data element of “Not Pregnant”, with an expanded value set .  The data element of “Any pregnancy outcome within the last 42 days?” is covered  by data element number 8: “Pregnancy Outcome”.  What is missing from the Pregnancy Status Class is a specific data element of “Not Pregnant”
    • Value set for “Not Pregnant”: LMP, method of contraception, pregnancy intention, pregnancy prevention intention-reported, medically unable to conceive {hysterectomy, inability to conceive with current partner, bilateral oophorectomy, bilateral salpingectomy, genetically unable to conceive, menopause}.
    • ACOG recommends the Pregnancy Intention value set include the values specified by LOINC 86645-9:  Yes, I want to become pregnant; I'm OK either way; No, I don't want to become pregnant; Unsure                  
    • ACOG recommends the Pregnancy Prevention Intention -Reported value set include the values specified by LOINC 91144-6: I am already doing something to prevent pregnancy; I want to start preventing pregnancy; I don't want to prevent pregnancy;  I am unsure whether I want to prevent pregnancy;  I prefer not to answer; This question does not apply to me.

    Use Case: Support of clinical decision support (CDS) for medication prescribing; necessary data elements to support research which may require confirmation of protection against pregnancy.

    LOINC Details: Pregnancy prevention intention – Reported has existing LOINC codes. 

    LOINC Term Description: A patient’s current intentions to prevent pregnancy. This includes a male patient’s intentions to prevent pregnancy with a female partner. This term was created for, but not limited in use to, the Office of Population Affair’s (OPA’s) clinical performance measures for contraceptive provision endorsed by the National Quality Forum (NQF).     https://loinc.org/91144-6/

    Pregnancy Intention is a component of the LOINC Pregnancy and Contraception Panel 86642-6 (FPAR) Family Planning Annual Report.  LOINC Term Description: A patient's intention or desire in the next year to either become pregnant or prevent a future pregnancy. This includes male patients seeking pregnancy with a female partner. Pregnancy intention may be used to help improve preconception health screenings and decisions, such as determining an appropriate contraceptive method, taking folic acid, or avoiding toxic exposures such as alcohol, tobacco and certain medications. This term was based on, but is not limited in use to, Power to Decide's One Key Question®, used by the Office of Population Affair's (OPA's) Family Planning Annual Report (FPAR).  https://loinc.org/86645-9/

     

     

     

    11. LMP (Last Menstrual Period)

    Requirement Level: Nice to have alternate to EDD/GA not dependent on pregnant

    Value Set: Date

    Comments

    • Last menstrual period (LMP) should be a “Must Have” and not a “Nice to Have” as a data element.  LMP remains important in determining EDD/GA along with the first accurate ultrasound or both.
    • Value set, in addition to date, should include certain, estimated, unknown, N/A.  N/A should have the ability to include the reason for no menses {pre-menarcheal, hormonal suppression, breastfeeding, hysterectomy, endometrial ablation}.

    ACOG Related Materials

    • ReVITALize: Obstetrics Data Definitions: Estimated Due Date (EDD): The best EDD is determined by last menstrual period if confirmed by early ultrasound or no ultrasound performed, early ultrasound if no known last menstrual period or the ultrasound is not consistent with last menstrual period, or known date of fertilization (e.g., assisted reproductive technology).
    • ACOG Committee Opinion #700 Methods for Estimating the Due Date (05/2017)

     

     

     

    12. MULTIPLICITY OF BIRTH/PREGNANCY

    Requirement Level: Nice to have

    Value Set: Numeric

    Comments

    • Multiplicity of birth/pregnancy should be a “Must Have” and not a “Nice to Have” data element.  Twins and higher order pregnancies have an increase in fetal morbidity and mortality, primarily due to prematurity.  Because of the increase in adverse outcomes with non-singleton pregnancies, it is important to capture this data for both clinical research and public health use cases.  

    ACOG Related Materials

    • Practice Bulletin #169 Multifetal Gestations: Twin, Triplet, and Higher-Order Multifetal Pregnancies (10/2016)

    20200921_USCDI ACOG.docx

    Regenstrief - Comment

    We concur with the recommendations on the use of LOINC and SNOMED CT here, and the pattern holds for additional relevant information collected.

    Error in table of contents

    When using the left-hand side-bar, and select Pregnancy Status, the link displayed is incorrect. It is to Representing Health Care Data for Emergency Medical Services, but should be Representing Patient Pregnancy Status. Please see attached documentation for more details.

    ISA_link issue.docx

    Thanks - we will look into…

    Thanks - we will look into this and correct this issue ASAP.

    Procedures

    Representing Dental Procedures Performed

    Comment

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Representing Medical Procedures Performed

    Comment

    The CPT PLA and MAAA codes are for laboratory tests

    The AMA asks that ONC move the following bullet under “Limitations, Dependencies, and Preconditions for Consideration” to Representing Laboratory Tests Ordered with the edit noted:

     

    The AMA asks that ONC move the following bullet under “Applicable Value Set(s) and Starter Set(s)” to Representing Laboratory Tests Ordered:

    • CPT:
      • 80047 - 89398 - including Multianalyte Assays with Algorithmic Analyses (MAAA) codes 81490-81599
      • Proprietary Laboratory Analyses (PLA) U codes
      • MAAA administrative M Codes (0002M-0013M)

     

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    Have to be very careful with…

    Have to be very careful with the scope of what is intended by procedures. Historically, HL7 distinguished surgical procedures from diagnostic procedures. Currently, all of the LRI and LOR require LOINC for the order and for the result. ISA specifies LOINC for the name of radiology tests.  If a diagnostic test is defined as a procedure as below then there will be no way to verify that by comparing codes if the test ordered got results.  

    In the 4th bullet point under limitations, SNOMED CT is described as for coding treatments. That distinction regarding procedures should be made more broadly, so avoid the use of one code system to order a diagnostic study and another to report it.
        

    New IHE Profile IHE  [PCS] Paramedicine Care Summary 

    Be aware of and promote new profile. IHE  [PCS] Paramedicine Care Summary maps the flow of the patient information from the ambulance patient record, commonly known as the electronic Patient Care Record (ePCR), to the hospital Electronic Medical Record (EMR).

    From Profile - Currently, interventions and assessments are written into an ambulance electronic Patient Care Record (ePCR), and are either manually updated by the Emergency Medical Services (EMS) crew, or collected from electronic devices (e.g., hemodynamic monitor). The ePCR is updated with treatments and interventions that are administered during the transport. The hospital will not typically have access to paper or electronic versions of this patient information until the report is finished and signed in the ePCR and it is requested by the hospital. In this profile, the prehospital and paramedicine interventions and patient assessments are made available to the hospital/emergency room IT system electronically when the patient arrives, or in advance of patient arrival to the hospital. This informs medical decision making during the hospital treatment to improve patient care and to save lives

    AMA comments on the 2018 ISA

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

    Comment:

    Under “Limitations, Dependencies, and Preconditions for Consideration,” the AMA recommends that “CPT” be removed from the statement – “CPT/HCPCS are billing codes used for Outpatient Procedures.”  The CPT code set is mandated and widely used for claims processing, but it also serves in various functions outside of billing, including medical care review guidelines, medical education, patient outcomes, health services, and quality research. 

    Representing Social Care Procedures

    Comment

    Provenance

    Representing Data Provenance

    Comment

    IHE - Document Sharing

    The IHE Document Sharing includes Provenance of documents that are shared. 

    See the IHE whitepaper describing the Foundations of Document Sharing exchanges https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#

    see the normative specification on Document Sharing metadata

        https://profiles.ihe.net/ITI/TF/Volume3/ch-4.1.html#4.1.3

    Document Digital Signature

    The IHE-Document Digital Signature (DSG) profile Implementation Guide provides a method for digitally signing documents. Where documents are any form of stream of bytes including CDA and FHIR-Documents. The DSG profile is normative and can provide integrity protection with attribution to the signer. 

    The Normative publication at IHE is --  https://profiles.ihe.net/ITI/TF/Volume1/ch-37.html

    The Document Digital Signature (DSG) Profile defines general purpose methods of digitally signing of documents for communication and persistence. Among other uses, these methods can be used within an IHE Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD). There are three methods of digital signature defined here: Enveloping, Detached (manifest), and SubmissionSet.

    • An Enveloping Signature is a Digital Signature Document that contains both the signature block and the content that is signed. Access to the contained content is through removing the Enveloping - Digital Signature. Among other uses, this method should not be used with Document Sharing infrastructure.
    • A Detached Signature is a Digital Signature Document that contains a manifest that points at independently managed content. Detached signatures leave the signed document or documents in the original form. Among other uses, this method is recommended for use with a Document Sharing infrastructure to support Digital Signatures, as this method does not modify the original Document Content. This method uses the Document Sharing “SIGNS” relationship provides linkage.
    • A SubmissionSet Signature is a Detached Signature Document that attests to the content in a SubmissionSet by: containing a manifest of all the other Documents included in the SubmissionSet, and a reference to the SubmissionSet. The Document Sharing “SIGNS” relationship may be used but is not required.

    Ink-on-paper signatures have been a part of the documentation process in health care and have traditionally been indicators of accountability. Reliable exchange and storage of electronic data between disparate systems requires a standard that implements equivalent non-repudiation to prevent document creators from denying authorship and rejecting responsibility.

    Document Metadata

    The Document Metadata defined in IHE XDS/XCA/XDR/XDM and in IHE MHD (using FHIR DocumentReference); provides full Provenance for the document the metadata describes. The metadata also describes things beyond just Provenance.

    See https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#2-principles-of-ihe-for-health-document-sharing

    Public Health Emergency Preparedness and Response

    Representing Healthcare Personnel Status

    Comment

    Representing Hospital/Facility Beds Utilization

    Comment

    Representing Laboratory Operations (Population Laboratory Surveillance)

    Comment

    Representing Mass Vaccination Status

    Comment

    NCPDP Comments

    1. Request ONC add ICD-10 as a value since pharmacies report maximum vaccinations using ICD-10.
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- ICD-10

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 4

    Federally Required – Yes

    Cost – $

    Test Tool Availability – N/A

    Representing Population-Level Morbidity and Mortality

    Comment

    Race, Ethnicity and Tribal Affiliation

    Representing Patient Race and Ethnicity

    Comment

    AIRA Comments on Race and Ethnicity

    AIRA would welcome and encourage ONC’s coordination and/or leadership in determining  what value set should be used for “flavors of null” or “Data absent reasons” for race and ethnicity data. AIRA and other organizations can then encourage and support all systems in adopting those codes (and all work together via the ISA to expand those codes as necessary). Through our Standards and Interoperability Steering Committee (SISC), we have discussed recommending the following codes of UNK (unknown), ASKU (asked but unknown) and PHC1175 (refused to answer), but this draft attempt is not yet final due in large part to the number of groups simultaneously working to better define a standard in this area.

    AIRA recognizes that we are one of many groups grappling with race and ethnicity codes currently, and we would be happy to participate in a larger process to ensure the race and ethnicity data captured is accurate, consistent, complete, and timely, so that it can be used to address health disparities and ensure equity across the public and private health care system.

    Oregon Health Authority ISA Comments

    Oregon has implemented standards for the collection of Race, Ethnicity, Disability, and Language (REALD). State legislation in 2013 (HB 2134) required OHA and the Oregon Department of Human Services (ODHS) to develop standards in all programs that collect, record, or report demographic data. It is critical to collect these data in a consistent and standardized manner to assess how racism impacts community and individual health. While we aim to align state standards to national standards where possible, specific to race and ethnicity, the CDC v1.0 standard is not inclusive enough and is missing two races that are collected, recorded, and reported in Oregon – Somali and Slavic. We are unclear on the pathway to recommend changes to the CDC standard and if approved the time for the standard to be updated. We encourage ONC to deploy a clear path and forum for states to use when updates to national standards for demographics data are needed.

    OHA ISA Comments on letterhead_.pdf

    Changes to the CDC Standard on Race and Ethnicity

    ONC continues to work with our federal partners on refining standards related to demographic data. This is an area that will continue to evolve over time.

    Difficult to know what the…

    Difficult to know what the CDC specification is: I could find no enumeration of the possible codes in the proposal. This makes it hard to know what is intended and why. Something clearer should be produced before asking respondent to comment. The current OMB is clear regarding the top 5 and the extension The proposal has a lot of content regarding options for entering more than one race (but thought that capability was available in current race specification).

    What Use Case Does LOINC Support?

    What use case does LOINC support that is not currently supportable with existing implementations?  We are concerned about adding additional complexity for implementing an additional value set that does not align.

    This is good.

    This is good.

    Representing Tribal Affiliation

    Comment

    Research

    Representing Data for Biomedical and Health Services Research Purposes

    Comment

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of HL7: "Row 2 includes Pharmacogenomics and medical devices, which, to the best of my knowledge are rarely used or not used at all.  So lumping those with drug trials is inaccurate.  They should separate those out with adoption level 1.

    Row 3 - same comment as above:  Therapeutic Area Standards lists Process Maturity as Final, Implementation maturity as Production.  But, in fact, this refers to a whole series of IGs, some of which are in development as draft, some provisional (not quite final).  It’s not appropriate to lump them together and adopt the most mature value, but you don’t want to separate them out either.  I would change these values to Need Feedback or to some indication the they vary.  The phrase “apply across all therapeutic areas” is not correct.  They haven’t addressed, all, only some."

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of HL7: "The adoption levels in this section are mostly reasonable.  The exception is row 2 for SDTM. While EVS terminologies for drug trials are generally mature and widely adopted for regulatory submissions, row 2 includes Pharmacogenomics and medical device terminology, which, to the best of my knowledge are rarely used or not used at all.  So lumping those with drug trials is inaccurate.  They should separate those out.  Also, as a comment shows, they don’t really link to the appropriate terminology set — they just link to EVS.  The link should be to the appropriate code set not just the tool." 

    feedback

    Adoption of Sentinel and PCORNet is at least 2 dots.
    OMOP CDM adoption has increased in 2018 and should be changed to 4 dots.
    ADaM is an analytical standard but SDTM is not. SDTM is also listed in other parts of ISA. I think SDTM should be removed from the list here completely.

    Also, I fully agree with other commenter that the task "Representing Analytic Data for Research Purposes" should be defined in preconditions for considerations.
     

    If they are talking about…

    If they are talking about research use, then LOINC, RxNorm, SNOMED CT, ICD and CPT should also be listed they are all incuded in OMOP. Believe that LOINC and some of the others are listed are in PCORI and I2B2.

    All claims data bases in the US carry CPT and ICD9/10.


    While mentioning databases I2B2 sHould also be listed 

    Believe OMOP (ODHSI) has the…

    Believe OMOP (ODHSI) has the best of the cross institutional data models. It is in the 3rd or 4th generation. More than 100 institutions have contributed to it. It is international including data sets from the US, Korea and many others. It carries an estimated 400 million distinct patients. Google Scholar asserts 2980 papers mention OMOP.  Think it qualifies as final production and adoption of 3-4 bullets. 

    The adoption level may…

    The adoption level may exaggerate the reality. First, it only applies to a limited context, not analytic data nor all research purposes and FDA submission constraint is not stated. Further, in some contexts the codes are post coordinated using 3-4 fields and are not consistently included.

    Regenstrief - Comment

    This major section is about Vocabularies/Code Systems/Terminology standards. There’s another section for data models or transport/exchange/API standards. As such, this list should be pruned to vocabularies only and the standards for data models, data tabulation models, and other storage/transport specifications should be moved elsewhere.

    The question posed last year remains. What is “analytic data” (besides the obvious “data that can be analyzed”)? How is it different from the other domains of content listed elsewhere? Surely lab data is is analyzed for researched purposes. The mention of the research network (OHDSI, PCORnet, etc) data models not intended to spur their listing here, but rather to illustrate that they have adopted the main vocabularies listed elsewhere in the ISA (e.g. LOINC, SNOMED, RxNorm) for “research purposes”. So it just isn’t clear at all what this interoperability need is really meant for and why it is here. Please clarify with a a better definition and purpose statement.

    This is an example of a…

    This is an example of a poorly crafted interoperability need. What is “analytic data” and which kinds of “research purposes” is this meant to cover? More importantly though is why/how is this need is different from all of the other kinds of content listed elsewhere in the ISA (e.g. Lab tests, medications, diagnoses, etc). Certainly all of the large scale observational research networks (OMOP, Mini Sentinel, OHDSI, PCORnet) have developed common data models that employ many of the same vocabularies (LOINC, SNOMED, ICD) listed elsewhere in the ISA.

    CDISC may be appropriate for…

    CDISC may be appropriate for clinical trials, but is inadequate for a wide variety of other Analytic research.  This area needs more work.

    list non-CDISC standards

    In addition to CDISC standards, AllOfUs project (and many others) are using OMOP Common Data Model to standardize data.

     

    This standard should be added to the list

    Specs are here

    https://github.com/ohdsi/commondatamodel/wiki

     

    OMOP CDM Conformance testing tool is here

    https://github.com/OHDSI/Achilles

     

    cost is free

    adoption: 2 dots

    both maturities are: production/final

     

     

     

    Sex at Birth, Sexual Orientation and Gender Identity

    Representing Patient Gender Identity

    Comment

    AIRA Comments on Sexual Orientation and Gender Identity

    AIRA appreciates the work ONC has done around Sexual Orientation and Gender Identity (SOGI), and are exploring updating our SOGI guidance to better align with these referenced codesets.

    Additional values in the value set

    Gender identity represented in ISA does not represent all different gender identities expressed by the community as a whole. There are additional gender identities that could not be categorized in any of the values existing in the current version. For example – there are community members identifying themselves as ‘Transgender’ rather than either ‘Male Transgender’ or ‘Female Transgender’.

    Youth have shared mixed preferences on the inclusion of transgender identity in gender identity questions versus having a separate question about transgender experience. They have also expressed mixed preferences on the binary “transgender male/transgender female” option versus a general “transgender” label.

    Similarly, there are additional categories that are presently represented by ‘other’ which accurately represents additional gender identities, as follows:

    • Male
    • Female
    • Cis or Cisgender*
    • Transgender Male
    • Transgender Female
    • Transgender (non-specific)*
    • Non-binary*                                     
    • Gender-queer
    • Two-spirit*
    • Gender fluid*
    • Bigender*
    • Demigirl*
    • Demigirl*
    • Demiboy*
    • Questioning/not sure*
    • Choose not to disclose
    • Other, please describe
    • Unknown

     

    *New values being proposed

    Note: Other values is recommended for addition based on best practices

     

    ASKU does not mean Choose not to disclose

    Based on the cited codeSystem (http://terminology.hl7.org/CodeSystem/v3-NullFlavor) the meaning of ASKU is "asked but unknown". The subtly of "choosing not to disclose" is meaningful and is not captured in the ASKU notion defined in the HL7 nullFlavor code system. "choosing not to disclose" is best represented with the concept "asked-declined" in the data absent reason code system.

     

    ASKU | asked but unknown  | Information was sought but not found (e.g., patient was asked but didn't know)

     

    If the goal is to express the notion of "choose not to disclose", then you need to use the concept "asked-declined" from the Code System http://terminology.hl7.org/CodeSystem/data-absent-reason.

    Please note that this comment actually applies in many places throughout the ISA and should be changed consistently where ever the use of the notion "choose not to disclose" is indicated.

     

     

     

    ACLA ISA comment re: Representing Gender Identity

    We suggest that if AMA codes are added to the ISA, they should be added in the appropriate category of their use.  For example, 55970 and 55980 as a new Gender Identity section under the existing Procedures category, perhaps with a new “sub-category” added to existing “Dental” and “Medical Procedures” sub-categories. Codes associated with billing functions are more appropriate under the Administrative section.

     

    Current ISA Procedures

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Gender Identity. CPT code 55970 identifies an intersex surgery of male to female. CPT code 55980 identifies an intersex surgery of female to male.

    Evaluation and Management codes for a new patient (99381) and established patient (99391) include completing a gender appropriate history, exam, counseling and interventions.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports using LOINC and SNOMED CT; however, we ask for clarification as to why HL7 Version 3 Null Flavor was removed for 2018 review; it was added to the final 2017 ISA.  

    Regenstrief - Comment

    We concur with the recommendations on the use of LOINC and SNOMED CT (and null flavor) here. A new concept (and corresponding answer list) request for “Personal pronoun” will be submitted to LOINC and made available in a subsequent release.

    Personal Pronoun Value Set needed

    It is important and respectful to the patient to record their personal pronoun. Establish a value set for personal pronoun and include in transition of care documents.

    standard for preferred pronoun

    Please consider also a standard for preferred pronoun. Assuming gender based on the first name or registered sex and/or gender preference can present challenges to health care providers and their teams. In 2013, the World Professional Association for Trangender Health Electronic Medical Record Workging Group published recommendations for how gender should be recorded in EHRs. These recommendations specify that “Preferred Name, gender identity and pronoun preference, as defined by the patient, be included as demographic variables collected in the EHR.

    https://academic.oup.com/jamia/article/20/4/700/2909343

      AllianceChicago

     

    JAMIA - Transgender Health and EMRs.pdf

    Prounouns and name used are necessary too

    We think that the Applicable Value Set(s) and Starter Set(s) provide appropriate answer options to measure current gender identity. We also encourage the Office of the National Coordinator of Health Information Technology to encourage providers to ask the patient what pronoun and name the patient uses, use that pronoun and name when interacting with the patient, and enter this information into the Electronic Health Record. Knowledge of this information is essential to providing affirming health care to transgender patients.

    Chris Grasso, MPH

    Associate Vice President for Informatics and Data Services

    Fenway Health

     

    Representing Patient Sex (At Birth)

    Comment

    Additional values in the value set

    Current birth sex representation values categorize everything other than ‘Male’ and ‘Female’ into ‘Unknown’. It is important to disaggregate “unknown” further to accurately represent birth sex categories other than the two mentioned above.    “Sex assigned at birth” is an assigned label and does not always reflect how a person identifies and does not necessarily reflect a person’s gender identity. Sex assigned at birth and gender identity are not interchangeable concepts. Normalizing the term “sex assigned at birth”, we recommend removing the parenthesis from the category “Sex (assigned at Birth)”.

    The gender value set being proposed is as follows:

    • Male
    • Female
    • Intersex*
    • X*
    • Other, please describe
    • Not asked*
    • Asked, but unknown

     

    *New values being proposed

    NCPDP Comment

    1. NCPDP recommends the addition of Non-Binary as a valid value.

    LOINC has a number of…

    LOINC has a number of observation codes that could appy including sex assigned at birth as suggested by at least 2 commentators.

    46098-0 Sex 
    74698-2 Sex [AHRQ] 
    72143-1 Sex [HL7.v3] 
    21840-4 Sex NAACCR v.11 
    54131-8 Sex [USSG-FHT] 
    76689-9 Sex assigned at birth 

    Best Practice Recommendation from American Clinical Lab Assoc.

    The American Clinical Laboratory Association (ACLA) has developed a Best Practice Recommendation for administrative sex and clinical patient gender used for laboratory testing and reporting. Please add the hyperlink below to the "Limitations, Dependencies, and Preconditions for Consideration" section, referencing ACLA's guidance document.

    http://www.acla.com/acla-best-practice-recommendation-for-administrative-and-clinical-patient-gender-used-for-laboratory-testing-and-reporting/

     

    Need Sex Assigned at Birth

    Administrative sex is used to indicate the sex a person has listed with their insurance company. Administrative sex and sex assigned at birth are not always the same. If someone legally changes their sex or the sex listed with their insurance company is different, then their administrative sex and sex assigned at birth no longer align. Therefore, it is necessary to ask both administrative sex and sex assigned at birth to accurately identify all transgender/GenderQueer patients. When insurance companies accept both sex assigned at birth and gender identity, then administrative sex will no longer be necessary.

     

    Chris Grasso, MPH

    Associate Vice President for Informatics and Data Services

    Fenway Health

    Is "Sex at birth" different…

    Is "Sex at birth" different from Administrative Gender collected during registration?  This needs clarification in the industry, as different approaches have been used in multiple places.  It appears that "Sex at birth" has a) been considered a clarification of the meaning of "Administrative Gender", and b) been considered to be a separate demographic.

    Administrative sex is not…

    Administrative sex is not perfectly aligned with "Sex at birth" because at birth an infant can be undifferentiated. In addition, if we want sex recorded on the birth certificate, then many sates allow this to be changed: https://www.lambdalegal.org/know-your-rights/article/trans-changing-birth-certificate-sex-designations And as of January 2017, NY has allowed a person to have "Non-binary" as her birth certificate gender identity, see http://www.pbs.org/newshour/rundown/new-york-city-issues-nations-first-birth-certificate-marked-intersex/

    Representing Patient-Identified Sexual Orientation

    Comment

    Additional values in the value set

    Current sexual orientation values represented in ISA has ‘Something else, please describe’ which represents different sexual orientation categories that may have specific and different needs when compared to another distinct group with different sexual orientation. For example, as per the current ISA content, person with sexual orientation as ‘pansexual’ falls in the same group as person with e.g. ‘asexual’ as their orientation. These two groups may have completely different physical, social, emotional health needs which goes unnoticed in the current context of health equity. The term “homosexual” should be used only after consultation with community. GLADD recommends to “avoid identifying gay people as “homosexuals” as it can be considered derogatory and offensive to many lesbian and gay people.”

    The sexual orientation value set being proposed is as follows:

    • Straight or Heterosexual
    • Gay , Lesbian, or Same-gender-loving*
    • Bisexual
    • Pansexual*
    • Queer*
    • Asexual *
    • Two-spirit*
    • Graysexual or Gray asexual*
    • Demisexual*
    • Questioning/not sure*
    • Choose not to disclose
    • Other, please describe

     

    *New values being proposed

    The answer list for the…

    The answer list for the LOINC term listed below 
    System Answer ID 1 Bisexual /snomed.info/sct ©: 42035005 Bisexual (finding)  LA22877-7 2 Heterosexual snomed.info/sct ©: 20430005 Heterosexual (finding)                        LA22876-9 
    Homosexual //snomed.info/sct ©: 38628009 Homosexual (finding)                    LA22875-1 
    Other LA46-8 5 Asked but unknown                                                                    LA20384-6 
    Unknown ://snomed.info/sct ©: 261665006 Unknown (qualifier value) HL7     LA4489-6 

    Not aware that there is as of yet a federal requirement to use any particular list, SNOMED CT or otherwise.
     

    Sexual Orienation

    We think that the Applicable Value Set(s) and Starter Set(s) provide appropriate answer options to measure sexual orientation. Knowledge of this information is essential to providing affirming culturally competent health care to lesbian, gay and bisexual patients.


    Chris Grasso, MPH

    Associate Vice President for Informatics and Data Services

    Fenway Health

    Please consider a separate…

    Please consider a separate vocabulary term for asexual, a fairly common category.

    Social, Psychological and Behavioral Data

    Representing Alcohol Use

    Comment

    NCPDP Comments

    NCPDP supports the use of SNOMED CT.

    NCPDP Comment

    1. Substance use fields are available in NCPDP SCRIPT Standard Version 2017071 to allow alcohol use information to be transmitted via SNOMED codes
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Alcohol Use. CPT codes 99408 and 99409 identify patient screening and intervention for alcohol abuse. CPT codes 8032-80322 identify testing for alcohol. CPT code 82075 identifies an alcohol breath test.

    In addition, CPT Category II codes identify a patient screened for unhealthy alcohol use (3016F), patient counseled about risks of alcohol use (4158F), and patient counseled for pharmacologic treatment for alcohol dependence (4320F).

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    NCPDP Comment

    1. The SubstanceUse fields will be available in NCPDP SCRIPT Standard Version 2017071 to allow alcohol use information to be transmitted via SNOMED codes.

    NCPDP Comment

    1. Alcohol Use reporting via SNOMED codes is available in the NCPDP SCRIPT Standard Version 2017071.

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes.

    Since this LOINC code and…

    Since this LOINC code and answer set has been developed (30 behavior and functional status variables suggested by the IOM report and adopted for requirement in the last MU NPRM), the adoption level could now be very high.

    NCPDP - Comments

    SNOMED – Not currently used in NCPDP MMA mandated standards. Future versions of the NCPDP SCRIPT standard support SNOMED.

    Consider adding additional screening tools

    The Joint Commission currently has 3 chart-abstracted quality measures screening for alcohol use and treatment (SUB-1, SUB-2/2a, and SUB-3/3a) that are used by The Joint Commission and CMS in quality reporting programs.  We agree with inclusion of the Audit-C, as that is a validated screening tool for unhealthy alcohol use.  However, we also think that the AUDIT tool should be included as well.  This tool is also a validated survey instrument, and seems to be the most commonly used one for our chart-abstracted measures.  LOINC currently has 72110-0 Alcohol Use Disorder Identification Test [AUDIT] and 75624-7 Total Score [AUDIT].  In order for use, the rest of the questions from the survey instrument would need to be added in LOINC as well as the LOINC answer lists.

    AUDIT 10-question panel

    Thank you for your comment.  We have added the full AUDIT panel code and the total score code.  This does not imply any requirement for an EHR or other health IT system to capture the AUDIT test questions or total score, but we recognize that this test may currently be in use.

    Representing Depression

    Comment

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Depression. CPT code 96127 specifically identifies the screening of a patient within a behavioral assessment for depression.  CPT code 99483 includes an assessment for depression within the cognitive care plan. 

    These identified CPT codes were designed based on objective criteria for evaluating and assessing the severity and co-morbidities associated with the assessment and treatment of depression that should be listed as a standard for this interoperability need.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Depression. CPT code 96127 identifies patient screening through a behavioral assessment for depression.  CPT code 99483 includes an assessment for depression within the cognitive care plan.  CPT code 96127 includes an assessment for depression with this developmental/behavioral screening and testing.

    In addition, CPT Category II code 1040F, 2060F, and 3088F – 3093F identify evaluations of major depressive disorder. CPT Category II codes 1220F, 3351F – 3354F, 3725F identify a patient screened for depression within the treatment of other clinical conditions. CPT Category II codes 4060F – 4067F identify various services provided depression.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    General comment on social, psychological, and behavioral data

    The American Medical Association appreciates the opportunity to comment. Coding systems like SNOMED CT are designed to capture granular clinical data accurately. While it is possible to convert granular clinical data to ICD-10-CM (e.g., SNOMED CT -> ICD-10-CM), the reverse (e.g., ICD-10-CM -> SNOMED CT) is not reliable.

    Where ICD-10-CM may be the best choice to meet specific needs (e.g., public health reporting or administrative forms for payors), there are means whereby ICD-10-CM codes can be computed from the more specific clinical data provided by code systems like SNOMED CT.

    For these reasons, where there are established (legacy) code systems, we should continue to support them. However, where possible, we should also consider the graceful evolution to codings systems (e.g., SNOMED CT) that more accurately support granular clinical data.

    Since this LOINC code and…

    Since this LOINC code and answer set has been developed (30 behavior and functional status variables suggested by the IOM report and adopted for requirement in the last MU NPRM), the adoption level could now be very high.

    Representing Drug Use

    Comment

    NCPDP Comments

    NCPDP supports the use of SNOMED CT.

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Drug Use. CPT codes 99408 and 99409 identify patient screening and intervention for substance abuse. CPT codes 80320 – 80377 identify definitive drug testing.

    In addition, CPT Category II codes identify a patient screened for injection drug use (4290F) and counseled for pharmacologic treatment for opioid addiction (4306F).

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Representing Intimate Partner Violence

    Comment

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Exposure to Violence (Intimate Partner Violence). The CPT Evaluation and Maintenance services include assessing a patient’s risk and exposure to violence.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Since this LOINC code and…

    Since this LOINC code and answer set has been developed (30 behavior and functional status variables suggested by the IOM report and adopted for requirement in the last MU NPRM), the adoption level could now be very high.

    Additional questions needed

    Additional questions needed 

    Exposure to firearms, I do not see a viable code set for this. It should be a single question and answer

    Has the patient or significant other been incarcerated?

    We applaud adding Social Determinates being added to ISA.

    Re: patient/significant…

    Re: patient/significant other been incarcerated: may be a privacy concern about this one, though, would likely have predictive value.

    Representing Financial Insecurity

    Comment

    Representing Food Insecurity

    Comment

    Representing Housing Instability

    Comment

    Representing Educational Attainment

    Comment

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Level of Education. The CPT Evaluation and Maintenance services include assessing a patient’s level of education.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Representing Physical Activity

    Comment

    Current Procedural Terminology (CPT) code set be added

    The American Medical Association (AMA) requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Physical Activity. Currently a two-question screening tool in LOINC is listed as the standard for this interoperability need. The CPT code set can convey additional information about a patient’s physical activity. Specifically, codes for physical and occupational therapy evaluations identify a change in a patient’s activity status. The evaluation and plan of care for a person undergoing physical or occupational therapy are critical to returning them to their former level of physical activity or their new optimal level. Changes in a person’s physical activity can have a significant effect on their social and psychological well-being, and, therefore, are important to convey through care coordination with other providers. Other CPT codes related to physical activity include ones for athletic training evaluations, therapeutic procedures to improve physical function, orthotic management and training and prosthetic training, and tests and measurements of physical performance.

     

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders.

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Physical Activity. Physical activity is identified in the Physical Therapy Evaluations codes, 97161 – 97164, and Occupational Therapy Evaluations codes, 97165 – 97167. CPT codes 97169 – 97172 identify athletic training evaluations, which includes a physical activity profile. The CPT Evaluation and Maintenance services include assessing a patient’s level of physical activity. CPT codes 97750 and 97755 identify tests and measurements of physical performance.

    In addition, CPT Category II code 1003F identifies an assessment of patient level of activity.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Since this LOINC code and…

    Since this LOINC code and answer set has been developed (30 behavior and functional status variables suggested by the IOM report and adopted for requirement in the last MU NPRM), the adoption level could now be very high.

    Regenstrief - Comment

    Although there are many ways to record or observe physical activity, we agree that LOINC is the appropriate terminology for these observations and that the “exercise vital sign” screen is a good starting place.

    In version 2.64, LOINC published a slightly updated panel (89574-8) for the EVS that reflects Kaiser Permanente’s conceptualization of these screening observations. The two child elements in this panel are 89555-7 and 68516-4.

    Representing Social Care Services Information

    Comment

    Representing Social Connection and Isolation

    Comment

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Social Connection and Isolation. The CPT Evaluation and Maintenance services include assessing a patient’s social history.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Since this LOINC code and…

    Since this LOINC code and answer set has been developed (30 behavior and functional status variables suggested by the IOM report and adopted for requirement in the last MU NPRM), the adoption level could now be very high.

    Representing Social Determinants of Health - Conditions and Diagnoses

    Comment

    NCPDP Comment

    NCPDP recommends that ONC add to the Limitations, Dependencies, and Preconditions for Consideration section: NCPDP supports the use of ICD-10-CM and SNOMED CT US Edition codes to represent SDOH Conditions and Diagnoses.  NCPDP produced a white paper, Collecting and Exchanging Social Determinants of Health Data in the Pharmacy, to assist in the usage of these codes within the NCPDP SCRIPT and Telecommunication Standards, as well as the Pharmacist eCare Plan.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports ONC’s recommendation for using SNOMED CT U.S. Edition and ICD-10-CM to represent SDOH conditions and diagnoses.  PHIT also recommends reviewing NCPDP’s white paper, “Collecting and Exchanging Social Determinants of Health Data in Pharmacy,” which was produced to assist in the usage of these codes within NCPDP SCRIPT and Telecommunications Standards and the Pharmacist eCare Plan.

    Representing Transportation Insecurity

    Comment

    Oregon Health Authority ISA Comments

    Oregon is pursuing multiple approaches to address unmet needs related to SDOH. We support the inclusion of standards for representing housing insecurity, representing food insecurity, and representing transportation insecurity. Although PRAPARE is one commonly used screening tool, other validated tools also are in widespread use. We encourage the inclusion of coding for additional screening tools as available, building on the work of the Gravity Project.

    OHA ISA Comments on letterhead__0.pdf

    Comments from the Alliance for Nursing Informatics

    Thank you for the opportunity to provide comments on the Interoperability Standards Advisory (ISA) and the Standards Version Advancement Process (SVAP).

    ANI strongly endorses social determinants of health (SDOH) as a key interoperability need for better care and health nationwide, amplified as a need during the COVID-19 public health emergency. While SDOH data elements are present within the ISA, but adoption is low, and standards are not federally required. Therefore, ANI strongly supports further development to include SDOH standards in regulations and as federal program requirements.

    Please see attachment for our full comments.

    ANI COMMENTS on ISA-SVAP _FINAL_1.pdf

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Transportation Insecurity. The CPT Evaluation and Maintenance services include assessing a patient’s level of transportation insecurity. Care plan services also address transportation needs.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Representing Social Determinants of Health - Goals

    Comment

    Representing Social Determinants of Health - Interventions

    Comment

    SNOMED codes for SDOH

    Working for under priveledge population of India

    Representing Social Determinants of Health - Screening Assessments

    Comment

    Representing Stress

    Comment

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Stress. The CPT codes 90839 and 90840 are used to identify psychotherapy for a crisis. Also, the CPT Evaluation and Maintenance services include assessing a patient’s level of stress.

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Since this LOINC code and…

    Since this LOINC code and answer set has been developed (30 behavior and functional status variables suggested by the IOM report and adopted for requirement in the last MU NPRM), the adoption level could now be very high.

    LOINC cited is insufficient

    76542-0 is stated to be Occupational Stress Questionnaire.  Stress has multiple causes, Occupational, Personal, etc.  This needs exploration and better difinition 
     

    76542-0

    Do you feel stress - tense, restless, nervous, or anxious, or unable to sleep at night because your mind is troubled all the time - these days [OSQ]

    supplemental LONIC suggestion 

    66578-6

    Now thinking about your mental health, which includes stress, depression, and problems with emotions, for how many days during the past 30 days was your mental health not good [HRQOL]

     

    This is the specific one…

    This is the specific one chosen (from a Finnish survey instrument by the IOM report and required by ONC), it is what is in there.

    Representing Elder Abuse

    Comment

    Representing Employment Status

    Comment

    Representing Health Insurance Coverage

    Comment

    Representing Homelessness

    Comment

    Representing Inadequate Housing

    Comment

    Representing Material Hardship

    Comment

    Representing Medical Cost Burden

    Comment

    Representing Veteran Status

    Comment

    Tobacco Use

    Representing Patient Electronic Cigarette Use (Vaping)

    Comment

    WA State Department of Health Tobacco/Smoking/Vaping Comments

    In 2018, e-cigarette products with nicotine concentrations of five percent or greater comprised approximately two-thirds of the e-cigarette market, while zero-nicotine products accounted for less than one percent.[1] To more accurately assess nicotine intake and potential nicotine dependence among patients, Washington State Department of Health recommends distinguishing e-cigarette use by nicotine concentration, rather than e-cigarette liquid with nicotine versus e-cigarette liquid without nicotine. Additionally, Washington State Department of Health concurs with the recommendation submitted on September 19, 2018 by Dr. Michael Fiore and Robert Adsit to implement non-overlapping values for smoking status. [1] Romberg AR, Miller Lo EJ, Cuccia AF, Willet JG, Xiao H, Hair EC . . . King BA (2019). Patterns of nicotine concentrations in electronic cigarettes sold in the United States, 2013-2018, Drug and Alcohol Dependence, 203, 1-7. doi:10.1016/j.drugalcdep.2019.05.029.

    WA State Department of Health Tobacco/Smoking/Vaping Comments

    In 2018, e-cigarette products with nicotine concentrations of five percent or greater comprised approximately two-thirds of the e-cigarette market, while zero-nicotine products accounted for less than one percent.[1] To more accurately assess nicotine intake and potential nicotine dependence among patients, Washington State Department of Health recommends distinguishing e-cigarette use by nicotine concentration, rather than e-cigarette liquid with nicotine versus e-cigarette liquid without nicotine. Additionally, Washington State Department of Health concurs with the recommendation submitted on September 19, 2018 by Dr. Michael Fiore and Robert Adsit to implement non-overlapping values for smoking status.

    [1] Romberg AR, Miller Lo EJ, Cuccia AF, Willet JG, Xiao H, Hair EC . . . King BA (2019). Patterns of nicotine concentrations in electronic cigarettes sold in the United States, 2013-2018, Drug and Alcohol Dependence, 203, 1-7. doi:10.1016/j.drugalcdep.2019.05.029.

    NCPDP Comments

    Modify NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 Adoption Level to 5.

    Removed Reference

    Removed “See LOINC projects in the Interoperability Proving Ground” since LOINC has been removed from the Standards in this section.

    NCPDP Comment

    1. Substance use fields are available in NCPDP SCRIPT Standard Version 2017071 to allow tobacco use information to be transmitted via SNOMED codes
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    Representing Patient Secondhand Tobacco Smoke Exposure

    Comment

    WA State Department of Health Tobacco/Smoking/Vaping Comments

    In 2018, e-cigarette products with nicotine concentrations of five percent or greater comprised approximately two-thirds of the e-cigarette market, while zero-nicotine products accounted for less than one percent.[1] To more accurately assess nicotine intake and potential nicotine dependence among patients, Washington State Department of Health recommends distinguishing e-cigarette use by nicotine concentration, rather than e-cigarette liquid with nicotine versus e-cigarette liquid without nicotine. Additionally, Washington State Department of Health concurs with the recommendation submitted on September 19, 2018 by Dr. Michael Fiore and Robert Adsit to implement non-overlapping values for smoking status.   [1] Romberg AR, Miller Lo EJ, Cuccia AF, Willet JG, Xiao H, Hair EC . . . King BA (2019). Patterns of nicotine concentrations in electronic cigarettes sold in the United States, 2013-2018, Drug and Alcohol Dependence, 203, 1-7. doi:10.1016/j.drugalcdep.2019.05.029.

    WA State Department of Health Tobacco/Smoking/Vaping Comments

    In 2018, e-cigarette products with nicotine concentrations of five percent or greater comprised approximately two-thirds of the e-cigarette market, while zero-nicotine products accounted for less than one percent.[1] To more accurately assess nicotine intake and potential nicotine dependence among patients, Washington State Department of Health recommends distinguishing e-cigarette use by nicotine concentration, rather than e-cigarette liquid with nicotine versus e-cigarette liquid without nicotine. Additionally, Washington State Department of Health concurs with the recommendation submitted on September 19, 2018 by Dr. Michael Fiore and Robert Adsit to implement non-overlapping values for smoking status.

     

    [1] Romberg AR, Miller Lo EJ, Cuccia AF, Willet JG, Xiao H, Hair EC . . . King BA (2019). Patterns of nicotine concentrations in electronic cigarettes sold in the United States, 2013-2018, Drug and Alcohol Dependence, 203, 1-7. doi:10.1016/j.drugalcdep.2019.05.029.

    NCPDP Comments

    1. Substance use fields are available in NCPDP SCRIPT Standard Version 2017071 to allow tobacco use information to be transmitted via SNOMED codes
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 5

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Second Hand Tobacco Smoke Exposure. CPT Category II code 1032F identifies a patient who is a current smoker or currently exposed to secondhand smoke.  

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    Representing Patient Tobacco Use (Smoking Status)

    Comment

    WA State Department of Health Tobacco/Smoking/Vaping Comments

    In 2018, e-cigarette products with nicotine concentrations of five percent or greater comprised approximately two-thirds of the e-cigarette market, while zero-nicotine products accounted for less than one percent.[1] To more accurately assess nicotine intake and potential nicotine dependence among patients, Washington State Department of Health recommends distinguishing e-cigarette use by nicotine concentration, rather than e-cigarette liquid with nicotine versus e-cigarette liquid without nicotine. Additionally, Washington State Department of Health concurs with the recommendation submitted on September 19, 2018 by Dr. Michael Fiore and Robert Adsit to implement non-overlapping values for smoking status. [1] Romberg AR, Miller Lo EJ, Cuccia AF, Willet JG, Xiao H, Hair EC . . . King BA (2019). Patterns of nicotine concentrations in electronic cigarettes sold in the United States, 2013-2018, Drug and Alcohol Dependence, 203, 1-7. doi:10.1016/j.drugalcdep.2019.05.029.

    WA State Department of Health Tobacco/Smoking/Vaping Comments

    In 2018, e-cigarette products with nicotine concentrations of five percent or greater comprised approximately two-thirds of the e-cigarette market, while zero-nicotine products accounted for less than one percent.[1] To more accurately assess nicotine intake and potential nicotine dependence among patients, Washington State Department of Health recommends distinguishing e-cigarette use by nicotine concentration, rather than e-cigarette liquid with nicotine versus e-cigarette liquid without nicotine. Additionally, Washington State Department of Health concurs with the recommendation submitted on September 19, 2018 by Dr. Michael Fiore and Robert Adsit to implement non-overlapping values for smoking status.

    [1] Romberg AR, Miller Lo EJ, Cuccia AF, Willet JG, Xiao H, Hair EC . . . King BA (2019). Patterns of nicotine concentrations in electronic cigarettes sold in the United States, 2013-2018, Drug and Alcohol Dependence, 203, 1-7. doi:10.1016/j.drugalcdep.2019.05.029.

    NCPDP Comments

    1. Substance use fields are available in NCPDP SCRIPT Standard Version 2017071 to allow tobacco use information to be transmitted via SNOMED codes
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 5

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    NCPDP Comment

    1. Substance use fields are available in NCPDP SCRIPT Standard Version 2017071 to allow tobacco use information to be transmitted via SNOMED codes
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    The AMA requests that the…

    The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Tobacco Use (Smoking Status). CPT codes 99406 and 99407 identify the patient as a tobacco user and that cessation counseling was provided.

    In addition, CPT Category II codes identify assessment of tobacco use (1000F), current tobacco user with asthma (1032F), current tobacco user with heart disease (1034F), tobacco use cessation counseling (4000F), tobacco use cessation pharmacologic therapy (4001F), and patient screened as a tobacco user and received cessation intervention (4004F).

    CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.

    NCPDP Comment

    1. The SubstanceUse fields will be available in NCPDP SCRIPT Standard Version 2017071 to allow tobacco use information to be transmitted via SNOMED codes.

    Support smoking status clarification

    Dear ONC,

    I support eliminating the redundant terminology of "light" and "heavy" smoker, as keeping these would require some standard definition to reference.

    I would also support that "passive smoker - nonsmoker exposed to secondhand smoke" be included.  The Surgeon General has determined that there is no risk-free level of smoke exposure.

    Elisa Tong, MD, MA
    Associate Professor of Internal Medicine
    University of California, Davis

    Final SRNT comment

    Attached please find the final comment from the Society for Tobacco Research and Intervention (SRNT).  The version submitted previously by Bruce Wheeler was a draft document.

    Sincerely,

    Megan Piper, SRNT Treasurer

    SRNT smoking status comments letter - FINAL.docx

    RE: smoking status

    Reproduced from the attached letter:

    October 1, 2018

    Office of the National Coordinator for Health Information Technology

    U.S. Department of Health and Human Services

    330 C St SW, Floor 7

    Washington, DC 20201
     

    Re: Representing Patient Tobacco Use (Smoking Status)

    Dear Colleagues, 

    The Tobacco Treatment Program at the Medical University of South Carolina appreciates the opportunity to provide input on the Interoperability Standards Advisory (ISA) process for representing patient tobacco use.  We commend the Office of the National Coordinator for Health Information Technology (ONC) on their commitment to ensuring the ISA process facilitates interoperability for clinical, public health, and research purposes. It is our hope that smoking status can be more documented in Electronic Health Records (EHR) in a way that provides more consistency to allow for interoperability and streamlines categories to reduce confusion and improve providers’ workflow. 

    One concern with the Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) EHR smoking status classification is that the categories are open to interpretation and importantly are not mutually exclusive which adds confusion to the process of correctly classifying patients smoking status. The current value set includes:

    Current every day smoker

    Current some day smoker

    Former smoker

    Never smoker

    Smoker, current status unknown

    Unknown if ever smoked

    Heavy tobacco smoker

    Light tobacco smoker

    The overlap in values, lack of definitions for categories that are open to interpretation (e.g., light and heavy smoker), and risk of different interpretations of the record between different healthcare settings reduces the potential for tobacco use data to be organized, queried, and analyzed for the benefit of individuals, institutions, and populations.

    To address overlap and interpretation challenges, we propose ONC address the following through the ISA process:

    1. Simplify the smoking status choices/classifications. 
    2. Remove overlapping smoking status classifications.

    We recommend adoption of the following simplified categories:

    Current Every Day Smoker

    Current Some Day Smoker

    Former Smoker

    Never Smoker

    Smoking Status Unknown

    A second concern has to do with fully capturing smoking status in a meaningful way to direct interventions to those who are current smokers.  We have found that asking a follow-up question of CURRENT and FORMER smokers beyond the one recommended above, improves capture by about 25% of those who may be in need of help with quitting and remaining off cigarettes.   

    ASK OF CURRENT AND FORMER SMOKERS: 

    When did you last smoke a cigarette (even one or two puffs)?

    •         I smoked a cigarette today (at least one puff)

    •         1 to 7 days ago

    •         8 days to 1 month ago

    •         More than 1 month ago to 1 year ago

    •        More than 1 year ago

    •        Don't know/don't remember

    Thank you for considering our input on this important issue. These comments are based on careful discussion by members of our Tobacco Treatment Program. If we at MUSC can provide any additional information or assistance to ONC, please do not hesitate to contact Benjamin Toll, PhD, Professor of Public Health Sciences, at toll@musc.edu.

    Sincerely,

    Kathleen Cartmell, Ph.D.

    K. Michael Cummings, Ph.D.

    Georges El Nahas, Ph.D.

    Phil Smeltzer, Ph.D.

    Benjamin Toll, Ph.D.

    Graham Warren, M.D., Ph.D.

    MUSC ONC Smoking Status FINAL.pdf

    Units of Measure

    Representing Units of Measure (For Use with Numerical References and Values)

    Comment

    This safe medical practice…

    This safe medical practice as defined in the context of prescribing. Not reporting of numeric results, so the objection is not relevant. 

    The "^" value could be a problem. It's in V2 but it's not the only way to represent powers. Will ask the UCUM committee to address V3 CDA and FHIR so there aren't delimiters to conflict with.

    UCUM should be considered the code in triumvirate of code display text and code system. Senders are free to deliver whatever display text they now send.

    Point out industry standards. The problem in observation messages is that they are totally understandardized. 

    Strongly support UCUM use so…

    Strongly support UCUM use so results can be accurately analyzed.

    We strongly concur with the…

    We strongly concur with the listing of UCUM here. Daniel Vreeman has compiled a list of UCUM conversion and validation resources here. It is worth noting that UCUM is designed for accomplishing a computable units representation in electronic communication. This is the main interoperability need. Having display strings for humans (whether patients, providers, or others) is another matter. We recommend that the last bullet point (Numerical representation are uniform…) be removed as it totally unclear.

    Table 3: Dimensionless units…

    Table 3: Dimensionless units. The units ppb and ppt are deprecated because the names “billion” and “trillion” are ambiguous. The expression “10*-9” or “10*-12” should be used instead. When the units percent or “parts per N” are used for concentrations specific units are prefered, e.g., “ug/l” for mass concentration. The expression “ug/kg” for ppb is also valid.
    the number ten for arbitrary powers  10n  10*  10*  no 10 
    the number ten for arbitrary powers  10n  10^  10^  no 10 

     

    Both * and ^ can be used for arbitrary powers as shown in the table above (see http://unitsofmeasure.org/ucum.html#section-Derived-Unit-Atoms)

    Recognize a value set that uses the ^ form.

    WHICH values in HL7 conflict? I know SOME values are different, but I have seen none that conflic. See http://motorcycleguy.blogspot.com/2009/11/iso-to-ucum-mapping-table.html

     

     

    Good point. Will explore…

    Good point. Will explore with users.

    Test tool

    UCUM validators exist. Ability to test if unit is valid or unit1 converts to unit2 are all valid test tasks. Consider changing n/a in testing to linking to validation and conversion tools.

     

    e.g.,

    http://xml4pharmaserver.com/WebServices/UCUM_webservices.html

    https://lhncbc.github.io/ucum-lhc/demo.html

     

    Thank you for this comment…

    Thank you for this comment. Links to these test tools have been added. 

    Vital Signs

    Representing Patient Vital Signs

    Comment

    Continuous Glucose Monitoring

    Please provide details for the implementation of continuous glucose monitoring data in the Vital Signs data elements.  Would like to know when to expect this data element and which version of USCDI to expect this to be released.  Would also require the data element type (expecting integer) including precision (expecting 0).

    Preserving Clinical Context

    General Comments:

    USCDI specifies lots of clinical data classes and data elements

    • Resolving to myriad de-coupled fragments
    • With vanishingly little focus on:
      • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
      • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

    It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

    LOINC and IEEE have an…

    LOINC and IEEE have an agreement and the IEEE codes are linked to the LOINC code for vitals (and many other things but FHIR and HL7 V2 argue that the LOINC code should be the code sent is the message). 

    Should not be proposing two different code systems for the same purpose and it will break interoperability. 

    Vital Sign Definition Enhancements Needed for CCDA

    Current HL7 CDA R2.1 IG: Transition of Care Vital Signs Value Set: Vital Sign Result Type urn:oid:2.16.840.1.113883.3.88.12.80.62   This is a finite group of vital signs. Current CCDA IG has not defined inclusion of device information related to vital signs, this will need to be resolved if transport is to include CCDA

    Depending on the transition of care environment and workflow there is a higher percentage of vital signs that will not include device information and the majority of the “vital signs” in defined Vital Sign Result Type are not readily supported by devices.

    With inclusion of device support it is implied that the Vital Sign Result Type list should be expanded beyond basic vital signs, that will need to be specified. 

    Vital signs should optionally contain supporting information.  E.g. “8310-5 Body Temperature” should have supporting collection information. Oral, Tympanic, Rectal, Etc. This is clinically valuable, it needs to be defined in implementation guide. 

    ISO/IEEE 11073 Health informatics - Medical / health device communication standards should remain not federally required if there is a cost involved.

    Agree and LOINC carries such…

    Agree and LOINC carries such variables if ISA goes that way.

    Section I – V Representing Patient Vital Signs

    In the connected health system, the device status info and context info are useful to ensure safe and efficient operation and maintenance of the system.

    Such info is not the vital sign itself, but is necessary ingredient for the infrastructure when conveying vital sign data from one end to another.

    It may also be leveraged by the platform operator or service provider to remotely manage and/or configure the user devices. Therefore we suggest ONC ISA to include such type of data, at least as an Annex.

    ISO/1EEE 11073 Nomenclature is a data set which contains such info. For example: the generic device status, the CGM device status, the operational and therapy conditions of insulin pump, etc.

    Section I - V Representing Patient Vital Signs

    For adoption one should mention that the MDC codes are being adopted into FHIR and has become the defacto representation for device data by the HL7 Devices on FHIR profiles for PHD and PoCD representations.

    Background: 

    Regarding 'Test tool availability':
    I know there is room for improvement (in terms of quality and clinical value) but don't we have test tools for IHE profiles based on 11073 already nicely provided by the National Institute of Standards and Technology:
    http://ihe-pcd-precon.nist.gov/PCD-HL7WebPreCon/
    For 11073-10103 we work together with the heart rhythm society for years now and soon more representatives from Europe to improve the clinical value of the standard and tests of the nomenclature 11073-10103.

    Regarding 'Federally required':
    A number of 11073 nomenclatures may soon become required (!) by the Austrian Federal Ministry of Health for example. Italy already had national tenders requesting to be compliant to IHE IDCO based on 11073.
    FDA already labels some of the 11073 as Recognized Consensus Standards.


    Regarding 'Adoption level':
    The federal rule from Austria above correctly states that all major vendors do support this standard already (which is not fully correct but we are fairly close) and the number of devices already sending 11073 data is in the area of a few millions every day.


    Do you think the Pacemaker industry should be more active in Continua as well? So far, I see this more as a place for external devices.

     

    ISA is US oriented federal…

    ISA is US oriented federal means the US federal government.

    Section I – V Representing Patient Vital Signs

    Please make the following changes:

    1.For 2nd row, ISO/IEEE 11073 Implementation Maturity should be noted as Production

    2.The Adoption Level at least 3 dots.

    3.The test tool availability should be noted as Yes.

    4.Add the following note to the Dependencies section for Consideration: See Continua CODE for Healthcare in the Interoperability Proving Ground. Link: https://www.healthit.gov/techlab/ipg/node/4/submission/2046

    Section I – V Transmitting a Unique Device Identifier

    Please make the following changes:

    1.Please add row for  “Implementation” and add “IEEE 11073 PHD Harmonization Pattern for Unique Device Identifiers”. The remaining fields are the same as for HL7 Harmonization…

    Work Information

    Representing Job, Usual Work, and Other Work Information

    Comment

    NIOSH Comments

    NIOSH suggests adding HL7 value sets under the Applicable Value Set(s) and Starter Set(s) section as they are in the interoperability standards for sharing work information. The HL7 value set recommendations are applicable to Employment Status, Work Schedule, and Work Classification as outlined in the attachment.

     

    2023 NIOSH ISA Updates - Vocabulary_CodeSet_Terminology_0.pdf

    Proposed Additional Industry and Occupation Value Sets

    We are collaborating internally to prepare a comment adding the updated CDC_Census industry and occupation value sets and will provide further information as soon as possible.

    Sending a Notification of a Long-Term Care Patient’s Admission, Discharge and/or Transfer Status to the Servicing Pharmacy

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC sunset: NCPDP® Specialized Standard, Implementation Guide, Version 10.6 as this version is no longer supported by the industry.
    2. NCPDP recommends that ONC add the following:

    Type – Standard

    Standard/Implementation Specification – NCPDP Specialized Standard, Implementation Guide, Version 2023011

    Standards Process Maturity – Final

    Implementation Maturity- Feedback Requested

    Adoption Level – Feedback Requested

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to add NCPDP Specialized Standard, Implementation Guide, Version 2023011 to the standard type.

    NCPDP Comment

    1. Need to change NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 to NCPDP Specialized Standard, Implementation Guide, Version 2017071 with the following updates:

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    1. Test Tool Link: https://tools.ncpdp.org/erx/#/home
    2. For NCPDP SCRIPT Standard, Implementation Guide, Version 10.6, need to update the Test Tool Availability to Yes. Test Tool Link: https://tools.ncpdp.org/erx/#/home

    NCPDP Comment

    1. Need to change NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 to NCPDP Specialized Standard, Implementation Guide, Version 2017071 with the following updates:

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. For NCPDP SCRIPT Standard, Implementation Guide, Version 10.6, need to update the Test Tool Availability to Yes. Test Tool Link: https://tools.ncpdp.org/erx/#/home

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports using NCPDP SCRIPT Standard, Implementation Guide, Version 10.6

    Admission, Discharge, and Transfer

    Sending a Notification of a Patient’s Admission, Discharge and/or Transfer Status to Other Providers

    Comment

    Updates to Event Notifications Via the Direct Standard (R)

    This entry should be updated to reflect current adoption and status of the standard.

    Here is a link to the published Standard: https://directtrust.org/standards/event-notifications-via-direct

    Direct Standard(r) is now a Registered Trademark. 

    Process Maturity Level should be "Final"

    Adoption Level should be "Medium" - three "dots".

    Update the Limitations in the following matter:

    • A variety of transport protocols are available for use for event notifications delivery. Trading partners will need to determine which transport tools best meet their interoperability needs, however, Direct (referenced further in Exchange/Services - "Push" Exchange), has been adopted by both EHRs and by intermediaries as a prominent option for transport. Even when HIE networks are in place, Direct is often used as a transport protocol to deliver notifications to EHRs in provider workflows. 
    • DirectTrust Standards Implementation Guide "Event Notifications via the Direct Standard(R)" provides a profile for the payload included in event notifications when Direct is the transport. The guide standardizes HL7 2.5.1 usage and maps metadata elements to support appropriate routing and workflow for receiving systems. Human readable text is also stipulated as a part of the specification to support uncomplicated edge systems. The Implementation Guide was published and ANSI approved May 11, 2022. 

    Consider IHE Patient…

    Consider IHE Patient Administration Management profile for this message: http://wiki.ihe.net/index.php/Patient_Administration_Management

     


    Content/Structure

    Admission, Discharge and Transfer

    Sending a Notification of a Patient’s Encounter to a Record Locator Service

    Comment

    Advance Directives

    Comment

    Update status of ePOLST CDA Implementation Guide

    The ePOLST CDA Implementation Guide represents an important move forward in creating a consensus CDA standard for a POLST portable medical order. It enables access to and exchange of POLST information by electronic health record (EHR) and emergency medicine services (EMS) data systems to capture patient wishes and physician orders concerning resuscitation and initial scope and focus of treatment. Several states are considering the use of the ePOLST CDA as a standard for interoperability and for use in POLST registry initiatives.

    We appreciate ONC capturing this important work in the ISA. However, the entry listed in the 2023 Reference Edition is out of date. We respectfully ask that ONC update the entry to reflect that the ePOLST CDA Implementation has been published by HL7 as STU1 by:

    • Updating the “Standard / Implementation Specification” to reflect the published version of the Guide on HL7 as the “HL7 CDA® R2 Implementation Guide: ePOLST: Portable Medical Orders About Resuscitation and Initial Treatment, Release 1 - US Realm” at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=600 [hl7.org].
    • Updating the “Standards Process Maturity” to “Balloted Draft”.
    • Updating the “Implementation Maturity” to “Pilot” to reflect the plans of the Oregon POLST registry to pilot test the Implementation Guide and the National POLST Collaborative promotion of pilot testing in other states.
    • Updating the “Adoption Level” to one filled circle, consistent with other Emerging Implementation Specifications with Pilot level Implementation Maturity and reflecting the strong promotion of the Guide by several states and the National POLST Collaborative.
    • Updating the “Limitations, Dependencies, and Preconditions for Consideration” to read:
      • The ePOLST CDA Implementation Guide is based on the National POLST form, first published in August 2019 and adopted by several states. The National POLST form represents a major step toward national consensus on a POLST form developed through many months of interviews and listening, consensus building, feedback, compromise, and iterative revisions.
      • Use of the ePOLST CDA Implementation Guide requires that a state-adopted POLST form be compatible with the National POLST form, but does not require adoption of the National POLST form.

    We also note that the correct term for this section of the ISA is "Advance Care Planning" rather than "Advanced Care Planning" as it currently appears in the ISA.

    • Robert M. Cothren, PhD
      Technology Advisor, National POLST Collaborative

     

    Update Status of ePOLST CDA Implementation Guide

    The ePOLST CDA Implementation Guide represents an important move forward in creating a consensus CDA standard for a POLST portable medical order. It enables access to and exchange of POLST information by electronic health record (EHR) and emergency medicine services (EMS) data systems to capture patient wishes and physician orders concerning resuscitation and initial scope and focus of treatment. Several states are considering the use of the ePOLST CDA as a standard for interoperability and for use in POLST registry initiatives.

    We appreciate ONC capturing this important work in the ISA. However, the entry listed in the 2023 Reference Edition is out of date. We respectfully ask that ONC update the entry to reflect that the ePOLST CDA Implementation has been published by HL7 as STU1 by:

    • Updating the “Standard / Implementation Specification” to reflect the published version of the Guide on HL7 as the “HL7 CDA® R2 Implementation Guide: ePOLST: Portable Medical Orders About Resuscitation and Initial Treatment, Release 1 - US Realm” at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=600 [hl7.org].
    • Updating the “Standards Process Maturity” to “Balloted Draft”.
    • Updating the “Implementation Maturity” to “Pilot” to reflect the plans of the Oregon POLST registry to pilot test the Implementation Guide and the National POLST Collaborative promotion of pilot testing in other states.
    • Updating the “Adoption Level” to one filled circle, consistent with other Emerging Implementation Specifications with Pilot level Implementation Maturity and reflecting the strong promotion of the Guide by several states and the National POLST Collaborative.
    • Updating the “Limitations, Dependencies, and Preconditions for Consideration” to read:
      • The ePOLST CDA Implementation Guide is based on the National POLST form, first published in August 2019 and adopted by several states. The National POLST form represents a major step toward national consensus on a POLST form developed through many months of interviews and listening, consensus building, feedback, compromise, and iterative revisions.
      • Use of the ePOLST CDA Implementation Guide requires that a state-adopted POLST form be compatible with the National POLST form, but does not require adoption of the National POLST form.

    We also note that the correct term for this section of the ISA is "Advance Care Planning" rather than "Advanced Care Planning" as it currently appears in the ISA.

     

    Robert M. Cothren, PhD
    Technology Advisor, National POLST Collaborative

    Care Coordination

    Referral from Acute Care to a Skilled Nursing Facility

    Comment

    Referral to a Specialist - Request, Status Updates, Outcome

    Comment

    Cooperation for electronic referrals and record sharing

    Many specialists I refer to are not utilizing record sharing or direct ID for referrals.  I have called many and they are only doing the bare minimum to meet meaningful use criteria, because of the effort involved in changing office operations.   My recommendation would be for assistance from healthIT.gov for organizations to use their EMR's capabilities maximally and promote interoperability.  No amount of technological advances in information exchange will be of value unless providers actually use them.  I have already spent a great deal of time calling offices in our area to encourage use of information exchange in order to help my practice waste less time chasing down records and results.  Unfortunately, however, most have not been interested in putting in the necessary work, which limits my ability to use information exchange.

    Referrals Between Clinicians and Community-Based Organizations and Other Extra-Clinical Services

    Comment

    Defining "extra-clinical" services

    Recommend defining "extra-clinical" services for clarity. Does “extra” mean additional or does it mean beyond additional clinical services?

    Care Plan

    Documenting and Sharing Care Plans for a Single Clinical Context

    Comment

    NCPDP Comment

    1. Modify the following:

    Type- Standard

    Standard Implementation/Specification- HL7® FHIR® US Core R.3.0 - Care Plan Profile

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    1. Modify the following:

    Type-Emerging Implementation Specification

    Standard Implementation/Specification- HL7® C-CDA on FHIR® Care Plan

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    1. Add the following:

    Type- Emerging Implementation Specification

    Standard Implementation/Specification- HL7® FHIR® US Core R.4.0 - Care Plan Profile

    Standards Process Maturity – In development

    Implementation Maturity- Need Feedback

    Adoption Level – Need Feedback

    Federally Required - No

    Cost - free

    Test Tool Availability - No

    NCPDP Comment

    1. Add the following:

    Type-Emerging Standard

    Standard Implementation/Specification- HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes and C-CDA on FHIR R4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Available – Spring 2020

    NCPDP Comment

    For NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan, change Adoption level to Pilot.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the balloted drafts of HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1 and HL7 Resource Care Plan (v3.0.1).  The Collaborative also supports HL7 Fast Healthcare Interoperability Resources (FHIR), STU3, which is in development.

    Care Plan Document Type is not Required

    HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1. 

    This should not be listed as required. MU2015 did not require the care plan document. MU2015 did require Concerns and Goals within transition of care documents but not specifically the Care Plan document. The snapshot or visit context of a care plan for transition of care is appropriate. A longitudinal care plan in the form of a CCDA is unwieldly and virtually useless from the perspective of a provider. The longitudinal care plan needs to be in the context of an application for optimal management and viewing.

    NCPDP - Comment

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 2

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP HL7 CDA® R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm - US Realm

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 2

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP HL7 CDA® R2 FHIR Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm - US Realm

    Comment: FHIR is used to implement the Care Plan. See https://www.healthit.gov/techlab/ipg/node/4/submission/1376

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Documenting and Sharing Medication-Related Care Plans by Pharmacists

    Comment

    NCPDP Comments

    1. HL7® C-CDA on FHIR® Care Plan – Adoption Level should be a 3
    2. HL7 CDA® R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm, Volume 1 – Adoption Level should be a 2
    3. HL7® FHIR® US Core R.4.0 - Care Plan Profile should be Production and 1. The current version of the Pharmacist Car Plan DOES utilize FHIR R4 (it is just not based on the FHIR R4 Care Plan – it is still a profile of the C-CDA on FHIR Care Plan).

    NCPDP Comment

    1. Modify the following:

    Type- Standard

    Standard Implementation/Specification- HL7® FHIR® US Core R.3.0 - Care Plan Profile

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    1. Modify the following:

    Type-Emerging Implementation Specification

    Standard Implementation/Specification- HL7® C-CDA on FHIR® Care Plan

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    1. Add the following:

    Type- Emerging Implementation Specification

    Standard Implementation/Specification- HL7® FHIR® US Core R.4.0 - Care Plan Profile

    Standards Process Maturity – In development

    Implementation Maturity- Need Feedback

    Adoption Level – Need Feedback

    Federally Required - No

    Cost - Free

    Test Tool Availability - No

    NCPDP Comment

    1. Add the following:

    Type-Emerging Standard

    Standard Implementation/Specification- HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes and C-CDA on FHIR R4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Available – Spring 2020

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative appreciates the ONC taking our recommendation and adding NCPDP Pharmacist eCare Plan Version 1.0 Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan and HL 7 CDA R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 – US Realm, Volume 1 to the final 2018 version. The Collaborative also recommends adding Pharmacist Care Plan FHIR Implementation Guideto the standard implementation/specifications.

    Documenting Care Plans for Person Centered Services

    Comment

    Domain or Disease-Specific Care Plan Standards

    Comment

    NCPDP Comment

    1. Modify the following:

    Type- Standard

    Standard Implementation/Specification- HL7® FHIR® US Core R.3.0 - Care Plan Profile

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    1. Modify the following:

    Type-Emerging Implementation Specification

    Standard Implementation/Specification- HL7® C-CDA on FHIR® Care Plan

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    1. Add the following:

    Type- Emerging Implementation Specification

    Standard Implementation/Specification- HL7® FHIR® US Core R.4.0 - Care Plan Profile

    Standards Process Maturity – In development

    Implementation Maturity- Need Feedback

    Adoption Level – Need Feedback

    Federally Required - No

    Cost - Free

    Test Tool Availability - No

    NCPDP Comment

    1. Add the following:

    Type-Emerging Standard

    Standard Implementation/Specification- HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes and C-CDA on FHIR R4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Available – Spring 2020

    1. For NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan , change Adoption level to Production.

    NCPDP - Comment

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 2

    Federally Required – No

    Cost – $

    Test Tool Availability - Yes

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Consultant Pharmacist Consult Note, Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Consult Note

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 2

    Federally Required – No

    Cost – $

    Test Tool Availability - Yes

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP HL7 CDA® R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm - US Realm

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP HL7 CDA® R2 FHIR Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm - US Realm

    Comment: FHIR is used to implement the Care Plan. See https://www.healthit.gov/techlab/ipg/node/4/submission/1376

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Sharing Patient Care Plans for Multiple Clinical Contexts

    Comment

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the addition of the balloted drafts of:  HL7 Cross-Paradigm Specification: Clinical Quality Language, Release 1, STU Release 2; HL7 FHIR Profile: Quality (QI Core), DSTU Release 1; HL7 Version 3 Standard: Decision Support Service, Release 2; HL7 Implementation Guide Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1.3, Draft Standard Trial Use;  HL7 FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR), DSTU Release 1, HL7 FHIR Profiles: Quality Improvement Core (QI Core), Release 2; and HL7 Fast Healthcare Interoperability Resources (FHIR) Clinical Reasoning STU Release 3. 

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the balloted draft IHE Dynamic Care Team Management (DCTM), Rev. 1.1 Trial Implementation.  

    DCP FHIR Component

    We want to call out the new FHIR content added this year, this is an exciting advance in functionality supporting an integrated care planning process. 

    Clinical Decision Support

    Communicate Appropriate Use Criteria with the Order and Charge to the Filling Provider and Billing System for Inclusion on Claims

    Comment

    “Clinical Decision Support” Adoption Level IHE CDS-OAT should be

    • Section II:
      • Under “Clinical Decision Support”
        • For “Communicate Appropriate Use Criteria with the Order and Charge to the Filling Provider and Billing System for Inclusion on Claims”, the Adoption Level for IHE CDS-OAT should be 1

    Section II_Comments from Kinson Ho, Change Healthcare.docx

    NCPDP - Comment

    • Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 10.6

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Provide Access to Appropriate Use Criteria

    Comment

    GAO has no resources to…

    GAO has no resources to continue the work.

    NCPDP - Comment

    • The Drug Utilization Review segment within the NCPDP Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010, enables clinical decision support.  The Observation Segment within the NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 enables clinical decision support (e.g. weight segment and diagnosis code).
    • NCPDP provides additional guidance and recommendations that enables clinical decision support. (e.g.: mL guidance document: NCPDP Recommendations and Guidance for Standardizing the Dosing Designations on Prescription Container Labels of Oral Liquid Medications).

    Sharable Clinical Decision Support

    Comment

    AIRA Comments - Clinical Decision Support

    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.

    feedback

    consider the following text for Preconditions for Consideration:

    AHRQ CDS Connect provides examples of shared CDS content and use of standards during authoring (CDS Connect Authoring Tool) 

    reference https://cds.ahrq.gov/cdsconnect

     

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the addition of the balloted drafts of:  HL7 Cross-Paradigm Specification: Clinical Quality Language, Release 1, STU Release 2; HL7 FHIR Profile: Quality (QI Core), DSTU Release 1; HL7 Version 3 Standard: Decision Support Service, Release 2; HL7 Implementation Guide Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1.3, Draft Standard Trial Use;  HL7 FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR), DSTU Release 1, HL7 FHIR Profiles: Quality Improvement Core (QI Core), Release 2; and HL7 Fast Healthcare Interoperability Resources (FHIR) Clinical Reasoning STU Release 3. 

    NCPDP - Comments

    • The Drug Utilization Review segment within the NCPDP Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010, enables clinical decision support.  The Observation Segment within the NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 enables clinical decision support (e.g. weight segment and diagnosis code).
    • NCPDP provides additional guidance and recommendations that enables clinical decision support. (e.g.: mL guidance document: NCPDP Recommendations and Guidance for Standardizing the Dosing Designations on Prescription Container Labels of Oral Liquid Medications).

    Documentation of Clinical Notes

    Comment

    Discharge C-CDA Content Needs

    The Texas Health Services Authority Standardizing C-CDA content workgroup completed a community survey to understand the clinician needs with a Discharge C-CDA.  The goal of the workgroup is to recommend clinical content to be included in the C-CDA that will benefit transitions of care.  The complete document was shared in a previous post but it is believed the survey may help inform other initiatives.  

     

    Discharge C-CDA Minimum Data-Set Content

     

    1. Discharge Summary Narrative (aka Hospital Course)
    2. Discharge Medications
    3. Allergies
    4. Admission Diagnosis
    5. Discharge Diagnosis
    6. Procedures:  including Interventional Radiology, Cardiac Cath, operative procedures
    7. Diagnostic Imaging – Advanced imaging for example:  MRI, CT, PET, Nuclear Imaging, Ultrasound, Echo, & Venous Doppler
    8. Laboratory – Recommend first and last laboratory result for every test.  On rare tests – they are only done once so would be included (ANA Rheumatoid)
    9. Consultations
    10. Assessment & Plan (includes future orders for follow-up with PCP and diagnostic tests)
    11. Problem List

    CCDA Content Standardization Survey Results.pdf

    Discharge Clinical Note

    The Texas Health Services Authority supports a multi-disciplinary workgroup that focuses on improving clinical communication by standardizing C-CDA content. 

    “The feedback from providers is that all too often the content of the data currently being exchanged has too little or too much information. This leads to lack of trust and will lead to lower utilization. Too much information is as much a problem as too little information – providers today struggle with cognitive overload from electronic health records. It is very important to have succinct and relevant information presented to healthcare providers. Future capabilities, like FHIR, may enable the best of both worlds – a succinct summary with the ability to drill down to further details if needed.”  

    The workgroup has formulated a minimum dataset for the Discharge C-CDA to improve communication.  We would appreciate if this content standard could be adopted nationally, recognizing that this is a start.  The content was developed from workgroup experience and from a community survey with 119 respondents on what is important in the C-CDA.  The Survey will be attached separately.    

    Discharge C-CDA Minimum Data-Set 9.28.2022.docx.pdf

    USCDI formats?

    Where can I access the USCDI fields, format for the patient data?  Such as Date of Birth, Medical History etc...

     

    Darrell Calderon 

    Clinical Quality Measurement and Reporting

    Reporting Aggregate Quality Data for Quality Reporting Initiatives

    Comment

    Reporting Patient-level Quality Data for Quality Reporting Initiatives

    Comment

    Sharing Quality Measure Artifacts for Quality Reporting Initiatives

    Comment

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports combining the previous Sections II-D and II-E into a single Section II-D, and the addition of the balloted editions: HL7 Version 3: Representation of the Health Quality Measures Format (eMeasures) DSTU Release 2.1; HL7 FHIR Profile: Quality, Release 1; HL7 Cross-Paradigm Specification: Clinical Quality (CQL) Language, Release 1, STU Release 1.1; HL7 Version 3 Implementation Guide: Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), Release 1.4 DSTU (based on HAMF 2.1 - US Realm); HL7 Version 3 Implementation Guide: Clinical Quality Language (CQL)-based Health Quality Measure Format (HQM)F, Release 1.1 DTSU 2 (based on HQMF 2.1 - US Realm);   HL7 Version 3 Implementation Guide: Clinical Quality Language (CQL)-based Health Quality Measure Format (HQM)F, Release 2 DTSU 32 (based on HQMF 2.1 - US Realm).  The Collaborative also supports HL7 FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR) and HL7 Fast Healthcare Interoperability Resources (FHIR) Clinical Reasoning STU Release 3, which are in development.

    Data Provenance

    Establishing the Authenticity, Reliability, and Trustworthiness of Content Between Trading Partners

    Comment

    Document Digital Signature

    IHE Document Digital Signature (DSG) profile Implementation Guide provides digital signature capability across any kind of document. This includes CDA and FHIR-Documents with the same solution. 

    Find the normative specification from IHE -- https://profiles.ihe.net/ITI/TF/Volume1/ch-37.html

    37 Document Digital Signature (DSG)

    The Document Digital Signature (DSG) Profile defines general purpose methods of digitally signing of documents for communication and persistence. Among other uses, these methods can be used within an IHE Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD). There are three methods of digital signature defined here: Enveloping, Detached (manifest), and SubmissionSet.

    • An Enveloping Signature is a Digital Signature Document that contains both the signature block and the content that is signed. Access to the contained content is through removing the Enveloping - Digital Signature. Among other uses, this method should not be used with Document Sharing infrastructure.
    • A Detached Signature is a Digital Signature Document that contains a manifest that points at independently managed content. Detached signatures leave the signed document or documents in the original form. Among other uses, this method is recommended for use with a Document Sharing infrastructure to support Digital Signatures, as this method does not modify the original Document Content. This method uses the Document Sharing “SIGNS” relationship provides linkage.
    • A SubmissionSet Signature is a Detached Signature Document that attests to the content in a SubmissionSet by: containing a manifest of all the other Documents included in the SubmissionSet, and a reference to the SubmissionSet. The Document Sharing “SIGNS” relationship may be used but is not required.

    Ink-on-paper signatures have been a part of the documentation process in health care and have traditionally been indicators of accountability. Reliable exchange and storage of electronic data between disparate systems requires a standard that implements equivalent non-repudiation to prevent document creators from denying authorship and rejecting responsibility.

    Document Metadata

    The Document Metadata defined and used by IHE XDS/XDR/XCA/XDM provides complete Provenance for the document, in addition to other functionality.

    see IHE publication -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#26-value-of-metadata

    The IHE metadata is described -- https://profiles.ihe.net/ITI/TF/Volume3/ch-4.1.html#4.1.3

    Where each element contributing to Provenance is highlighted.

    CDA IG needs work

    Document last updated with ballot comments Release1 - Sep 30, 2015. This document has seen little use and needs further definition. As kwboone stated the FHIR definition is better suited.  For the sake of implementation there needs to be a better operational definition of provenance and at what level is this expected. Document, section, data?  From the ONC 2nd Annual Forum it was clear that the industry has not engaged with the concept of data level provenance in a way that can be shared.

    Consider HL7 FHIR Provenance…

    Consider HL7 FHIR Provenance resources, which are much better suited.

    Diet and Nutrition

    Exchanging Diet and Nutrition Orders Across the Continuum of Care

    Comment

    Make Required

    Very positive to see this in ISA, the CDA requirements for nutrition have been maturing. To speed promotion and implementation of this clinically valuable information it will need to be required.

    Family Health History (Clinical Genomics)

    Representing Family Health History for Clinical Genomics

    Comment

    Promote - My Family Health Portrait

    General population – Collecting family history is time consuming yet valuable as the first step in analysis of further need for genetic studies.  Promoting the U.S. Surgeon General My Family Health Portrait  should be encouraged as part of patient engagement. The My Family Health Portrait creates a standard implementation, usable visual rendering that can be consistently implemented, and promotes interoperability

    Lacks clarity and needs…

    Lacks clarity and needs further work before adoption.  

    Healthy Weight

    Sending Healthy Weight Information

    Comment

    Valuable but not a priority, it should be

    Very good to see this included in ISA, the prevalence of obesity and Type II diabetes has a huge impact on health care and patient population quality of life.

    As previous comment states - voluntary is not going to see this adopted. 

    Been there, done that, doing…

    Been there, done that, doing it again for the umpteenth year in IHE. It isn't hard, but adoption is low because there's not a significant incentive for use of any standards to do this in light of other mandates (you can call CEHRT/MU/MIPS a voluntary program but, let's be realistic here).

    Human and Social Services

    Format for Structuring and Sharing Social Care Directory Information

    Comment

    Images

    Format of Medical Imaging Reports for Exchange and Distribution

    Comment

    “Format of Radiation Exposure Dose Reports for Exchange Distribu

    Section II_Comments from Kinson Ho, Change Healthcare_0.docx

    Format of Radiation Exposure Dose Reports for Exchange and Distribution

    Comment

    Format Radiation Exposure Dose Reports Exchange & Distribution

    Kevin O’Donnell, Canon Medical Research USA

    Format of Radiation Exposure Dose Reports for Exchange and Distribution

    Recommend 1st row (X-ray) adoption be increased to 4 for CT, 2 for other x-ray modalities

    Recommend 2nd row (Radiopharmaceutical) imp. maturity is pilot and adoption decreased to 1

    Recommend 3rd row (Patient Dose) imp. maturity is pilot and adoption decreased to 0

    Suggest IOD references in column 2 point to the module tables (subsection *.3) instead of the IOD (subsection *.1) to take people closer to the specification details in the first click.

    To survey implementations, an internet search for the relevant SOP Class UID and the phrase “DICOM Conformance Statement” will typically return links to specific products.  SOP Class UIDs can be found by searching for the SOP Class name (e.g. Radiation Dose) in Annex A of DICOM Part 6: http://dicom.nema.org/medical/dicom/current/output/chtml/part06/chapter_A.html

    For example implementations of X-ray, Radiopharmaceutical and Patient Dose can be found with the following searches, respectively:

    1.2.840.10008.5.1.4.1.1.88.67 "dicom conformance statement"

    1.2.840.10008.5.1.4.1.1.88.68 "dicom conformance statement"

    1.2.840.10008.5.1.4.1.1.88.75 "dicom conformance statement"

    Format Radiation Exposure Dose Reports Exchange Distribution_ODonnell_DICOM Comments.docx

    Format of Radiology Reports for Exchange and Distribution

    Comment

    Format Radiology Reports for Exchange and Distribution

    Format of Radiology Reports for Exchange and Distribution

    Recommend either removing the entry for MRRT or re-casting the purpose of this section.  IHE Management of Radiology Report Templates provides a format for the exchange of templates between systems that radiologists use to author diagnostic reports.  MRRT is not a format for the exchange of the actual diagnostic report document (which may or may not have used a template to guide the authoring) between repositories of patient reports.

     

    Format of Radiology Reports for Exchange and Distribution_ODonnell_DICOM.docx

    Medical Image Formats for Data Exchange and Distribution

    Comment

    DICOM meta-objects need to be more tightly defined

    Currently machine learning output in radiology is not stored in a standard format - often it is encapsulated as a 'secondary capture' image or in a proprietary format. This means that ML output is not in a format that could be reused and that it is not portable. Instead - this section should specify that algorithm output below the level of an image specified using the FHIR ImagingStudy object should use either a DICOM SR using Template TID 1500 (for graphical annotations) or DICOM Segmentation objects for segmentations.

    Exchange InVitro Diagnostics (IVD) Orders and Results

    Comment

    ACLA ISA comment re: typo, header titles, harmonization status

    Please clarify the term “harmonization status”.  We suggest this term be removed until it can be further clarified for expected implementation, clearly measured, etc.  It is too nebulous as currently stated.  For example, can it be measured and if so, how is it validated and how does it relate to the laboratory or provider’s EHR system Exchanging InVitro Diagnostics (IVD) Test Orders & Results?

     

    Correct typo in last bullet.  “OMB Circular A-1195” should be “OMB Circular A–119”.

     

    The 2nd column ‘header’ is titled “Applicable Value Set(s) and Starter Set(s)” but the comments are not related to value sets; Suggest you retitle; these seem like general comments

    Exchange Laboratory Test Results

    Comment

    ACLA ISA comment re: added text and definition of harmonization

    This text was added under Limitations, Dependencies, and Preconditions for Consideration: “Laboratory test results may require additional information beyond the result value for correct handling and interpretation, including units, reference range, harmonization status of the test, and identifiers for device, test kit, kit version, reagent lot, and calibrator lot. Not all of these elements are included in current messaging standards for the full result reporting path. See “Representing Laboratory Values/Results.”

    Please clarify the term “harmonization status”.  We suggest this term be removed until it can be further clarified for expected implementation, clearly measured, etc.  It is too nebulous as currently stated.  For example, can it be measured and if so, how is it validated and how does it relate to the laboratory test results or provider’s EHR system laboratory test results?

    Please review the “Applicable Security Patterns for Consideration” applicability to the section and if not applicable, remove.  This would be more appropriate in an introductory section.  This change, if approved, might be applied throughout the document.

     

     

    Comments for 2021 Reference Edition publication of the ONC (ISA)

    Quest Diagnostics, Incorporated collaborated with the American Clinical Laboratory Association (ACLA) to develop 2021 Reference Edition ISA comments (http://www.acla.com/). We support the comments submitted by ACLA. Thank you for the opportunity to provide comments.   

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Modify the following:

    Type-Change to: Implementation Specification

    Standard Implementation/Specification- HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes and C-CDA on FHIR® R4

    1. Modify the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Specialized Standard, Implementation Guide, Version 2017071

    Implementation Maturity- Production

    Comments for 2021 update of the ONC Interoperability Standards A

    Quest Diagnostics, Incorporated collaborated with the American Clinical Laboratory Association (ACLA) to develop 2021 ISA comments (http://www.acla.com/).  We support the comments submitted by ACLA. 

    Thank you for the opportunity to provide comments.

     

    NCPDP Comment

    1. Add the following:

    Type-Emerging Standard

    Standard Implementation/Specification- HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes and C-CDA on FHIR R4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Available – Spring 2020

    1. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 10.6

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 2

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Specialized Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    Update to the most recent version of LRI

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Release 1, STU Release 3 - US Realm
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V251_IG_LRI_R1_STU3_2018JUN.pdf
    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=226

    Value Set IG:
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip
    For comments on the Value set Companion guide, please submit DST comments under the guide that the vocabulary belongs to - if for the document itself, just pick one of the guides and submit there with the reference to the companion guide document and page number/section or applicable spreadsheet

    LRI ISA Update.docx

    Order Laboratory Test

    Comment

    ACLA ISA comment re: using FHIR for laboratory orders and securi

    We suggest that ONC sponsor a project for FHIR laboratory orders and results in US Core (multiple payers) to provide the same functionality as V2.5.1 laboratory implementation guides (LOI, LRI, ELR) with V2 to FHIR mapping provided.  The quality of patient results is impacted by the quality of the order the laboratory receives.

    Please review the “Applicable Security Patterns for Consideration” applicability to the section and if not applicable, remove.  This would be more appropriate in an introductory section.  This change, if approved, might be applied throughout the document.

    Update to most recent version of LOI

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 3 - US Realm
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V251_IG_LABORDERS_R1_STU_R3_2018JUN.pdf
    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=227 

    Value Set IG:
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip
    For comments on the Value set Companion guide, please submit DST comments under the guide that the vocabulary belongs to - if for the document itself, just pick one of the guides and submit there with the reference to the companion guide document and page number/section or applicable spreadsheet

    LOI ISA Update.docx

    Transmit Laboratory Directory of Services to Provider System

    Comment

    ACLA ISA comment re: request to add missing content, clarify sec

    Please add:

    HL7 Version 2.5.1 Implementation Guide: Standards & Interoperability (S&I) Framework Laboratory Test Compendium Framework (eDOS) Ask at Order Entry (AOE) Release 2, STU Release 3.1 (US Realm)

    • Justification statement:  Prior to Release 2, STU Release 3.1, the Ask at Order Entry (AOE) content was published as Appendix A in a single document. In 2021, the AOE content was published separately for greater visibility and because it is standard agnostic, except for the data types which may be different for HL7 V2 vs. HL7 FHIR. There is an HL7 project (1634) to publish an update in future to also reference FHIR datatypes.

    Hyperlink to AOE IG: http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3.1_2021JAN_AOE.pdf

     

    Please review the “Applicable Security Patterns for Consideration” applicability to the section and if not applicable, remove.  This would be more appropriate in an introductory section.  This change, if approved, might be applied throughout the document.

     

     

    Update to most recent version for eDOS

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3 - US Realm
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3_2018JUN.pdf
    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=225

    Value Set IG:
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip
    For comments on the Value set Companion guide, please submit DST comments under the guide that the vocabluary belongs to - if for the document itself, just pick one of the guides and submit there with the reference to the companion guide document and page number/section or applicable spreadsheet

    EDOS ISA Update.docx

    Update to most recent version for eDOS

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3 - US Realm
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3_2018JUN.pdf
    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=225

    Value Set IG:
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip
    For comments on the Value set Companion guide, please submit DST comments under the guide that the vocabluary belongs to - if for the document itself, just pick one of the guides and submit there with the reference to the companion guide document and page number/section or applicable spreadsheet

    EDOS ISA Update.docx

    Update to most recent version for eDOS

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3 - US Realm
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3_2018JUN.pdf
    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=225

    Value Set IG:
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip
    For comments on the Value set Companion guide, please submit DST comments under the guide that the vocabluary belongs to - if for the document itself, just pick one of the guides and submit there with the reference to the companion guide document and page number/section or applicable spreadsheet

    Update to most recent version for eDOS

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3 - US Realm
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3_2018JUN.pdf
    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=225

    Value Set IG:
    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip
    For comments on the Value set Companion guide, please submit DST comments under the guide that the vocabluary belongs to - if for the document itself, just pick one of the guides and submit there with the reference to the companion guide document and page number/section or applicable spreadsheet

    Update to most recent version for Laboratory Orders Interface

    Please update to point to the most recent version:

    HL7 Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 3 - US Realm


    Link to specification = http://www.hl7.org/documentcenter/public/standards/dstu/V251_IG_LABORDERS_R1_STU_R3_2018JUN.pdf


    Link to DSTU comment page = https://www.hl7.org/dstucomments/showdetail.cfm?dstuid=227 

    Update to lab eDOS Implementation Specifications

    HL7 has just published an updated to the eDOS Implementation Guide. 

    Please change:

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, DSTU Release 2 (also referred to as eDOS (Electronic Directory of Service)

    to (updated title and hyperlink)

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, STU Release 3 (also referred to as eDOS (Electronic Directory of Service), which is posted at: http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3_2018JUN.pdf

    Additionally the Value Set Guide referenced in "Limitations, Dependencies, and Preconditions for Consideration" was updated.

    Please change:

    HL7 Laboratory US Realm Value Set Companion Guide, Release 1, September 2015

    to (updated title and hyperlink)

    HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm, which is posted at: http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip

    Please change:

    Please update this text in ""Limitations, Dependencies, and Preconditions for Consideration"

    Note that the current version has been harmonized with the most current suite of Lab US Realm Implementation Guides, was updated in the HL7 January 2017 Ballot Cycle, and is pending publication

    to (updated text)

    Note that the current version has been harmonized with the most current suite of Lab US Realm Implementation Guides, published by HL7 June 2018.

    Update to lab eDOS Implementation Specifications

    HL7 has just published an updated to the eDOS Implementation Guide. 

    Please change:

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, DSTU Release 2 (also referred to as eDOS (Electronic Directory of Service)

    to (updated title and hyperlink)

    HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, STU Release 3 (also referred to as eDOS (Electronic Directory of Service), which is posted at: http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_LTCF_R2_STU_R3_2018JUN.pdf

    Additionally the Value Set Guide referenced in "Limitations, Dependencies, and Preconditions for Consideration" was updated.

    Please change:

    HL7 Laboratory US Realm Value Set Companion Guide, Release 1, September 2015

    to (updated title and hyperlink)

    HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm, which is posted at: http://www.hl7.org/documentcenter/public/standards/dstu/V2_IG_VALUESETS_R1_STU3_2018JUN.zip

    Please change:

    Please update this text in ""Limitations, Dependencies, and Preconditions for Consideration"

    Note that the current version has been harmonized with the most current suite of Lab US Realm Implementation Guides, was updated in the HL7 January 2017 Ballot Cycle, and is pending publication

    to (updated text)

    Note that the current version has been harmonized with the most current suite of Lab US Realm Implementation Guides, published by HL7 June 2018.

    Medical Device Communication to Other Information Systems/Technologies

    Transmitting Patient Vital Signs from Medical Devices to Other Information Systems/Technologies

    Comment

    Regenstrief - Comment

    Please correct typo from “Regenstreif” to “Regenstrief”.

    Section I I – N Transmitting Patient Vital Signs from Medical de

    Please make the following changes:

    1.Please add a new row “Implementation Specification” with Standard Implementation/Specification named “Continua Design Guidelines”. The remaining fields are the same as for IHE-PCD in the row above.

    2.Please add a new row “Implementation Specification” with Standard Implementation/Specification named “ITU H.810, H.811, H.812, H.12.5 and H.813”. The remaining fields are the same as for IHE-PCD in the row above.

    3.Within Dependencies for Consideration field, please change the first bullet to IHE-PCD, Continua and ITU IEEE 11073-10101 standard for its nomenclature.

    Patient Education Materials

    Clinical Information Systems to Request Context-Specific Clinical Knowledge From Online Resources

    Comment

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of HL7 Version 3 Standard: Context-Aware Knowledge Retrieval Application (Infobutton), Knowledge Request, Release 2; HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Conext-Aware Knowledge Retrieval (Infobutton) Domain, Release 1; and HL7 Version Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.

    Regenstrief - Comment

    Since all of ISA is about standards, propose rewording this need from ”A Standard Mechanism for Clinical Information Systems to Request Context-Specific Clinical Knowledge From Online Resources” to “Clinical Information System Requests for Context-Specific Knowledge From Online Resources”.

    Patient Identity/Identification Management

    Patient Demographic Record Matching

    Comment

    Add HL7 Interoperable Digital Identity & Patient Matching IG

    HL7's Interoperable Digital Identity & Patient Matching Implementation Guide is an Emerging Implementation Specification we recommend for inclusion in both the Patient Demographic Record Matching and Exchanging Patient Identification Within and Between Communities sections of the ISA due to its utility to both of these categories.

    Additionally, in the Limitations, Dependencies, and Preconditions for Consideration section of this page, we suggest removing the phrase "but more information related to this topic is below:...." as well as the sub-bullets listed beneath it.

    -HL7 Interoperable Digital Identity & Patient Matching workgroup

    Patient Identity Proofing - Response to 2018-10-1 Post

    MaxMD was contacted by DirectTrust on 9/23/2019 regarding a post to HealthIT.gov accompanied by a cover letter the Health Information Technology Advisory Committee asserting a “worrisome Identity Assurance Disconnect”.  MaxMD reviewed the post and associated letter and responded back to the leadership of DirectTrust within hours. 

    In the instance in question MaxMD correctly performed identity proofing to the NIST LoA 3 standard through a remote identity proofing workflow.

    Below is the NIST LoA 3 remote vetting requirements copied and pasted and annotated in-line in Bold with how MaxMD meets the standard for ease of tracking.

    RA verifies information provided by Applicant including ID number (Social Security Number) AND account number (mobile phone number) through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application and sufficient to identify a unique individual (MaxMD confirms with LexisNexis that the applicant’s SSN matches the individuals first name, last name, date of birth, and home address.) (At the same time this verification of the ID number is taking place, MaxMD verifies the applicant’s utility account by checking if the mobile phone number matches the first name and last name of the account holder.) . At a minimum, the records check for both the ID number AND the account number should confirm the name (MaxMD matches both the Applicant’s ID and Account number with their first name and last name) and address of the Applicant (see Address confirmation below). For utility account numbers, confirmation shall be performed by verifying knowledge of recent account activity. (This technique may also be applied to some financial accounts.)

    • Address confirmation:

    a) CSP issues credentials in a manner that confirms the ability of the applicant to receive mail at a physical address associated with the Applicant in records; or

    b) If personal information in records includes both an electronic address and a physical address that are linked together with the Applicant’s name, and are consistent with the information provided by the applicant, then the CSP may issue credentials in a manner that confirms ability of the Applicant to receive messages (SMS, voice or e-mail) sent to the electronic address (If the applicant is verified as the account holder of the mobile phone then we have linked physical address from the ID with the electronic address of the Account holder. MaxMD then delivers a time-oriented one-time password to the mobile phone number. This allows the applicant to verify knowledge of recent activity by entering the one-time password they received). Any secret sent over an unprotected session shall be reset upon first use and shall be valid for a maximum lifetime of seven days (The one-time password delivered via SMS text message expires in 10 minutes).

    As to our process; MaxMD is a DirectTrust Accredited HISP, RA, and CA and as such we are thoroughly and routinely audited/evaluated with regards to Procedures, Infrastructure and compliance with HIPAA and DirectTrust established Standards contained in the DirectTrust Certificate Policy v1.4. This process involves a roughly 500 page submission and two days of onsite visits with evaluators.  And to be clear MaxMD made no assertion verbally or in writing that this remote proofing processes satisfies the IAL2 proposed standard. It should also be noted that even today almost 1 year after posting this flawed analysis IAL2 is not a requirement published into the DirectTrust Certificate Policy.

    Lastly at no time during the past year did the independent Subject Matter Experts reach out to me or any senior MaxMD personnel to discuss their analysis or their concerns.  Had they, we would have been happy to educate them. 

    Scott A. Finlay 

    CEO MaxMD

    Patient Identity Proofing - Response to 2018-10-1 Post

    We only just this week had the Monday 10/1/2018 post called to our attention in the process of reviewing the ISA for comments.  As the attachment on the above post asserted a compliance issue with a DirectTrust HISP, we immediately contacted the HISP in question.  In review of the processes that the HISP utilizes, it maps precisely to the remote proofing process as described in NIST 800-63-2.  Please see the post below from Scott Finley of MaxMD who outlines in detail how remote proofing is supported there.  DirectTrust at this time still conforms to LoA3 (remote) under 800-63-2.  Our workgroups are nearly completed with the updates to our CP and our accreditation criteria which will support IAL2 requirements. 

    We agree with the assertions of the group that moving to IAL2 is important and that all CSPs and RAs should migrate to the new standard.  We are in the process of doing so.  Our current processes conform with LoA3 for remote proofing or better.  Further questions about DirectTrust processes should be forwarded to me at DirectTrust.  

    Scott Stuewe

    President and CEO, DirectTrust

    Patient Identity Proofing

    Accurate patient identification is the absolute bedrock underlying interoperability.  This need is already critical and will only grow more important over time.  NIST 800-63-3 IAL2 is the minimum assurance level that should be accepted.  There should be NO exceptions such as "allowing Participant staff to act as trusted referees" because such exceptions make it impossible to trust ANY of the identities asserted by the system.  Both patients and providers need to be identified to at least IAL2.

    The recent RAND report "Defining and Evaluating Patient-Empowered Approaches to Improving Record Matching" indicates that there is at least one currently available strategy which "If adopted and used as intended, this solution would match records used by the same individual perfectly" (p 25).  It appears appropriate to initiate a pilot study to determine whether this claim can be achieved in actual practice.

    Finally, a group of healthcare identity experts have recently discovered a discrepancy in the implementation of NIST IAL2 that must be resolved in order to enable all healthcare information exchange to be trusted with respect to patient identity.  See the attached document for a description of this problem.

    800-63-Ccoverletter.docx

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the name change.

    Implementation Guide for Expressing Context in Direct Messaging

    The Implementation Guide for Expressing Context in Direct Messaging, published by the Direct Project, was designed to facilitate inter-organizational patient demographic record matching by standardizing the inclusion of patient demographic metadata in Direct messages, and should be added to this category. This standard was successfully piloted by the Direct Project community at their October 2017 connect-a-thon. 

    Luis Maas

    CTO, EMR Direct

    Patient Identity Assurance Level (IAL2)

    I agree completely with the desire to identity proof patients to the level of IAL2.  However, I'm not understanding the last sentence of this consideration: "all collected PII collected by the Signatory shall be limited to the minimum necessary to resolve a unique identity and the Signatory shall not copy and retain such PII".  The Signatory should and in fact MUST be able to copy and retain PII to properly perform identity assurance. 

    One of the elements necessary to perform strong identity proofing is to verify a strong or superior piece of identity evidence (like the patient's drivers license).  During the course of verification the image of the identity evidence may be imaged and sent to a 3rd party to "proof" the authenticity of the document.  Typically the image of the drivers license is kept on file by the Provider along with an image of the insurance card.  Would maintaining a copy or image of the driver's license and insurance card violate the language in this sentence?  It appears that it would.  Also the PII data gleaned from those documents (person's name, address, DOB, etc.) is also "retained".

    This sentence should be revised to state "All collected PII collected by the Signatory shall be limited to the minimum necessary to resolve a unique identity." 

    Representing Patient Address

    Comment

    ACLA ISA comment re: Patient Address

    Proposed guidance should not conflict with and must not supersede ANSI accredited standards already cited for federal adoption, for example by CMS or ONC that may be included in HL7 V2 standards such as the Meaningful Use Stage 1 citation of HL7® Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification. 

     

    Perhaps the ISA scope statement could contain a statement that the ISA does not intend to cite conflicting standards and any conflicts should be reported directly to ONC?  For example, following this section in the scope statement.

                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 a next-generation approach.

     

    Representing Patient Names

    Comment

    Naming Policy Framework 2023: Enhancing Person Matching with Ess

    AHIMA supports the inclusion of the Naming Policy Framework 2023: Enhancing Person Matching with Essential Demographic Data Elements into the ISA to support the accurate capture and representation of a patient's name. This 2023 Policy Framework includes details on the following:

    • Standardizing Naming Policies: addresses the lack of standardization in naming policies across the healthcare ecosystem. This standardization is crucial for efficient and accurate identification and matching of person(s) to their health records, as well as for large data set migrations.
    • Recognizing Evolving Ecosystem: The framework acknowledges the changing landscape of health information management, where essential person(s) demographic data goes beyond traditional master/enterprise patient indexes. With entities collecting and sharing Electronic Health Information, additional data elements become necessary for effective identification, matching, and management of health records.
    • Guiding Best Practices: AHIMA calls for the adoption and use of this demographic data element framework, representing current operational best practices. It is designed to evolve over time with technological advancements and operational procedures, ensuring it remains relevant and effective in the ever-changing healthcare environment.

    naming-policy_final.pdf

    Patient Naming Policy

    We will not reach complete and accurate interoperability until all of the industry follows the same naming standards. I support AHIMA's Patient Naming Policy to improve interoperability and patient safety.

    Patient Naming Policy

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

    Patient Naming Policy

    Accurately determining patient identity is critical for patient safety and hospital operations. I support AHIMA's Naming Policy for accurate capture of patient names to reduce duplicates and overlays and support interoperability. 

    Patient Naming Policy

    I support AHIMA’s Patient Naming Policy to improve patient safety and also to decrease the financial burden of duplicate tests that are ordered when patient records cannot be assimilated.

    Patient Safety

    I support AHIMA;s Naming Policy to improve patient safety.

    Patient Naming Policy

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

    Patient Naming Policy

    I support AHIMA’s Patient Naming Policy to decrease the financial burden of duplicate tests that are ordered when patient records cannot be assimilated.

    Patient Name Requiremts

    I support AHIMA's Patient Naming Policy to improve patient safety in healthcare by utilizing the legal name as standard practice.

    ACLA ISA comment re: Patient Names

    Proposed guidance should not conflict with and must not supersede ANSI accredited standards already cited for federal adoption, for example by CMS or ONC that may be included in HL7 V2 standards such as the Meaningful Use Stage 1 citation of HL7® Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification.

     

    Perhaps the ISA scope statement could contain a statement that the ISA does not intend to cite conflicting standards and any conflicts should be reported directly to ONC?

                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 a next-generation approach.

     

     

    Patient Preference/Consent

    Recording Patient Preferences for Electronic Consent to Access and/or Share their Health Information with Other Care Providers

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC remove the comment, “The NCPDP WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers,” from the Limitations, Dependencies, and Preconditions for Consideration section. The WG18 Patient Consent Task Group has been disbanded.
    2. NCPDP recommends that ONC create a new distinct category from the existing electronic consent for patient preference. The goal of the new category is to obtain authorization for an individual medication and not to designate a preference for other medications.
    3. NCPDP recommends that ONC add the following category:
      1. Category Name: Obtaining patient or provider authorization/consent related to a specific medication fulfillment
        Type: Implementation Specification
        Standard: Specialty Medication Enrollment FHIR® Implementation Guide STU2
        Standards Process Maturity: Final
        Implementation Maturity: Pilot

                       Adoption Level: 1
                       Federally Required: No
                       Cost: Free
                       Test Tool Availability: No

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to create a new distinct category from the existing electronic consent for patient preference: Obtaining patient or provider authorization/consent related to a specific medication fulfillment. As NCPDP notes, the goal of the new category is to obtain authorization from an individual medication and not to designate a preference for other medications.

    NCPDP Comments

    The NCPDP WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers.

    NCPDP Comment

    The NCPDP WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers.

    NCPDP Comment

    1. NCPDP is forming a task group to explore the need for transactions that support the exchange of patient consent.

    Allows a Long Term or Post-Acute Care to Request to Send an Additional Supply of Medication

    Comment

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 3

    Pharmacy Interoperability

    Allows a Pharmacy to Notify a Prescriber of Prescription Fill Status

    Comment

    NCPDP Comment

    NCPDP recommends that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 as this version of the standard is no longer supported by the industry.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP SCRIPT Standards, Implementation Guide, Version 2017071 update adoption level to 2.

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 3

    NCPDP Comment

    1. Add the following:
      1. RxFillIndicatorChange Transaction
      2. RxFill Transaction

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPDP Script Standard, Implementation Guide, Version 10.6.

    NCPDP - Comments on Version 10.6

    The adoption level should be modified to a 2.

    Allows a Pharmacy to Request a Change to a Prescription

    Comment

    NCPDP Comment

    NCPDP recommends that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 as this version is no longer supported by the industry.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 3

    NCPDP Comment

    1. Add the following:
      1. RxChangeResponse Transaction
      2. RxChangeRequest Transaction

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPD Script Standard, Implementation Guide, Version 10.6.

    NCPDP - Comments on Version 10.6

    The adoption level should be modified to a 3.

    Allows a Pharmacy to Request a New Prescription For a New Course of Therapy or to Continue Therapy

    Comment

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    HL7 FHIR Medication Request

    The American Medical Association appreciates the opportunity to comment. “HL7 FHIR Medication Request” is listed as an emerging standard for a pharmacy. Presumably this is to replace the SCRIPT standard. While HL7 FHIR Medication Request may have potential, we would have concern with the adoption of two different standards creating multiple methods to doing the same thing. 

     

    HL7 FHIR Medication Request

    Thank you for your comment. The ONC Interoperability Standards Advisory is meant to be a reference of available, recognized interoperability standards and implementation specifications, and therefore contains a number of standards for each use case that developers may choose from according to their needs and capabilities. 

    Allows a Pharmacy to Request Additional Refills

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 as this version is no longer supported by the industry.
    2. NCPDP recommends that ONC sunset language around “DeniedNewPrescriptionToFollow” in the Limitations, Dependencies, and Preconditions for Consideration section. Remove: “DeniedNewPrescriptionToFollow response is not to be sent in an RxRenewalResponse for this version of SCRIPT. However, the DeniedNewPrescriptionToFollow response could be received in an RxRenewalResponse from a previous version of SCRIPT and is included for backwards compatibility. DeniedNewPrescriptionToFollow response only exists for entities that need to map this version to a previous version of SCRIPT that does not support a Replace.”

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6, as well as sunsetting language around DeniedNewPrescriptionToFollow in the Limitations, Dependencies, and Preconditions for Consideration section.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 5

    NCPDP Comment

    1. Add the following:
      1. RxRenwalResponse Transaction
      2. RxRenewalRequest Transaction

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPD Script Standard, Implementation Guide, Version 10.6.

    Allows a Pharmacy to Request, Respond to or Confirm a Prescription Transfer

    Comment

    NCPDP Comment

    NCPDP recommend that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 2013101 as this version is not supported by the industry.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 2013101.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 2013101

    NCPDP Comments

    NCPDP SCRIPT Standards, Implementation Guide, Version 2017071 update adoption level to 1.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 3

    NCPDP Comment

    1. Add the following:
      1. RxTransferConfirm Transaction
      2. RxTranferResponse Transaction
      3. RxTransferRequest Transaction

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.   We also recommend including NCPDP SCRIPT Standard Implementation Guide Version 2013101.

    Allows a Prescriber or a Pharmacy to Request a Patient’s Medication History

    Comment

    NCPDP Comment

    NCPDP recommends that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 as this version is no longer supported by the industry.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    RX History

    Does the provider have to have written authorization from the patient to obtain RX history

    Provider history for Necole Rodgers

    This is my request to get my prescription history sent to me for the last five years. I hope this is enough to get my history sent to me without extra paperwork from my end. I'm not sure what I'm doing so disregard it this request is doing wrong. 

     

    Thanks

    Necole rodgers

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 4

    NCPDP Comment

    1. NCPDP supports the use of the NCPDP SCRIPT RxHistoryRequest/RxHistoryResponse transactions for PDMP.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPDP Script Standard, Implementation Guide, Version 10.6.

    Allows a Prescriber to Cancel a Prescription

    Comment

    NCPDP Comment

    NCPDP recommends that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 as this version is no longer supported by the industry.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level - 4

    NCPDP Comment

    1. Add the following:
      1. CancelRx Response Transaction
      2. CancelRx Transaction

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPD Script Standard, Implementation Guide, Version 10.6.

    NCPDP - Comments on Version 10.6

    The adoption level should be modified to a 2.

    Allows a Prescriber to Communicate Drug Administration Events

    Comment

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    Allows a Prescriber to Communicate with a REMS Administrator

    Comment

    NCPDP Comments

    NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 update Implementation Maturity from pilot to Production.

    NCPDP Comment

    1. Modify Implementation Maturity to Pilot for NCPDP SCRIPT Standard, Implementation Guide, Version 2017071.

    Allows a Prescriber to Prescribe Medication Using Weight-Based Dosing

    Comment

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to update Structured and Codified Sig Format Implementation Guide Version 2.1 to Structured and Codified Sig Format Implementation Guide Version 2.2.

    NCPDP Comments

    NCPDP SCRIPT Standards, Implementation Guide, Version 2017071 update adoption level to 3.

    Requirement for weight and height for prescriptions

    Except for chemotherapeutic agents and a very few other medications, a patient's height is not necessary to determine medication dosing.  Medications such as eye drops, ear drops, skin creams, and inhaled medications (bronchodilators, inhaled steroids, etc.) do not require weights at all.  These categories should be exempted from requiring height and weight data on prescriptions as refills and even initial prescriptions are often sent in or called in without the child being actually seen in the office.  ("Pink Eye" does not always need an office visit!)  Imagine how disruptive it would be if you had to leave work, pick up a child from school or daycare, and come to the pediatrician's office just to get an update weight and height for your eye drops or albuterol refill!  Moreover, as telemedicine becomes more prevalent, patients may be evaluated by a physician and prescriptions sent in without there being an actual physical visit to an office where updated heights and weights are obtained.  This is especially true for behavioral health conditions such as ADHD and anxiety/depression.  Again, medications would be refilled without a patient actually being present for a new height and weight. (These medications are not particularly dosed by weight anyway.)

    As a practical matter, most pediatricians will not send in prescriptions for patients they have not seen in over a year, but for those patients who are current, as long as we can use the most recent measurements we have on-file, this policy should be workable--especially if you eliminate the height requirement and exempt the categories noted above.

     

    Alan L. Schwartz, M.D.; Pediatrician,

    Indianapolis, IN

    NCPDP Comment

    1. Add the following:
      1. Observation Element in NewRx Transaction

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of Structured Codified Sig Format Implementation Guide Version 2.1.  The Collaborative also supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.

    Allows a Prescriber to Recertify the Continued Administration of a Medication Order

    Comment

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    Allows a Prescriber to Request, Cancel or Appeal Prior Authorization for Medications

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC update NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 to Federally Required.
    2. NCPDP recommends that ONC update NCPDP Formulary and Benefits Standard, Version 3 to Federally Required with an Adoption Level of 4.
      1. This version is federally required but does not allow a prescriber to request/cancel a prior authorization but allows them to see if the drug requires a prior authorization.
    3. NCPDP recommends that ONC sunset the following:
      1. NCPDP Formulary and Benefits Standard, Version 53
      2. NCPDP Formulary and Benefits Standard, Version 54
      3. NCPDP Formulary and Benefits Standard, Version 55
    4. NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP Formulary and Benefits Standard, Version 60

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation updating NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 to Federally Required; update NCPDP Formulary and Benefits Standard, Version 3 to Federally Required with an adoption level of 4; sunsetting NCPDP Formulary and Benefit Standard Versions 53, 54, and 55; and adding NCPDP Formulary and Benefit Standard Version 60.

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Update Implementation Maturity to Production (as of 1/1/2020).

    NCPDP Comment

    1. Title should say: “Allows a Prescriber to Request, Cancel or Appeal Prior Authorization for Medications”.
    2. NCPDP SCRIPT 2013101 should have:
      1. an adoption level of 3.
      2. Modify testing tool availability to Yes

     

    1. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes.

     

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change. The Collaborative supports theuse of NCPDP SCRIPT Standard, Implementation Guide Version 2013101.

    NCPDP - Comment on Version 10.6

      • The adoption level should be modified to a 2.
      • Under Limitations, Dependencies, and Preconditions for Consideration add the following:
        • The following transactions need to be implemented for interoperability purposes:
          • PAInitiationRequest and PAInitiationResponse
          • PARequest and PAResponse
          • PAAppealRequest and PAAppealResponse
          • PACancelRequest and PACancelResponse
        • Both the prescriber and the payer/processor/pharmacy benefits manager (PBM) must have their systems configured for the transaction in order to facilitate successful exchange.
      • Under Applicable Security Patterns for Consideration add the following:
        • Secure Communication – create a secure channel for client-to- serve and server-to-server communication.
        • Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
        • Authentication Enforcer – centralized authentication processes.
        • Authorization Enforcer – specifies access control policies.
        • Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).
        • Assertion Builder – define processing logic for identity, authorization and attribute statements.
        • User Role – identifies the role asserted by the individual initiating the transaction.
        • Purpose of Use - Identifies the purpose for the transaction.

    Allows a Prescriber to Send a New Prescription to a Pharmacy

    Comment

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. This topic needs to be broken into three categories:
      1.  A Pharmacy requests a prescription for a new course of therapy.
      2.  A Pharmacy requests a new prescription to continue therapy.
      3.  Where a prescriber sends a new prescription to a pharmacy.
    2. Items 1 + 2 are available currently with adoption level of 5.
    3. Item three is available in SCRIPT 2017071:
      1. NewRxResponseDenied Transaction
      2. NewRxRequest Transaction

     Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPD Script Standard, Implementation Guide, Version 10.6.

    NCPDP - Comments on Version 10.6

    The adoption level should be modified to a 5

    Allows a Prescriber to Send a Prescription to a Pharmacy for a Controlled Substance

    Comment

    NCPDP Comment

    NCPDP recommends that ONC update NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to Implementation Maturity = Pilot, Adoption Level = 1, Federally Required = Yes.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to add NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to Federally Required.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 update Adoption Level to 5.

    eprescribing with NADEAN

    Electronic prescriptions for controlled drugs require the prescriber's DEA number. This is included automatically with every prescription with most EHRs as the DEA number is not confidential, is assigned to the user, and the user must perform two-factor authentication.

    Most electronic prescriptions for buprenorphine also require an NADEAN number. The NADEAN likewise is not confidential, in fact it appears on every prescription for buprenorphine, and is only a slight modification of the DEA number.

    Nevertheless, some EHRs require the user to manually enter the NADEAN on every prescription for buprenorphine, not the best use of our time. Is this a regulatory requirement? Why can't the NADEAN be filled in automatically for the authenticated provider?

    Any information is appreciated.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Implementation Maturity - Production

    Adoption Level – 4

    TEST TOOL - Yes

    1. Include Test Tool Link: https://tools.ncpdp.org/erx/#/home

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 10.6

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Implementation Maturity- Production (effective 1/1/2020)

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    Allows a Prescriber to Request a Patient’s Medication History from a State Prescription Drug Monitoring Program (PDMP)

    Comment

    NCPDP Comment

    NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to add NCPDP SCRIPT Standard, Implementation Guide, Version 2022011.

    NCPDP Comments

    1. NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6
    2. NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 2013101

    WA State Department of Health PDMP Comments

    Washington State Department of Health appreciates having the standards listed on the PDMP pages and does not have any recommended changes at this time.

    WA State Department of Health PDMP Comments

    Washington State Department of Health appreciates having the standards listed on the PDMP pages and does not have any recommended changes at this time.

    NCPDP Comments

    Sunset NCPDP SCRIPT Implementation Guide Version 10.6

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. For NCPDP SCRIPT Standard, Implementation Guide, Version 10.6, modify testing tool availability to Yes. Test Tool Link: https://tools.ncpdp.org/erx/#/home
    2. For NCPDP SCRIPT Standard, Implementation Guide, Version 2017071, modify testing tool availability to Yes. Test Tool Link: https://tools.ncpdp.org/erx/#/home
    3. NCPDP SCRIPT Standard is a mature standard that can alleviate identified interoperability issues.

    PDMP Standards

    The Washington State Department of Health (DOH) appreciates the opportunity to submit these comments in response to the Office of the National Coordinator for Health Information Technology (ONC) request for public comments regarding the Interoperability Standards Advisory (ISA). DOH operates the Prescription Drug Monitoring Program (PDMP) in the state of Washington. DOH supports the proposed switch to the National Council for Prescription Drug Programs (NCPDP) 2017-071; however, DOH respectfully requests that the proposed deadline to implement NCPDP 2017-071 be extended to ensure that small to medium sized providers and critical access hospitals have a reasonable period of time to implement.

    DOH supports NCPDP 2017-071 and recognizes the benefits, including allowing the system to query the PDMP more than once every 24 hours (which is the current maximum), and allowing the system to send dispense level patient information. A previously adopted Centers for Medicare and Medicaid Services (CMS) rule, CMS-4182-F (Changes to the Medicare Advantage Prescription Drug Benefit Program, aka Medicare part D), required adoption of NCPDP 2017-071 for e-prescribing by January 1, 2020. By moving toward adoption of NCPDP 2017-071, the health care system will keep PDMP in harmony with other federal regulations.

    DOH supports the switch to NCPDP 2017-071, but we want to ensure that the deadline to do so is feasible. Currently, Washington State cannot accept NCPDP 2017-071 queries, as DOH’s system uses NCPDP 10.6 for the PDMP. NCPDP 2017-071 is not backward compatible with NCPDP 10.6. DOH staff contacted our electronic medical record vendors and the vendors indicated their certified Health IT software that meet these new requirements will be released in summer of 2019. Hospitals’ adoption of this new version will occur in a rolling adoption period after the release date. For DOH’s PDMP system, we hope to be able to begin the switch to NCPDP 2017-071 by January 1, 2020. DOH anticipate needing to support both NCPDP 2017-071 as well as 10.6, for a transition period from January 1, 2020 through approximately January 1, 2021, assuming not all providers convert simultaneously.

    In addition, DOH believes it would also be helpful for CMS to clarify whether, if the community pharmacy could not accept the prescription due to the different versions, this would be considered an exclusion for the hospital to maintain both versions. DOH recommends that CMS consider providing administrative support for public health, community pharmacies, small- to medium-sized providers, and critical access hospitals to upgrade to NCPDP 2017-071. If communities do not have the resources or incentives to upgrade, it will be crucial for PDMP systems to support both versions during this transition period.

    The proposed deadline to implement NCPDP version 2017-071 should be extended to ensure that PDMP systems and the health care system have a reasonable period of time to implement. DOH recommends that the ISA allow for NCPDP v10.6 grandfathering until January 1, 2021.

    Sincerely,

    John Wiesman, DrPH, MPH

    Secretary of Health

    Washington State Department of Health

     

    Allows for Communication of Prescription Information Between Prescribers and Dispensers

    Comment

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Adoption Level – 4

    Allows for the Exchange of State Prescription Drug Monitoring Program (PDMP) Data

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC update NCPDP Prescription Drug Monitoring Programs Reporting Standard, Implementation Guide to Version 15.
    2. NCPDP recommends that ONC update “NCPDP Telecommunication Standard, Version D” to “NCPDP Telecommunication Standard, Version D.0”.
    3. NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    1. NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP Telecommunication Standard, Version F6

    Standards Process Maturity – Pilot

    Implementation Maturity- Feedback Requested

    Adoption Level – Feedback Requested

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to update NCPDP Prescription Drug Monitoring Programs Reporting Standard, Implementation Guide to Version 15; updating NCPDP Telecommunication Standard, Version D to NCPDP Telecommunication Standard, Version D.0.

    NCPDP Comments

    NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

    WA State Department of Health PDMP Comments

    Washington State Department of Health appreciates having the standards listed on the PDMP pages and does not have any recommended changes at this time.

    WA State Department of Health PDMP Comments

    Washington State Department of Health appreciates having the standards listed on the PDMP pages and does not have any recommended changes at this time.

    NCPDP Comment

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Implementation Maturity – Production

    Adoption Level – 1

    Test Tool Availability – Yes

    1. For NCPDP SCRIPT Standard, Implementation Guide Version 2017071 add Test Tool Link: https://tools.ncpdp.org/erx/#/home
    2. Remove Implementation Specification: NCPDP SCRIPT Standard, Implementation Guide, Version 10.6

    NCPDP Comment

    1. NCPDP SCRIPT Standard Implementation Guide, Version 2017071 and the NCPDP Telecommunication Standard Implementation Guide, Version D.0 are mature standards that can alleviate identified interoperability issues.
    2. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Implementation Maturity – Production

    Adoption Level – N/A

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Update the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 10.6

    Adoption Level – N/A

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Prescription Drug Monitoring Programs Reporting Standard, Implementation Guide, Version 11

    Standards Process Maturity – Final

    Implementation Maturity - Pilot

    Adoption Level – N/A

    Federally required – No

    Cost - $

    Test Tool Availability - No

    Allows Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescriber Systems

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC remove NCPDP Formulary and Benefit Standard Version(s) 53, 54 and 55.
    2. NCPDP recommends that ONC remove the comment, “The NCPDP® WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers,” from the Limitations, Dependencies and Preconditions for Consideration section. The WG18 Patient Consent Task Group has been disbanded.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation to remove NCPDP Formulary and Benefit Standard Version(s) 53, 54, and 55.

    NCPDP Comments

    For NCPDP Real-Time Prescriptions Benefit Standard, add “Version 12” to the Standard/Implementation Specification title.

    NCPDP Comment

    1. Remove existing NCPDP verbiage under “Limitations”.
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Formulary and Benefit Standard, Implementation Guide, Version 53

    Standards Process Maturity – Final

    Implementation Maturity – Feedback requested

    Adoption Level – Feedback requested

    Federally required – No

    Cost - $

    Test Tool Availability – No

    1. Modify the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Real Time Prescription Benefit Standard

    Standards Process Maturity – Final

    Implementation Maturity – Production

    Adoption Level – 1

    NCPDP Comment

    NCPDP developed a Beta version of the Real Time Prescription Benefit Standard to be balloted in the Fall of 2019.

    Real Time Prescription Benefit

    The American Medical Association appreciates the opportunity to comment. Real-time Prescription Benefit (RTPB) is mentioned, however it is not linked nor actually named. We believe this section should be updated as RTPB now has a standard out for ballot.

    NCPDP - Comment

    • The second bullet under Limitations, Dependencies, and Preconditions for Consideration should be modified to the following:
      • NCPDP is developing a Real Time Prescription Benefit standard that should be monitored as a potential emerging implementation specification.

    Public Health Reporting

    Adverse Event Reporting

    Comment

    Case Reporting to Public Health Agencies

    Comment

    WA State Department of Health eCR Comments

    Washington State Department of Health appreciates having the standards listed on the “Case Reporting to Public Health Agencies” page and does not have any recommended changes at this time.

    WA State Department of Health eCR Comments

    Washington State Department of Health appreciates having the standards listed on the “Case Reporting to Public Health Agencies” page and does not have any recommended changes at this time.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the balloted drafts of HL7 CDA R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes (US Realm), DSTU Release 2.1 (with errata); HL7 CDA Release 2 Implementation Guide: Reporting to Public Health Case Reporting, Release 1, DSTU Release 1.1 (US Realm), the Electronic Initial Case Report (eICR); HL7 FHIR Implementation Guide: Structured Data Capture (SDC) STU2; and HL7 CDA R2 Implementation Guide: Reportability Response Release 1, STU Release 1.0 (US Realm).

    Data Submission for Title X Family Planning Annual Reporting

    Comment

    Electronic Transmission of Reportable Laboratory Results to Public Health Agencies

    Comment

    WA State Department of Health ELR Comments

    Washington State Department of Health appreciates having the standards listed on the “Electronic Transmission of Reportable Lab Results to Public Health Agencies” page and only has one recommended change at this time. Washington State Department of Health recommends adding FHIR US Lab Report (https://www.hl7.org/FHIR/2016May/uslab/uslabreport-guide.html) as an emerging standard for electronic lab reporting. 

    ACLA ISA request to clarity ““Limitations, Dependencies, and Pre

    Please add to “Limitations, Dependencies, and Preconditions”

    EHRs should report required public health information directly to public health agencies (PHA) using eCR (electronic case reporting) standards or other appropriate standard from the ISA section “Case Reporting to Public Health Agencies”. This will provide the data timelier to the PHA which may support improved patient tracking.    This will also curtail proliferation of ancillary information that is not necessary to process laboratory test results being added to the ELR.  Additionally, the laboratory will not be required to serve as a data repository and be required to add new fields and/or store and forward to public health agencies.

     

    Please review the “Applicable Security Patterns for Consideration” applicability to the section and if not applicable, remove.  This would be more appropriate in an introductory section.  This change, if approved, might be applied throughout the document.

    Thank you for your comment,…

    Thank you for your comment, the above has been incorporated with modification. 

    WA State Department of Health ELR Comments

    Washington State Department of Health appreciates having the standards listed on the “Electronic Transmission of Reportable Lab Results to Public Health Agencies” page and only has one recommended change at this time. Washington State Department of Health recommends adding FHIR US Lab Report (https://www.hl7.org/FHIR/2016May/uslab/uslabreport-guide.html) as an emerging standard for electronic lab reporting.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of HL7 2.5.1; HL7 Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification; the balloted drafts of HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory to Public Health, Release (US Realm), Draft Standard for Trial Use, Release 1.1; and emerging implementation specification HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Results Interface Implementation Guide, Release 1 STU Release 2 (US Realm), which is in development.

     

    Link updated

    Thank you for bringing this to our attention. The link has been updated. 

    Exchanging Immunization Data with Immunization Registries

    Comment

    AIRA Comments on Exchanging Immunization Data

    AIRA recommends that the following statement be updated:

    “…and determine which transport methods are acceptable for submitting immunization registry data as there may be jurisdictional variation or requirements.”

    We have validated through our testing that there is near universal IIS adoption of the preferred transport standard referenced here: https://www.healthit.gov/isa/transport-immunization-submission-and-queryresponse. We would recommend that the statement acknowledge this wide adoption and link to the standard above.

    AIRA Comments on Exchanging Immunization Data

    AIRA recommends that the following statement be updated:

    “…and determine which transport methods are acceptable for submitting immunization registry data as there may be jurisdictional variation or requirements.”

    We have validated through our testing that there is near universal IIS adoption of the preferred transport standard referenced here: https://www.healthit.gov/isa/transport-immunization-submission-and-queryresponse. We would recommend that the statement acknowledge this wide adoption and link to the standard above.

    Adoption level for Release 1.5

    The Release 1.5 implementation guide is widely adopted and should rate a 5 on the scale.

    WA State Dept. of Health - Immunizations Comment

    Washington State Department of Health appreciates having the standards listed on the “Exchanging Immunization Data with Immunization Registries” page and does not have any recommended changes at this time. 

    AIRA Comments - Adoption Level

    AIRA recommends the adoption level of 1.5 to be all 5 bullets (high or widespread adoption). As of 12/31/2020 – the latest CDC published data from the IIS Annual Report, there were just over 121,000 live HL7 V2 interfaces.

    WA State Department of Health Immunizations Comments

    Washington State Department of Health appreciates having the standards listed on the “Exchanging Immunization Data with Immunization Registries” page and does not have any recommended changes at this time.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of HL7 2.5.1 and HL7 2.51 Implementation Guide for Immunization Messaging, Release 1.4 and 1.5.

    Thank you for bringing this…

    Thank you for bringing this to our attention. The link to the test tool has been updated. 

    Newborn Screening Results and Birth Defect Reporting to Public Health Agencies

    Comment

    WA State Department of Health UDS Comments

    As the Dept. of Health continues to develop our child developmental health registry, we will provide additional feedback on which standards we feel are best for universal developmental screening or if there are standards that would work well but need refinement (addition of data fields for example).   

    WA State Department of Health Newborn Screening Comments

    Washington State Department of Health appreciates having the standards listed on the “Reporting Newborn Screening and Birth Defects to Public Health Agencies” page and does not have any recommended changes at this time.

    WA State Department of Health NBS and CDH Comments

    Washington State Department of Health recommends having a separate page for public health newborn screening test ordering and reporting with reference to the Newborn Dried Blood Spot (NDBS) component of HL7 v 2.5.1 implementation Guide: Laboratory Orders from EHR (LOI) Release 3 and Lab Results Interface (LRI) Release 3. The newest version of these standards have incorporated a component for the electronic ordering and reporting for use in newborn screening programs, these versions are not currently listed on the ONC ISA. It is important to distinguish these efforts from those associated with Child Developmental Health as newborn screening is a laboratory test and public health program. We would recommend including the implementation guides for Critical Congenital Heart Defects (HL7 v 2.6 Implementation Guide: Critical Congenital Heart Defects (CCHD) pulse oximetry screening results, release 1) and Early Hearing Detection and Intervention (HL7 v 2.6 Implementation Guide: Early Hearing Detection and Intervention (EHDI) results Release 1) into a newborn screening page as many states programs include the point of care tests within their newborn screening programs. The Implementation guide for NANI could also be included with newborn screening as it serves as birth notification to newborn screening programs and is included in comprehensive newborn screening surveillance.

     

    Washington State Department of Health recommends having a separate page for public health newborn screening (test orders and return of results) from birth defects registry (BDR) reporting and universal developmental screening (UDS). While new born screening, BDR, and UDS are related, they all serve a different function and may have different standards that make the most sense to use. As we continue to develop our child developmental health registries we will provide additional feedback on which standards we feel are best for BDR and UDS or if there are standards that would work well but need refinement (addition of data fields for example).

    Update Test Tool

    Publicly available message validation tooling for CCHD and EHDI are available through the NIST v2 Tool Portal as part of their General Validation Tool (https://hl7v2.gvt.nist.gov/gvt/#/home) via Tool Scopes of CCHD National IG and EHDI National IG respectively

    Update Adoption Level

    The NANI standard is in use at 200+ facilities and across multiple states. We feel that an Adoption Level of Medium (3 filled circles) may be appropriate

    Update Maturity Level

    All of the NANI, CCHD or EHDI standards are in production use somewhere in the United States. We suggest that the Implementation Maturity for these standards be upgraded from “Pilot” to “Production”

    Normative status for CCHD and EHDI

    The CCHD and EHDI standards were published in 2020 as normative so the Standards Process Maturity should be Final rather than Balloted Draft

    Add DAR IG

    We suggest adding the v2.6 Diagnostic Audiology Reporting implementation guide to the Newborn Screening section. This IG is currently under development at HL7 and should be published as an STU standard later in 2021.

    Add LOI and LRI IGs to the newborn section

    We suggest adding the v2.5.1 LOI and LRI here and note these IGs contain profiles for newborn dried blood spot testing. Our research as part of the Innovations in Newborn Screening Interoperability project indicates that ~25% of jurisdictions are doing some sort of electronic order and result exchanges. We believe a low to medium adoption rate is appropriate.

    Reporting Antimicrobial Use and Resistance Information to Public Health Agencies

    Comment

    AUR Comments

    According to this page, the emerging IG is DSTU Release 2.1.  However when you follow the link, HL7 site indicates the latest version as Release 2 (Nov 2015).  Version numbers do not match from HealthIT and HL7 sites.

    Following are comments on HAI IG Release 2 (downloaded from HL7 site):

    Volume 2, Page 141, Section 2.1.20, “5. SHALL contain at least one [1..*] entry (CONF:1181-23046) such that it

    Comment: NHSN protocol limits exact number of entries to be reported in order to be submitted to CDC successful.  This needs a clarification with referencing back to NHS AUR module protocol to know the exact number to be included.

    Reporting Birth and Fetal Death to Public Health Agencies

    Comment

    CDC/NCHS Updates and Retirement of the v2 and CDA standards

    Changes/Updates:

    HL7® FHIR® Vital Records Birth and Fetal Death Reporting Implementation Guide: Type: Implementation Specification #1: Standards Process Maturity: Balloted Draft, #2: Implementation Maturity: Pilot, #3: Adoption Level: Low, #4: Federally Required: No, #5: Cost: Free, #6: Test Tool Availability: No

    The following can be removed from the “Limitations, Dependencies, and Preconditions for Consideration” section:

    In 2019, the Division for Vital Statistics at the National Center for Health Statistics (NCHS) started focusing their standards development on FHIR®. In May 2020 the drafting of a Birth and Fetal Death Reporting FHIR® implementation guide was initiated and will be balloted in January 2021. This work is sponsored under the HL7® Public Health Work Group.

    The V2 test tools listed above are found under "Tool scope: Vital Records Birth and Fetal Death v 2.6 Testing Tool."

    The IHE specification tool is supported by the CDA and V2.6 testing tools

    The following can be added to the “Limitations, Dependencies, and Preconditions for Consideration” section:

    A FHIR test tool is planned for development in 2023.

    The following specifications are being retired to allow implementers to concentrate on the FHIR IG that has been created to support the Birth/Fetal Death reporting requirements.  There are no current or planned standards development activity within NCHS; which may no longer be in use, or which should not be considered for use for these specifications.:

    • HL7® Version 2.6 Implementation Guide: Birth and Fetal Death Reporting, Release 1 STU Release 2 (US Realm - Standard for Trial Use)
    • HL7 CDA® R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2 - US Realm

    Retirement of the v2 and CDA standards

    The HL7 Public Health Work Group has officially retired the v2 and and CDA implementation guides. These should be removed from this list as implementers should focus on the FHIR standard.

    WA State Department of Health Live Birth and Fetal Death

    Washington State Department of Health appreciates having the standards listed on the “Reporting Birth and Fetal Death to Public Health Agencies” page and does not have any new standards to recommend. We do have some comments about the standards listed:  

    • It appears that some specific details are still under development. 

    • Live birth - From the IJE mapping section, the following fields in the current IJE files will not be in the birth transmissions: VOID, MATCH, MAGER, FAGER, MAGE_CALC, FAGE_CALC, MOM_OC_T, MOM_OC_C, DAD_OC_C, DAD_OC_C, MOM_IN_T, MOM_IN_C, DAD_IN_T, DAD_IN_C, SSN_CITIZEN_CD, SSN_MULT_BTH_CD, SSN_FEEDBACK, SSN_BRTH_CRT_NO, MARITAL_DESCRIP, REPLACE. Is this correct? There appear to be broken links, such as to the observation/pregnancy risk factor definitions. And the 5 minute APGAR score 

    • Fetal Death  - From the IJE mapping section, the following fields in the current IJE files will not be in the birth transmissions: VOID, MATCH, R_YR, R_MO, R_DY, MAGER, FAGER, HSV1, HIV, ALCOHOL, ALIAS, LONG_D, LAT_D, LONG, LAT, MAGE_CALC, FAGE_CALC, MOM_OC_T, MOM_OC_C, DAD_OC_T, DAD_OC_C, MOM_IN_T, MOM_IN_C, DAD_IN_T, DAD_IN_C, INFORMFST, INFORMMID, INFORMLST, INFORMRELATE, REPLACE. Is this correct? 

    WA State Department of Health Birth and Fetal Death Comments

    • Washington State Department of Health appreciates having the standards listed on the “Reporting Birth and Fetal Death to Public Health Agencies” page and does not have any new standards to recommend. We do have some comments about the standards listed:
      • It appears that some specific details are still under development.
      • Live birth
        • From the IJE mapping section, the following fields in the current IJE files will not be in the birth transmissions: VOID, MATCH, MAGER, FAGER, MAGE_CALC, FAGE_CALC, MOM_OC_T, MOM_OC_C, DAD_OC_C, DAD_OC_C, MOM_IN_T, MOM_IN_C, DAD_IN_T, DAD_IN_C, SSN_CITIZEN_CD, SSN_MULT_BTH_CD, SSN_FEEDBACK, SSN_BRTH_CRT_NO, MARITAL_DESCRIP, REPLACE. Is this correct?
        • There appear to be broken links, such as to the observation/pregnancy risk factor definitions. And the 5 minute APGAR score
      • Fetal Death
        • From the IJE mapping section, the following fields in the current IJE files will not be in the birth transmissions: VOID, MATCH, R_YR, R_MO, R_DY, MAGER, FAGER, HSV1, HIV, ALCOHOL, ALIAS, LONG_D, LAT_D, LONG, LAT, MAGE_CALC, FAGE_CALC, MOM_OC_T, MOM_OC_C, DAD_OC_T, DAD_OC_C, MOM_IN_T, MOM_IN_C, DAD_IN_T, DAD_IN_C, INFORMFST, INFORMMID, INFORMLST, INFORMRELATE, REPLACE. Is this correct?

    HIMSS Comments on Subsection II-R

    The Healthcare Information and Management Systems Society (HIMSS) is pleased to submit these comments for consideration by ONC to update the Interoperability Standards Advisory (ISA). These comments are one set in a series of comments that HIMSS has and will prepare to review the updates to the new web-based version of the ISA. More comments addressing other elements of this resource are forthcoming. For more information on previous comments, please visit the HIMSS website.

    HIMSS recommends that Interoperability Need “Reporting Birth Defects to Public Health Agencies” in Subsection II-R be rephrased and expanded to “Reporting Newborn Birth, Health and Death to Public Health Agencies”. HIMSS has provided the attached information as a suggested expansion of the standards and specifications included in this section.

    Subsection II-R New Interop Need Table_HIMSS.pdf

    Reporting Cancer Cases to Public Health Agencies

    Comment

    WA State Department of Health Cancer Comments

    Washington State Department of Health appreciates having the standards listed on the “Reporting Cancer Cases to Public Health Agencies” page and does not have any recommended changes at this time. 

     

    WA State Department of Health Cancer Comments

    Washington State Department of Health appreciates having the standards listed on the “Reporting Cancer Cases to Public Health Agencies” page and does not have any recommended changes at this time.

    Digital in Healthcare

    Hello,

    The cancer cases are increasing nowadays and according to online research, healthcare should be available to everyone to fight against the diseases. The initiative by Public Health Agencies are recommendable for the future of civilians. 

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the addition of HL7 Clinical Document Architecture (CDA), Release 2.0, Final Edition, as well as the balloted drafts HL7 CDA Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 (US Realm) and IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation.

    Reporting Death Records to Public Health Agencies

    Comment

    CDC/NCHS Updates

    HL7® Vital Records Death Reporting (VRDR) FHIR Implementation Guide 2.0.0 - STU 2 - Latest version is 2.2.0 - STU 2.2 – expected to be published through HL7 during the time of this submission to ISA.

    IHE Quality, Research and Public Health Technical Framework Supplement Vital Records Death Reporting (VRDR) R 3.2 - No active development since 2021 and no future planned development on this standard.  

    Update for Limitations, Dependencies, and Preconditions for Consideration:

    State vital records offices will be working with The National Center for Health Statistics (NCHS) to move to production end of 2023.  This effort will include the transmission of FHIR messages using HL7 Vital Records Death Reporting (VRDR) FHIR Implementation Guide 2.2.0-STU 2.2

    The Vital Records Common Library (http://hl7.org/fhir/us/vr-common-library/STU1/) is a US Realm specific framework that provides common data elements among the vital records, Vital Records Death Reporting (VRDR), Birth and Fetal Death Reporting (BFDR) and Medicolegal Death Investigation (MDI) FHIR® implementation guides. The purpose of this library is to avoid defining the same profiles multiple times within respective implementation guides.

    CDC/NCHS Updates and Retirement of the v2 and CDA standards

    Change emerging standard titled – “Vital Records Death Reporting v0.1.0 - STU Ballot #1” to an Implementation Specification – “HL7 Vital Records Death Reporting (VRDR) FHIR Implementation Guide 2.0.0 - STU 2”. Please note that ballot #1 for STU 1 was published. However, since the last ISA update VRDR FHIR STU 2 was balloted and published and will remain the active STU for implementation with the National Vital Statistics System (NVSS). The HL7 FHIR VRDR STU 1 will be retired. Type: Implementation Specification, #1: Standards Process Maturity: Balloted Draft, #2: Implementation Maturity: Pilot, #3: Adoption Level: Medium, #4: Federally Required: No, #5: Cost: Free, #6: Test Tool Availability: Yes (GitHub - nightingaleproject/canary: A FHIR VRDR testing framework for both data providers and consumers.)

    The following can be removed from the “Limitations, Dependencies, and Preconditions for Consideration” section:

    The National Center for Health Statistics (NCHS) had previously developed HL7® messaging and document standards for mortality reporting. NCHS has recently made the decision to move to the FHIR® standards for exchange of data between jurisdictions and NCHS and is in the process of developing an HL7® FHIR® IG for Death Reporting which should be published by January 2020. This will be tested at the IHE Connectathon in January 2020 and piloted at NCHS during that same year.

    HL7® balloted HL7® Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 2 (US Realm - Standard for Trial Use) in May 2019. Publication is expected by December 2019.

    The V2 test tools above are found under "Tool scope: Vital Records"

    The following can be added to the “Limitations, Dependencies, and Preconditions for Consideration” section:

    State vital records offices will be working with The National Center for Health Statistics (NCHS) to move to production beginning in early 2023.  This effort will include the transmission of FHIR messages using HL7 Vital Records Death Reporting (VRDR) FHIR Implementation Guide 2.0.0 - STU 2.

    The following specifications are being retired to allow implementers to concentrate on the FHIR IG that has been created to support death reporting requirements.  There are no current or planned standards development activity within NCHS for these standards; which may no longer be in use, or which should not be considered for use for these specifications.:

    • HL7® Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 1 STU R2.1 - US Realm
    • HL7® CDA® R2 Implementation Guide: Vital Records Death Reporting, Release 1 STU 2.1 - US Realm

    The Vital Records Common Library is a US Realm specific framework that provides common data elements between the birth and fetal death reporting and birth defects reporting FHIR® implementation guides. The purpose of this library is to avoid defining the same profiles multiple times within respective implementation guides.

    Retirement of the v2 and CDA standards

    The HL7 Public Health Work Group has officially retired the v2 and and CDA implementation guides. These should be removed from this list as implementers should focus on the FHIR standard.

    WA State Department of Health Death Record Comments

    Washington State Department of Health appreciates having the standards listed on the “Reporting Death Records to Public Health Agencies” page and does not have any new standards to recommend. We do have some comments about the standards listed: 

    • The value binding link for VRDR Decedent address.district appears to be broken. The text of the hyperlink is correct but encoding the URL has broken the functionality of ‘?’ and ‘=’. Similar bugs appear in multiple places. 

    • The change history indicates decedent.address.city should be numeric (presumably for city FIPS), but the resource profile says text. Which is correct? 

    • We are unable to locate some profile elements listed in the terminology bindings page: Certifier role (observation.code and observation.valueCodeableConcept) & Death Certificate.Informant (contact.relationship) 

    • The terminology bindings page seems to indicate that usual industry, usual occupation, and military service are part of a profile called Decedent Employment History, but the artifacts indicate resources of ‘Decedent Military Service’ and ‘Decedent’s Usual Work’. 

    WA State Department of Health Death Records Comments

    • Washington State Department of Health appreciates having the standards listed on the “Reporting Death Records to Public Health Agencies” page and does not have any new standards to recommend. We do have some comments about the standards listed:
      • The value binding link for VRDR Decedent address.district appears to be broken. The text of the hyperlink is correct but encoding the URL has broken the functionality of ‘?’ and ‘=’. Similar bugs appear in multiple places.
      • The change history indicates decedent.address.city should be numeric (presumably for city FIPS), but the resource profile says text. Which is correct?
      • We are unable to locate some profile elements listed in the terminology bindings page
        • Certifier role (observation.code and observation.valueCodeableConcept)
        • Death Certificate.Informant (contact.relationship)
      • The terminology bindings page seems to indicate that usual industry, usual occupation, and military service are part of a profile called Decedent Employment History, but the artifacts indicate resources of ‘Decedent Military Service’ and ‘Decedent’s Usual Work’.

    Reporting Syndromic Surveillance to Public Health (Emergency Department, Inpatient, and Urgent Care Settings)

    Comment

    WA State Department of Health Syndromic Comments

    Washington State Department of Health appreciates having the standards listed on the “Reporting Syndromic Surveillance to Public Health (Emergency Department, Inpatient, and Urgent Care Settings)” page and does not have any recommended changes at this time.

    Sending Health Care Survey Information to Public Health Agencies

    Comment

    CDC/NCHS updates and additions of specifications for NHCS

    1. Implementation Specification- HL7® CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1 - US Realm- Under Implementation Maturity, change from Production to Pilot

    2. Implementation Specification- HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 1.2 - US Realm- Under Implementation Maturity, change Implementation Maturity from Pilot to Production. Under Adoption Level -Medium to High 

    3. Implementation Specification - HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 1.1 - US Realm-Under Implementation Maturity change from Pilot to Replaced by 1.2 

    4. Change from Emerging Standard to Implementation Specification, under Standards Process Maturity change from In Development to Published in a balloted draft. Under the Adoption level add Feedback Requested. Under Test Tool Availability -No

    5.   Limitations, Dependencies, and Preconditions for Consideration- Additional bullet 

    • To align with CDC’s data modernization initiative, DHCS has developed and published the  Health Care Surveys FHIR Implementation Guide 1.0.0- STU1 Release 1. This is one of the use cases that is testing the application and use of the MedMorph reference architecture. This standard is not currently listed in ONC’s Standards Version Advancement Process (SVAP).

    CDC/NCHS updates and additions of specifications for NHCS

    Changes/Updates:

    Implementation Specification – “HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1 - US Realm” is phased out with replacement.

    STU 1.2 Aligns with Promoting Interoperability program requirements. Current STU 1.2 implementations who want to fix issues with 1.2 submissions should consider upgrading to STU 2.1

    Please add new specifications:

    Type: Implementation Specification; Standard/Implementation Specification:  HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), Release 1, STU Release 3 – US Realm; Standards Process Maturity: Balloted Draft; Implementation Maturity: Pilot; Adoption Level: Low; Federally Required: Yes; Cost: Free; Test Tool Availability: Yes

    Type: Emerging Standard; Standard/Implementation Specification:  HL7 FHIR Health Care Surveys Content Implementation Guide 0.1.0 - STU 1 Ballot; Standards Process Maturity: In Development; Implementation Maturity: Pilot; Adoption Level: Low; Federally Required: Yes; Cost: Free; Test Tool Availability: No

    Data Collection for Submission to Registries and Reporting Authorities

    Comment

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of HL7: "Again, I don’t think there’s any case where CDASH or RFD is or could be used for submission to reporting authority.  If ACC refers to the American College of Cardiology, why is it listed in ISA at all?  I think this section should be dropped.  I’m not aware if CDA is used in this context, but again, may not be necessary anyway.  Current production version of CDA is v2.1 (which I hope is on the HL7 comments)."

    feedback

    section Preconditions for Consideration should better define what it means to

    "Complete Disease Registry Forms and Submit to Reporting Authority (ACC)"

    It should also explain what ACC stands for.
     

    Consider merging this section with a section that talks about populating research form. A registry can be viewed as a special case of a research study. A special section for just registries may not be needed.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports use of CDISC Clinical Data Acquisition Standards Harmonization (CDASH), IHE-RFD (Retrieve Form for Data Capture) and HL7 Clinical Document Architecture (CDA), Release 2, Final Edition.

    Prepopulation of Research Forms from Electronic Health Records

    Comment

    Broken link to CDISC CDASH

    The top link in the standards list to CDISC's CDASH standard, does not work. It gives a "page not found" error. The URL it's trying to go to is https://www.cdisc.org/cdash

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of HL7: "I believe all of these in this section should be listed with Adoption Level 1.  I don’t believe any of these (including FHIR Audit Event) have had any significant adoption."

    feedback

    the last item (HL7 FHIR Questionnaire/Questionnaire Response) - adoption is 1 dot.  

    (It has FHIR maturity level 3 "which is means no longer just emerging.")

    Consider adding the following applicable value sets text:

    "A major research study in USA (AllofUs study) is collecting body measurements and uses LOINC to encode them. Updates to such measurements are imported from EHR data. The value set used by them is available here http://athena.ohdsi.org/search-terms/terms?conceptClass=Clinical+Observation&vocabulary=PPI&page=1&pageSize=50&query=

    For examle, AllofUs study pre- (and post-) populates their database with the following EHR elements (and others listed in the URL above)

    Body Weight (LOINC 29463-7)
    Body Height (LOINC 8302-2)
    Body Mass Index (LOINC 39156-5)
    Heart Rate Rhythm (LOINC 8884-9)
    and others...
    "

    Registering a Clinical Trial

    Comment

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of HL7: "Again, while ODM can be adoption level 5 for exchanging clinical trial databases between research systems, ODM has no adoption that I’m aware of for this context."

    updates

    CTR-XML is no longer just balloted. It was released (2016-march 28). 

    In preconditions for considerations add the following:

    "CTR-XML standard is based on CDISC ODM. It is an extension of the ODM standard."

    Submission of Clinical Research Data Contained in EHRs and Other Health IT Systems for General Purpose or Preserving Specific FDA Requirements

    Comment

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of Hl7: "I don’t understand why this section is here at all.  It’s not addressing all FDA requirements, and I don’t believe these are currently in use for actual integration.  I don’t even understand what the title means.  It’s misleading at best and hardly of practical use.  The last row on pharmacogenomics was approved, but I don’t see how it’s applicable for this activity, since there’s no use case involving EHRs or Health IT systems.  It’s a conversion to CDISC structures and terminologies."

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of IHE-RFD (Retrieve Form for Data Capture), HL7 Clinical Document Architecture (CDA), Release 2.0, Final Edition, and CDISC Pharmacogeneomics/genetics (PGx) Implementation Guide.

    Submission of Clinical Research Data to FDA to Support Product Marketing Applications

    Comment

    On behalf of Wayne Kubick,…

    On behalf of Wayne Kubick, CTO of HL7: "Row 3 - ODM is not accepted for regulatory submissions.  It’s true it has a high adoption level for other contexts, but it should be 1 for regulatory submissions 

    Row 8 for Therapeutic Area Standards lists Process Maturity as Final, Implementation maturity as Production. But, in fact, this refers to a whole series of IGs, some of which are in development as draft, some provisional (not quite final).  It’s not appropriate to lump them together and adopt the most mature value, but you don’t want to separate them out either. I would change these values to Need Feedback or to some indication the they vary.  The phrase “apply across all therapeutic areas” is not correct.  They haven’t addressed, all, only some.

     In the comments section here, the statement "although CDISC standards are a requirement for CDER and CBER and not for CDRH,  all three Centers promote the use of Real World Data (RWD) in EHRs, registries, administrative claims and mobile health technology to generate Real World Evidence regarding the safety and effectiveness of medical products” implies that CBER, CDER and CDRH use CDISC for real world data.  That’s not accurate.  Instead, the secant should say “FDA CDER, CBER and CDRH promote the use of Real World data (RWD) in EHRs…. 

    A comment from AllofUS makes a similar point."

    OMOP CDM

    AllOfUs research project is not using CDISC standards. Since it uses RWE, it chose to adopt OMOP CDM. OMOP should be added to the list with medium adoption. (adoption measured by sites generating the data)

    Submit Adverse Event Report from an Electronic Health Record to Drug Safety Regulators

    Comment

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of IHE-RFD (Retrieve From for Data Capture) and balloted drafts of IHE-DSC (Drug Safety Content) and IHE-CPRC (Clinical Research Process Content).

    PRM model

    remove this entry from the table. PRM is not closely related to adverse event submission.

    Security Tags for Sensitive Information

    Security Tags for Sensitive Information

    Comment

    HL7® v2.8 - ARV Access Restrictions Segment

    HL7® v2.8 - ARV Access Restrictions Segment is incorrect.  The ARV Access Restrictions Segment, as well as the BHS, FHS, and MSH segments adopted HL7 Healthcare Privacy and Security Classification System syntax for assigning security labels in HL7 v2.9. Noteworthy for ISA is that these updated segments to support security labeling may be pre-adopted by any implementer of a preceding HL7 V2 message version. Please correct.

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of Consolidated HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1; HL7 Clinical Document Architecture (CDA), Release 2.0, Final Edition and IHE IT Infrastructure Technical Framework Volume 4 – National Extensions – Section 3.1 Data Segmentation for Privacy (DS4P). The Collaborative also supports Consent2Share FHIR Consent Profile Design, which is in development.

    Is Federally required accurate?

    Federally required, MU2015 this was an optional certification criteria at the document level for DS4P, is Federally required accurate if optional or does that apply to use of this IG?

    CDA DS4P segmentation applied to section level. CDA Privacy Segmented Section-may apply to any section of a C-CDA document if that section metadata (sensitivity, confidentiality) is different than the document's overall

    This IG needs further development.  The concept that a section is more private then the document is pointless. The Document privacy should be inherited from the most private section. Esp. when the MU2015 optional certification was limited to document level privacy. 

    Support a Transition of Care or Referral to Another Health Care Provider

    Comment

    NCPDP Comment

    NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    NCPDP Comments

    NCPDP supports ONC’s recommendations.

    NCPDP Comment

    1. Modify the following:

    Type-Change to: Implementation Specification

    Standard Implementation/Specification- HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1

    Standards Process Maturity –Final

    Implementation Maturity- Production

    1. Add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2020101

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Remove: NCPDP Specialized Standard. The Referral transactions have been moved to the NCPDP SCRIPT Standard, Implementation Guide, Version 2020101

    NCPDP Comment

    1. Add the following:

    Type-Emerging Standard

    Standard Implementation/Specification- HL7 Implementation Guide for C-CDA Release 2.1: Consolidated CDA for Clinical Notes and C-CDA on FHIR R4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Available – Spring 2020

    1. Emerging Standard New transactions proposed within NCPDP SCRIPT Standard:
      1. Patient Care Service Referral (ServiceReferral)
      2. Patient Care Service Documentation (ServiceDocumentation)
      3. Response to Request for Patient Care Service Referral (ResponseToReferralRequest)
      4. Request for Patient Care Service Referral (RequestForReferral)
      5. Response to Patient Care Service Referral (ServiceReferralResponse)
    2. Request NCPDP PatientCareServiceReferral Transactions be added to the ONC 360 project

    Specifications to manage x-organizational referrals and TOC

    See attached file for comments related to referrals/transitions of care - received via email on 9/23. 

    2019_ISA_Comments_Approval_Final Submitted_2.pdf

    Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

    The Pharmacy HIT Collaborative supports the use of HL7 Clinical Document Architecture (CDA), Release 2.0, Final Edition; the balloted drafts of: HL7 Consolidated CDA Release 1.1 (HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1, US Realm), HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1, and  IHE Patient Care Coordination Technical Framework Supplement 360 Exchange Closed Loop Referral, Rev. 1.1, Trial Implementation; and NCPDP Specialized Standard.

    ​​​​​​​Does ONC anticipate 360x becoming federally required

    HE Patient Care Coordination Technical Framework Supplement 360 Exchange Closed Loop Referral (360X) Rev. 1.1 – Trial Implementation

    The Shall use XDM needs to be reduced to May. That will be consistent with MU2015 requirements to send/receive a single document and use of XDR. Sending a single document is patient based workflow facilitating patient matching and meeting the workflow requirements when sending direct, it lowers the bar for adoption.  

    Does ONC anticipate use of 360x becoming federally required?

    Consider CDA on FHIR and…

    Consider CDA on FHIR and CCDA on FHIR.

    NCPDP - Comment

    In Emerging Implementation Specification add the following:

    • NCPDP Specialized Standard supports request/referral for MTM Services may be initiated by the payer, treating or prescribing physician, pharmacist, a hospital or other facility, and/or the patient or caregiver.
    • CCDA R2 is the basis for NCPDP recommendations for Pharmacy Transition of Care, Pharmacy/Pharmacist care notes, and HL7 CDA® R2 Implementation Guide: Medication Therapy Management (MTM) Templates, Release 1 - US also known as HL7 IG for CDAR2: Medication Therapy Management (MTM) Templates, R1", MTM CMR Take-away document; MTM CMS document, CDAR2, MTM
    • Adoption Level should be a 1.

    Unique Device Identification

    Defining a Globally Unique Device Identifier

    Comment

    NCPDP Comment

    Support of the UDI-DI will be available in the NCPDP SCRIPT Standard Version 2017071 and the NCPDP Telecommunication Standard Version F2. Today, these numbers are reformatted to support the field size limitations.

    New Comment -Section I – U Defining a Globally Unique Device

    Please make the following changes:

    1.Please add row for  “Implementation” and add “IEEE 11073 PHD Harmonization Pattern for Unique Device Identifiers”. The remaining fields are the same as for HL7 Harmonization…

    NCPDP - Comment

    Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Product Identifiers Standard Implementation Guide Version 1.4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    NCPDP Product Identifiers Standard IG recommendation

    Thank you for your comment.  Can you please provide additional information about this IG, including a link to the actual IG for reference and information?

    NCPDP Response

    The NCPDP Product Identifiers Standard Implementation Guide is intended to define, clarify, and ensure continuity of the Product Identification Codes for drugs and other items used in the healthcare marketplace to meet the needs within the healthcare industry including but not limited to payers, providers and patients. You must be an NCPDP member to access the standards.

    Representing Unique Implantable Device Identifiers

    Comment

    Transmitting a Unique Device Identifier

    Comment

    NCPDP Comment

    NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports NCPDP’s recommendation of adding NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to the implementation specification.

    NCPDP Comments

    1. Update: NCPDP Telecommunication Standard, Implementation Guide, Version F6 is not in production. It is a published version. We are waiting for CMS to name this version in HIPAA. No date for production is available at this time. Adoption Level should be “Feedback Requested”.
    2. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 5

    Federally Required – Yes

    Cost – $

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Support of the full length of the UDI-DI will be available in the NCPDP SCRIPT Standard Implementation Guide, Version 2017071, and the NCPDP Telecommunication Standard Implementation Guide, Version F6. Today, these numbers are reformatted to support the field size limitations.

    NCPDP Comment

    1. Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – Yes

    Test Tool Link: https://tools.ncpdp.org/erx/#/home

    1. Support of the full length of the UDI-DI will be available in the NCPDP SCRIPT Standard Implementation Guide, Version 2017071, and the NCPDP Telecommunication Standard Implementation Guide, Version F6. Today, these numbers are reformatted to support the field size limitations.
    2.  Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F6

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    NCPDP Comment

    1. Support of the full length of the UDI-DI will be available in the NCPDP SCRIPT Standard Implementation Guide, Version 2017071 and the NCPDP Telecommunication Standard Implementation Guide, Version F2. Today, these numbers are reformatted to support the field size limitations.

    NCPDP Comment

    Support of the UDI-DI will be available in the NCPDP SCRIPT Standard Version 2017071 and the NCPDP Telecommunication Standard Version F2. Today, these numbers are reformatted to support the field size limitations.

    Regenstrief - Comment

    This interoperability need corresponds to a syntax standard, not a terminology standard. As such, it should be moved to the Content/Structure Standards and Implementation Specifications section.

    NCPDP - Comment

    Add the following:

    Type-Implementation Specification

    Standard Implementation/Specification- NCPDP Product Identifiers Standard Implementation Guide Version 1.4

    Standards Process Maturity – Final

    Implementation Maturity- Production

    Adoption Level – 3

    Federally Required – No

    Cost – $

    Test Tool Availability - No

    Work Information Templates

    Comment

    NIOSH Comments

    NIOSH suggests modifying applicable implementation specifications to accommodate for updates made to titles, versions, and hyperlinks as outlined in the attachment.  

    Updates to ISA for 2023 - Content_Structure.pdf

    Proposed version updates

    We are preparing a comment updating to the latest standards versions and will provide further information as soon as possible.


    Services/Exchange

    "Push” Exchange

    An Unsolicited "Push" of Clinical Health Information to a Known Destination and Information System User

    Comment

    NCPDP Comment

    1. NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    1. NCPDP recommends that ONC update Specialty Medication Enrollment HL7 FHIR Type to “Implementation Specification”, Standards Process Maturity to “Final” and Implementation Maturity to “Production”.

    Pharmacy HIT Collaborative (PHIT) comment

    PHIT supports the following NCPDP recommendations: adding NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to the implementation specification; updating Specialty Medication Enrollment HL7 FHIR Type to implementation specification, Standards Process Maturity to final, and implementation maturity to production.

    NCPDP Comments

    1. NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 - Update adoption level to 5.
    2. NCPDP SCRIPT Standard, Implementation Guide, Version 2019071 - This version has been published and available by trading partner agreement. Currently 2017071 is required by Medicare Part D and ONC certification.

    IHE - Mobile Access to Health Documents

    The IHE Mobile Access to Health Documents (MHD) includes support for PUSH based exchanges. This functionality is very similar to XDR, but uses FHIR. 

    see IHE publication -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#:~:text=the%20three%20models.-,3.1%20Push,-3.1.1%20Cross-Enterprise

    The MHD Profile provides a point-to-point method of sending documents to a specific recipient. It leverages common principles described in Section 2. It sends documents and metadata using FHIR Rest push to deliver one or more documents to a Document Recipient.

    The typical use case for MHD in this mode is when documents are known to be needed by a recipient. Such as a patient referral in the use case given in XDR.

    In addition the MHD can be used as an push API to a system that ultimately delivers the content. For example diagrammed below is MHD initiating a push to an Intermediary. In this use case the MHD push request could be handled by the intermediary that further pushes the content using XDR or an e-mail carrying XDM (e.g., the Direct Project). On the recipient side (not shown in the diagram) the MHD could be used by an intermediary to forward a XDR or XDM push content. MHD (not shown in the diagram) could also be used on the recipient side as a query/retrieve where the intermediary has cached content addressed to that recipient. This Intermediary is an example of a Direct Project HISP with the added functionality provided by MHD, enabling FHIR based push with end-to-end interoperability between three different transport stacks in MHD, XDR, and e-mail XDM.

    An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Systems

    Comment

    NCPDP Comment

    NCPDP recommends that ONC add the following:

    Type- Implementation Specification

    Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

    Standards Process Maturity – Final

    Implementation Maturity- Pilot

    Adoption Level – 1

    Federally Required – No

    Cost – $

    Test Tool Availability – No

    NCPDP Comments

    1. NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 - Update adoption level to 5
    2. NCPDP SCRIPT Standard, Implementation Guide, Version 2019071 - This version has been published and available by trading partner agreement. Currently 2017071 is required by Medicare Part D and ONC certification.

    eHealth Exchange Specifications Comment

     

    Can the hyperlinks to the eHealth Exchange Specifications listed below be corrected to reference this corrected link (https://ehealthexchange.org/testing-program/technical-specifications/) because the current links are broken.  Also, the eHealth Exchange would like to request that the Adoption Level  level be increased 5 since the eHealth Exchange specifications used by network is very mature with 300+ gateways in production today exchanging data using these specifications since 2009 when it was an ONC project.  Also, the test tool availability should reference this link (https://wiki.ihe.net/index.php/IHE_Test_Tool_Information).  Please contact ddavis@sequoiaproject.org if you have any questions related to this request.  eHealth Exchange Specification: Document SubmissioneHealth Exchange Specification: Messaging Platform,  eHealth Exchange Specification: Authorization Framework

     

      NCPDP Comment

      1. Add the following:

      Type-Emerging Standard

      Standard Implementation/Specification- Specialty Transaction HL7® FHIR®

      Standards Process Maturity – Balloted Draft

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      1. Update the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

      Adoption Level – 2

      Add: Test Tool Link: https://tools.ncpdp.org/erx/#/home

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2019071

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 2

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      1. MedicationList is a new transaction available in NCPDP SCRIPT Standard, Implementation Guide, Version2019071

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – N/A

      Federally Required – No

      Cost – $

      Test Tool Availability – Yes

      Test Tool Link: https://tools.ncpdp.org/erx/#/home

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2019071

      Standards Process Maturity – Final

      Implementation Maturity- N/A

      Adoption Level – N/A

      Federally Required – No

      Cost – $

      Test Tool Availability – Yes

      Test Tool Link: https://tools.ncpdp.org/erx/#/home

      1. MedicationList is a new transaction available in NCPDP SCRIPT Standard, Implementation Guide, Version 2019071 for transmission of dispensed medication data from dispensing entities to an HIE or HIE-like entity.

      Use of Direct for System-to-System Communication

      There are many systems in the field today that have Direct-enabled endpoints in use to send or accept data for automated workflows at the system level. This model is most commonly used in care coordination, public health, and related applications. We see a lot of continued growth in the number of organizations joining Direct networks to take advantage of the system-to-system transmission enabled by Direct. Adoption Level of 1 understates this use and I encourage ONC to increase the stated Adoption Level to 2 or 3.  

      Julie Maas

      CEO, EMR Direct

      "Push” Exchange

      Medical Device Communication to Other Information Systems/Technologies

      Comment

      Section:III-A Push Communication of Vital Signs from Medical Dev

      HIMSS and PCHAlliance encourages the Need inclusion of medical device-related data sets, typically aligned with the IEEE 11073 nomenclature, which go beyond device identification attributes currently contained in the CCDE list to include vital signs measurements and other physiological data.

      HIMSS and PCHAlliance recommends ONC leads the joint efforts of advancing medical devices interoperability for patient-centered care. The key pieces such as human factors/usability engineering, service-oriented architecture design and implementation, communication testing and facilitator for integration that ONC could orchestrate with are listed as follows:

      •         HL7 has a work committee, Health Care Devices to coordinate and facilitate the integration of health care devices to ensure interoperability and harmonization of data within healthcare entities.

      •         IEEE 11073-20701, Standard for Service-Oriented Medical Device Exchange Architecture & Protocol Binding that defines the architecture for service-oriented distributed PoC medical devices and medical IT system.

      •         FDA has CDRH Human Factors team for Human Factors and Medical Devices

      •         NIST Medical Device Communication Testing – test tool update, joint IEEE/HL7 May WG meeting @ San Diego, CA

      Push Communication of Vital Signs from Medical Devices

      Comment

      Section III-A Push Communication of Vital Signs from Medical Dev

      Comments:

      1.For the 3rd Row (ITU H.810…), please change:

      •Standards Process Maturity to Final.

      •Implementation maturity to Production.

      •Adoption Level to 3 dots.

      •Test Tool Availability should be ‘Yes’

      •Add ‘H.812.5’ after ‘H.812’ within the series of standards to the ‘Standard Implementation/Specification

      All should be equivalent to the first row (for ISO/IEEE 11073) as the 11073 the base protocols of the ITU and Continua Design Guidelines (where the test tool exists and is freely available).

      2.There is no mention of IEEE 11073 Nomenclature. This nomenclature is recognized within the IHE/HL7 record-set. Please add a new row for this.

      ***Please note that several of the comments above were submitted last year but not implemented.*** 

      Remote Patient Monitoring to Support Chronic Condition Management, Patient Education and Patient Engagement

      Comment

      Remote patient monitoring

      Thank you for highlighting the significant benefits of remote patient monitoring in supporting chronic condition management, patient education, and patient empowerment. By leveraging technology to monitor patients' health remotely, healthcare providers can enhance the quality of care, increase patient engagement, and potentially reduce hospitalizations. Remote patient monitoring has the potential to revolutionize healthcare delivery and improve outcomes for individuals with chronic conditions.

      Section III-A Remote Patient Monitoring to Support Chronic Condi

      Related to prior comment, Continua, via the ITU, has also been approved for its test suites at the ITU. Test suites are freely available via both Continua and the ITU. These are the ITU's H.820. Link: https://www.itu.int/md/T13-IPTV.GSI-C-0229/en 

       

      Section III-A Remote Patient Monitoring to Support Chronic Condi

      Comments:

      1.For the 1st Row (ITU H.810…), please change:

      •Standards Process Maturity to Final.

      •Implementation maturity to Production.

      •Adoption Level to 3 dots.

      •Test Tool Availability should be ‘Yes’

      •Add ‘H.812.5’ after ‘H.812’ within the series of standards to the ‘Standard Implementation/Specification

      2.Add a second row for “Continua Design Guidelines by PCHAlliance and include the same as the fields for the ITU above.

       

      Representing Path Traversal Expressions

      Comment

      This specification is in wrong category

      FluentPath is a language describing where in a FHIR Resource data might be. This has nothing to do with Push Exchanges.

       

      see -- http://hl7.org/fhirpath/2016May/index.html

      Clinical Decision Support Services

      Immunization Decision Support Forecast

      Comment

      Providing Patient-Specific Assessments and Recommendations Based on Patient Data for Clinical Decision Support

      Comment

      NCPDP Comment

      1. NCPDP requests additional information on ONC’s intent. It is possible the Pharmacist eCare Plan v1.0 could be a useful tool to assist in patient assessment.

      Retrieval of Contextually Relevant, Patient-Specific Knowledge Resources from Within Clinical Information Systems to Answer Clinical Questions Raised by Patients in the Course of Care

      Comment

      I know of relatively few…

      I know of relatively few implementations of SOAP based messages, but rather a large number of the HTTP based requests.

      Consumer Access/Exchange of Health Information

      Collection and Exchange of Patient-Reported Outcomes

      Comment

      IHE - Mobile Access to Health Documents

      The IHE MHD implementation guide could be used to provide a method for patients to submit data with attribution. The data could be in the form of CDA, FHIR-Documents, or simply FHIR Bundles. 

      Patient Exchanging Secure Messages with Care Providers

      Comment

      Engage Patients with a Copy of Their Complete Health Data

      Direct addresses at the NIST Level of Assurance 3 level, used by DirectTrust participants, provide security and assurance to providers that the person on the other end of the exchange is who they say they are. The use of Direct addresses allows the consumer to effectively communicate with all their providers and payers, without any party being worried about inappropriate release of data or reputational harm. Provider EHRs are beginning to ask consumers to enter the consumer’s personal health record (PHR) address and indicate that the consumer wants any updates to their EHR record to be sent automatically to their PHR. Essentially all the PHRs on the market now accept C-CDAs from provider EHRs and many of them do so using Direct addresses. Because there are currently more than 1.5M Direct addresses including 50,000 consumer addresses, and more than 200M messages have already been exchanged, I would suggest at least two dots for Adoption. 

      FHIR could be used in the future to send data to PHRs but FHIR is not ready for this task now for the following reasons:
      1) there is too much optionality in current resource definitions (DirectTrust fully specifies the acceptable Direct message options)
      2) there is no provider or organization directory (there is with DirectTrust)
      3) there is no OAuth-based trust network (there is with DirectTrust)
      4) FHIR doesn't cover organizations without EHRs like skilled nursing facilities, longterm care, home health, public health (DirectTrust works for them)

      Patient Exchanging Secure Messages

      Patients and providers should be able to have two-way communication through email, Facetime or Skype, texting, photos, videos, and phone calls. New communication technology conduits should be readily adopted for such two-way communication, rather than requiring a regulation or legislation to allow people to communicate.

      The patient should be able to choose to communicate through a text or email with his or her provider and FaceTime where appropriate. Like in the legal world, providers may have a disclaimer regarding confidentiality and security.

      The patient’s own choice of privacy and security should supersede any institutional requirements. The patient should be able to opt in for deeper levels of security but should automatically be able to choose to share their fully integrated electronic file where they deem fit. The integrated file should be automatically available for emergency care.

      The current software allows for physician notes to be viewable to the patients themselves. Patients should have readily available access to these physician notes. In addition, patients’ ability to edit and provide comments to the physician notes would be an important link to their longitudinal care. Better yet, patient edited and co-produced notes with their providers may be optimal. Most importantly, the collective needs to allow for patient participation and communication two-way with the patient’s integrated EHR.

      Patients should have a “key”…

      Patients should have a “key” to be able to share ‘read-only’ access to an entire record for another provider and include a time out option.

      Patients should be able to choose the levels of privacy AND choose the levels of security.

      Patients should be able to communicate in a non-secured way and include a confidentiality disclaimer at the bottom of emails. This can be either a confidentiality disclaimer, or one that states the patient understands that privacy cannot be guaranteed; this goes on every email chain. The patient agrees that they will not hold the institution/provider accountable for it.

      If the patient chooses and asks for a non-secure, readily available text or email with the provider, the patient should be free to email and text and choose their own level of privacy. The patient will be responsible for it.

      The patient could also choose to use a secure, portal email as well.

      Provider notes and/or synthesis of care should include a two-way update with the ability to go back and forth on comments/edits to patient notes.

      AMA comments on the 2018 ISA

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

      Comment:

      The AMA requests the Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) be added to the standards listed for Patient Exchanging Secure Messages with Care Providers. The CFD code set was developed in 2010 in response to industry demand for a patient-focused version of CPT that is comprehensive and useful. The CFDs take the complex terminology of medical procedures and services within CPT and translates it into a language that patients and caregivers can better understand and use. An example is CPT code “Arthrodesis, great toe; metatarsophalangeal joint,” which translates to the CFD “Fusion of great toe.” The CFDs have been included in the Centers for Medicare & Medicaid Services’ (CMS) guidance to Medicare Administrative Contractors (MACs) for adding new CPT codes. One specific example is CMS Transmittal 3670 on the addition of CPT codes to report physical and occupational therapy evaluations.

      Advancing Patient Communication

      Given the prevalence of Direct among providers today, and the fact that many Health IT vendors certified for 2014 Edition e.3 (Secure Messaging) using Direct, I would recommend at least two dots for the adoption level of patient message exchange via Direct. To improve the efficiency of providing care through the use of this secure electronic communication method, I encourage the following: 1) patients should be able to register/link their patient Direct address in EMRs during in-person visits so that providers can have confidence in the identity of an address during correspondence, 2) encouraging providers to make a suitable Direct address, at least that of their office as a fax replacement, available to patients in a public Direct Directory and via other public sources such as their website rather than being "unlisted", and 3) usability and other enhancements to the user interfaces within EMRs so that secure messages from patients and other providers can be answered and managed, just like email is used today for efficient correspondence in all other business sectors of the US economy, without requiring a specific attachment type or other attachment type such as a CCDA. 

      Empower patients with secure, portable, usable transport of PHI

           As a consumer and sometime patient interested in electronic exchange since discussion of the first RHIO in my state, I am pleased to find this new section of the ISA out for public comment. The efficiency of such exchange with my providers is beyond question. What's needed, though, is: a) authoritative assurance that privacy and security of my personal health information are designed into software protocols that are readily and easily usable by me *and* my providers; b) portability of my identity so multiple providers will accept my information and/or requests for information without a different process, log-ins with different passwords, etc. with each provider; and c) protection against miss-use or sale of my personal health information by any party in the chain of technology that links me to my providers.

           As a volunteer member of DirectTrust, Co-Chair for several years of its Patient and Consumer Participation in Direct Work Group, and consumer member of its Board of Directors, I am persuaded that the Direct Protocol for health information exchange, as elaborated in DirectTrust's policies and expectations, serves these needs.

           If I had a Direct address that I could use for all my providers, this would be a huge leap for consumer/patient empowerment for access to and use of their personal health information. While some allege that FHIR accomplishes this, the fact is that FHIR is not a health information exchange standard; it is a patient access standard applicable for limited use cases. So, for example, I cannot use FHIR to transmit my records directly from an existing patient portal to a new physician. Let me urge that the final draft of the ISA incorporate standards that the entire HIT community AND consumer/patients can use TODAY. These include the Direct Standard for transport and CCDA and FHIR for content.

      Feedback on use of Direct Standard

      As President and CEO of DirectTrust and speaking on behalf of our large membership and community interested in patient participation in Direct exchange with their Providers and others of their choice, my feedback would be that the adoption level is growing rapidly, as patients and consumers obtain Direct addresses for personal applications, such as PHRs, and also as third parties work with patients to obtain their permission to receive and use their health information via Direct exchange.  Patients' HIPAA rights enable them to designate an electronic end point via Direct to which their health information in electronic format, for example the C-CDA formatted CCD, must be sent by the health care provider or their organization.  Patient portals are becoming capable of asking patients to designate a Direct address for such transmission, which does not require any additional permissions or filling out of forms by the patient with the portal account.  This methodology is attracting a wide stakeholder audience, as researchers, referral specialists, application providers, and many others recognize the ease and ubiquity of Direct exchange for secure and interoperable health information exchange initiated by patients and consumers.  I would suggest at least 2 dots in the Adoption Level column of this ISA table.  Thank you, David C. Kibbe

      Push Patient-Generated Health Data into Integrated EHR

      Comment

      IHE - Mobile Access to Health Documents

      The MHD implementation guide could enable patient managed applications to submit medical information to their clinician. The MHD implementation guide provides methods of expressing the medical data (document), the Provenance of that document (metadata), and the reason for submitting (submission Set).

      ​​​​​​​Data provenance - Identify patient data over time

      As patient supplied data is integrated within a record its origin needs to be considered. Data provenance is an important  factor within this workflow, as commented earlier data provenance needs to be refined and supported with specific guidance.

      Push Patient-Generated Health Data into Integrated EHR

      We live in a mobile and global world. Our health data need to reflect our mobile, instant, connected world. It is our right as patients to access and own the results of our medical care instantaneously for our own longitudinal record, and shared with whomever we please. We as patients should own our health information and digital results of our care free of charge. We already paid for them by paying for the medical service through our insurance premiums, copays, deductibles, and taxes.

      We should be allowing for the design of the future rather than addressing the dysfunction of today. In doing so, this will empower the consumer to control their own health information so they can make better choices about their health.

      This EHR should be readily available by the patient and secured by the patient’s choice of password combined with third party verification, biometric or facial recognition, or the state-of-the-art technology as used in other sectors.

      Providers and their software vendors need to allow for open technology development, leveraging existing state-of-the-art security and patient safety measures like thumbprint, voice, or facial recognition and device verification. The electronic medical record should be transactional, mobile, and secure like mobile banking is in the financial industry. A patient-centered longitudinal record gives the patients the choice of when, how, with whom, and to what extent their own medical records can be shared.

      The patient receipt of their own health care record should be automatic. We need to eliminate the requirement for the patient to ask for copies of their information and copies of their films. A copy or photo of an image or film should be automatically provided to the patient. The patient should not have to go to a separate location in the hospital, fill out a separate form, and then wait up to 30 days to receive their information. Those 3 things collectively inhibit timely and quality care. We can achieve timely and the best of quality care if we provide the patient with immediate access to his or her own patient-owned integrated EHR.

      We need our electronic health record to follow us so we are free to receive care wherever we choose. Through cooperation and non-discrimination, we can have one, single, mobile, longitudinal record.

      Multiple, separate portals from each provider, difficult to access, each acting as an island unto itself, is a broken way for a physician to provide optimal health care. It is onerous, expensive, and redundant. It is broken. It does not work.

      Patients need ownership rights to their own health information and data, and ability to have an aggregated, integrated, longitudinal, patient-owned electronic health record. That EHR should be readily available to them through their mobile devices. Hospitals/providers should have open API’s, and images, films, EKG’s, CT’s, MRI’s, radiology, open notes regarding discharge and care should be readily accessible in a shared, open architecture for other institutions on behalf of the patient. The EHR should also have available linkage to the patient’s pharmacy for populating a history of prescription fills.

      We can greatly improve the quality of health care and provide timely, life saving measures to patients in emergent care with informed physicians and patients, family and caregivers alike. We can substantially reduce costs of health care by eliminating redundancies in providing care across institutions. This common sense approach can, in fact, be readily done with today’s technology, as evidenced in almost every industry other than health care.

      Digital copies of new tests and electronic files should be available immediately in the patient’s own designated banked account. As lab results, physician notes, and tests become electronically available to the physician and provider/facility, a copy should instantaneously be populated into the patient’s own, integrated and aggregated, patient-owned, “banked” EHR.

      The patient’s integrated EHR should be transactionally populated, much like the financial community, where each digital transaction is shown in the patient’s “banked account.” It should be integrated and aggregated through the patient’s applications of choice, much like Mint or Quicken aggregate financial transactions. Wherever the patient receives care, the patient receives that information into the patient’s “banked account.” Categories such as labs can be dated and aggregated, and trends and results can then easily be charted by the patient and the patient’s care providers.

      For example, as a test result or x-ray is read and becomes digitally available to the institution, the patient should be able to have the results and findings reported electronically to their own application and site of choice. Eventually, in addition to lab reports and radiology reads, relevant photos and images should be included in the patient-owned and integrated EHR.

      Near term, providers and patients alike (especially emergency departments) need readily available, shared access to existing images produced for patients. Imaging sharing should be open such that any institution could pull up an image no matter where it is, and that access should be provided across institutions for the patient.

      We should eliminate the need for the patient to fill out a form to get access to their information. It should be instantaneously populated, versus up to 30 days. Thirty days is not an acceptable time frame. Those 30 days greatly diminish the quality of care.

      Patients should be able to secure what they want to keep private, and readily share what they choose to share with other providers, physicians, family members, caregivers. Patients should be able to determine the level of privacy and to whom they want to share their own integrated EHR. Patients should be able to choose to “time out” that sharing, similar to a feature of the Find My Friends and Life360 apps.

      Innovation needs to allow for compatibility of our health records with all technology vendors, and for the ability to analyze, aggregate, and readily share health data.

      The standard needs to be that the electronic record is provided instantaneously, mobile, portable, compatible with all applications in the repository of our choice, and allowing for state-of-the-art and future technologies.

      We need a transparent patient-centered record with full visibility into all our health records – labs, radiology, prescription fills, and care plans – to ensure the best, timely, informed, and efficient care.

      Likewise, we need transparency into the quality, performance, and cost of care. With access to these metrics, we can shop for physicians and medical services at a competitive marketplace, not be restricted to certain providers, and hold both patients and providers accountable for performance.

      The patient needs to know per drug administered the cost to the patient, itemized by the care facility. For instance the cost of Zantac administered from an ER versus the acceptable range of costs versus over the counter. The billing system of the hospital needs to be aligned with the patient’s instantaneous care as it’s populated, so that the patient has full transparency into the costs being charged for services rendered. Additionally, when a procedure like an MRI can be done electively, the cost of that MRI other than under emergent care where available, should be provided, and the price range of cost for the patient choice. Any out-of-network cost should be revealed to the patient upfront.

      Cost data should be aligned with the EHR and be visible to the patient and physician. Physicians and patients alike are blind as to the ultimate cost of procedures. They are blind to what is “in network” and “out of network.” The “out of network charges are additional charges that occur unknowingly to patients and can be gamed by providers. To ultimately give the patient freedom of knowledge and choice, we need to strive for a near-term goal of attaching the cost to the insurer and the cost to the patient as it is aligned with the care provided for the patient, real time to the doctor and to the patient when available.

      With data driven choice, we can utilize sites similar to Yelp, Amazon, and OpenTable to shop, assess quality, and book our care globally. When aggregated health data is readily available for comparative quality, cost, research, and analysis, the cost of care lowers and the quality improves.

      The Hippocratic oath is to “do no harm.” Today’s EHR software companies and providers are causing harm to the patient by using protectionism and misusing HIPAA, blocking the patient from this readily available, integrated, longitudinal record of his/her health. Let’s get it done. The technology is all here. It is being used cost effectively in almost every other industry. It would drastically change the economics of health care for the better and greatly improve the quality of care to patients, as well as the quality of the jobs of our health professionals. Let’s do the right thing and make a systemic commitment to enable the complete, integrated EHR and empower the patient and give the patient freedom of choice.

      Provide patients ownership…

      Provide patients ownership of their health information. In doing so, this will empower the consumer to control their own health information so they can make better choices about their health. Instantaneous population of medical information (labs, films, test results, etc) into the patient portal/health vault. If the patient chooses to have their portal pushed to their own mobile phone health repository, the provider should allow for the push and for the patient to be responsible for the security. It should allow for two-way communication through email. The patient should not have to ask the institution for a copy of the records. The records should be automatically PUSHED. For example, as soon as an x-ray is available to the provider, at least a photo or pertinent information is populated into the patient’s portal and/or mobile application of choice.

      We need an open API to allow for eventual aggregators like Mint, or Quicken (which aggregate transactional data in the financial community) to do the same thing for patient EHRs.

      There should be ONE patient-owned EHR. The patient-owned EHR should not be a separate record from what the medical community has.

      AMA comments on the 2018 ISA

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

      Comment:

      The AMA requests the Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) be added to the standards listed for Push Patient-Generated Health Data into Integrated EHR. The CFD code set was developed in 2010 in response to industry demand for a patient-focused version of CPT that is comprehensive and useful. The CFDs take the complex terminology of medical procedures and services within CPT and translates it into a language that patients and caregivers can better understand and use. An example is CPT code “Arthrodesis, great toe; metatarsophalangeal joint,” which translates to the CFD “Fusion of great toe.” The CFDs have been included in the Centers for Medicare & Medicaid Services’ (CMS) guidance to Medicare Administrative Contractors (MACs) for adding new CPT codes. One specific example is CMS Transmittal 3670 on the addition of CPT codes to report physical and occupational therapy evaluations.

      Remote Patient Authorization and Submission of EHR Data for Research

      Comment

      IHE Advanced Patient Privacy Consent

      The IHE Advanced Patient Privacy Consent (APPC) is a Trial-Implementation companion to the normative BPPC profile. The APPC profile is used when additions or deviations from a "Basic" consent policy are needed. The APPC mechanism provides for deeper coded consents beyond what BPPC supports. BPPC continues to be used to capture the ceremony and overall policy, where APPC provides the specific additions or deviations.

      see the IHE publication https://profiles.ihe.net/ITI/TF/Volume1/ch-43.html

      IHE Basic Patient Privacy Consent

      The IHE Basic Patient Privacy Consent (BPPC) provides a means for recording the ceremony of patient consenting to a policy. The BPPC profile is normative and widely used to record consent in cross-enterprise settings, such as HIE or research. The BPPC profile includes support for gross coded consent, enabling basic consents to be supported.

      The IHE normative specification -- https://profiles.ihe.net/ITI/TF/Volume1/ch-19.html

      19 Basic Patient Privacy Consents (BPPC)

      The document sharing infrastructure provided by XD* allow for the publication and use of clinical documents associated with a patient. This profile allows for a Patient Privacy Policy Domain (e.g., an XDS Affinity Domain to have a number of Patient Privacy Policies that can be acknowledged (aka consent). This allows for more flexibility to support some patient concerns, while providing an important and useful dataset to the healthcare provider. Without BPPC, the XDS Profile requires that the administrators of an XDS Affinity Domain creates and agrees to a single document publication and use policy (see ITI TF-1: Appendix L ). Such a single XDS Affinity Domain Policy is enforced in a distributed way through the inherent access controls of the systems involved in the XDS Affinity Domain.

      This profile will use terms consistent with ISO 22600 - Privilege Management and Access Control (PMAC), but is not restricted to systems that implement PMAC. This profile uses the term “Patient” to refer to the human-subject of health-related data. In this context “Patient” is not to imply only those subjects under current treatment, this is sometimes referred to as “consumer”. This profile uses the term “Consent” to mean acknowledgement of a privacy policy, also known as an information access policy. In this context the privacy policy may include constraints and obligations. The systems involved in XDS are expected to support sufficient Access Controls to carry out the Policy of the XDS Affinity Domain.

      See the IHE white paper Enabling Document Sharing Health Information Exchange Using IHE Profiles published on the IHE web site.

      ...

      Trusted Dynamic Client Registration

      With regards to system authentication for this use case, UDAP Dynamic Client Registration provides an extension to RFC 7591 to better scale the use of FHIR client apps. This profile has seen interest from numerous industry stakeholders as an alternative to re-registering apps at every different datasource and as a way to enable sharing of information about apps among datasources. Trusted Dynamic Client Registration provides a path for verification of attributes for apps holding valid digital certificates and the communication of these attributes (e.g. privacy policy) to the end user, increasing confidence in valid FHIR clients within the ecosystem and facilitating the connection of research study apps to clinical FHIR servers without manual preregistration.

      UDAP is an open collaborative developing profiles to increase confidence in Open API ecosystems. This profile is in draft status and is in pilot stage. UDAP DCR has been tested at several HL7 FHIR connectathons and has received positive feedback from multiple stakeholders, including national health information networks, EHR vendors, and app developers.

      Remote Patient Authorization and Submission of EHR Data for Rese

      Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others.

      Patient information should not automatically be used for research or brokered even if it is “anonymized.” Patients should have the choice to opt in to any broad or specific medical research, and the institution should not be able to broker the patient’s data without the patient having full transparency and the choice to opt in to having their information brokered and shared. Patients should be remunerated for the per-patient access to such information if the researcher and the institution are being compensated for delivery of such information.

      The patient should be fully informed of wherever the institution sends the patient data, even if they claim it is anonymized. The patient should also be informed of the transactional brokerage of their health data and the extent to which it is forwarded to pharmaceutical companies and their subsidiaries or contracted firms, anonymized or not.

      If the institution is being paid for those data, the patient should have full transparency into payments the provider or researcher received for his or her medical record. Remunerations should be made to the patient for the use of such data.

      Patients should own their…

      Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others. The patient should have an upfront choice to opt in or opt out. They should be able to opt out of their data being shared for research without their knowledge, even if it is supposedly “anonymized”.

      Patients should be informed of the transactional brokerage of their health data and the extent at which it is forwarded to pharmaceutical companies, PBM’s, advertising firms, or organizations that re-broker the selling of patient data, anonymized or not (from insurance companies, hospitals, and providers).

      Patients can make choices about with whom and when to share their information.

       

      Patients should own their…

      Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others. The patient should have an upfront choice to opt in or opt out. They should be able to opt out of their data being shared for research without their knowledge, even if it is supposedly “anonymized”.

      Patients should be informed of the transactional brokerage of their health data and the extent at which it is forwarded to pharmaceutical companies, PBM’s, advertising firms, or organizations that re-broker the selling of patient data, anonymized or not (from insurance companies, hospitals, and providers).

      Patients can make choices about with whom and when to share their information.

      AMA comments on the 2018 ISA

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

      Comment:

      The AMA requests the Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) be added to the standards listed for Remote Patient Authorization and Submission of EHR Data for Research. The CFD code set was developed in 2010 in response to industry demand for a patient-focused version of CPT that is comprehensive and useful. The CFDs take the complex terminology of medical procedures and services within CPT and translates it into a language that patients and caregivers can better understand and use. An example is CPT code “Arthrodesis, great toe; metatarsophalangeal joint,” which translates to the CFD “Fusion of great toe.” The CFDs have been included in the Centers for Medicare & Medicaid Services’ (CMS) guidance to Medicare Administrative Contractors (MACs) for adding new CPT codes. One specific example is CMS Transmittal 3670 on the addition of CPT codes to report physical and occupational therapy evaluations.

      Add Kantara UMA as a patient-designated HIE Standard

      As Chief Technology Officer of Patient Privacy Rights Foundation, I strongly endorse the addition of Kantara Initiative User Managed Access (UMA) to the API standards for patient directed exchange. UMA should apply equally to both research and clinical APIs so I suggest we remove the “for Research” and make the title “Remote Patient Authorization and Submission of EHR Data”.

      The healthcare application of the UMA standard has been profiled by the HEAlth Relationship Trust (HEART) workgroup http://openid.net/wg/heart/ and this work should be recognized in the ISA.

      The work of the 2016 API Task Force should also be recognized for its contribution to patient-directed exchange. In particular, that Task Force elucidated the patient’s absolute right to designate a destination for transmission via a FHIR API without any blocking on the basis of “trust” by the API operator. Per the Task Force, the FHIR API operator can warn the patient directing exchange that a destination is “untrusted” but it cannot cannot block the patient from using it if they insist. Per the API Task Force, information blocking on the FHIR API would only be allowed for destinations that would endanger the institution’s security or other patients such as through a denial-of-service attack.

      The 21st Century Cures Act provision for API access “without special effort” should be referenced and discussed in the ISA. One way to enable patients to provide access to the FHIR API “without special effort” is to allow the patient to specify their UMA Authorization Server via the institution’s Patient Portal. This would be equivalent to a patient using the portal to opt-in to a health information exchange (HIE) of their choice. Once the patient has done this, their choice should be honored for the next year or until the patient signs into the portal and revokes the HIE designation. There’s no need for the patient to sign-in to the portal for every data access by the designated HIE. There are major benefits of portal control of the HIE to the patient and to interoperability. The patient can point various service providers to the same HIE regardless of whether a particular provider “trusts” a particular HIE. An HIE can then serve a patient’s providers wherever or whoever they are including mental health services, long-term care, research, patient communities, or international facilities. For their part, the HIEs will have to compete on the basis of their privacy policies for the patient’s trust and will not need to worry that their access would be blocked by some FHIR API operators.

      Another patient benefit would be a more uniform user experience across different service providers. Patients already need to get credentials to the provider’s patient portal for View, Download, and Transmit. Adding the ability to designate their HIE to the VDT patient portal would avoid introducing a new set of credentials and a new user experience. This would promote health information exchange and help to create longitudinal health records.

      Patient identity matching is also enabled by allowing the patient to designate their HIE via the patient portal. That HIE designation would be verified by the HIE the same familiar way a service provider verifies an email address today. This voluntary association between the patient identity and the patient’s HIE preserves the privacy of the patient and allows matching across a full range of services including mental health because the patient’s consent is conveniently factored in.

      View, Download and Transmit Data from EHR

      Comment

      This work has now been…

      This work has now been jointly published by UDAP.org and HL7. The Security for Scalable Registration, Authentication, and Authorization (UDAP Security - http://hl7.org/fhir/us/udap-security/) Consumer-Facing workflow and Tiered OAuth for User Authentication (the latter for reusable patient credentials) are therefore recommended for use in this type of exchange; it is an Emerging Implementation Specification for securely scaling FHIR transactions by validating trusted ecosystem participants and efficiently managing patient identities. 

      IHE - Query for Existing Data for mobile

      The IHE Query for Existing Data for mobile (QEDm) implementation guide is in Trial-Implementation status. This implementation guide provides for a simple query for a subset of clinical FHIR Resources. This subset is consistent with USCDI.

      IHE publication -- https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_QEDm.pdf

      The Query for Existing Data for Mobile Profile (QEDm) supports dynamic queries for clinical data elements, including observations, allergy and intolerances, problems, diagnostic results, medications, immunizations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises to support provision of better clinical care. It defines a transaction used to query a list of specific data elements, persisted as FHIR resources

      IHE - Mobile Access to Health Documents

      The IHE Mobile Access to Health Documents (MHD) provides a simple API for document discovery and download. This API may be used in many settings including by Patient managed applications.

      See -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html

      View, Download, and Transmit Data from EHR

      Much like the financial community, patients should be able to download their medical data. If any provider or the patient himself wants to view the integrated lab tests and look at a five or ten year horizon, he/she should be able to readily download the data and compare and contrast changes. They should stored in machine-readable form to allow for data analytics by care providers, caregivers, patients, and for research (where the patient has chosen to opt in).

      HHS should seek to remove blockage and process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy. See our comments above regarding instantaneous population to the digital record and eliminating signing a form for access and waiting 30 days.

      Patients should be able to view their complete patient record, including pricing, tests, films, lab results, and health care provider notes. The EHR should provide affiliated charges and pricing. Price and cost transparency, outside of emergency situations, should be provided upfront to the patient prior to rendering services. As patients access the EHR, they should access the range of pricing from the institution compared to other comparable price ranges for a similar procedure elsewhere.

      Health care providers should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have a two-way ability to communicate via email, phone, and text with each other regarding patient care.

      We support the OpenNotes movement for physician notes to be provided attached to the patient EHR and two-way communication to be allowed for patient engagement.

      Remove process burdens on…

      Remove process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy.

      Patients should have instantaneous population of care into their medical record

      Patients should have a “key” to be able to share ‘read-only’ access to an entire record for another provider and include a time out option.

      Allow patients to view the complete patient record, including pricing, tests, films, lab results, and health care provider notes. Enable patients to comment on their review of such services. Provide affiliated charges and pricing. Price and cost transparency should occur before patients get care and should be presented electronically. As patients access the EHR, they should access the range of pricing from the institution.

      The health care provider should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have the ability to email notes and orders to each other to communicate regarding patient care.

      Technology can support automatic data transfer to patients and better security protection. This will allow patients to be sure their health care providers have the information they need to provide high quality treatment while allowing patients and caregivers to manage their acute and chronic conditions at home.

      AMA comments on the 2018 ISA

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

      Comment:

      The AMA requests the Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) be added to the standards listed for View, Download, and Transmit Data from EHR. The CFD code set was developed in 2010 in response to industry demand for a patient-focused version of CPT that is comprehensive and useful. The CFDs take the complex terminology of medical procedures and services within CPT and translates it into a language that patients and caregivers can better understand and use. An example is CPT code “Arthrodesis, great toe; metatarsophalangeal joint,” which translates to the CFD “Fusion of great toe.” The CFDs have been included in the Centers for Medicare & Medicaid Services’ (CMS) guidance to Medicare Administrative Contractors (MACs) for adding new CPT codes. One specific example is CMS Transmittal 3670 on the addition of CPT codes to report physical and occupational therapy evaluations.

      How about just simple e-mail…

      How about just simple e-mail?  SMPT, POP3, et cetera.  I'm NOT a covered entity, and would like this to remain simple.

      Remove "trust" barriers to patient-directed interoperability

      As Chief Technology Officer of Patient Privacy Rights Foundation, I urge the removal of trust barriers to patient-directed interoperability via Direct or FHIR API. This will enable information to flow without special effort and help patients assemble a longitudinal health record accessible to all of his / her real-world caregivers.

      The work of the 2016 API Task Force should also be recognized for its contribution to patient-directed exchange. In particular, that Task Force elucidated the patient’s absolute right to designate a destination for transmission via a FHIR API without any blocking on the basis of “trust” by the API operator. Per the Task Force, the FHIR API operator can warn the patient directing exchange that a destination is “untrusted” but it cannot cannot block the patient from using it if they insist. Per the API Task Force, information blocking on the FHIR API would only be allowed for destinations that would endanger the institution’s security or other patients such as through a denial-of-service attack.

      I strongly endorse the addition of Kantara Initiative User Managed Access (UMA) to the API standards for patient directed exchange. UMA should apply equally to both research and clinical APIs so I suggest we remove the “for Research” and make the title “Remote Patient Authorization and Submission of EHR Data”.

      The healthcare application of the UMA standard has been profiled by the HEAlth Relationship Trust (HEART) workgroup http://openid.net/wg/heart/ and this work should be recognized in the ISA.

      The 21st Century Cures Act provision for API access “without special effort” should be referenced and discussed in the ISA. One way to enable patients to provide access to the FHIR API “without special effort” is to allow the patient to specify their UMA Authorization Server via the institution’s Patient Portal. This would be equivalent to a patient using the portal to opt-in to a health information exchange (HIE) of their choice. Once the patient has done this, their choice should be honored for the next year or until the patient signs into the portal and revokes the HIE designation. There’s no need for the patient to sign-in to the portal for every data access by the designated HIE. There are major benefits of portal control of the HIE to the patient and to interoperability. The patient can point various service providers to the same HIE regardless of whether a particular provider “trusts” a particular HIE. An HIE can then serve a patient’s providers wherever or whoever they are including mental health services, long-term care, research, patient communities, or international facilities. For their part, the HIEs will have to compete on the basis of their privacy policies for the patient’s trust and will not need to worry that their access would be blocked by some FHIR API operators.

      Another patient benefit would be a more uniform user experience across different service providers. Patients already need to get credentials to the provider’s patient portal for View, Download, and Transmit. Adding the ability to designate their HIE to the VDT patient portal would avoid introducing a new set of credentials and a new user experience. This would promote health information exchange and help to create longitudinal health records.

      Patient identity matching is also enabled by allowing the patient to designate their HIE via the patient portal. That HIE designation would be verified by the HIE the same familiar way a service provider verifies an email address today. This voluntary association between the patient identity and the patient’s HIE preserves the privacy of the patient and allows matching across a full range of services including mental health because the patient’s consent is conveniently factored in.

      Direct adoption level for VDT

      Since transmit via Direct is required functionality under the 2014 Edition Certification criteria, then the adoption level should be at least that of 2014 Edition certified EHRs (4 or 5).

      Julie Maas

      CEO, EMR Direct

      Feedback on Adoption Level of Direct

      As President and CEO of DirectTrust and speaking on behalf of our large membership and community interested in patient participation in Direct exchange with their Providers and others of their choice, my feedback would be that the adoption level is growing rapidly, as patients and consumers obtain Direct addresses for personal applications, such as PHRs, and also as third parties work with patients to obtain their permission to receive and use their health information via Direct exchange.  Patients' HIPAA rights enable them to designate an electronic end point via Direct to which their health information in electronic format, for example the C-CDA formatted CCD, must be sent by the health care provider or their organization.  Patient portals are becoming capable of asking patients to designate a Direct address for such transmission, which does not require any additional permissions or filling out of forms by the patient with the portal account.  This methodology is attracting a wide stakeholder audience, as researchers, referral specialists, application providers, and many others recognize the ease and ubiquity of Direct exchange for secure and interoperable health information exchange initiated by patients and consumers.  I would suggest at least 2 dots in the Adoption Level column of this ISA table.  Thank you, David C. Kibbe

      Healthcare Directory, Provider Directory

      Listing of Providers for Access by Potential Exchange Partners

      Comment

      IHE - mCSD whitepaper

      IHE has published a whitepaper covering some use-case analysis and recommendations on how to use mCSD for those use-cases.

      https://profiles.ihe.net/ITI/papers/mCSD/index.html

      NCPDP Comment

      1. NCPDP Formulary and Benefit Standard Version 53 supports the provision of pharmacy network information (in/out) and maximum day supply allowed at the pharmacy.  This information is supplied by payers/PBMs and made available to prescribers via their EHR.

      HPD should be reconsidered as mandated

      “Healthcare Provider Directory (HPD), Trial Implementation was proposed, but not adopted for CEHRT 2015. The Health IT community has recognized the value of the underlying data elements and structure of that standard.”

      • That was unfortunate, HPD should be reconsidered as mandated to insure adoption.

      IHE profile in progress

      Just an FYI that there is a IHE profile development process happening now for provider and facility directories via the "Mobile Care Services Discovery (mCSD)".  It will leverage FHIR STU3:
        https://groups.google.com/forum/#!topic/ititech/qPz-ok3AHuk
      It is tracking the Argonaut work, as well as intended to include the functionality in the IHE CSD and HPD profiles. 

      Volume 1 is being worked on/finalized now.

      Cheers,
      -carl

      Thank you for this helpful…

      Thank you for this helpful information. We'll continue to monitor progress on this work and assess it's readiness for inclusion into the table above as it reaches trial implementation status within IHE.  

      Image Exchange

      Exchanging Images Outside a Specific Health Information Exchange Domain

      Comment

      Exchanging Imaging Documents Outside a Specific HIE Domain

      Exchanging Imaging Documents Outside a Specific Health Information Exchange Domain

      Recommend addition of IHE PDI (Portable Data for Imaging) with an adoption of 5. Add a corresponding note to acknowledge that network transfers are clearly preferable to digital media, but when network solutions are not yet in place, transfer using digital media is preferable to no transfer at all.  PDI does work and is successfully used widely.

      https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf

      Exchanging Imaging Documents Outside a Specific HIE Domain_ODonnell_DICOM.docx

      Suggestions for Section III

      Section III: Standards and Implementation Specifications for Services/Transport/Exchange

      Recommendations:

      1. Change the title of the first block to be:  Interoperability Need: Exchanging Images Outside of a Specific Health Information Exchange Domain
      2. For this block, the standard is DICOM (not DICOMweb – DICOMweb is an implementation within the DICOM standard, and the XCA-I implementation does not rely on DICOMweb).
      3. For now I would leave the next two rows (IHE XCA-I and IHE-XCPD/IHE-PIX) the same. But I think we will want to revisit this and consider if/how WIA fits for exchange outside of a HIE.
      4. Change the title of the second block to be:  Interoperability Need: Exchanging Images Within a Specific Health Information Exchange Domain

      Given the way the document is structured, the “Implementation Specification” rows should reference the implementation documentation that utilizes the “Standard” defined in the first row. So once again, the “Standard” is DICOM.

      If a Health Information Exchange is built on a VNA, or dedicated PACS acting as a VNA, then DICOM or DICOMweb provides the standard, and we can reference Part 4, or Part 18 for the Implementation Specification.  

      Recommendations for Section III_DICOM.docx

      Uptake of XCA-I (and XDS-I) profile

      The XCA-I and XDS-I profiles are both beyond the pilot phase and have been generally adopted by the diagnostic imaging industry. Both profiles are in "production" globally.

      Using the Direct Protocol for Image Exchange

      As a member of the Direct Project Workgroup, I would like to highlight work in progress to make the Direct Protocol feasible for image exchange and DICOM study exchange.  The workgroup is testing the concept of message fragmentation (defined in RFC2046 section 5.2.2).  This technique when combined with the Trust, Encryption, and Delivery notification standards of the Direct Protocol create an opportunity to eliminate the SMTP limit of 10 MB for message size and also eliminate the need for expensive persistent connections between parties.  With Direct, any party with a Direct Address can immediately inter-operate with any other party with a Direct Address.  This cost reduction should lead to more widespread Image Exchange.

      Bruce Schreiber

      CTO MaxMD

      Exchanging Images Within a Specific Health Information Exchange Domain

      Comment

      IHE - Document Sharing

      As indicated XDS-I provides the link to the Imaging world from a Document Sharing exchange. The Document Sharing exchange is not sufficiently described in the section. I recommend that Document Sharing exchange be more comprehensively expressed thru use of the IHE Whitepaper on Health Information Exchange. Thus removing mentions of PIX and PDQ as these are just a fragment of needed infrastructure that also includes Security, Privacy, Discovery, Retrieve, and management.

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#

       

      Comments_Exchanging Imaging…

      Comments_Exchanging Imaging Documents Within an HIE Domain_DICOM

       

      There are IHE Connectathon testing results for Web-based Image Capture (which uses STOW-RS)

      (See image in uploaded document)

      and Web-based Image Access (which uses QIDO-RS and WADO-RS).

      (See image in uploaded document)

      So for DICOMweb, we suggest at least Medium if not High, definitely not Low.

      Examples with DICOMweb™  support

      Examples with DICOMweb™ support but not in Conformance statement

      This list is based on initial research and not complete as there are likely many more.

       

      Comments_Exchanging Imaging Documents Within an HIE Domain_DICOM.docx

      Exchanging Imaging Documents Within a Specific HIE Domain

      Exchanging Imaging Documents Within a Specific Health Information Exchange Domain

      Recommend XDS-I.b adoption be increased to 2?

      Recommend listing IHE WIA which profiles the use of DICOMweb

      Recommend DICOMweb adoption be increased to 3

      To survey implementations of RESTful DICOMweb services to store, query, retrieve, an internet search for the relevant service (STOW-RS, QIDO-RS, WADO-RS) and the phrase “DICOM Conformance Statement” will typically return links to specific products.  

      STOW-RS "dicom conformance statement"

      QIDO-RS "dicom conformance statement"

      WADO-RS "dicom conformance statement"

      To survey implementations of IHE profiles, a search at the IHE Connectathon Results database (connectathon-results.ihe.net) will return lists of vendors that have successfully tested either a product or a prototype product. An internet search for the profile acronym (WIA, MHD-I) and the phrase “integration statement” will often return links to specific products

       

      Exchanging Imaging Documents Within a Specific Health Information Exchange Domain_DICOM_ODonnell.docx

      Infrastructure

      Client Application Management

      Comment

      Exchanging Patient Identification Within and Between Communities

      Comment

      Add HL7 Interoperable Digital Identity & Patient Matching IG

      HL7's Interoperable Digital Identity & Patient Matching Implementation Guide is an Emerging Implementation Specification we recommend for inclusion in both the Patient Demographic Record Matching and Exchanging Patient Identification Within and Between Communities sections of the ISA due to its utility to both of these categories. -HL7 Interoperable Digital Identity & Patient Matching workgroup

      IHE - Patient Master Identity Registry (PMIR)

      The IHE Patient Master Identity Registry (PMIR) provides a collaborative community based system of cooperating patient identity sources maintaining a master identity for each patient. PMIR leverages the FHIR standard.

      see the whitepaper - https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#54-patient-master-identity-registry-pmir

      For example, a consumer system may query the PMIR registry to receive the shared master Patient Identity (aka. golden identity) based on their local identifiers or based on the identifying characteristics of the patient (demographics). In this way a PCP office can discover the master Patient Identity so that it can communicate with the systems in that community using a known patient identifier. This query uses Patient Identity Cross-referencing for Mobile (PIXm) or Patient Demographics Query for Mobile (PDQm).

      Patient identity source will feed create, update, or merge events to the PMIR registry, which will further propagate these changes to a set of patient identity consumers that have subscribed. Upon receiving a create, update, or merge event these subscribed consumers are expected to update their patient information accordingly. For example when a merge has been declared, the subscribed consumer will merge into the surviving identity any data that was known against the merged identity. This set of patient identity source keep the master identity accurate, using update when there are changes to the demographics.

      The PMIR, PDQm, and PIXm Profiles are used within the MHDS Profile to manage and find the patient’s identifier in that community as part of the Centralized Discovery and Retrieve environment.

      This is an introduction to the PMIR Profile use within MHDS. PMIR Profile includes other optional functions. Please reference the Profile for details in PMIR.

      IHE - Patient Identity management

      See the IHE whitepaper covering the many methods of managing Patient Identities.

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#5-patient-identity-management

       

      HL7 FHIR and the Patient/$match operation

      Since STU3, HL7 FHIR has included the Patient/$match operation which allows for patient matching using MPI-based logic. When such a FHIR operation is performed within a community, this is comparable in functionality to the IHE standards already referenced. This is being actively explored in multiple stakeholder groups (e.g FAST). For this reason, we recommend that HL7 FHIR be included as an implementation specification in this sub-section with the $match operation called out specifically in the limitations, dependencies, & preconditions area. The match operation replaced a similar MPI query available in DSTU2. 

       

       

      Julie Maas, CEO, EMR Direct

      Public Health Exchange

      Transport for Immunization Submission and Query/Response

      Comment

      AIRA Comments - Clarifying Relevance

      It’s unclear the relevance of the comment in left-most blue cell as it relates to the CDC WSDL used in immunization exchanges with widespread adoption. AIRA proposes it be further explained how IHE Document Sharing ties to the CDC WSDL or asks that it be removed.

      IHE - Document Sharing

      The IHE Document Sharing infrastructure is ready to support Public Health Exchanges. These are simply other PurposeOfUse that are technically supported, for which policy authorization is all that is necessary.

      see IHE publication - https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#

      See article I have authored - https://healthcaresecprivacy.blogspot.com/2020/03/public-health-is-purposeofuse-pubhlth.html

      The Public Health use would most likely be thru PUSH based interactions. The Document Sharing enables any kind of content including CDA and FHIR-Documents; but can also carry documents that don't meet the HL7 definition of document such as a FHIR Bundle of measures.

      Haven't heard this…

      Haven't heard this referenced OUTSIDE of the context of an ISA in the past four years.  SOAP? Really?

       

      Publish and Subscribe

      Publish and Subscribe Message Exchange

      Comment

      IHE - Document Sharing

      The IHE Document Sharing infrastructure is well suited for Publish and Subscribe.  See section 3.2.4 Notifications in the white paper on Document Shairng

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#:~:text=BPPC%20and%20others-,3.2.4%20Notifications,-The%20XDS%20Profile

      Query

      Data Element Based Query for Clinical Health Information

      Comment

      AIRA Comments on Bulk FHIR

      AIRA appreciates this thorough review of standards related to bulk FHIR; we are currently partnering with the Helios FHIR Accelerator project to explore use of bulk FHIR query for immunizations, so this is helpful as we work toward implementation.

      mXDE + QEDm = Provenance

      The combination of mXDE and QEDm provide for Provenance evidence between the FHIR Resources made available via QEDm and the documents from which that data was decomposed. In this way the client application using FHIR Resource data can ask for Provenance. For each Provenance record given there is a unique document that contained that information. Thus the client can know how many documents stated the medical information, and can navigate to those documents.

      see IHE whitepaper section https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#4-consuming-data-as-fhir-resources

      UDAP for Client App Registration, Authentication & Authorization

      Since FHIR transactions require the use of a FHIR client, client application registration and management is an integral component of query using FHIR. With regards to system authentication for this use case, UDAP Dynamic Client Registration provides an extension to RFC 7591 to better scale the registration and use of FHIR client apps. This profile has seen interest from numerous industry stakeholders as an alternative to manually re-registering apps at every different datasource and as a way to enable sharing of information about apps among datasources. Trusted Dynamic Client Registration provides a path for verification of attributes for apps holding valid digital certificates and the communication of these attributes (e.g. privacy policy) to the end user, increasing confidence in valid FHIR clients within the ecosystem and facilitating the connection of apps to clinical FHIR servers without manual pre-registration. This can be used together with UDAP JWT-based Client Authentication to support reusable client identity for authentication and authorization, to help scale the use of client credentials or authorization code flow, and UDAP JWT-based Client Authorization Grants can be used to transmit Purpose of Use and Consent Information.

       

       

       

       

       

       

      UDAP is an open collaborative developing profiles to increase scalability, confidence, security, and trust in Open API ecosystems, and allows the re-use of identity proofing and credentialing processes already in place in existing national health information networks. These profiles are in draft status and are in pilot stage. UDAP DCR and Authentication/Authorization have been tested successfully at several HL7 FHIR connectathons and have received positive feedback from multiple stakeholders, including national health information networks, EHR vendors, patient privacy rights advocates, and app developers. These profiles are also compatible with SMART App Launch and UMA.

       

       

       

       

      We recommend that this be listed as a separate interoperability need sub-section of Query or possibly as a new top-level entry in Section III (e.g. Client Application Management), as it potentially overlaps with many of the other existing sub-sections where FHIR is used, including Query, Consumer Access, and Push.

       

       

       

       

      Julie Maas, CEO, EMR Direct

      UDAP for Client App Registration, Authentication & Authorization

      This work has now been jointly published by UDAP.org and HL7. The Security for Scalable Registration, Authentication, and Authorization (UDAP Security - http://hl7.org/fhir/us/udap-security/) Business-to-Business workflow is therefore recommended for use in this type of exchange; it is an Emerging Implementation Specification for securely scaling FHIR transactions by validating trusted ecosystem endpoints.

      Query for Documents Outside a Specific Health Information Exchange Domain

      Comment

      UDAP for Client App Registration, Authentication & Authorization

      This work has now been jointly published by UDAP.org and HL7. The Security for Scalable Registration, Authentication, and Authorization (UDAP Security - http://hl7.org/fhir/us/udap-security/) Business-to-Business workflow is therefore recommended for use in this type of exchange; it is an Emerging Implementation Specification for securely scaling FHIR transactions by validating trusted ecosystem endpoints.

      Additionally, the Interoperable Digital Identity & Patient Matching IG is recommended as it includes best practice guidance for patient matching.

      IHE - Document Sharing

      The Document Sharing exchange family of specifications from IHE fit this use-case well.

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html

      This includes FHIR based exchanges as specified in the Mobile access to Health Documents (MHD) and Mobile Health Documents Sharing (MHDS)

      eHealth Exchange Specifications

      To whom it may concern, 

      Can the hyperlinks to the eHealth Exchange Specifications listed below be corrected to reference this corrected link (https://ehealthexchange.org/testing-program/technical-specifications/) because the current links are broken.  Also, the eHealth Exchange would like to request that the maturity level be increased to match the maturity of the Carequality Implementation Guide (level 5) since Carequality does references these exact same specifications for their Query IG with further constraints and the eHealth Exchange network is very mature with 300+ gateways in production today exchanging data using these specifications since 2009 when it was an ONC project.  Also, the test tool availability should reference this link (https://wiki.ihe.net/index.php/IHE_Test_Tool_Information) instead of the Aegis DIL.  The eHealth Exchange has not used the Aegis DIL for testing since July 2018.  Please contact ddavis@sequoiaproject.org if you have any questions related to this request. 

      eHealth Exchange Specification: Patient Discovery

      eHealth Exchange Specification: Messaging Platform

      eHealth Exchange Specification: Authorization Framework

      eHealth Exchange Specification: Query for Documents

      eHealth Exchange Specification: Retrieve Documents

      eHealth Exchange Specifications Tooling Comment

      Rather than using the (https://wiki.ihe.net/index.php/IHE_Test_Tool_Information), please reference this link instead (https://validation.sequoiaproject.org).  The Sequoia Interoperability Testing Platform has specific test cases and scripts designed for the eHealth Exchange specifications leveraging IHE tooling components. 

      Since STU3, HL7 FHIR has…

      Since STU3, HL7 FHIR has included the Patient/$match operation which allows for patient matching using MPI-based logic. The FHIR DocumentReference resource can then be used to query for documents. When these are performed across communities, this provides comparable functionality to the XCPD and XCA standards already referenced. For this reason, we recommend that HL7 FHIR be included as an implementation specification in this sub-section with the $match operation and DocumentReference resource called out specifically in the limitations, dependencies, & preconditions area. The match operation replaced a similar MPI query available in DSTU2. Suggested maturity of Pilot and Adoption Level of 1.

       

       

      Julie Maas, CEO, EMR Direct

      Query for Documents Within a Specific Health Information Exchange Domain

      Comment

      IHE - Document Sharing

      The Document Sharing exchange infrastructure is a family of implementation guides specifically designed to support this setting.

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html

      This includes the FHIR based Mobile Health Document Sharing (MHDS) comprehensive community exchange.

      Both XDS and MHDS enable the automation of discovery and retrieve of document content by more advanced health information systems.

      Resource Location

      Care Service Discovery Within the U.S.

      Comment

      Align with the Hi

      The specification for Care Service Discovery appears to be relevant to the domain of human service information-and-referral, so I am commenting to encourage alignment of this vocabulary with the Human Services Data Specification and API protocols developed by the Open Referral Initiative and endorsed as industry standards by the Alliance of Information and Referral Systems. (Read more about this endorsement here: https://openreferral.org/airs-recommends-open-referral-for-resource-database-interoperability/

      At a glance, most of the concepts here align – the core elements of organization, services and locations that are necessary to identify a service available for a person in need. HSDS also includes additional layers of information that reflect the broad practice of information-and-referral from the human service sector, many of which are germane to the use cases described in this specification. By developing comparative analysis, extensions as necessary, and translation capabilities between these specifications, we can ensure alignment between the health and human service sectors.

      HSDS and HSDA are currently used by market leaders for both resource-referral call-center software (such as iCarol) as well as health-centered care-coordination software (such as Healthify and Unite Us). 

      These protocols are also under adoption by a range of local governments (such as New York City) and philanthropic funders (such as the Florida Bar Foundation). Open Referral’s protocols for resource data exchange have also been recognized by the US Data Federation, under the General Services Administration: https://federation.data.gov/ 

      Documentation of the standard is here, and a testing tool is available here: http://hsdsvalidator.openreferral.org/

      By ensuring alignment between the ISA and HSDS/A, we can promote integration among emerging service directory data ecosystems that span the healthcare and human service sectors. This may entail development of a new Interoperability need to address Community Resource Directories within the Content/Structure of the ISA. It may also entail alignment with the Healthcare Provider Directory (although there are significant differences, in that human services typically are not structured around individual practitioners and often are not associated with healthcare plans). 

      I would welcome any questions or suggestions, and can be reached at bloom@openreferral.org

      IHE mobile Care Services Discovery

      The IHE Mobile Care Services Discovery (mCSD) covers the use-cases of CSD and HPD but uses the FHIR standard. 

      https://profiles.ihe.net/ITI/TF/Volume1/ch-46.html

      Finding and Retrieving Human Services Information

      Comment


      Administrative

      Administrative Transactions - Non-Claims

      Administrative Transaction Acknowledgements

      Comment

      Enrollment and Disenrollment in a Health Plan

      Comment

      Health Care Eligibility Benefit Inquiry and Response

      Comment

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports NCPDP’s recommendation to add NCPDP Real-Time Prescription Benefit Standard Version 12 to the implementation specification.

      NCPDP Comments

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Real-Time Prescription Benefit Standard Version 12

      Standards Process Maturity – Final

      Implementation Maturity – Production

      Adoption Level – 1

      Federally required – No

      Cost - $

      Test Tool Availability – No

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP  Real Time Prescription Benefit Standard

      Standards Process Maturity – Final

      Implementation Maturity – Production

      Adoption Level – 1

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Remove the following statement: NCPDP is developing a Real Time Prescription Benefit standard that should be monitored as a potential emerging implementation specification. It is currently in beta status, with anticipated balloting expected Fall 2019.

      NCPDP Comment

      1. NCPDP developed a Beta version of the Real Time Prescription Benefit Standard to be balloted in the Fall of 2019.

      Health Care Eligibility Benefit Inquiry and Response for Retail Pharmacy Coverage

      Comment

      NCPDP Comment

      NCPDP recommends that ONC update the Real-Time Prescription Benefit (RTPB) Standard from Version 12 to Version 13. RTPB is not a HIPAA transaction and NCPDP does not recommend it to be identified as such.

      NCPDP Comments

      1. NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2020 and equivalent Batch Standard Implementation Guide, Version 15 is published, adoption level of N/A and not Federally Required yet. NCPDP has requested these versions be named under HIPAA.
      2. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Real-Time Prescription Benefit Standard Version 12

      Standards Process Maturity – Final

      Implementation Maturity – Production

      Adoption Level – 1

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Update the following: NCPDP Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010 add the equivalent Batch Standard Implementation Guide Version 1.2

      updated weblink for NCPDP standard

      updated link for NCPDP due to 404 error on prior link

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP  Real Time Prescription Benefit Standard

      Standards Process Maturity – Final

      Implementation Maturity – Production

      Adoption Level – 1

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Remove the following statement: NCPDP is developing a Real Time Prescription Benefit standard that should be monitored as a potential emerging implementation specification. It is currently in beta status, with anticipated balloting expected Fall 2019.
      2. Modify the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2020 and Equivalent Batch Standard Implementation Guide, Version 15

      NCPDP Comment

      1. Remove “NCPDP is in the investigative stage of providing a test tool” under Limitations, Dependencies, and Preconditions for Consideration.

      NCPDP Comment

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15

      Standards Process Maturity – Final

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No.

       

      Limitations, Dependencies, and Preconditions for Consideration

       

      • The Telecommunication Standard Implementation Guide Version F2 has been requested to be adopted under HIPAA.
      • NCPDP is in the investigative stage of providing a test tool.
      •  

      Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

      The Pharmacy HIT Collaborative supports the use of NCPDP Telecommunications Standard Implementation Guide, Version D, Release 0.

      NCPDP - Comment

      • The Standard Listed – NCPDP Version D.0 is incorrect. The Standard and Implementation Guide are not separated. There is no separate standard and the Standard section material should be deleted.
      • Standard Implementation/Specification: incorrectly lists the wrong version of the Telecommunication Standard Implementation Guide. It should be Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010.

      Administrative Transactions to Financial Exchanges

      Electronic Funds Transfer for Payments to Health Care Providers

      Comment

      updated link to FR https:/…

      updated link to FR https://www.govinfo.gov/content/pkg/FR-2012-01-10/pdf/2012-132.pdf#page=36 

      NCPDP - Comment

      The Electronic Funds Transfer for Payments to Health Care Providers is applicable to all providers and not just those which bill professional or institution claims. Remove “Professionals and Institutions”.

      Health Care Payment and Remittance Advice

      Comment

      NCPDP - Comment

      Limitations, Dependencies, and Preconditions for Consideration:  NCPDP provides specific guidance on how the ASC X12N 835 should be mapped in response to a NCPDP Version D.0 transaction.

      Health Plan Premium Payments for Covered Members

      Comment

      Administrative Transactions to Support Clinical Care

      Health Care Attachments to Support Claims, Referrals and Authorizations

      Comment

      NCPDP Comment

      1. NCPDP recommends that ONC sunset NCPDP® SCRIPT Standard Implementation Guide Version 2020101 as this version is not supported by the industry.
      2. NCPDP recommends that ONC remove from Limitations, Dependencies, and Preconditions for Consideration section: Pharmacy referral transactions have been published in the NCPDP SCRIPT Standard Version 2020101. These transactions are currently available for use by trading partner agreement.  Authorizations are also available in NCPDP SCRIPT Standard Version 2017071. The SCRIPT transactions can handle a single attachment that can contain multiple documents.

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports NCPDP’s recommendation of adding NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to the implementation specification.

      NCPDP Comments

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard Implementation Guide Version 2020101

      Standards Process Maturity – Final

      Implementation Maturity – Published

      Adoption Level – N/A

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Referral transactions published in the NCPDP SCRIPT Standard Version 2020101. These transactions are currently available for use by trading partner agreement.
      2. Authorizations are currently available in NCPDP SCRIPT Standard Version 2017071. The SCRIPT transactions can handle a single attachment that can contain multiple documents.

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard Implementation Guide Version 2020101

      Standards Process Maturity – Final

      Implementation Maturity – Production

      Adoption Level – 1

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Referral transactions published in the NCPDP SCRIPT Standard Version 2020101.

      NCPDP Comment

      1. Emerging Transaction(s) within NCPDP SCRIPT Standard:
        1. Patient Care Service Referral (ServiceReferral)
        2. Patient Care Service Documentation (ServiceDocumentation)
        3. Response to Request for Patient Care Service Referral (ResponseToReferralRequest)
        4. Request for Patient Care Service Referral (RequestForReferral)
        5. Response to Patient Care Service Referral (ServiceReferralResponse)

      Acknowledgments

      The American Medical Association appreciates the opportunity to comment. This section includes acknowledgments, however, acknowledgments typically does not support claims, referrals, or authorizations. We believe acknowledgments is misplaced in this section. We understand the reasoning could be because they are lumped together on the regulatory agenda, however the 999 does not seem related. Acknowledgments intersects with multiple transactions, therefore we believe it should have its own section. The guidance claims that two payers have successfully implemented attachments after piloting in 2004. This is inaccurate as the standard that is currently under consideration was not created until 2016. 

      NCPDP Comment

      Request removal of NCPDP 2017 comments.

      The very large list of…

      The very large list of standards in this section suggests that it should be broken up into different interoperability needs. There also seems to be a mix of base standards (X12 Version 6020), implementation guides specific to attachments, and some other general implementation guides that probably don’t need to be listed here because they are pointed to in the attachment specific guides (C-CDA, LOINC Document Ontology IG, Digital signatures, etc). Previously, the HITSC recommended separating out base standards from implementation guides.

      NCPDP - Comment

      • This should be under the main category of V-D: Administrative Transaction to Support Clinical Care.
      • Add a bullet for Standards for referral certification and authorization transaction - Pharmacy

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 3

      Federally Required – Yes

      Cost – $

      Test Tool Availability –

      • Add a bullet for Standards for referral certification and authorization transaction - Pharmacy

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard Implementation Guide, Version 2013101

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 2

      Federally Required – Yes

      Cost – $

      Test Tool Availability -

      Referral Certification and Authorization for Pharmacy Transactions

      Comment

      NCPDP Comments

      1. Update the following: NCPDP SCRIPT Standard Implementation Guide, Version 2013101 should be removed.
      2. Update the following: NCPDP SCRIPT Standard, Implementation Guide, Version 2017071 should be production and level 5.
      3. Update the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard Implementation Guide Version 2020101

      Standards Process Maturity – Final

      Implementation Maturity – Published

      Adoption Level – N/A

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Referral transactions published in the NCPDP SCRIPT Standard Version 2020101. These transactions are currently available for use by trading partner agreement.
      2. Update the following: NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2020 is published, adoption level of N/A and not Federally Required yet. NCPDP has requested this version be named under HIPAA.

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard Implementation Guide Version 2020101

      Standards Process Maturity – Final

      Implementation Maturity – Production

      Adoption Level – 1

      Federally required – No

      Cost - $

      Test Tool Availability – No

      1. Referral transactions published in the NCPDP SCRIPT Standard Version 2020101.

      NCPDP Comment

      1. Add Referral transaction to be published in the NCPDP SCRIPT Standard.
      2. Emerging Transaction(s) within NCPDP SCRIPT Standard:
        1. Patient Care Service Referral (ServiceReferral)
        2. Patient Care Service Documentation (ServiceDocumentation)
        3. Response to Request for Patient Care Service Referral (ResponseToReferralRequest)
        4. Request for Patient Care Service Referral (RequestForReferral)
        5. Response to Patient Care Service Referral (ServiceReferralResponse)
      3. Remove “NCPDP is in the investigative stage of providing a test tool” under Limitations, Dependencies, and Preconditions for Consideration.
      4. Modify Standard/Implementation Specification to “NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018

      Standards Process Maturity – Final

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No.

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 201707

      Standards Process Maturity – Final

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – Yes.

       

      Limitations, Dependencies, and Preconditions for Consideration

       

      • The Telecommunication Standard Implementation Guide Version F2 and SCRIPT Standard Version 2017071 have been requested to be adopted under HIPAA.
      • NCPDP is in the investigative stage of providing a test tool for the Telecommunication Standard
      • NCPDP has a testing tool available for the SCRIPT Standard Version 2017071.
      •  

      Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

      The Pharmacy HIT Collaborative supports the use of NCPDP Telecommunications Standard Implementation Guide, Version D, Release 0.

      Referral Certification and Authorization Request and Response for Dental, Professional and Institutional Services

      Comment

      Administrative Transactions: Price Transparency

      Advanced Estimates for Patient Costs from Providers & Payers

      Comment

      Health Care Claim Status Request and Response

      Comment

      Health Care Claims and Coordination of Benefits

      Health Care Claims or Equivalent Encounter Information for Dental Claims

      Comment

      CARIN Alliance Comments on ISA

      The CARIN Alliance, a multi-sector group of stakeholders requests that ONC update the Health Care Claims or Equivalent Encounter Information for Professional Claims and Institutional Claims in the ISA to include the latest information related to the HL7® FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide (IG). Please see the attached comment letter for additional details.

      CARIN Alliance Comments on ISA 093022_0.pdf

      Health Care Claims or Equivalent Encounter Information for Institutional Claims

      Comment

      CARIN Alliance Comments on ISA

      The CARIN Alliance, a multi-sector group of stakeholders requests that ONC update the Health Care Claims or Equivalent Encounter Information for Professional Claims and Institutional Claims in the ISA to include the latest information related to the HL7® FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide (IG). Please see the attached comment letter for additional details.

      CARIN Alliance Comments on ISA 093022.pdf

      Health Care Claims or Equivalent Encounter Information for Professional Claims

      Comment

      CARIN Alliance Comments on ISA

      The CARIN Alliance, a multi-sector group of stakeholders requests that ONC update the Health Care Claims or Equivalent Encounter Information for Professional Claims and Institutional Claims in the ISA to include the latest information related to the HL7® FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide (IG). Please see the attached comment letter for additional details.

      CARIN Alliance Comments on ISA 093022_1.pdf

      The use of standards based…

      The use of standards based on 30 year-old UN-EDIFACT based standards needs consideration.  They work, but quite frankly, take a mountain of healthcare specific training to adopt. The payment industry needs to consider pilots for moving towards RESTFUL based APIs for payment based transactions across the board, in both batch and real-time formats.  It takes 5-10 years simply to adopt a new version of these standards to change the width of some fields and accommodate new coding or identifier systems 

      CMS Response

      CMS Response: We appreciate the feedback and look forward to receiving specific recommendations from industry for the use of alternative standards that enable the electronic exchange of health care information. The HIPAA regulations encourage pilots to test the use of alternative standards which meet the objectives of administrative simplification.

      Health Care Claims or Equivalent Encounter Information for Retail Pharmacy Claims

      Comment

      NCPDP Comment

      1. NCPDP recommends that ONC update: NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15 to NCPDP Telecommunication Standard, Implementation Guide Version F6, April 2022 and equivalent Batch Standard Implementation Guide Version 15
      2. NCPDP recommends that ONC update: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007 to NCPDP Batch Standard Medicaid Subrogation Implementation Guide Version 3.0
      3. NCPDP recommends that ONC update: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to NCPDP Batch Standard Subrogation Implementation Guide Version 10
      4. NCPDP recommends that ONC remove: HL7® FHIR® DaVinci Provider Data Exchange (PDex: Formulary) Implementation Guide. The guide does not support pharmacy claims submission nor is it adopted under HIPAA.
      5. NCPDP recommends that ONC update the Limitations, Dependencies, and Preconditions for Consideration section to remove: Information about the CMS May 2020 Interoperability and Patient Access final rule and the HL7 FHIR APIs included in that rule may be found on the CMS Interoperability website. This rule includes use of the HL7® FHIR® DaVinci Provider Data Exchange (PDex: Formulary) Implementation Guide.
        1. Rationale: You cannot submit a claim using the HL7® FHIR® DaVinci Provider Data Exchange (PDex: Formulary) Implementation Guide. This guide possibly belongs under the section “Allows Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescriber Systems”; however, the purpose of the guide is to allow a consumer to verify formulary and benefit information.

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports the following NCPDP recommendations: updating NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15 to NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2022 and Equivalent Batch Standard Implementation Guide, Version 15; updating NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007 to NCPDP Batch Standard Medicaid Subrogation Implementation Guide Version 3.0; and updating NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to NCPDP Batch Standard Subrogation Implementation Guide Version 10.

      NCPDP Comments

      1. NCPDP recommends updating: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to the following:
        1. NCPDP Subrogation Implementation Guide for Batch Standard Version 10

       

      1. NCPDP recommends updating: NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15 to the following:
        1. NCPDP Telecommunication Standard Implementation Guide, Version F6, April 2022 and equivalent Batch Standard Implementation Guide Version 15

       

      1. NCPDP recommends removing the following:
        1. Standard / Implementation Specification: HL7® FHIR® DaVinci Provider Data Exchange (PDex: Formulary) Implementation Guide and
        2. Limitations, Dependencies, and Preconditions for Consideration: Information about the CMS May 2020 Interoperability and Patient Access final rule and the HL7 FHIR APIs included in that rule may be found on the CMS Interoperability website. This rule includes use of the HL7® FHIR® DaVinci Provider Data Exchange (PDex: Formulary) Implementation Guide.
          1. Rationale: You cannot submit a claim using the HL7® FHIR® DaVinci Provider Data Exchange (PDex: Formulary) Implementation Guide. This guide possibly belongs under the section “Allows Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescriber Systems”; however, the purpose of the guide is to allow a consumer to verify formulary and benefit information.

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15

      Standards Process Maturity – Final

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No.

       

      Limitations, Dependencies, and Preconditions for Consideration

       

      • The Telecommunication Standard Implementation Guide Version F2 has been requested to be adopted under HIPAA.
      • NCPDP is in the investigative stage of providing a test tool.
      •  

      NCPDP - Comment

        • The Standard Listed – NCPDP Version D.0 is incorrect. The Standard and Implementation Guide are not separated. There is no separate standard and the Standard section material should be deleted.
        • Standard Implementation/Specification: incorrectly lists the wrong version of the Telecommunication Standard Implementation Guide. It should be Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010.

      Health Care Claims or Equivalent Encounter Information for Retail Pharmacy Supplies and Professional Services

      Comment

      NCPDP Comment

      1. NCPDP recommends that ONC update: NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15 to NCPDP Telecommunication Standard, Implementation Guide Version F6, April 2022 and equivalent Batch Standard Implementation Guide Version 15
      2. NCPDP recommends that ONC update: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007 to NCPDP Batch Standard Medicaid Subrogation Implementation Guide Version 3.0
      3. NCPDP recommends that ONC update: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to NCPDP Batch Standard Subrogation Implementation Guide Version 10
      4. NCPDP recommends that ONC sunset: NCPDP Uniform Healthcare Payer Data Standard Implementation Guide V24 as this version is not supported by the industry.
      5. NCPDP recommends that ONC sunset: NCPDP Uniform Healthcare Payer Data Standard Implementation Guide V28 as this version is not supported by the industry.

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports the following NCPDP recommendations: updating NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15 to NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2022 and Equivalent Batch Standard Implementation Guide, Version 15; updating NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007 to NCPDP Batch Standard Medicaid Subrogation Implementation Guide Version 3.0; and updating NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to NCPDP Batch Standard Subrogation Implementation Guide Version 10.

      NCPDP Comments

      1. NCPDP recommends updating: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to the following:
        1. NCPDP Subrogation Implementation Guide for Batch Standard Version 10
      2. NCPDP recommends updating: NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15 to the following:
        1. NCPDP Telecommunication Standard, Implementation Guide Version F6, April 2022 and equivalent Batch Standard Implementation Guide Version 15
      3. NCPDP recommends modifying: The 8th bullet of Limitations, Dependencies, and Preconditions for Consideration:
        1. From: “The NCPDP Telecommunication Standard Implementation Guide Version F2 and subrogation Version 10 have been requested for adoption under HIPAA by NCVHS.  NCVHS recommendation letters to HHS may be viewed on the NCVHS website.”
        2. To: “The NCPDP Telecommunication Standard Implementation Guide Version F6 and the NCPDP Subrogation Implementation Guide for Batch Standard Version 10 have been requested for adoption under HIPAA by NCVHS.  NCVHS recommendation letters to HHS may be viewed on the NCVHS website.”
          1. Note: the NCVHS link has been updated

      NCPDP Comments

      1. Update: NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and equivalent Batch Standard Implementation Guide, Version 15 to reflect Version F6.
      2. NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2020 is published, adoption level of N/A and not Federally Required yet. NCPDP has requested this version be named under HIPAA.
      3. Update: NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 to the following:
      • Type: Implementation Specification
      • Standard / Implementation Specification: NCPDP Batch Standard Subrogation Implementation Guide Version 10
      • Implementation Maturity: Production
      • Adoption Level: 1
      1. NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 10 has been requested to be adopted under HIPAA

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Uniform Healthcare Payer Data Standard Implementation Guide V28

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability –No

      1. Remove “NCPDP is in the investigative stage of providing a test tool” under Limitations, Dependencies, and Preconditions for Consideration.

      NCPDP Comment

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F2, March 2018 and Equivalent Batch Standard Implementation Guide, Version 15

      Standards Process Maturity – Final

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No.

      Limitations, Dependencies, and Preconditions for Consideration

       

      • The Telecommunication Standard Implementation Guide Version F2 has been requested to be adopted under HIPAA.
      • NCPDP is in the investigative stage of providing a test tool.
      •  

      NCPDP - Comment

      • The Standard Listed – NCPDP Version D.0 is incorrect. The Standard and Implementation Guide are not separated. There is no separate standard and the Standard section material should be deleted.
      • Standard Implementation/Specification: incorrectly lists the wrong version of the Telecommunication Standard Implementation Guide. It should be Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010.
      • Standard Implementation/Specification: The Telecommunication Standard, Implementation Guide Version 5, Release 1, September 1999 should be deleted.

       

      • Add a bullet for Medicaid Pharmacy Subrogation

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 5

      Federally Required – Yes

      Cost – $

      Test Tool Availability –

      • Add a bullet for Uniform Healthcare Payer Data Standard

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Uniform Healthcare Payer Date Standard Implementation Guide V24

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability –

      Operating Rules to Support Administrative Transactions

      CAQH CORE Operating Rules for Connectivity

      Comment

      Updates to the CORE Connectivity Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Connectivity website. The changes are outlined on Page 7-8 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      NCPDP Comment

      NCPDP recommends that ONC add the following:

      Type- Operating Rules

      Standard Implementation/Specification- Operating Rule Connectivity, V2.0

      Standards Process Maturity – Final

      Implementation Maturity- Feedback Requested

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports NCPDP’s recommendation adding Operating Rule Connectivity, V2.0 to operating rules.

      Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA)

      Comment

      Updates to the CORE EFT/ERA page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advise (ERA) website. The changes are outlined on Page 11-12 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      CAQH CORE Operating Rules for EFT and ERA Updates

      Updates to the CAQH CORE Operating Rules for EFT and ERA are on pages 8-10 in the attached document. CAQH CORE has proposed a substantive change of increasing the adoption level of these Operating Rules from three to four. Upwards of 67% of insured lives are covered under health plans that are currently CORE-certified on the CAQH CORE Operating Rules for EFT and ERA. Given that these rules are federally mandated it can be assumed that overall industry adoption is even higher. Therefore, CAQH CORE believes that is justified to increase the adoption level reflected in the 2023 ISA Reference Edition and web version. Other non-substantive changes have been accommodated for consistency, conciseness, and grammar and syntax. Changes are highlighted in gray with proposed deletions shown as strikethrough text.

      CAQH CORE ISA Letter 2022_2.pdf

      updated weblink

      updated weblink

      comment

      acknowledged

      CAQH CORE Comments to ONC ISA - Phase III

      Aligning ISA with New Operating Rule Structure: In Spring 2020, CAQH CORE restructured its operating rules from phase-based rule sets to rule sets based on the business processes supported by the rules. No substantive changes were made to existing rule requirements. As a result of the restructuring, CAQH CORE recommends updates to the following sections of the ISA:

      Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Remittance (Phase III) -- Payments & Remittance Operating Rules

      ISA Comments from CAQH CORE 11.1.20 FINAL_2.pdf

      CAQH CORE Comments to ONC ISA 2020 Reference Edition - Phase III

      Statutory References for Operating Rules for Electronic Funds Transfer and Electronic Remittance Advice for Payments and Reconciliation (Phase III) 


      CAQH CORE recommends ONC include the statutory reference in the subpage titled “Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA)” to enhance ease of use. Such reference would be (Incorporated by reference in § 162.920) after each of the five bullets. This would be consistent with language currently included in the ISA for Operating Rules to Support Eligibility Transactions (Phase I) and Operating Rules to Support Eligibility and Claim Status Transactions (Phase II). 
      For example: 
       
      Phase III Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Reconciliation include:  
      (1) Phase III CORE 350: Healthcare Claim Payment/Advice (835) Infrastructure Rule (Incorporated by reference in § 162.920)

      (2) Phase III CORE 360: Uniform Use of CARCs and RARCs (835) Rule (Incorporated by reference in § 162.920)

      (3) Phase III CORE 370: EFT and ERA Reassociation (CCD+/835) Rule (Incorporated by reference in § 162.920)

      (4) Phase III CORE 380: EFT Enrollment Data Rule (Incorporated by reference in § 162.920)

      (5) Phase III CORE 382: ERA Enrollment Data Rule (Incorporated by reference in § 162.920)

      CAQH CORE Comment Letter to ONC ISA_1.pdf

      CAQH CORE Comments on 2018 Interoperability Standards Advisory

      • “Operating Rules” should be included as one of the structures under “Type,” which presently only includes “Standard” or “Implementation Specification.” Although there are other utilities referenced in the ISA (e.g. Integrating the Healthcare Enterprise (IHE)’s Integration Profiles) that also technically do not meet the definition of either a standard or implementation specification, operating rules are distinct in this regard. The Centers for Medicare and Medicaid Services (CMS) notes, in its definition of operating rules, that they are “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications” (emphasis added).

      (Above content is an except of the full CAQH CORE Comment Letter).

      CAQH CORE Operating Rules for Eligibility & Benefits

      Comment

      Updates to Eligibility and Benefits Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Eligibility and Benefits website. The changes are outlined on Page 9-10 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      CAQH CORE Operating Rules for Eligibility and Benefits Updates

      Updates to the CAQH CORE Operating Rules for Eligibility and Benefits are on pages 6-7 in the attached document. Proposed changes are highlighted in gray with proposed deletions being shown as strikethrough text. CAQH CORE recommends renaming the section to ‘Operating Rules for Eligibility and Benefits’ for consistency in naming conventions. Additionally, CAQH CORE recommends that this section be the first in the list of Operating Rules. Further, language has been included to denote differences between federally mandated CAQH CORE Operating Rules for Eligibility and Benefits and those that are available for voluntary adoption. Other non-substantive updates have been made.

      CAQH CORE ISA Letter 2022_0.pdf

      updated weblink

      updated weblink -previous one does not work

      CAQH CORE Comments to ONC ISA - Phase I

      Aligning ISA with New Operating Rule Structure: In Spring 2020, CAQH CORE restructured its operating rules from phase-based rule sets to rule sets based on the business processes supported by the rules. No substantive changes were made to existing rule requirements. As a result of the restructuring, CAQH CORE recommends updates to the following sections of the ISA:

      Operating Rules to Support Eligibility Transactions (Phase I) -- Eligibility & Benefits Operating Rules

      ISA Comments from CAQH CORE 11.1.20 FINAL_1.pdf

      Aligning ISA with New…

      Aligning ISA with New Operating Rule Structure: In Spring 2020, CAQH CORE restructured its operating rules from phase-based rule sets to rule sets based on the business processes supported by the rules. No substantive changes were made to existing rule requirements. As a result of the restructuring, CAQH CORE recommends updates to the following sections of the ISA:

      Operating Rules to Support Eligibility Transactions (Phase I) -- Eligibility & Benefits Operating Rules

      ISA Comments from CAQH CORE 11.1.20 FINAL.pdf

      CAQH CORE Comments on 2018 Interoperability Standards Advisory

      • “Operating Rules” should be included as one of the structures under “Type,” which presently only includes “Standard” or “Implementation Specification.” Although there are other utilities referenced in the ISA (e.g. Integrating the Healthcare Enterprise (IHE)’s Integration Profiles) that also technically do not meet the definition of either a standard or implementation specification, operating rules are distinct in this regard. The Centers for Medicare and Medicaid Services (CMS) notes, in its definition of operating rules, that they are “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications” (emphasis added).
      • Operating Rules to Support Eligibility Transactions (Phase I): “Adoption Level” for these operating rules is currently listed as 3 out of 5. CAQH CORE updated its market share data in 2018 and determined that 65 percent of the commercial and publicly insured population in the United States are covered by Phase I CORE-certified health plans. Given the Phase I CAQH CORE Operating Rules are federally mandated and CORE Certification is voluntary, it is reasonable to conclude that more health plans have implemented the rules than have pursued CORE Certification. Therefore, CAQH CORE suggests increasing the industry adoption level of the Phase I CAQH CORE Operating Rules to 4 out of 5.

      (Above content is an except of the full CAQH CORE Comment Letter).

      NCPDP - Comments

      This should be under the main category of V-E: Operating Rules to Support Administrative Transactions.

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Operating Rules for the X12 270/271 Transactions in Electronic Prescribing v1.0

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 5

      Federally Required – No

      Cost – $

      Test Tool Availability -

      Operating Rules for Health Care Claims

      Comment

      Updates to the CORE Health Care Claims Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Health Care Claims website. The changes are outlined on Page 12-13 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      NCPDP Comment

      1. NCPDP recommends that ONC add to the Limitations, Dependencies, and Preconditions for Consideration section - NCPDP operating rules are incorporated as part of the NCPDP standard and separate operating rules are not adopted under HIPAA for pharmacy standards.
      2. NCPDP recommends that ONC add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version F6

      Standards Process Maturity – Pilot

      Implementation Maturity- Feedback Requested

      Adoption Level – Feedback Requested

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports NCPDP’s recommendation to add NCPDP Telecommunication Standard, Version D to NCPDP Telecommunication Standard, Version D.0 and NCPDP Telecommunication Standard, Implementation Guide, Version F6  to implementation specification.

      CAQH CORE Operating Rules for Health Care Claims Updates

      Updates to the CAQH CORE Operating Rules for Health Care Claims are on pages 11-13 in the attached document. Proposed changes are primarily non-substantive in nature and address consistency, conciseness, and grammar and syntax. Changes are highlighted in gray with proposed deletions shown as strikethrough text.

      CAQH CORE ISA Letter 2022_4.pdf

      NCPDP Comments

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP Telecommunication Standard, Implementation Guide, Version D.0

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 5

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      1. NCPDP operating rules are in the NCPDP Telecommunication Standard, Implementation Guide, Version D.0

      updated weblink

      updated weblink

      CAQH CORE Comments to ONC ISA - Phase IV

      Aligning ISA with New Operating Rule Structure: In Spring 2020, CAQH CORE restructured its operating rules from phase-based rule sets to rule sets based on the business processes supported by the rules. No substantive changes were made to existing rule requirements. As a result of the restructuring, CAQH CORE recommends updates to the following sections of the ISA:

      Operating Rules for Claims, Enrollment, and Premium Payment (Phase IV) -- Healthcare Claims Operating Rules, Benefit Enrollment Operating Rules, Premium Payment Operating Rules

      ISA Comments from CAQH CORE 11.1.20 FINAL_3.pdf

      CAQH CORE Comments to ONC ISA 2020 Ref Edition - Phases IV & V

      2. Implementation Maturity and Adoption Level for Operating Rules for Claims, Enrollment, and Premium Payments (Phase IV) 
       
      CAQH CORE recommends changing the Implementation Maturity for the Phase IV Operating Rules from “Pilot” to “Production”. Entities are actively implementing this rule set and achieving Phase IV CORE Certification. Additionally, we recommend updating the Adoption Level to 1 out of 5.  
       
       3. Addition of the Phase V Operating Rules for Prior Authorization 
       
      CAQH CORE is pleased to announce the release of the final Phase V Operating Rules for the prior authorization transaction and recommends ONC expand the ISA content in Section IV: Administrative Standards and Implementation Specifications - Operating Rules to Support Administrative Transactions to include this rule set.  
       
      The Phase V CAQH CORE Operating Rules, approved in May 2019, include:

      • Phase V CAQH CORE Prior Authorization (278) Request / Response Data Content Rule v5.0.0

      • Phase V CAQH CORE Prior Authorization Web Portal Rule v5.0.0

      The Phase V CAQH CORE Operating Rules focus on standardizing components of the prior authorization process, closing gaps in electronic data exchange to move the industry towards a more fully automated adjudication of a request. To develop the Phase V Operating Rules, CAQH CORE conducted an environmental scan of over 100 entities, participated in industry meetings and convened multi-stakeholder groups to agree on opportunities for operating rule development and refine rule requirements.  

      CAQH CORE recommends the following additional content for the Phase V Rules: 
       
      • Type: Operating Rules

      • Standard / Implementation Specification: CAQH CORE Phase V Operating Rule Set

      • Standards Process Maturity: Final

      • Implementation Maturity: Pilot • Adoption Level: 1 out of 5

      • Federally Required: No

      • Cost: Free

      • Test Tool Availability: Yes 
       
      The Limitations, Dependencies, and Preconditions for Consideration section can mirror that for the other operating rule sets with the exception of the fourth bullet which should read: 
       
      • The Phase V CAQH CORE Operating Rules, available for use on a voluntary basis as of May 2019, include:

         o Phase V CAQH CORE Prior Authorization (278) Request / Response Data Content Rule v5.0.0

         o Phase V CAQH CORE Prior Authorization Web Portal Rule v5.0.0 

      CAQH CORE Comment Letter to ONC ISA_2.pdf

      Attributed Patient Roster

      Comment

      Recommended Updates to the CORE Attributed Patient Roster Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for the Exchange of an Attributed Patient Roster website. The changes are outlined on Page 3 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      Operating Rules to Support Claim Status Transactions

      Comment

      Updates to the CORE Claim Status Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Claim Status website. The changes are outlined on Page 13-14 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      CAQH CORE Operating Rules for Claim Status Updates

      Updates to the CAQH CORE Operating Rules for Claim Status are on pages 7-8 in the attached document. Proposed changes are primarily non-substantive in nature and address consistency, conciseness, and grammar and syntax. Changes are highlighted in gray with proposed deletions shown as strikethrough text.

      CAQH CORE ISA Letter 2022_1.pdf

      Comments and edits acknowledged

      Most edits and revisions completed 10/10. thank you for the clarifications. Will determine when we can add Patient Attribution, and logistics for any re-ordering. Again, thank you for the comprehensive submission. 

      CAQH CORE Comments to ONC ISA - Phase II

      Aligning ISA with New Operating Rule Structure: In Spring 2020, CAQH CORE restructured its operating rules from phase-based rule sets to rule sets based on the business processes supported by the rules. No substantive changes were made to existing rule requirements. As a result of the restructuring, CAQH CORE recommends updates to the following sections of the ISA:

      Operating Rules to Support Eligibility and Claim Status Transactions (Phase II) -- Claim Status Operating Rules

      ISA Comments from CAQH CORE 11.1.20 FINAL_0.pdf

      CAQH CORE Comments on 2018 Interoperability Standards Advisory

      • “Operating Rules” should be included as one of the structures under “Type,” which presently only includes “Standard” or “Implementation Specification.” Although there are other utilities referenced in the ISA (e.g. Integrating the Healthcare Enterprise (IHE)’s Integration Profiles) that also technically do not meet the definition of either a standard or implementation specification, operating rules are distinct in this regard. The Centers for Medicare and Medicaid Services (CMS) notes, in its definition of operating rules, that they are “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications” (emphasis added).
      • Operating Rules to Support Eligibility and Claim Status Transactions (Phase II): “Adoption Level” for these operating rules is currently listed as 3 out of 5. CAQH CORE updated its market share data in 2018 and determined that 65 percent of the commercial and publicly insured population in the United States are covered by Phase II CORE-certified health plans. Given the Phase I CAQH CORE Operating Rules are federally mandated and CORE Certification is voluntary, it is reasonable to conclude that more health plans have implemented the rules than have pursued CORE Certification. Therefore, CAQH CORE suggests increasing the industry adoption level of the Phase II CAQH CORE Operating Rules to 4 out of 5.

      (Above content is an except of the full CAQH CORE Comment Letter).

      Operating Rules for Enrollment and Disenrollment

      Comment

      Recommended Updates to the Benefit Enrollment PAge

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Benefit Enrollment and Disenrollment. The changes are outlined on Page 4 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      CAQH CORE Operating Rules for Benefit Enrollment Updates

      Updates to the CAQH CORE Operating Rules for Benefit Enrollment are on pages 13-14 in the attached document. Proposed changes are primarily non-substantive in nature and address consistency, conciseness, and grammar and syntax. Changes are highlighted in gray with proposed deletions shown as strikethrough text.

      CAQH CORE ISA Letter 2022_5.pdf

      Operating Rules for Premium Payments

      Comment

      Updates to the CORE Premium Payments Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Premium Payments. The changes are outlined on Page 5 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      CAQH CORE Operating Rules for Premium Payment Updates

      Updates to the CAQH CORE Operating Rules for Premium Payment are on pages 14-15 in the attached document. Proposed changes are primarily non-substantive in nature and address consistency, conciseness, and grammar and syntax. Changes are highlighted in gray with proposed deletions shown as strikethrough text.

      CAQH CORE ISA Letter 2022_6.pdf

      updated weblink

      updated weblink

      Operating Rules for Prior Authorization and Referrals

      Comment

      Updates to CORE PA and Referrals Page

      CORE recommends several substantive content and clarifying changes to the CAQH CORE Operating Rules for Prior Authorization and Referrals website. The changes are outlined on Page 6-7 of the letter found at this link: CORE Submission for the 2024 ISA Open Comment Period.

      Pharmacy HIT Collaborative (PHIT) comment

      PHIT supports NCPDP’s recommendation of adding NCPDP SCRIPT Standard, Implementation Guide, Version 2022011 to the implementation specification.

       

      CAQH CORE Operating Rules for PA and Referral Updates

      Changes to Operating Rules for Prior Authorization and Referrals are on pages 10-11 in the attached document. CAQH CORE proposes an update to change the name of this section from “CAQH CORE Operating Rules for Prior Authorization” to “CAQH CORE Operating Rules for Prior Authorization and Referrals.”  Other changes are primarily non-substantive and address consistency, conciseness, and grammar and syntax. Changes are highlighted in gray with proposed deletions shown as strikethrough text.

      CAQH CORE ISA Letter 2022_3.pdf

      NCPDP Comments

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 5

      Federally Required – No

      Cost – $

      Test Tool Availability – Yes

      Test Tool Link: https://tools.ncpdp.org/erx/#/home

      1. NCPDP operating rules are in the NCPDP SCRIPT Standard, Implementation Guide Version 2017071

      updated weblink

      updated weblink

      CAQH CORE Comments to ONC ISA - Phase V

      Aligning ISA with New Operating Rule Structure: In Spring 2020, CAQH CORE restructured its operating rules from phase-based rule sets to rule sets based on the business processes supported by the rules. No substantive changes were made to existing rule requirements. As a result of the restructuring, CAQH CORE recommends updates to the following sections of the ISA:

      Operating Rules for Prior Authorization (Phase V) -- Prior Authorization & Referrals Operating Rules

      ISA Comments from CAQH CORE 11.1.20 FINAL_4.pdf

      Operating Rules to Support Electronic Prescribing Transactions

      Comment

      NCPDP Comment

      1. NCPDP Recommends that ONC add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP® Operating Rules for the Formulary and Benefit Standard v11

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      1. NCPDP recommends that ONC update the Limitations, Dependencies, and Preconditions for Consideration section: “Operating rule for formulary corresponds with NCPDP Formulary and Benefit Standard v50 and later which has not been named in regulation.” to “Operating rule for formulary corresponds with NCPDP Formulary and Benefit Standard v60 and later which has not been named in regulation.”
      2. NCPDP Recommends that ONC add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2022011

      Standards Process Maturity – Final

      Implementation Maturity- Pilot

      Adoption Level – 1

      Federally Required – No

      Cost – $

      Test Tool Availability – No

      1. NCPDP recommends that ONC update the Limitations, Dependencies, and Preconditions for Consideration section to add - NCPDP operating rules are incorporated as part of the NCPDP SCRIPT Standard, Implementation Guide Version 2022011
      2. NCPDP recommends that ONC sunset NCPDP Operating Rules to Support Electronic Prescribing Transactions

      NCPDP Comments

      1. Add the following:

      Type-Implementation Specification

      Standard Implementation/Specification- NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

      Standards Process Maturity – Final

      Implementation Maturity- Production

      Adoption Level – 5

      Federally Required – No

      Cost – $

      Test Tool Availability – Yes

      Test Tool Link: https://tools.ncpdp.org/erx/#/home

      1. NCPDP operating rules are in the NCPDP SCRIPT Standard, Implementation Guide Version 2017071

      updated web link

      prior link gave 404 error

      NCPDP Comment

      1. Add the following:

      Type: Operating Rules

      Standard/Implementation Specification – NCPDP Operating Rules for the Formulary and Benefit Standard v10

      Standards Process Maturity: Final

      Implementation Maturity: Production (Limitation: Corresponds with NCPDP Formulary and Benefit Standard v50 and later which has not been named in regulation)

      Adoption Level: 1

      Federally Required: No

      Cost: $

      Test Tool Availability: No

      Appendix I – Sources of Security Standards and Security Patterns

      Comment

      End-to-End security

      IHE provides two solutions for End-to-End Security. Where End-to-End security enables an ultimate consuming system to confirm security of data regardless of the pathway the data took.

      SOAP end-to-end security -- In this model the communications of the medical sensitive data are protected for confidentiality, integrity, and availability using WS-Security or AS4 security. This model is well suited when Intermediaries are needed to support cross-boarder policies. The AS4 configuration is mandated in the EU for cross-boarder flows.

      • The WS-Security model is integrated into the XDS/XCA/XCPD infrastructure as a named option
      • The AS4 Option is defined in a Trial Implementation supplement 

      Document Encryption (DEN) and Document Digital Signatures (DSG) -- In this model the document may be protected from the source to the ultimate destination using Document Encryption and Document Digital Signatures.  This model does not require a single transport type, such as XDS or XCA end-to-end.

      • The Document Digital Signature (DSG) would protect the document regardless of the transitions between transports, using Digital Signature standards. The DSG standard is normative. The DSG  profile can sign any kind of document including CDA and FHIR-Documents. The DSG profile includes support for signatures, counter-signatures, and co-signatures. 
        • https://profiles.ihe.net/ITI/TF/Volume1/ch-37.html
      • The Document Encryption (DEN) would protect the document for confidentiality. The DEN standard is Trial-Implementation, based on highly used encryption standards. The DEN profile can encrypt any kind of document including CDA and FHIR-Documents. The DEN profile includes encryption methods using  Digital Certificate and Password. The DEN profile can also encrypt XDM content.
        • https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DEN.pdf 

      Importantly the use of DEN and DSG can be used together or independently. Where only Digital Signature is needed, one would only use DSG.

      Missing IHE specifications

      The following IHE specifications on the Privacy and Security topic are missing

      • The IHE IT Infrastructure technical white paper, Template for XDS Affinity Domain Deployment Planning outlines some of the issues that should be evaluated for inclusion in the local Policy creation and Risk Management decisions. 
      • The APPC Profile adds to the BPPC functionality the ability to include deviations from the base policy in a structured and coded format. Where BPPC is limited to agreement or not to a pre-defined policy, APPC allows for more fluid patient privacy consent function.
      • organization directory (mCSD), 
      • user authentication/authorization (IUA)
      • Consistent Time (CT). 
      • Secure Retrieve https://wiki.ihe.net/index.php/Secure_Retrieve

      See the following section in the IHE HIE whitepaper

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#7-security-and-privacy

       

      IHE - Cybersecurity Standards

      The link under the text "IHE Cybersecurity Standards" does not  reference an IHE specification. 

      For IHE the following link would be the most comprehensive https://wiki.ihe.net/index.php/Category:Security

      ISA Security Standards Recommendation

      Given the current climate of increased cybersecurity threats, HIMSS recommends that ONC take steps to increase the visibility of the ISA security standards.  With the security standards placed in the appendices due to the breadth of the material, it may be helpful to supply ISA users with a brief summary of the standards in the body of ISA that point to the greater detail in the appendices and serve as a visual roadmap for the resource.  We believe this will help users grasp the importance of looking to ISA for cybersecurity standards as well as where to apply the standards.

       

      HIMSS also emphasizes that we want to continue to be a resource to ONC moving forward on identifying the most widely-used cybersecurity standards by all stakeholders, including industry and academia.  The need for a definitive resource on cybersecurity standards is not going to subside, and HIMSS wants to be helpful to ONC and the community-at-large in identifying the standards for consideration.  

       

      HL7 FHIR Security

      The HL7 FHIR specification includes security considerations in the FHIR Security section. We propose that this be added as a Source in this sub-section.

       

       

       

      Julie Maas, CEO, EMR Direct

      Appendix II - Models and Profiles

      Comment

      NCPDP Comment

      NCPDP requests that ONC add the following:

      The National Council for Prescription Drug Programs (NCPDP) is a not-for-profit American National Standards Institute (ANSI) Accredited Standards Developer (ASD) consisting of more than 1,500 members representing entities including, but not limited to, claims processors, data management and analysis vendors, federal and state government agencies, insurers, intermediaries, pharmaceutical manufacturers, pharmacies, pharmacy benefit managers, professional services organizations, software and system vendors and other parties interested in electronic standardization within the pharmacy services sector of the healthcare industry. NCPDP provides a forum wherein our diverse membership can develop business solutions, including ANSI-accredited standards and guidance for promoting information exchanges related to medications, supplies and services within the healthcare system.

       

       

      For over 40 years, NCPDP has been committed to advancing the electronic exchange of information between healthcare stakeholders. The NCPDP Telecommunication Standard is the standard used for eligibility, claims processing, reporting and other functions in the pharmacy services industry, as named in the Health Insurance Portability and Accountability Act (HIPAA). The NCPDP SCRIPT Standard and the Formulary and Benefit Standard are the standards in use in electronic prescribing, as named in the Medicare Modernization Act (MMA).

      NCPDP Comments

      1. NCPDP recommends adding the following:

      For over 40 years, NCPDP has been committed to furthering the electronic exchange of information between healthcare stakeholders. NCPDP develops and maintains standards within the pharmacy services sector of the healthcare industry. NCPDP provides a forum wherein our diverse membership can develop solutions, including ANSI-accredited standards, and guidance for promoting information exchanges related to medications, supplies and services within the healthcare system.

      NCPDP Comments

      1. Add the following:

      The National Council for Prescription Drug Programs (NCPDP) is a not-for-profit, American National Standards Institute (ANSI) Accredited Standards Developer (ASD)  consisting of more than 1,700 members who represent drug manufacturers, chain and independent pharmacies, drug wholesalers, insurers, mail order prescription drug companies, pharmaceutical claims processors, pharmacy benefit managers, physician services organizations, prescription drug providers, software vendors, telecommunication vendors, service organizations, government agencies, professional societies and other parties interested in electronic standardization within the pharmacy services sector of the healthcare industry. NCPDP provides a forum wherein our diverse membership can develop solutions, including ANSI-accredited standards, and guidance for promoting information exchanges related to medications, supplies and services within the healthcare system.

       

      For over 40 years, NCPDP has been committed to furthering the electronic exchange of information between healthcare stakeholders. The NCPDP Telecommunication Standard is the standard used for eligibility, claims processing, reporting and other functions in the pharmacy services industry as named in HIPAA. The NCPDP SCRIPT Standard, Telecommunication Standard and the Formulary and Benefit Standard are the standards in use in electronic prescribing as named in MMA.

      IHE - Document Sharing

      The IHE Document Sharing is a framework in multiple architectures. It should be called out independent of the general IHE specifications.

      https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#

      Understanding Emerging API-Based Standards

      NCPDP Connectivity Operating Rules Implementation Guide an API Application Programming

      NCPDP Connectivity Operating Rules Implementation Guide - “An API – application programming interface – at its most basic level, allows your product or service to talk to other products or services. In this way, an API allows you to open up data and functionality to other developers and to other businesses. It is increasingly the way in which agencies and companies exchange data and services, both internally and externally”. There are common technical and practical choices companies need to be aware of when using APIs. This document lays out some of the requirements to ensure the NCPDP Standards employ the API standards appropriately.

       

      For details, refer to the Connectivity Operating Rules Implementation Guide at NCPDP Standards (https://standards.ncpdp.org/Access-to-Standards.aspx).

      Comment

      NCPDP Comments

      1. NCPDP Connectivity Operating Rules Implementation Guide - “An API – application programming interface – at its most basic level, allows your product or service to talk to other products or services. In this way, an API allows you to open up data and functionality to other developers and to other businesses. It is increasingly the way in which agencies and companies exchange data and services, both internally and externally”. There are common technical and practical choices companies need to be aware of when using APIs. This document lays out some of the requirements to ensure the NCPDP Standards employ the API standards appropriately.

       

      For details, refer to the Connectivity Operating Rules Implementation Guide at NCPDP Standards .

      Register for course Understanding Emerging API-Based Standards

      How do I register for this course: Understanding Emerging API-Based Standards

      This is not a course, just…

      This is not a course, just an educational description of API standards. 

      Patient Privacy

      The AMA wholeheartedly supports the right of patients to receive their medical information using smartphone applications (apps), but is concerned about the lack of safeguards to ensure that patients understand what they are consenting to when they grant permission to an app to access their information. These apps share sensitive health information with third parties, often without an individual's knowledge. Much of this information can end up in the hands of data brokers and be used or sold for advertising and marketing. Data being used in this way may ultimately erode patients’ privacy and their willingness to disclose information to their physicians.

      As a first step to address this issue, the AMA is calling for controls to be instituted that establish transparency as to how health information is being used, who is using it, and how to prevent the profiteering of patients’ data. To help provide a minimal amount of transparency to patients about how a health app will use their health information, the federal movement should implement a basic privacy framework requiring certified EHR vendor APIs to check an app’s “yes/no” attestations to:

      • Industry-recognized development guidance
      • Transparency statements and best practices
      • A clear privacy notice to patients

      Understanding Observations and Observation Values

      Comment

      ACLA ISA comment re: updating 2017 ISA Task Force developed cont

      We suggest this section be updated; ACLA would be happy to collaborate with ONC to update this content.

      Note: This content is referenced from ISA section "Representing Laboratory Test Performed”