Toggle comment Display

ISA Single page with Comment


This file is created on 2019-09-23 06:01:07am

Introduction to the ISA


ONC Standards


2019 ISA Reference Edition


API Resource Collection in Health (ARCH)


U.S. Core Data for Interoperability (USCDI)



Section I

Allergies and Intolerances

Representing Patient Allergic Reactions


Comment

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.

 

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.

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.

Representing Patient Allergies and Intolerances; Environmental Substances


Comment

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

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.

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.  

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.

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 

Representing Patient Allergies and Intolerances; Medications


Comment

Links and descriptions are lacking.

You link to RX Norm, but not to the value set.  How hard would it be to include https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.7/expansion

Similarly, for SNOMED CT.  You've identified 327,000 codes, but not much else.  At the very least you could identify the appropriate heirarchies.

Need to include appropriate SNOMED specifics

The Consideration: "When a medication allergy necessitates capture by medication class, SNOMED CT® should be used." would mean the use of a specific SNOMED CT subset that are descendants of  Pharmaceutical / biologic product (product) [373873005]. As a change from NDFRT this recommendation should also have specifications regarding the concern about consistency among the members of a drug class concept.

Also, it is VERY confusing that the SNOMED CT consideration noted above does not align with the SNOMED CT "starter Set" noted on the right - this set of "disorders" is a completely different thing than the substance-type recommendations every where else in this part of the ISA. This is extremely problematic and as a condition-type concept should not be used here at all. That is not to say that implementers should not consider using disorders to also represent allergies, but the ISA has consistently appropriately said that the best way to represent an allergy/intolerance reactant is using a concept that is a substance, not a condition. Don't change this.

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? 

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

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.   

Agree - MED-RT should be the…

Agree - MED-RT should be the preferred class specification. It is tied to RxNorm and reasonably sized.

Emergency Medical Services

Representing Health Care Data for Emergency Medical Services


Comment

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

Representing Patient Dental Encounter Diagnosis


Comment

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

Need code system for family…

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

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/

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

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. 

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

Functional Status/Disability

Representing Patient Functional Status and/or Disability


Comment

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.

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.

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.

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.

 

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.

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.

Health Care Providers, Family Members, and Other Caregivers

Representing Health Care Providers


Comment

Broken link

The link to National Provider Identifier Standard Implementation/Specification is broken. Please correct.

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)

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.

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)

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.

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. 

NCPDP Comment

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

Representing Provider Role in Team Care Settings


Comment

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. 

NCPDP - Comment

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

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

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.  

Representing Relationship Between Patient and Another Person


Comment

Imaging (Diagnostics, Interventions and Procedures)

Representing Imaging Diagnostics, Interventions and Procedures


Comment

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.

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.

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.

Some misunderstanding: there…

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

Immunizations

Representing Immunizations – Administered


Comment

On behalf of American…

On behalf of American Medical Association I appreciate the ability to comment on the 2017 Interoperability Standards Advisory.

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in I-G: Immunizations – Interoperability Need: Immunizations – Administered.  The CPT code set contains a comprehensive and regularly curated list of immunization product codes that are reported with an administration procedure code.  The combination of codes accurately captures what the immunization product is and that it has been administered, which has been specifically useful for tracking immunizations in the pediatric population.  CPT has a high level of maturity for its development process and implementation, and is the most widely adopted outpatient procedure code set.  It is also federally required.

VSAC links for value sets

Agree with the code system and value set identified. The VSAC direct url for this value set is https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.6/expansion. 

The RxNorm value set that should be identified is Vaccine Clinical Drug 2.16.840.1.113762.1.4.1010.8 https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.8/expansion

NCPDP - Comments

The National Drug Code (NDC) Adoption rate is a level 5

The lot number should be added as a requirement when NDC is used.  The lot number is used in conjunction with the NDC when reporting immunizations to state registries.

CVS seems more appropriate…

CVS seems more appropriate than NDC, as it is specific to immunization, and can be reconciled well with historical data that largely uses it.  A CPT to CVX valueset recommendation might be published (and has been in the past), but it should not be considered to be the primary vocabulary.

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 recommends that the adoption level for CPT be changed from “Feedback Requested” to “high or widespread adoption.” The CPT procedure codes for vaccines and immune globulins products have been in place for decades and are updated as appropriate for new products. The product codes are reported in addition to the relevant administration procedure code to accurately capture the route of immunization and counseling related to the administered vaccine product. The combination of these codes is widely used for tracking immunizations in the pediatric population. CPT has a high level of maturity for its development process and implementation, and is the most widely adopted outpatient procedure code set. It is also federally required.

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 recommends that the adoption level for CPT be changed from “Feedback Requested” to “high or widespread adoption.” The CPT procedure codes for vaccines and immune globulins products have been in place for decades and are updated as appropriate for new products. The product codes are reported in addition to the relevant administration procedure code to accurately capture the route of immunization and counseling related to the administered vaccine product. The combination of these codes is widely used for tracking immunizations in the pediatric population. CPT has a high level of maturity for its development process and implementation, and is the most widely adopted outpatient procedure code set. It is also federally required.

RxNorm Complicates Implementation

RxNorm unless it fills a specific gap not covered with the other code sets it will only complicate implementation

Agree.

Agree.

NCPDP Comment

NDC is used by pharmacy to identify and report immunizations.  Adoption rate = 5.

Representing Immunizations – Historical


Comment

Agree with the code system…

Agree with the code system and value set identified. The VSAC direct url for this value set is https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.6/expansion. 

I would like to also have the ISA include RxNorm as an additional code system to describe vaccines. That value set is Vaccine Clinical Drug 2.16.840.1.113762.1.4.1010.8 https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.8/expansion

This is clearly the right…

This is clearly the right value set for historical data, as that is the value set used.

added value of RxNorm

Given the uptake of CVX/MVX standards, what would the added value of RxNorm be in representing vaccines over CVX/MVX along?

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?  

Agree, it should not be…

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

Comments on Immunization Topics

Thank you for the opportunity to comment on these and other immunization topics related to the ISA. Our member feedback from the American Immunization Registry Association is attached. 

AIRA Letter and Comments - ONC 2018 Standards Advisory - Oct 2018.pdf

Industry and Occupation

Representing Patient Industry and Occupation


Comment

extend limitations

Add the following text to the limitations:

 

- Use of CDC Census Coding System requires registration (and request approval by CDC).

 

 

 

 

comments:

See their website after registering Thank you for requesting a user account for the NIOSH Industry and Occupation Computerized Coding System (NIOCCS). You will receive notification once your request has been processed.

 

Page updated

Thank you for this comment. The limitations field has been updated as requested. 

correction to previous comment

Based on further investigation, I would like to replace my previous comment with a 2 corrected comments:


- Occupation and Industry coding terms can be downloaded from Public Health Information Network Vocabulary Access and Distribution System.

- National Institute for Occupational Safety and Health (NIOSH) provides a web based system called NIOSH Industry & Occupation Computerized Coding System (NIOCCS) (use of this web based system requires registration and request approval by CDC)

Consider IHE profiles for…

Consider IHE profiles for CDA templates for recording of Patient Industry and Occupation.

We concur with the listing…

We concur with the listing of the CDC codes here, but believe it is also worth mentioning the Observation / Observation value paradigm here as well. LOINC has several codes that are used as the observation identifier for patient industry/occupation variables. These LOINC codes are used in the American College of Surgeons National Trauma Data Standards dictionary. In addition, the CDC/NIOSH have balloted a OCCUPATIONAL DATA FOR HEALTH section inside the standard: HL7 CDA R2 IG: Consolidated CDA Templates for Clinical Note (US -Realm), Vol. 3: Additional Templates. In this model, the variables are identified by LOINC codes and the observation values are drawn from other coding systems such as the CDC’s census codes. Last, both PhenX and NHANES have questions about occupation and industry that are represented in LOINC.

Industry and Occupation require relationship linkage

Industry and Occupation require relationship linkage.  When speaking with a patient they can easily answer occupation but tying that accurately to an industry is difficult, a smaller list based on relationships would make documentation easier.  The same difficulty is experienced by the provider trying to document both against a specific coded pick list. 

Might be split into standard…

Might be split into standard for the observation which LOINC would serve and standard for the observation value which the CDC codes would serve. Agree that in the case that a specific field is dedicated to occupation history that the CDC Census 2010 is correct.

Laboratory

Representing Laboratory Tests


Comment

On behalf of American…

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

The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in I-I: Lab Tests – Interoperability Need: Representing Laboratory Tests.  The CPT code set contains a comprehensive and regularly curated list of laboratory tests and nomenclature.  Of particular note are the Multianalyte Assay with Algorithmic Analyses (MAAA) codes, Molecular Pathology Tier 1 and Tier 2 codes, and the new Proprietary Laboratory Analyses (PLA) section of CPT.  The Molecular Pathology section addresses a growing need to identify specific laboratory procedures involving the analyses of nucleic acid to detect variants in genes.  The PLA section identifies clinical diagnostic laboratory tests (CDLTs), as well as tests that CMS designates as advanced diagnostic laboratory tests (ADLTs).  The PLA section is designed to include the full range of medical laboratory tests including, but not limited to, MAAA and Genomic Sequencing Procedures.  CPT has a high level of maturity for its development process and implementation, and is the most widely adopted outpatient procedure code set.  It is also federally required.

LOINC is absolutely right…

LOINC is absolutely right for coding tests. CPT is OK, but lacks the specificity that LOINC has.

SNOMED CT is good for microbacterial susceptibility, and certain other kinds of values, but that needs more clarity in the ISA.

UCUM should be considered for units.

We strongly concur with the…

We strongly concur with the listing of LOINC and SNOMED CT for this interoperability need, and is the solution being used successfully in many countries. 

Concur it is the right thing…

Concur it is the right thing to do. Be careful about using more than one coding system for a given purpose because it will thwart interoperability.  Believe that the NCVHS is taking a position of one code system for one purpose. 

From one HIE integrator, we…

From one HIE integrator, we get a figure of 50% of lab tests coming across with LOINC codes. The large referral labs have LOINC codes for 99%+ of their unique codes and they represent about 45% of the nation's test results. Think 50% might be a fair estimate. If so, think it deserves higher than a 3+.

The % of ordinal values with SNOMED codes are small, <5%.

feedback

consider the following text for Preconditions for Consideration section

Guidance exists for using SNOMED CT and LOINC together (link to guidance is https://confluence.ihtsdotools.org/display/DOCLOINC/5+Guidance+on+Use+of+SNOMED+CT+and+LOINC+Together

 

adoption

adoption of SNOMED CT is 1 dot.

Medications

Representing Patient Medications


Comment

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.

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

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.

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.

Nursing

Representing Clinical/Nursing Assessments


Comment

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

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.  

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.

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.

Representing Nursing Interventions


Comment

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.

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

Representing Outcomes for Nursing


Comment

Regenstrief - Comment

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

Representing Patient Problems for Nursing


Comment

Patient Clinical “Problems” (i.e., conditions)

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


Comment

Agree with Rob McClure,…

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

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.

Preferred Language

Representing Patient Preferred Language (Presently)


Comment

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.

Pregnancy Status

Representing Patient Pregnancy Status


Comment

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

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.

Procedures

Representing Dental Procedures Performed


Comment

Representing Medical Procedures Performed


Comment

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. 

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

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.
    

Race and Ethnicity

Representing Patient Race and Ethnicity


Comment

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.

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

Research

Representing Data for Biomedical and Health Services Research Purposes


Comment

medical devices terminology

This page is listing 3 terminologies but the hyperlinks are identical.

The third standard, the linked website does not have any medical devices terminology there. (not even a word device is on the page). The device terminology link should be corrected or the item removed.

I Agree this list needs…

I Agree this list needs better curation. If appropriate it should be reviewed and approved by CDISC folks. What is here is not useful.

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

 

 

 

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.

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.

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.

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.

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. 

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 

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.
 

Sex at Birth, Sexual Orientation and Gender Identity

Representing Patient Gender Identity


Comment

NCPDP - Comment

NCPDP currently uses sex/gender values of (M)ale, (F)emale and (U)nknown.  NCPDP is evaluating future modifications to include additional gender identity concepts.

Please consider appropriate…

Please consider appropriate vocabulary for preferred pronoun.  It would be extremely helpful to improve the patient-provider experience.

 

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

 

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

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.

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.

Representing Patient Sex (At Birth)


Comment

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/

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.

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

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/

 

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 

Representing Patient-Identified Sexual Orientation


Comment

Please consider a separate…

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

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

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.
 

Social, Psychological, and Behavioral Data

Representing Alcohol Use


Comment

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.

NCPDP - Comments

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

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.

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

Representing Depression


Comment

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 Exposure to Violence (Intimate Partner Violence)


Comment

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.

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.

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 Resource Strain


Comment

Representing Level of Education


Comment

Representing Physical Activity


Comment

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.

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 Connection and Isolation


Comment

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 Stress


Comment

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]

 

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.

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.

Tobacco Use

Representing Patient Electronic Cigarette Use (Vaping)


Comment

Representing Patient Second Hand Tobacco Smoke Exposure


Comment

Representing Patient Tobacco Use (Smoking Status)


Comment

Consider adding additional tobacco concepts to this standard

Thank you for making the tobacco use (smoking status) codes and value sets a little more clear than previous versions.  We would like to recommend including standard codes for smokeless tobacco, in addition to the smoking status codes.  Clinical quality measures are interested in assessing both forms of tobacco use.  We recently requested a new LOINC code for Smokeless Tobacco Status, and was approved for a future release.  This LOINC code will have the following SNOMED CT answer list:
713914004 User of smokeless tobacco (finding)

451381000124107 Smokeless tobacco non-user (finding)

TBD Former smokeless tobacco user (finding) (this code was recently requested of SNOMED CT and was approved for their next release)

In addition to having standard codes to capture the smoking or smokeless tobacco status, we feel it is also very important to have a standard way to capture the quit date for both smoking and smokeless tobacco. Here are the recommended LOINC codes:

TBD- Date Quit Smokeless Tobacco (this code was recently requested of LOINC and was approved for a future release)

74010-0 Date Quit tobacco smoking 

The rationale for this is important, in that different quality measures may have different time frames for when they consider someone a current tobacco user or not.  For example, The Joint Commission considers a person who has used tobacco products in the past 30 days a current user and someone who needs tobacco cessation interventions.  Other measure stewards may have different thresholds.  In order to capture the data once in order to re-use many times, there needs to be a standard way to codify this data in a more granular fashion.  That way, The Joint Commission eCQM could use logic to ask the tobacco use status, if the person is a "former user", then ask for the quit date, and use logic to determine if that quit date was within the past 30 days or not.  If a measure has a different threshold, the same granular level of data could be used, and their measure could use logic with a different time frame.  This would decrease the burden on implementation, because then every measure steward would not be using a different pre-coordinated term (e.g. LOINC 68535-4 to get the past 30 days, or LOINC 54845-3 to get the past 7 days) to get the information, which forces duplication of documentation just to satisfy a measure. 

 

NCPDP - Comment

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

Update with specific codes

The Joint Commission has an update to last year's comment.  We have received the following codes, and request these be added for inclusion for smokeless tobacco:

456711000124105 Former smokeless tobacco user (finding)

88030-2  Date quit smokeless tobacco

 

Smoking Status Classifications

Presently, there is much confusion about the smoking status choices and classifications in EHRs which creates overlap and confusion at the point of care when smoking status is documented.   It would be very beneficial if all EHR vendors could standardize how this important information is classified. It would be better if vendors could:

*Simplify and reduce the smoking status choices/classifications

*Remove overlapping smoking status classifications

*Use clear, non-duplicative language such as below:

           Current Every Day Smoker

           Current Some Day Smoker

           Former Smoker

           Never Smoker

           Smoking Status Unknow

It is also important to be able to assess other tobacco use as well in this same way.  I would recommend the same classifications for "Tobacco User" along with a way to collect "quit date" for those that are "former smokers" or "former tobacco users".  

 

 

Smoking status classifications: 2nd hand smoke addition, revis

Firstly, given the links between childhood exposures and development of chronic and acute illness (e.g, asthma, allergies, ear infections) there should be entries for exposure to secondhand smoke as a child, adolescent / adult, and currently.   I hope  these entries will eventually  be seen as the left side of a dose-response curve. 

Further, I think there are advantages to classifying "less than 8 cigarettes" per day as light tobacco use, 8- 16 cigarettes as intermediate tobacco use, and more than 16 cigarettes per day as heavy tobacco use.  If a some is a former tobacco user, the quit date should be listed next to the classfication, along with some indication of the nature of use. 

Lastly, I think EHRs have to explicitly and accurately capture nicotine use in the context of addiction.  For this reason, there should be a linked series of classifications for nicotine delivery devices. And since tobacco use involves a constellation of harms attributable (1) toxic exposure and (2) addiction to nicotine,  there should be entries tracking use of multiple nicotine delivery systems (snus, cigarettes, cigars,  etc) when used simultaneously.  

Scott Matthews MD MPH

Smoking Status Versus Tobacco Use

Increased charting requirements - Consider the degree of clinical value and how that information would actually be employed in the care of the patient versus the increase provider burden required in documenting. Comparing Snomed smoking status versus Tobacco use below. Unless it’s a specific use smoking status is sufficient.

Smoking status versus  Tobacco Use SNOMED versus LOINC

  • The only real cost to switching is implementation time and retraining. Is the clinical impact worth the effort/expense?

Smoking status Value Set Name Smoking Status  Code System      SNOMEDCT   OID        2.16.840.1.113883.11.20.9.3

  • 8 charting values

Tobacco Use SNOMED 2.16.840.1.113883.11.20.9.41 Contains all values descending from the SNOMED CT 365980008 tobacco use and exposure

  • 63 charting values

Simpler, non-overlapping Smoking Status classifications

Thank you for the opportunity to provide input on Smoking Status documentation in the EHR.

The major concern with the current smoking status classifications is that the choices are not mutually exclusive, creating overlap and confusion at the point of care when smoking status is documented.

Overlap and confusion is created by:

  • Vagueness of “some day” smoker (i.e. what frequency?).
  • Vagueness of “heavy” and “light” smoker (i.e. number of cigarettes/day).
  • Vagueness of “former smoker” (i.e. how long since quit?).
  • Each patient is documented with one smoking status which creates overlap:
    • “Current every day smoker” and “light smoker”.
    • “Current every day smoker” and “heavy smoker”.
    • “Current some day smoker” and “light smoker”.
  • Uncertainty that all clinical staff who are identifying and documenting patient smoking status are using consistent definitions for each category.

In an effort to clarify and streamline “Smoking Status” documentation, we recommend that ONC simplify and promote non-overlapping criteria for smoking status documentation in the EHR.  The clear, non-duplicative smoking status classifications that we recommend for the ONC ISA and EHR Certification Program are:

Smoking Status

SNOMED CT Code

Current Every Day Smoker

449868002

Current Some Day Smoker

428041000124106

Former Smoker

8517006

Never Smoker

266919005

Smoking Status Unknown

266927001

We fully support the continuation of smoking status being documented for each patient age 13 years old and older.

Michael Fiore, MD, MPH, MBA                                              Robert Adsit, MEd

Professor of Medicine, Director                                             Director of Education and Outreach

University of Wisconsin School of Medicine and Public Health Center for Tobacco Research and Intervention

 

Smoking Status Documentation in the EHR

Our group includes researchers, academicians in the area of tobacco, and tobacco dependence treatment counselors. We concur with ATTUD member Rob Adsit and colleagues who advocate to:

  • Simplify and reduce the smoking status choices/classifications.
  • Remove overlapping smoking status classifications.
  • Recommended clear, non-duplicative smoking status classifications.
  • Use new smoking status classifications as follows:
    • Current Every Day Smoker
    • Current Some Day Smoker
    • Former Smoker
    • Never Smoker
    • Smoking Status Unknown

In addition, our suggestions and comments also include the following:

  1.  Simplified list [5 (above) vs. 8] is definitely better. 
    1. Whatever is decided, the classifications should map to ICD-10 or whatever standardized diagnostic codes are appropriate.
    2. Concurrent other tobacco and e-cigarette use is not captured with these suggested classifications.
  2. Question language is needed that allows the provider to funnel the patient according to these suggested categories and best solicit true answers. There is currently no consensus on measurement with regards to how this is conducted.
  3. If cigarette use is on the decline, there should be thought given to how overall substance use/abuse is addressed in health/social histories.
  4. Research suggests documentation of tobacco using classifications/codes is less frequent than tobacco use documentation occurring in the progress notes. If there is a way that categories can be automatically assigned as the provider asks the patient questions? 

Recent papers:

Challenges with Collecting Smoking Status in Electronic Health Records 

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5977725/

 

Validating the use of veterans affairs tobacco health factors for assessing change in smoking status: accuracy, availability, and approach

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5948734/

current smoker…

current smoker

former smoker

never smoker

smokeless tobacco use

there is no safe level of cigarette use so why does it matter if someone is a some day smoker

protocol is to ask each patient every time about tobacco  so "unknown" should not be allowed

 

Dear ONC,…

Dear ONC,

As a physician scientist with my research focus on smoking cessation, I recommend to simplify and reduce the smoking status choices by removing overlapping smoking status classifications, and presenting clear, non-duplicative smoking status choices.

Please see my letter attached. 

Sincerely, 

Li-Shiun Chen, M.D., M.P.H., Sc.D.

Associate Professor of Psychiatry

Washington University School of Medicine in St. Louis

Campus Box 8134, 660 South Euclid Avenue

St. Louis, Missouri 63110

li-shiun@wustl.edu; Phone: 314-362-3932; Fax: 314-362-4247

 

ONC comments about EHR smoking status Sep 27 2018.doc

Units of Measure

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


Comment

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. 

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  1 
the number ten for arbitrary powers  10n  10^  10^  no 10  1 

 

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

 

 

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.

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. 

Vital Signs

Representing Patient Vital Signs


Comment

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…

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

 

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.

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.

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. 


Section II

Admission, Discharge, and Transfer

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


Comment

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


Comment

Consider IHE Patient…

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

 

Care Plan

Documenting and Sharing Care Plans for a Single Clinical Context


Comment

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

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.

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.

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.

Documenting and Sharing Medication-Related Care Plans by Pharmacists


Comment

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.

Domain or Disease-Specific Care Plan Standards


Comment

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

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. 

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. 

Sharing Patient Care Teams for Care Planning in Multiple Clinical Contexts


Comment

Clinical Decision Support

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


Comment

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

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

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

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. 

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

 

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

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.

Diet and Nutrition

Exchanging Diet and Nutrition Orders Across the Continuum of Care


Diet and Nutrition Orders

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.

Drug Formulary & Benefits

Allows Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescriber Systems


Comment

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.

Electronic Prescribing

Allows a Long Term or Post-Acute Care to Request to Send an Additional Supply of Medication


Comment

Allows a Pharmacy to Notify a Prescriber of Prescription Fill Status


Comment

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

Allows a Pharmacy to Request a Change to a Prescription


Comment

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

Allows a Pharmacy to Request a New Prescription For a New Course of Therapy or to Continue Therapy


Comment

Allows a Pharmacy to Request Additional Refills


Comment

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

Allows a Pharmacy to Request, Respond to, or Confirm a Prescription Transfer


Comment

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.

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

Allows a Prescriber or a Pharmacy to Request a Patient’s Medication History


Comment

NCPDP - Comment on Version 10.6

The second bullet under Limitations, Dependencies, and Preconditions for Consideration should be modified to include Hospitals and Accountable Care Organizations (ACOs).

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 Comment

  1. NCPDP supports the use of the NCPDP SCRIPT RxHistoryRequest/RxHistoryResponse transactions for PDMP.

Allows a Prescriber to Cancel a Prescription


Comment

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

Allows a Prescriber to Communicate Drug Administration Events


Comment

Allows a Prescriber to Communicate with a REMS Administrator


Comment

Allows a Prescriber to Prescribe Medication Using Weight-Based Dosing


Comment

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.

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

Allows a Prescriber to Recertify the Continued Administration of a Medication Order


Comment

Allows a Prescriber to Request a Patient’s Medication History from a State Prescription Drug Monitoring Program (PDMP)


Comment

PDMP Medication History using NCPDP SRIPT v10.6

NCPDP SCRIPT v10.6 was piloted by the S&I Framework and shown to effectively allow a prescriber to inquire into a PDMP using NCPDP's SCRIPT RxHistory request transaction and receive a RxHistory response. It is recommended that this standard be named so that prescriber and pharmacy system vendors can enhance systems so that these entities can obtain PDMP patient information within workflow. SCRIPT version 2017071 has recently been named in a CMS NPRM for comment and includes recommended changes as a result of the 10.6 pilots.

The Pharmacy HIT Collaborative supports the use of NCPDP SCRIPT

The Pharmacy HIT Collaborative supports the use of NCPDP SCRIPT Standard, Implementation Guide Versions 10.6, as well as the move to NCPDP SCRIPT Standards, Implementation Guide, Version 2017071 and HL7 FHIR Implementation Guide, US Meds STU2 as soon as participants can be ready to implement such a change. We also recommend including NCPDP SCRIPT Standard Implementation Guide Version 2013101.

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 a Prescriber to Request, Cancel or Appeal Prior Authorization for Medications


Comment

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.

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

  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.

 

Allows a Prescriber to Send a New Prescription to a Pharmacy


Comment

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

Allows a Prescriber to Send a Prescription to a Pharmacy for a Controlled Substance


Comment

Allows for Communication of Prescription Information Between Prescribers and Dispensers