Toggle comment Display

ISA Single page with Comment


This file is created on 2018-05-18 11:00:26am

Introduction to the ISA


 

The Interoperability Standards Advisory (ISA) process represents the model by which the Office of the National Coordinator for Health Information Technology (ONC) will coordinate the identification, assessment, and public awareness of interoperability standards and implementation specifications that can be used by the healthcare industry to address specific interoperability needs including, but not limited to, interoperability for clinical, public health, and research purposes. ONC encourages all stakeholders to implement and use the standards and implementation specifications identified in the ISA as applicable to the specific interoperability needs they seek to address. Furthermore, ONC encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in the ISA. For historical background on the ISA please review prior ISA publications.

The 2018 ISA has been updated to include improvements made based on recommendations received from public comments and subject matter expert feedback.  To learn more about major revisions of the ISA, please review recent ISA updates. Registered users may subscribe to change notifications to be alerted by e-mail of all revisions to individual interoperability needs or for ISA-wide changes. Anyone may become a registered user by submitting an account request. Once logged in, look for the blue “change notification” button at the bottom of the interoperability need page, or at the bottom of the home page to be notified of any changes across the ISA. 

Note that due to the volume of comments received, some comments will be addressed, with feedback incorporated to the web version of the ISA in early 2018.

Scope

Starting with the 2017 ISA, the ISA’s focus expanded to more explicitly include public health and health research interoperability. Thus, its scope includes electronic health information created in the context of treatment, and subsequently used to accomplish a purpose for which interoperability is needed (e.g., a referral to another care provider, public health reporting, or research). In late 2017, and included in the 2018 Reference Edition, the ISA now also includes interoperability needs related to Administrative functions within healthcare. These additions were made through coordination with CMS, and it is anticipated to include other administrative healthcare interoperability needs throughout 2018. 

The ISA is not exhaustive but it is expected to be incrementally updated to include a broader range of health IT interoperability needs. When more than one standard or implementation specification is listed it is intended to prompt industry dialogue as to whether one standard or implementation specification is necessary or if the industry can efficiently interoperate more than one. It may also reflect the fact that there is an ongoing transition from the use of one standard towards a new version or even next-generation approach.

As noted in previous ISA publications, a standard listed in one section is not intended to imply that it would always be used or implemented independent of a standard in another section. To the contrary, it will often be necessary to combine the applicable standards from multiple sections to achieve interoperability for a particular clinical health information interoperability need.

It is also important to note that the ISA is designed to inform standards and implementation specification choices for all types of health IT that support interoperability needs, not solely electronic health record (EHR) systems. Furthermore, the ISA is not intended to imply that health IT systems need to support all of the listed standards and implementation specifications. Rather, in the event that a health IT developer or healthcare provider seeks to address a particular interoperability need, the ISA should serve as the first resource consulted to inform the selection of standards and implementation specifications. Additionally, the ISA is designed to inform the “what” that could be used to address an interoperability need in order to assure industry consistency around standards selection and is not mean to explicitly direct “how” the standards and implementation specifications would be implemented to address an interoperability need (e.g., application programming interface or conversion tools).

The ISA is designed to be a coordinated catalog of standards and implementation specifications that can be used by different stakeholders to consistently address a specific interoperability need. However, a listed interoperability need (and its associated standard(s) and implementation specifications(s)) is not meant to universally apply to all stakeholders. Rather, if a listed interoperability need is relevant to a particular clinical specialty, for example, the ISA is designed to provide a consistent foundation from which these stakeholders can agree on applicable technical requirements. Similarly, in cases where a listed interoperability need is not applicable to a given stakeholder group, the ISA in no way compels such stakeholders to consider that interoperability need. 

Purpose

The Interoperability Standards Advisory is meant to serve at least the following purposes:

  1. To provide the industry with a single, public list of the standards and implementation specifications that can best be used to address specific clinical health information interoperability needs. Currently, the ISA is focused on interoperability for sharing information between entities and not on intra-organizational uses.  
  2. To reflect the results of ongoing dialogue, debate, and consensus among industry stakeholders when more than one standard or implementation specification could be used to address a specific interoperability need, discussion will  take place through the ISA public comments process. The web-version of the ISA improves upon existing processes, making comments more transparent, and allowing for threaded discussions to promote further dialogue.
  3. To document known limitations, preconditions, and dependencies as well as provide suggestions for security best practices in the form of security patterns for referenced standards and implementation specifications when they are used to address a specific clinical health IT interoperability need. 

The ISA is designed to provide clarity, consistency, and predictability for the public regarding the standards and implementation specifications that could be used for a given clinical health IT interoperability purpose.

Stakeholders who administer government programs, procurements, and testing or certification programs with clinical health IT interoperability components are encouraged to look first to the ISA in order to more fully inform their goals. In that regard, standards and implementation specifications in the ISA and their associated informative characteristics are also available to help more fully inform policymaking. In this case, a standard or implementation specification’s reference in the ISA may serve as the initial basis for industry or government consideration and action.  While the ISA itself is a non-binding document and meant to be advisory in nature, standards and implementation specifications listed in the ISA may be considered for rulemaking or other Federal requirements. However, those decisions would be made on a case-by-case basis by the administering organization.

ISA Structure

The ISA is organized and structured into five sections.

  • Section I – Vocabulary/Code Sets/Terminology Standards and Implementation Specifications (i.e., “semantics”).
  • Section II – Content/Structure Standards and Implementation Specifications (i.e., “syntax”).
  • Section III – Standards and Implementation Specifications for Services (i.e., the infrastructure components deployed and used to address specific interoperability needs)
  • Section IV – Models and Profiles
  • Section V – Administrative Standards and Implementation Specifications (i.e., payment, operations and other "non-clinical" interoperability needs)
  • Section VIQuestions and Requests for Stakeholder Feedback
  • Appendices 

Within each section specific “interoperability need” subheadings are listed and followed by tables similar to the one illustrated below.  Each interoperability need may have one or more standards and/or implementation specifications associated with it. Each standard and implementation specification has six informative characteristics attributed to it in order to provide added context.

When known, an “emerging” standard or implementation specification is also listed and is shaded in a lighter color and italicized for additional emphasis. In addition, for vocabulary standards, where there may be one standard used to represent the “observation” or question being asked, and one standard used for the “observation value” or answer these are listed in distinct rows. See Appendix II for educational information about observations and observation values. 

The ISA also includes links within the limitations, dependencies and preconditions to ONC’s Interoperability Proving Ground (IPG) to showcase real-world implementations of standards listed within the ISA. Please note: when accessing links to the IPG, all projects for the selected standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs. In addition, IPG entries are self-reported by stakeholders, so the quality and accuracy of the data may vary across entries.

In Section I, the vocabulary standards with unspecified code sets or context may be further constrained by a more explicit standard named in a subsequent section. For example, I-B Encounter Diagnoses specifies SNOMED-CT and ICD-10-CM but does not define the context of use. The Standard/Implementation Specification named for the “Interoperability Need: Ordering Labs for a Patient in Section II-L: Laboratory” further constrains the diagnosis for the patient in the context of a lab order to ICD-9CM or ICD-10CM since the lab order diagnosis is for billing/claims, not clinical diagnostics.

Interoperability need: [Descriptive Text]
Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally Required Cost Test Tool Availability
Standard Final Production rating 4 No Free No
Standard for observations Final Production rating 4 Yes Free Yes
Standard for observation values Final Production rating 4 No Free Yes
Emerging Standard Balloted Draft Pilot rating 4 No Free No
Limitations, Dependencies, and Preconditions for Consideration:

Section I: Applicable Value Set(s) and Starter Set(s):

Other Sections: Applicable Security Patterns for Consideration:

  • In the case where there is a need to reflect a conformance statement, the verbs “must” and “shall” will reflect an absolute requirement and the verbs “can” and “may” reflect optionality.
  • Where standards listed for an interoperability need have active projects listed on ONC’s Interoperability Proving Ground, a link to that standard will be provided in this section. Please note, all projects for the standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs.
  • Descriptive text

The following describes the ISA’s six informative characteristics in greater detail.  This detail is meant to better inform stakeholders about the maturity and adoptability of a given standard or implementation specification and provides definition for the terms and symbols used throughout the ISA.  These definitions remain similar in nature to those originally presented in the 2016 ISA, but have been modified slightly to provide additional clarity as requested by public comments. Stakeholders should consider all six characteristics together to gain insight into the level of maturity and adoptability of the standards and implementation specifications provided within the ISA.

#1: Standards Process Maturity
This characteristic conveys a standard or implementation specification’s maturity in terms of its stage within a particular organization’s approval/voting process.

  • “Final” – when this designation is assigned, the standard or implementation specification is considered “final text” or “normative” by the organization that maintains it. This also includes approved “ANSI Informative” specifications.
  • “Balloted Draft” – when this designation is assigned, the standard or implementation specification is considered to be a Draft Standard for Trial Use (DSTU), Standard for Trial Use (STU), or in a “trial implementation” status by the organization that maintains it and has been voted on or approved by its membership as such. This designation does not include standards and implementation guides that are unofficial drafts and early “works in progress”.
  • “In Development” – when this designation is assigned, the standard or implementation specification is currently in development. It also includes those that are in the midst of being balloted.  These standards would generally benefit from lessons learned through development and pilots.

#2: Implementation Maturity
This characteristic conveys a standard or implementation specification’s maturity based upon its implementation state. Where available, a link to published maturity assessments based on known published criteria about the standards is also provided. 

  • “Production” – when this designation is assigned, the standard or implementation specification is being used in production to meet a health care interoperability need.
  • “Pilot” – when this designation is assigned, the standard or implementation specification is being used on a limited scale or only as part of pilots to meet a health care interoperability need.

#3: Adoption Level
This characteristic conveys a standard or implementation specification’s approximate, average adoption level for that specific interoperability need in health care within the United States. The adoption level attempts to consider all implemented technology that would be used to address the identified interoperability need and is not limited to EHRs.  Adoption means that the standard or implementation specification is being used in health IT in the field by end users to address the specific interoperability need. Presently, the adoption levels listed are based on ONC’s analysis of several factors, including, but not limited to: 1) whether and/or how long a standard or implementation specification has been included in regulation for health IT certification (if applicable) or another HHS regulatory or program requirement which is used only as a proxy for industry adoption; 2) feedback from subject matter experts and 3) public comments. 

The adoption level also considers the variety of stakeholders and stakeholder groups that would use the standard and implementation specification to address the specified interoperability need and attempts to display it as such, with the understanding that the designation is a generality or "best guess" and not a pre-defined measured value. Where available, annotated references or links to publicly available documentation known about adoption levels for listed standards is also provided. 

The following scale is used to indicate the approximate, average adoption level among the stakeholders that would use a standard or implementation specification to meet the specified interoperability need:

“Feedback Requested” Indicates that we do not have a known status for the current level of adoption in health care.
rating 1 Indicates low adoption.
rating 2 Indicates low-medium adoption.
rating 3 Indicates medium adoption.
rating 4 Indicates medium-high adoption.
rating 5 Indicates high or widespread adoption.

#4: Federally Required
This characteristic (provided as a “Yes” or “No”) conveys whether a standard or implementation specification has been adopted in regulation, referenced as a federal program requirement, or referenced in a federal procurement (i.e., contract or grant) for a particular interoperability need. Where available, a link to the regulation has been provided. Please note this is meant to be provided as a reference only. Entities seeking to comply with federal regulations should look to any and all federal regulations that may apply to ensure adequate compliance. 

#5: Cost
This characteristic conveys whether a fee is involved to purchase, license, or obtain membership for access or use of the recommended standard or implementation specification.

  • $” – when this designation is assigned, it signifies that some type of payment needs to be made in order to obtain the standard or implementation specification. Where known, the estimated cost for access will be provided.
  • Free” – when this designation is assigned, it signifies that the standard or implementation specification can be obtained without cost. This designation applies even if a user account or license agreement is required to obtain the standard at no cost, but is not meant to imply that there are no costs associated with implementation.

#6: Test Tool Availability
This characteristic conveys whether a test tool is available to evaluate health IT’s conformance to the standard or implementation specification for the particular interoperability need. Where available, a link will be provided to the publicly available test tool. 

  • “Yes” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is free to use. Where available, a hyperlink pointing to the test tool will be included.
  • “Yes$”– When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and has a cost associated with its use. Where available, a hyperlink pointing to the test tool will be included.
  • “Yes – Open” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is available as open source with rights to modify. Where available, a hyperlink pointing to the test tool will be included.
  • “No” – When this designation is assigned, it signifies that no test tool is available for a standard or implementation specification.
  • “N/A” – When this designation is assigned, it signifies that a test tool for the standard or implementation would be “not applicable.”

Representing Patient Allergic Reactions


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
No
Free
N/A
Standard for observation values
Final
Production
Rating 4
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • SNOMED CT® may not be sufficient to differentiate between an allergy or adverse reaction, or the level of severity
  • For use of SNOMED CT®, codes should generally be chosen from the Clinical finding axis
  • See LOINC projects in the Interoperability Proving Ground.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

 

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.

Representing Patient Allergies and Intolerances; Medications


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • When a medication allergy necessitates capture by medication class, SNOMED CT® should be used.
  • RxNorm: Refers to the RxNorm source specifically (and not to other sources that are included with the RxNorm download).

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.

Representing Patient Allergies and Intolerances; Food Substances


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested

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.

Representing Patient Allergies and Intolerances; Environmental Substances


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested

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 Medical Encounter Diagnosis


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 4
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Use of SNOMED CT® codes should generally be chosen from three axes: Clinical finding, Situation with explicit context, and Event.
  • The use of these standards may be further constrained by other standards and implementation specifications found elsewhere in the ISA.
  • Systems should be able to process (or at minimum display) data coded using the older ICD-9-CM standard, as this legacy content still exists and may be used for analysis/decision support/quality measurement needs, where retroactive analysis is often required, but ICD-9 should not be collected for new entries.
  • A mapping from SNOMED CT® to ICD-10-CM is available from the National Library of Medicine to support semi-automated generation of ICD-10-CM codes from clinical data encoded in SNOMED CT for reimbursement and statistical purposes.
  • Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 (SNOMED CT® code system)
  • Recommended starter set: CORE Problem List Subset urn:oid: 2.16.840.1.113762.1.4.1018.240

Comment

Representing Patient Dental Encounter Diagnosis


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
$
N/A
Standard
Final
Production
Rating 4
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • 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.
  • OID 2.16.840.1.113883.3.3150

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 Family Health History


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
No
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Some details around family genomic health history may not be captured by SNOMED CT®
  • See LOINC projects in the Interoperability Proving Ground.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

Diagnosis and Conditions:

  • Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 (LOINC® code system)
  • Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 (SNOMED CT® code system)

For genomic data:

  • Gene Identifier: HGNC Value Set (2.16.840.1.113883.4.642.2.468)
  • Transcript Reference Sequence Identifier: NCBI vocabulary
  • DNA Sequence Variation Identifier: NCBI vocabulary
  • DNA Sequence Variation: HGVS nomenclature (2.16.840.1.113883.4.642.2.392)

For family relationships and roles:

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/

Representing Patient Functional Status and/or Disability


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
No
Free
N/A
Standard for observation values
Final
Production
Rating 3
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

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.

Representing Health Care Providers


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • NPPES permits non-billable care team members to apply for an NPI number to capture the concept of ‘person’.
  • NPI taxonomy does not describe all roles associated with an individual’s care team, however, NUCC Health Care Provider Taxonomy codes cover concepts of other 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)

Representing Provider Role in Team Care Settings


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • NUCCPT codes capture roles of direct care providers as well as other members of the care team as well as those provider supporting health services.

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

Representing Imaging Diagnostics, Interventions and Procedures


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)

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.

Representing Immunizations – Historical


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • CVX codes are designed to represent administered and historical immunizations and will not contain manufacturer-specific information.

  • When an MVX code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated providing further specificity as to the vaccines administered.

  • While the information is very helpful, MVX is fairly rare to have for historical vaccinations and is unrealistic to have providers collect.

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?

Representing Immunizations – Administered


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
No
Free
N/A
Standard
Final
Production
Feedback Requested
Yes
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
N/A
Standard
Final
Production
Rating 4
No
$
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • HL7 CVX codes are designed to represent administered and historical immunizations and will not contain manufacturer-specific information.
  • If an MVX code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated providing further specificity as to the vaccines administered.
  • There is a potential issue with use of the National Drug Code regarding which code to use when there are multiple active ingredients in a single package or multiple separate ingredients that need to be mixed together.
  • CPT is an acceptable alternative code set for local use, but may have limitations for interoperability across systems. 

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.

Representing Patient Industry and Occupation


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
In Developement
Pilot
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The CDC_Census 2010 system is used by the National Institute for Occupational Safety and Health (NIOSH) to classify industry and occupation entries in over 1 million records each year from health data collection systems such as health surveys, registries, and death records. They are based on the US Census' industry and occupation classification system, which is based on the North American Industry Classification System (NAICS) and Standard Occupational Classification (SOC) System. The CDC_Census system provides useful detail for the care provider and meets other federal requirements for statistical analysis.
  • NIOSH is developing updates to these value sets to include more detailed titles based on the Census Bureau Alphabetical Indexes for Industry and Occupation and will incorporate military service and occupation.  A tool for collecting patient industry and occupation titles in electronic health records is also under development.

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.

Representing Laboratory Tests


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
Yes
Free
N/A
Standard for observation values
Final
Feedback requested
Feedback Requested
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Laboratory test and observation work in conjunction with values or results which can be answered numerically or categorically.  If the value/result/answer to a laboratory test and observation is categorical that answer should be represented with the SNOMED CT® terminology. 
  • A single lab test with a single result will have the same LOINC® term for its order and result answer, but a panel order will have an order LOINC® term and multiple result LOINC® terms for each result in the panel. 
  • A single lab test with a single result may have the same LOINC® code for the order and the result or may have a more specific code in the result (for example if the order code was method less or did not declare the system property). A panel order will have an order LOINC® code and multiple result LOINC® terms for each result in the panel.  
  • See LOINC projects in the Interoperability Proving Ground.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

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. 

Representing Patient Medications


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
Yes
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Emerging Standard
In Developement
Pilot
Rating 1
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The use of NDC in conjunction with RxNorm can help minimize gaps in representing medications, including compounded products, over -the-counter medications, and herbals.
  • MED-RT allows for representing classes of medications when specific medications are not known.
  • Immunizations are not considered medications for this interoperability need.
  • RxNorm is often used for the exchange of information; however, it may not be available for export and import by end users.
  • Grouping Value Set: Medication Clinical Drug 2.16.840.1.113762.1.4.1010.4
    • Medication Clinical General Drug (2.16.840.1.113883.3.88.12.80.17)
    • Medication Clinical Brand-specific Drug (2.16.840.1.113762.1.4.1010.5) (RxNorm).
  • Grouping Value Set: Clinical Substance 2.16.840.1.113762.1.4.1010.2
    • Medication Clinical Drug (2.16.840.1.113762.1.4.1010.4) (RxNorm )
    • Unique Ingredient Identifier - Complete Set (2.16.840.1.113883.3.88.12.80.20) (UNII)

Comment

NCPDP - Comments

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.

Representing Clinical/Nursing Assessments


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
No
Free
N/A
Standard for observation values
Final
Production
Rating 1
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Assessments are represented as question/answer (name/value) pairs.
  • Codes should generally be chosen from two axes: Clinical finding and Situation with explicit context.
  • When representing validated scales, LOINC should be used for the question and LOINC answers (LA Codes) should be used for the answers
  • See LOINC projects in the Interoperability Proving Ground.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 
  • Feedback requested

Comment

Representing Nursing Interventions


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Coded interventions may be linked as related/dependent concepts to observations and assessments, as appropriate.
  • The Procedure axis of SNOMED CT is the terminology used for 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.

Representing Outcomes for Nursing


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Feedback Requested
No
Free
N/A
Standard for observation values
Final
Production
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Other ANA-recognized terminologies should be mapped to LOINC® for comparison across health systems and/or transmission.
  • Use LOINC® if the outcome is a measurement.
  • Use SNOMED CT® if the outcome is an observed assessment that a patient state has improved.  In addition, when the outcome is recorded as an assertion (e.g., normotensive, afebrile, etc.) the terminology to be used is SNOMED CT®. 
  • See LOINC projects in the Interoperability Proving Ground.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 
  • Feedback requested

Comment

Representing Patient Problems for Nursing


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observation values
Final
Production
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The use of SNOMED CT® for this interoperability need, codes should generally be chosen from two axes: Clinical finding and Situation with explicit context.
  • Local and other ANA-recognized terminologies should be converted to SNOMED CT® for comparison across health systems and/or transmission.

Comment

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


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observation values
Final
Production
Rating 5
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The use of SNOMED CT® for this interoperability need, codes should generally be chosen from three axes: Clinical finding, Situation with explicit context, and Event.
  • SNOMED CT® supports the combination of codes (post-coordination) to generate new meaning. Codes from other axes can be used in post-coordination. The need to pick multiple codes may be seen as a disadvantage. This can be avoided if post-coordination is limited to the backend, exposing a single code for users to pick.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

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.

Representing Patient Preferred Language (Presently)


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • RFC 5646 encompasses ISO 639-1, ISO 639-2, ISO 639-3 and other standards related to identifying preferred language
  • Language urn:oid:2.16.840.1.113883.1.11.11526 (based off RFC 4646. This will be updated to reflect RFC 5646)

Comment

Representing Patient Pregnancy Status


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
No
Free
No
Standard for observation values
Final
Production
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

Comment

Representing Dental Procedures Performed


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
$
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested
  • Feedback requested

Comment

Representing Medical Procedures Performed


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
$
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • ICD-10-PCS  is primarily a billing code used only in inpatient settings.
  • CPT and HCPCS are codes used to report procedures and services in outpatient srocedures.
  • ICD-10-PCS is named in the 2015 Edition certification rules as an optional code set for procedures.
  • SNOMED CT procedure codes can be used to describe treatment in any clinical setting and is not tied to billing, but can be cross-mapped to corresponding ICD-10-PCS and CPT/HCPCS codes.
  • Feedback requested

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. 

Representing Patient Race and Ethnicity


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Feedback Requested
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The CDC Race and Ethnicity Code Set Version 1.0, which expands upon and can be rolled up to the OMB standards may help to further define race and ethnicity for this interoperability need as it allows for multiple races and ethnicities to be chosen for the same patient.

  • The high-level race/ethnicity categories in the OMB Standard may be suitable for statistical or epidemiologic or public health reporting purposes but may not be adequate in the pursuit of precision medicine and enhancing therapy or clinical decisions.

  • LOINC® provides observation codes for use in the observation / observation value pattern for communicating race and ethnicity.

  • The LOINC answers for Race look similar to CDC/HL70005, but don’t match; this may be confusing to implementers.
  • When clinically significant, the patient's "race" or “ethnicity” should be managed using an "Ask on Order Entry" question (AOE). This process is defined in the eDOS Implementation Guide developed through the ONC Standards & Interoperability Framework, and is designed work in conjunction with the LOI Implementation Guide, also developed through the ONC S&I Framework. For example, Glomerular Filtration Rate, Estimated (eGFR) results reference ranges vary based on race.
  • Race (5 codes): Race Category Excluding Nulls urn:oid:2.16.840.1.113883.3.2074.1.1.3
  • Race (extended set, 900+codes): Race urn:oid:2.16.840.1.113883.1.11.14914
  • Ethnicity: Ethnicity urn:oid:2.16.840.1.114222.4.11.837
  • Ethnicity (extended set, 43 codes):  Detailed Ethnicity urn:oid:2.16.840.1.114222.4.11.877

Comment

Representing Analytic Data for Research Purposes


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Feedback requested
Feedback Requested
Yes
Free
N/A
Standard
Final
Feedback requested
Feedback Requested
Yes
Free
N/A
Standard
Final
Feedback requested
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested
  • Feedback requested

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.

Representing Patient Gender Identity


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
No
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Collect discrete structured data on patient gender identity, sex, and sexual orientation following recommendations issued in a report by The Fenway Institute and the Institute of Medicine.
  • Even though clinicians and their patients would benefit from having these data in patient records, this does not suggest that it is the sole responsibility of clinicians and their staffs to collect these sensitive data.
  • When patients provide a response to this question in a patient portal, it could contradict with the information collected by providers.
  • See LOINC projects in the Interoperability Proving Ground.
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

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

Representing Patient Sex (At Birth)


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 5
No
Free
N/A
Standard for observation values
Final
Production
Rating 5
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • HL7 Version 2 and 3 need to be harmonized.

  • See LOINC projects in the Interoperability Proving Ground.

  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

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

Representing Patient-Identified Sexual Orientation


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Feedback requested
Feedback Requested
No
Free
N/A
Standard for observation values
Final
Feedback requested
Feedback Requested
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Collect discrete structured data on patient gender identity, sex, and sexual orientation following recommendations issued in a report by The Fenway Institute and the Institute of Medicine.
  • See LOINC projects in the Interoperability Proving Ground. 
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 
  • LOINC® code: 76690-7 Sexual orientation
  • ONC’s 2015 Edition certification requirements reference the following value set for sexual orientation.  Codes from (i) through (iii) are SNOMED CT® and (iv) through (vi) are from HL7 Version 3:

(i) Lesbian, gay or homosexual.38628009
(ii) Straight or heterosexual. 20430005
(iii) Bisexual. 42035005
(iv) Something else, please describe.nullFlavor OTH
(v) Don’t know. nullFlavor UNK
(vi) Choose not to disclose. nullFlavor ASKU

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

Representing Financial Resource Strain


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)

Comment

Representing Level of Education


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)

Comment

Representing Stress


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • A single-question stress measure primarily tested in Scandinavian populations is part of the Occupational Stress Questionnaire™ (Q41) developed by the Finnish Institute of Occupational Health is best suited for this interoperability need.
  • See LOINC projects in the Interoperability Proving Ground.

Occupational Stress Questionnaire™ Q41 LOINC® code 76542-0

LOINC® answer list LL3267-3

Comment

Representing Depression


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The Patient Health Questionnaire 2 item (PHQ-2) is a 2-question initial screen for symptoms of depression in the past 2 weeks.  It consists of the first 2 questions of the PHQ-9, which can determine if an individual meet criteria for a depressive disorder, and is best suited for this interoperability need.
  • See LOINC projects in the Interoperability Proving Ground.

PHQ-2 panel LOINC® code 55757-9

  PHQ-2 member codes

  PHQ-2 Q1 LOINC® 44250-9

  PHQ-2 Q2 LOINC® 44255-8

  PHQ-2 Total Score LOINC® 55758-7

PHQ-9 panel LOINC® code 44249-1

Comment

Representing Physical Activity


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The Two-question screen, "moderate to strenuous activity in last 7 days" adapted by SAMHSA from the Kaiser Permanente Exercise Vital Sign screen of physical activity is best suited for this interoperability need.
  • See LOINC projects in the Interoperability Proving Ground.
  • How many days of moderate to strenuous exercise, like a brisk walk, did you do in the last 7 days? LOINC® code 68515-6
  • On those days that you engaged in moderate to strenuous exercise, how many minutes, on average, did you exercise? LOINC® code 68516-4
  • Responses use applicable UCUM unit of measure

Comment

Representing Alcohol Use


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
Yes
Free
N/A
Standard for observation values
Final
Production
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The Alcohol Use Disorder Identification Test - Consumption [AUDIT-C] consists of the first 3 questions of the World Health Organization’s 10-question AUDIT alcohol screening that can help identify patients who are hazardous drinkers or have active alcohol use disorders (including alcohol abuse or dependence), is best suited for this interoperability need.
  • See LOINC projects in the Interoperability Proving Ground. 
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

AUDIT-C panel (LOINC® code 72109-2)

AUDIT-C member codes

   LOINC® code 68518-0 (with LOINC® answer list ID LL2179-1)

   LOINC® code 68519-8 (with LOINC® answer list ID LL2180-9)

   LOINC® code 68520-6 (with LOINC® answer list ID LL2181-7)

   AUDIT-C total score (LOINC® code 75626-2)

AUDIT panel (LOINC code 72110-0)

AUDIT panel total score (LOINC code 75624-7)

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.

Representing Social Connection and Isolation


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The Social connection and isolation panel is a set of five questions used to assess the number of types of social relationships on which a patient is connected and not isolated.  It was developed for the National Health and Nutrition Examination Survey (NHANES), and is best suited for this interoperability need.
  • See LOINC projects in the Interoperability Proving Ground.

Social connection and isolation panel LOINC® code 76506-5,

  Member codes:

  LOINC® code  63503-7 (with LOINC answer list ID LL1068-7)

  LOINC® code 76508-1

  LOINC® code 76509-9

  LOINC® code  76510-7

  LOINC® code  76511-5 (with LOINC answer list ID LL963-0)

  Social isolation score LOINC® code 76512-3

Comment

Representing Exposure to Violence (Intimate Partner Violence)


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The HARK (Humiliation, Afraid, Rape, Kick) is a four-question screen for identifying women who have experienced intimate partner violence (IPV) in the past year and may help women disclose IPV in general practice. It is best suited for use with this interoperability need.
  • See LOINC projects in the Interoperability Proving Ground.

HARK panel LOINC® code 76499-3

  HARK member codes:

  LOINC® code 76500-8 (with LOINC® answer list ID LL963-0)

  LOINC® code 76501-6 (with LOINC® answer list ID LL963-0)

  LOINC® code 76502-4 (with LOINC® answer list ID LL963-0)

  LOINC® code 76503-2 (with LOINC® answer list ID LL963-0)

  HARK total score LOINC® code 76504-0

Comment

Representing Patient Tobacco Use (Smoking Status)


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 5
No
Free
N/A
Standard for observation values
Final
Production
Rating 5
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • There are limitations in SNOMED CT® for this interoperability need, which include, but not limited to:  not being able to capture severity of dependency, level of use, quit attempts, lifetime exposure, and use of e-Cigarettes.
  • LOINC® includes codes that support recording smoking status in the CDC’s preferred (and sometimes required) responses (e.g. Tobacco smoking status NHIS[76691-5]) and other kinds of observations (e.g. Have you smoked at least 100 cigarettes in your entire life [PhenX] [63581-3] or How old were you when you first started smoking cigarettes every day [PhenX] [63609-2].
  • See LOINC projects in the Interoperability Proving Ground. 
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

 

  • 'Tobacco smoking status NHIS' LOINC 72166-
  • Current Smoking Status urn:oid:2.16.840.1.113883.11.20.9.38
  • ONC’s 2015 Edition certification requirements reference the following value set for smoking status.  Codes from SNOMED CT® :
    1. Current every day smoker. 449868002
    2. Current some day smoker. 428041000124106
    3. Former smoker. 8517006
    4. Never smoker. 266919005
    5. Smoker, current status unknown. 77176002
    6. Unknown if ever smoked. 266927001
    7. Heavy tobacco smoker. 428071000124103
    8. Light tobacco smoker. 428061000124105
  • Additional tobacco-related codes: 
    1. User of smokeless tobacco (finding): SNOMED CT 713914004
    2. Smokeless tobacco non-user (finding): SNOMED CT 451381000124107
    3. Date quit tobacco smoking LOINC 74010-0

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.

Representing Unique Implantable Device Identifiers


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Implementation Specification
In Developement
Pilot
Rating 1
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Per the FDA, Unique Device Identification system will be phased in over several years, with the final compliance date of September, 2020.
  • Compliance date for UDI of implantable, life supporting and life sustaining devices was 9/24/2015.  These data are available at http://accessgudid.nlm.nih.gov.
  • The HL7 Harmonization Pattern for UDIs is currently in development, with the next revision release anticipated in February 2018.
  • See UDI projects in the Interoperability Proving Ground.
  •  Feedback requested

Comment

Defining a Globally Unique Device Identifier


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Implementation Specification
In Developement
Pilot
Rating 1
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Per the FDA, Unique Device Identification system will be phased in over several years, with the final compliance date of September, 2020.
  • Compliance date for UDI of implantable, life supporting and life sustaining devices was 9/24/2015.  These data are available at http://accessgudid.nlm.nih.gov.
  • The HL7 Harmonization Pattern for UDIs is currently in development, with the next revision release anticipated in February 2018.
  • See UDI projects in the Interoperability Proving Ground.
  •  Feedback requested

Comment

NCPDP - Comment

Add the following:

Type-Implementation Specification

Standard Implementation/Specification- NCPDP Product Identifiers Standard Implementation Guide Version 1.4

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 3

Federally Required – No

Cost – $

Test Tool Availability – No

New Comment -Section I – U Defining a Globally Unique Device

Please make the following changes:

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

Transmitting a Unique Device Identifier


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Implementation Specification
In Developement
Pilot
Rating 1
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Per the FDA, Unique Device Identification system will be phased in over several years, with the final compliance date of September, 2020.
  • Compliance date for UDI of implantable, life supporting and life sustaining devices was 9/24/2015.  These data are available at http://accessgudid.nlm.nih.gov.
  • The HL7 Harmonization Pattern for UDIs is currently in development, with the next revision release anticipated in February 2018.
  • See UDI projects in the Interoperability Proving Ground.
  • Feedback requested

Comment

NCPDP - Comment

Add the following:

Type-Implementation Specification

Standard Implementation/Specification- NCPDP Product Identifiers Standard Implementation Guide Version 1.4

Standards Process Maturity – Final

Implementation Maturity- Production

Adoption Level – 3

Federally Required – No

Cost – $

Test Tool Availability - No

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


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
Yes
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • UCUM is a syntax for representing units of measure for use with numerical references and values. It is not an enumerated set of codes.
  • The case sensitive version is the correct unit string to be used for interoperability purposes.
  • Per public comments received, there may be some limitations with UCUM in the laboratory domain that remain unresolved.
  • The abbreviations used for a few of the units of measure listed in the UCUM standard are currently on lists of prohibited abbreviations from the Institute for Safe Medication Practice (ISMP).
  • Some abbreviations for units of measure include symbols which may be in conflict with other HL7 standards.
  • Some abbreviations for units are nonstandard for human understanding.(For example, if a result for a White Blood Cell count is 9.6 x 103/μL, the UCUM recommendation for rendering this value in a legacy character application is 9.6 x 10*3/uL. Because the “*” is a symbol for multiplication in some systems.) This recommendation may result in errors either by the information system or the human reading the result.
  • Some abbreviations used in UCUM are not industry standard for the tests that use these units of measure.
  • Units Of Measure Case Sensitive 2.16.840.1.113883.1.11.12839 (most frequently used codes)
  • “Table of Example UCUM Codes for Electronic Messaging" published by the Regenstrief Institute, Inc. Value set is made available at http://loinc.org/usage/units and identified by the OID 1.3.6.1.4.1.12009.10.3.1

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.

Representing Patient Vital Signs


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • See LOINC projects in the Interoperability Proving Ground.
  • See Section I-K for discussion of units of measure used with quantitative observations.
  • Vital Sign Result urn:oid:2.16.840.1.113883.3.88.12.80.62

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.

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


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • A variety of transport protocols are available for use for ADT message delivery. Trading partners will need to determine which transport tools best meet their interoperability needs, however, Direct (referenced further in Section III-A), has been noted as a prominent option for transport, particularly where HIE networks are not in place or not being used for this purpose. 
  • See HL7 V2 projects in the Interoperability Proving Ground.
  • Secure Communication – create a secure channel for client-to-server 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.

Comment

Consider IHE Patient…

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

 

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


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 2
No
$
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The “Census Message” transaction allows for long-term and post-acute care settings to notify the servicing pharmacy of a patient’s admission, discharge and/or transfer status.
  • See NCPDP projects in the Interoperability Proving Ground.
  • 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.

Comment

Documenting and Sharing Care Plans for a Single Clinical Context


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 3
Yes
Free
Yes
Emerging Standard
In Developement
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The care plan as expressed in the C-CDA standard does not attempt to represent the longitudinal care plan; rather it represents a “snapshot” of a care plan at a single point in time for transmission to other providers and teams to ensure continuity of care.
  • The Care Plan Domain Analysis Model is used as a reference model for C-CDA care plan documents in the context of the longitudinal care plan.
  • FHIR Resources are in various stages of maturity. Please refer to the FHIR website for updates on specific profiles and their progress. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.

  • See CDA and FHIR projects in the Interoperability Proving Ground.
  • Feedback requested

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

Domain or Disease-Specific Care Plan Standards


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Feedback requested
Rating 3
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 3
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The two HL7 CDA R2 IGs are based on C-CDA R2.1 and align with the Care Plan document specifications. The IHE Profile is based on HL7 V2.6 IG: Early Hearing Detection and Intervention (EHDI) Messaging, Release 1.
  • The Personal Advance Care Plan Document is for the domain of patient-authored goals, priorities and preferences, including but not limited to Advance Directives.
  • See CDA and IHE projects in the Interoperability Proving Ground.
  • Feedback Requested

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 Teams for Care Planning in Multiple Clinical Contexts


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Feedback requested.
  • Feedback requested.

Comment

Documenting and Sharing Medication-Related Care Plans by Pharmacists


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 2
No
$
Yes$
Implementation Specification
Final
Production
Rating 1
No
$
Yes
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The two implementation specifications listed for this interoperability need are a result of a joint effort between HL7 and NCPDP to create a standardized, interoperable document for exchange of consensus-driven prioritized medication-related activities, plans and goals for an individual needing care Pharmacists work in multiple environments. This project was partially funded by ONC's High Impact Pilots Cooperative Agreement Program. The Community Pharmacy Enhanced Services Network maintains a listing of vendor participants from this program. 
  • More than 100 value sets are currently captured in VSAC in support of this interoperability need. Search for "PharmacyHIT" to view them. 
  • See this project in the Interoperability Proving Ground
  • Feedback requested. 

Comment

Sharing Patient Care Plans for Multiple Clinical Contexts


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • See IHE projects in the Interoperability Proving Ground.

  • Feedback requested

Comment

Sharable Clinical Decision Support


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Balloted Draft
Production
Rating 2
No
Free
Yes
Standard
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Standard
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 2
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Emerging Standard
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • See FHIR projects in the Interoperability Proving Ground.
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • Feedback requested

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

Provide Access to Appropriate Use Criteria


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Note that the FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR) in STU 3 was incorporated into FHIR as a core implementation guide, FHIR Clinical Reasoning.
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • See FHIR projects in the Interoperability Proving Ground.
  • Feedback requested

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

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


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested

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

Reporting Aggregate Quality Data to Federal Quality Reporting Initiatives


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Implementation Specification
Balloted Draft
Production
Rating 4
Yes
Free
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 1
Yes
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • See CDA and QRDA projects in the Interoperability Proving Ground.
  • Feedback requested

Comment

Reporting Patient-level Quality Data to Quality Reporting Initiatives


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Implementation Specification
Balloted Draft
Production
Rating 4
Yes
Free
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 1
Yes
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • See CDA and QRDA projects in the Interoperability Proving Ground.
  • Feedback requested

Comment

Sharing Quality Measure Artifacts for Quality Reporting Initiatives


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Balloted Draft
Pilot
Rating 4
No
Free
Yes
Standard
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Standard
Balloted Draft
Production
Rating 2
No
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 2
No
Free
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 2
No
Free
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
In Developement
Pilot
Rating 1
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • See FHIR projects in the Interoperability Proving Ground.
  • Feedback requested

Comment

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


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The first implementation specification listed is focused on data provenance representation for CDA R2 implementations and the use of CDA templates.
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • The FHIR implementation specification listed leverages the W3C Provenance specification to represent HL7® support of provenance throughout its standards. It is explicitly modeled as functional capabilities in ISO/HL7 10781 EHR System Functional Model Release 2 and ISO 21089 Trusted End-to-End Information Flows. Mappings are available within the resource. 

  • See CDA & FHIR projects in the Interoperability Proving Ground.
  • Feedback requested

Comment

Exchanging Diet and Nutrition Orders Across the Continuum of Care


Diet and Nutrition Orders
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • FHIR Resources are in various stages of maturity. Please refer to the FHIR website for updates on specific profiles and their progress. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.

  • In addition to the specifications listed above, work is underway to create a HL7 CDA R2 Implementation Guide: C-CDA R2.1 Supplemental Templates for Nutrition, Release 1 (US Realm), with balloting likely in January 2018. 

  • See FHIR projects in the Interoperability Proving Ground.
  • System Authentication  -  The information and process necessary to authenticate the systems involved
  • User Details -  identifies the end user who is accessing the data
  • User Role – identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use - Identifies the purpose for the transaction.

Comment

The Ability for Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescribers Systems


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
Yes
$
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • NCPDP Formulary and Benefits v3.0 does not provide real-time patient-level benefit information.
  • NCPDP is developing a Real Time Prescription Benefit standard that should be monitored as a potential emerging implementation specification.
  • 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.

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.

Allows a Prescriber to Request or Cancel Prior Authorization for Medications


Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Final
Feedback requested
Feedback Requested
No
$
No
Implementation Specification
Final
Production
Rating 2
No
$
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The prescriber system must receive timely Formulary & Benefit file updates from payers/intermediaries, giving group-level formulary and coverage information (including PA flags) for use when ordering medications.
  • The following ASC X12 patient eligibility transactions enhance the PA Request transactions by supplying the prescriber system with the patient’s pharmacy benefit information, and need to be implemented for interoperability purposes:
    • Eligibility Request (ASC X12 270)
    • Eligibility Response (ASC X12 271)  
  • The following SCRIPT 2017071 PA 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 these transactions in order to facilitate successful exchange, including the ability to send or receive status or error messages.
    • See NCPDP projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to- server 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.

    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.

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


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 2
    No
    $
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The following transactions need to be implemented for interoperability purposes:
      • RxHistoryRequest: a request from a prescriber for a list of medications that have been prescribed, dispensed, claimed or indicated (OTCs) by a patient to a state Prescription Drug Monitoring Program (PDMP).
        • This patient-specific transaction supplies enough information to uniquely identify the patient
      • RxHistoryResponse: a response from a PDMP to an RxHistoryRequest containing a patient’s medication history; includes the medications that were dispensed or obtained within a certain timeframe, optionally including the prescriber that prescribed it
        • PDMP must evaluate the Consent for accurate reporting
        • Returns with loops of Medication, HistorySource (pharmacy), Prescriber, Pharmacy, and Patient elements
        • HistorySource and FillNumber elements are included, when appropriate, so prescribers are able to de-duplicate records from multiple sources that reflect the same medication dispensing, and to help determine patient compliance with a prescription
          • Helps the prescriber determine if follow-up contact is required regarding the medication records
    • RxHistoryRequest and RxHistoryResponse may be sent directly or through an intermediary
    • Both the prescriber and the Prescription Monitoring Drug Program (PDMP) must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive status, or error transactions.
    • See NCPDP projects in the Interoperability Proving Ground
    • Secure Communication – create a secure channel for client-to- server 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.

    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.

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


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 2
    Yes
    $
    Yes
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The following transactions need to be implemented for interoperability purposes:
      • RxHistoryRequest: a request from a prescriber or a pharmacy for a list of medications that have been prescribed, dispensed, claimed or indicated (OTCs) by a patient
        • This patient-specific transaction supplies enough information to uniquely identify the patient
      • RxHistoryResponse: a response to an RxHistoryRequest containing a patient’s medication history; includes the medications that were dispensed or obtained within a certain timeframe, optionally including the prescriber that prescribed it
        • The receiver must evaluate the Consent for accurate reporting
        • Returns with loops of Medication, HistorySource, Prescriber, Pharmacy, and Patient elements when appropriate
        • HistorySource and FillNumber elements are included, when appropriate, so prescribers are able to de-duplicate records from multiple sources that reflect the same medication dispensing, and to help determine patient compliance with a prescription
          • Helps the prescriber determine if follow-up contact is required regarding the medication records
    • RxHistoryRequest and RxHistoryResponse may be sent directly or through an intermediary.
    • Medication history transactions may be exchanged among prescribers, pharmacies, or payers, and may include adjudicated claims and/or pharmacy dispensed/point of sale prescription information.
    • It is recommended that prescribers request Medication History from all applicable sources, whenever appropriate, to ensure the most complete view of a patient’s medication history. The Medication History may be reconciled with the prescriber’s patient record for improved medication management and to assist in clinical decision support.

    • Both the sender and receiver must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions. This may also include hospitals and/or Accountable Care Organizations (ACOs). 
    • See NCPDP projects in the Interoperability Proving Ground
    • Secure Communication – create a secure channel for client-to- server 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.

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

    Allows a Prescriber or a Pharmacy to Request a New Prescription


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 5
    Yes
    $
    Yes
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The following transactions need to be implemented for interoperability purposes:
      • NewRx: This transaction is a new prescription sent from the prescriber to the pharmacy electronically so that it can be dispensed to a patient.
      • SCRIPT 2017071 -
        • NewRxRequest: This transaction is a request from a pharmacy to a prescriber for a new prescription for a patient
          • NewRxResponseDenied: This transaction is a denied response to a previously sent NewRxRequest (If approved, a NewRx would be sent)
            • A NewRxResponseDenied response may occur when the NewRxRequest cannot be processed or if information is unavailable 
    • Both the prescriber and the pharmacy must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
    • See NCPDP projects in the Interoperability Proving Ground.
    • 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.

    Comment

    Allows a Pharmacy to Request Additional Refills


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 4
    Yes
    $
    Yes
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The following transactions need to be implemented for interoperability purposes:
      • SCRIPT 10.6 -
        • Refreq, originated from the pharmacy to the prescriber requesting additional refills.
        • Refres, originated from the prescriber to the pharmacy with a Rx authorization for refills; the response to a Refreq message.
      • SCRIPT 2017071 -
        • RxRenewalRequest, originated from the pharmacy to request additional refills beyond those originally prescribed
          • FollowUpRequest, originated from the pharmacy to:
            • notify prescribers that this is a follow-up RxRenewalRequest or RxChangeRequest transaction, when the prescriber has not responded to the first RxRenewalRequest or first RxChangeRequest transaction in a reasonable amount of time.
            • not sent on the original request of the RxRenewalRequest or RxChangeRequest transaction
        • RxRenewalResponse, originated from the prescriber to respond to the request 
          • Options allowed when generating an RxRenewalResponse to an RxRenewalRequest from a pharmacy:
            • Approved: Grant the RxRenewalRequest as requested by the pharmacy, or, when the pharmacy does not request a specific number of fills (PharmacyRequestedRefills is not present) and the prescriber approves any number of fills
            • ApprovedWithChanges: Grant the RxRenewalRequest, approving a NumberOfRefills different than the number requested by the pharmacy or when the information submitted in the RxRenewalRequest does not include all elements constituting a fillable prescription; the prescriber should include all information
            • Denied: Deny the RxRenewalRequest as requested by the pharmacy 
              • In a Denied response, the only new meaning that should be conveyed to the pharmacy is information that explains the denial. It is recommended that the prescribing software update the NumberOfRefills to zero and leave all other data as is in the RxRenewalResponse
            • Replace: Data is allowed to be changed except the patient DateOfBirth. If patient DateOfBirth changes, a Denied response would be sent, and then a NewRx would follow
          • The receiving pharmacy might handle each of these responses differently. Approved, ApprovedWithChanges, and Replace responses might be directed to a fulfillment queue, where a Denied response might be directed to a review queue
          • The Replace response should be used if there are any changes beyond what is outlined in the Response Element
        • RxRenewalRequest should never be responded to with a NewRx, as this would result in duplicate valid prescriptions
        • DeniedNewPrescriptionToFollow response is not to be sent in an RxRenewalResponse for this version of SCRIPT. However, the DeniedNewPrescriptionToFollow response could be received in an RxRenewalResponse from a previous version of SCRIPT and is included for backwards compatibility. DeniedNewPrescriptionToFollow response only exists for entities that need to map this version to a previous version of SCRIPT that does not support a Replace.
    • Both the pharmacy and the prescriber must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
    • See NCPDP projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to- server 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.

    Comment

    Allows a Pharmacy to Request a Change to a Prescription


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 3
    Yes
    $
    Yes
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The following transactions need to be implemented for interoperability purposes:
      • SCRIPT 10.6 -
        • RxChg, originated from the pharmacy to request a change in the original prescription.
        • Chgres, originated from the prescriber in response to the RxChg message.
      • SCRIPT 2017071 -
        • RxChangeRequest, originated from the pharmacy to request:
          • a change in the original prescription (new or fillable)
          • validation of prescriber credentials
          • a prescriber to review the drug requested
          • obtaining a prior authorization from the payer for the prescription
        • FollowUpRequest, originated from the pharmacy to:
          • notify prescribers that this is a follow-up RxRenewalRequest or RxChangeRequest transaction, when the prescriber has not responded to the first RxRenewalRequest or first RxChangeRequest transaction in a reasonable amount of time.
          • Not sent on the original request of the RxRenewalRequest or RxChangeRequest transaction
        • RxChangeResponse, originated from the prescriber to respond:
          • to a prescription change request from a pharmacy
          • to a request for a prior authorization from a pharmacy
          • to a prescriber credential validation request from a pharmacy
        • Options allowed when generating an RxChangeResponse in response to an RxChangeRequest from a pharmacy:
          • Approved: Grant the RxChangeRequest when the prescriber concurs with the request. The prescriber must submit an RxChangeResponse equal to what the pharmacy requested.
          • ApprovedWithChanges: When the information submitted in the RxChangeRequest does not include all elements constituting a fillable prescription; the prescriber should include all information.
          • Denied: Denies the RxChangeRequest with information that explains the denial.
          • Validated: Sent by the prescriber system in response to an RxChangeRequest for prescriber authorization.

    The receiving pharmacy should handle Approved, ApprovedWithChanges, and Validated responses as a fillable NewRx where the original linked prescription/order is discontinued. A Denied response should be directed to a review queue where the Denial reason code is displayed.

    Both the pharmacy and the prescriber must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.

    See NCPDP projects in the Interoperability Proving Ground.

    • Secure Communication – create a secure channel for client-to- server 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

    Comment

    Allows a Prescriber to Cancel a Prescription


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 2
    Yes
    $
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • The following transactions need to be implemented for interoperability purposes:
      • SCRIPT 10.6 -
        • CanRx: a request from a prescriber to a pharmacy to not fill a previously sent prescription.
        • CanRes: a response from a pharmacy to a prescriber to acknowledge a cancel request; the response to a CanRx.
      • SCRIPT 2017071 -
        • CancelRx: a request from the prescriber to the pharmacy to not fill a previously sent prescription
          • must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage form), prescriber, prescription number if available)
          • changes can be indicated in the MessageRequestCode in the CancelRx transaction
        • CancelRxResponse: a response from the pharmacy to the prescriber to acknowledge a CancelRx
          • used to denote if the cancellation is Approved or Denied
          • DenialReasonCode should be sent when a CancelRx is denied
        • When a Long Term care (LTC) prescriber has the need to modify an order and notify the pharmacy, the prescriber system will always send a CancelRx and a NewRx, regardless of the type of change

    Both the prescriber and the pharmacy must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.

    See NCPDP projects in the Interoperability Proving Ground.

    • Secure Communication – create a secure channel for client-to- server 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.

    Comment

    Allows a Pharmacy to Notify a Prescriber of Prescription Fill Status


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Implementation Specification
    Final
    Production
    Rating 2
    Yes
    $
    Yes
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The following transactions need to be implemented for interoperability purposes:
      • RxFill: sent from a pharmacy to a prescriber or long term or post-acute care (LTPAC) facility indicating the FillStatus (dispensed, partially dispensed, not dispensed or returned to stock, transferred to another pharmacy) of the new, refill or resupply prescriptions for a patent 
      • SCRIPT 2017071 -
        • RxFillIndicator: Informs the pharmacy of the prescriber’s intent for fill status notifications for a specific patient/medication
        • RxFillIndicatorChange: Sent by the prescriber to the pharmacy to indicate that the prescriber is changing the types of RxFill transactions that were previously requested, where the prescriber may modify the fill status of transactions previously selected or cancel future RxFill transactions
        • When transferring a prescription, the RxFillRequestIndicator should be passed to the new pharmacy as part of the prescription information. If it supports the RxFill transaction, the pharmacy to which the prescription was transferred is responsible to send the appropriate Physician RxFill Request Flag with each subsequent dispensing event.
    • The prescriber must electronically send the prescription via the NCPDP SCRIPT standard in order for the prescriber’s system to receive RxFill transactions, and ensures the correct matching between the original prescription and the subsequent RxFill transactions.

      Adoption of RxFill may be improved by allowing prescribers to specify which prescriptions are to receive RxFill transactions and which RxFill message types to receive. Additionally, prescribers may choose to receive RxFill transactions for patients receiving certain medications. EMRs may also provide additional capabilities to support RxFill message handling and prescriber preferred notifications that may provide process improvements such as limiting the number of transactions received, the cost of transactions, privacy concerns and information overload.

    • Both the pharmacy and the prescriber must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
    • See NCPDP projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to- server 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.

    Comment

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


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration

     The following transactions need to be implemented for interoperability purposes:

    • RxTransferRequest: Used when the pharmacy is asking for a transfer of one or more prescriptions for a specific patient to the requesting pharmacy
      • The transfer is for a fillable prescription which may be:
        • yet to be filled
        • on hold
        • open (active) fills
        • current therapy (defined as drug therapy that, based upon the most recent fill date, quantity and instructions, should still be active)
        • allowed to be transferred by law/regulation
      • If multiple specific prescriptions are to be transferred, but not all prescriptions, a separate RxTransferRequest must be sent for each specific prescription
    • RxTransferResponse: The response from the transferring pharmacy to the requesting pharmacy to the RxTransferRequest which includes the prescription(s) being transferred or a rejection of the transfer request
    • RxTransferConfirm: Used by the pharmacy receiving (originally requesting) the transfer to confirm that the transfer prescription has been received and the transfer is complete
    • The RxFill Transaction <FillStatus><Transferred> is originated by the transferring pharmacy once the <RxTransferConfirm> is received from the transfer to pharmacy. This transaction is used to notify the prescriber when a prescription has been transferred to another pharmacy and can no longer be filled at the original pharmacy. The RxTransfer transaction will identify if the receiving pharmacy supports RxFill.
    • Both pharmacies must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
    • See NCPDP projects in the Interoperability Proving Ground.

     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.

    Comment

    Allows a Prescriber to Prescribe Medication Using Weight-Based Dosing


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Emerging Implementation Specification
    Final
    Feedback requested
    Feedback Requested
    No
    $
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Value Set(s) and Starter Set(s)

    Included in the Structured and Codified Sig Format of electronic prescribing transactions are elements, fields and values that are directly related to the prescriber's instructions for use.

    The following elements of the Sig are required when Structured Sig is sent:

    • Code system
    • Dose
    • Vehicle
    • Route Of Administration
    • Site of Administration
    • Timing
    • Duration
    • Maximun Dose Restriction
    • Indication

    The following elements of the Sig are required when Structured Sig is sent and when dose is to be calculated:

    • Dose Calculation
      • Used where a body metric such as metric weight (kg) or surface area (m*2) is used to calculate a dose for a patient.
      • May often be used in conjunction with the Rate within TimingAndDuration and/or the Vehicle.

    The SCRIPT 2017071 Observation element supports the use of a patient's height, weight and other vital signs:

    • Inclusion of VitalSign (most recent patient's height and weight) and ObservationDate (YYYY-MM-DD height and weight observed/taken) is required for patients 18 years old and younger on all new and renewal prescriptions from a prescriber to a pharmacy.
      • If the height and/or weight have changed and a prescriber is sending an approved renewal response, the response should be coded as Approved with Changes.
    • ObservationDate is now mandatory when Observation Segment Measurement is sent.
    • ObservationNotes may contain other pertinent information pertaining to weight-based calculations.

    Comment

    Representing Family Health History for Clinical Genomics


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Balloted Draft
    Production
    Rating 1
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Production
    Rating 1
    No
    Free
    No
    Emerging Implementation Specification
    Final
    Pilot
    Feedback Requested
    No
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • There is no widely recognized vocabulary to capture family genomic health history, but several vocabularies/value sets are available for consideration. 
    • Further constraint of this standard and implementation specification may be required to support this interoperability need.
    • The Office of the National Coordinator for Health Information Technology (ONC), in partnership with National Institutes of Health (NIH), created Sync for Genes to strengthen genomic data sharing, a key component of the Precision Medicine Initiative. This project is also in alignment with the recommendations made by the Precision Medicine Task Force under the Health IT Standards Committee (HITSC) to advance data standards, address relevant privacy policies, and advance innovations in health IT that support precision medicine. Sync for Genes is the first step toward integrating clinical genomics into the point-of-care by expediting the use of standards, such as Health Level 7 (HL7®) Fast Healthcare Interoperability Resource (FHIR®), to enable and improve patient’s ability to seamlessly share their genomics information via point-of-care applications, such as application programming interfaces (APIs). Sync for Genes supports a critical element of sharing genomic data amplifying the ability to seamlessly share genomic information for research and commercial purposes. Below are the HL7 FHIR Clinical Genomic profiles that were tested as part of the Sync for Genes work:
    • The U.S. Surgeon General also offers the My Family Health Portrait, allowing individuals to enter their family health history details to share with their family members and/or healthcare providers, learn about risk for conditions that can be hereditary, and be saved as a resource that can be maintained and updated over time. 
    • See FHIR projects in the Interoperability Proving Ground.

    According to HIMSS, the following vocabularies/value sets may be considered:

    • Gene Identifier: HGNC Value Set
    • Transcript Reference Sequence Identifier: NCBI vocabulary
    • DNA Sequence Variation Identifier: NCBI vocabulary
    • DNA Sequence Variation: HGVS nomenclature

    Comment

    Sending Healthy Weight Information


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • The Integrating the Healthcare Enterprise (IHE) Healthy Weight Profile Childhood obesity surveillance systems utilize either measured (e.g. NHANES) or parent/self-report height and weight to calculate BMI.  The profile also includes the HL7 Occupational Data for Health (ODH) template.
    • Public health agencies have been studying the relationship between obesity and work factors; for example, the prevalence of obesity has been shown to vary substantially by occupation. 
    • See IHE projects in the Interoperability Proving Ground.
    • System Authentication  -  The information and process necessary to authenticate the systems involved
    • User Details -  identifies the end user who is accessing the data
    • User Role – identifies the role asserted by the individual initiating the transaction.
    • Purpose of Use - Identifies the purpose for the transaction.

    Comment

    Been there, done that, doing…

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

    Format of Medical Imaging Reports for Exchange and Distribution


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    No
    Free
    Yes
    Implementation Specification
    Final
    Production
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • DICOM defines both its own encoding of reports and templates for encoding narrative reports and machine-generated output as DICOM Structured Reports (SR) for use within imaging systems.
    • DICOM Part 20 is an implementation guide for HL7 CDA r2.
    • DICOM also defines a Diagnostic Imaging Report HL7 CDA Template, which is intended to supersede the C-CDA Diagnostic Imaging Report.
    • 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.

    Comment

    Format of Radiology Reports for Exchange and Distribution


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Balloted Draft
    Pilot
    Feedback Requested
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Feedback requested

    Comment

    Medical Image Formats for Data Exchange and Distribution


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Use Image Acquisition Technology Specific Service/Object Pairs (SOP) Classes.
    • Feedback requested

    Comment

    Format of Radiation Exposure Dose Reports for Exchange and Distribution


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Final
    Production
    Rating 2
    No
    Free
    Yes – Open
    Implementation Specification
    Final
    Production
    Rating 2
    No
    Free
    Yes – Open
    Implementation Specification
    Final
    Production
    Rating 2
    No
    Free
    Yes – Open
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • These reports record radiation dose in three forms:
      • The dose related information provided by an exposing device, e.g., CT, as reported by the device.
      • The dose related information about a radiopharmaceutical administration, as reported by the administering system
      • The patient or organ absorbed dose based on exposure information, patient characteristics, and patient model
    • See DICOM projects in the Interoperability Proving Ground. 
    • Feedback requested. 

    Comment

    Receive Electronic Laboratory Test Results


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 2
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Production
    Rating 1
    Yes
    Free
    Yes
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • 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.

    Comment

    Ordering Labs for a Patient


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 2
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • 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.

    Comment

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


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 2
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Production
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • 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.

    Comment

    Identify Linkages Between Vendor IVD Test Results and Standard Codes


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Final
    Production
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • The LIVD - Digital Format for Publication of LOINC to Vendor IVD Test results defines the digital publication of LOINC using vendor defined IVD tests associated with a set of predefined LOINC codes. LIVD assures that laboratory personnel select the appropriate LOINC codes for IVD test used by their laboratory. It also allows LIS systems to automatically map the correct IVD vendor test result to a LOINC code. LIVD was developed in collaboration with the members of the FDA IVD Semantic workgroup.
    • Feedback Requested. 

    Comment

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


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Final
    Production
    Rating 3
    No
    Free
    Yes
    Implementation Specification
    Final
    Production
    Rating 3
    No
    Free
    Yes
    Implementation Specification
    Final
    Production
    Rating 3
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • IHE-PCD, Continua and ITU refer to the IEEE 11073-10101 standard for its nomenclature.
    • The following specific IHE-PCD profiles that best meet this interoperability need include:
      • IHE-PCD (Patient Care Device Profiles) - Alert Communication Management (ACM)

      • IHE-PCD (Patient Care Device Profiles) - Device Enterprise Communication (DEC)

      • IHE-PCD (Patient Care Device Profiles) - Implantable Device – Cardiac Observation (IDCO)

      • IHE-PCD (Patient Care Device Profiles) - Point-of-Care Infusion Verification (PIV)

      • IHE-PCD (Patient Care Device Profiles) - Rosetta Terminology Mapping (RTM)

    • The Regenstreif LOINC/IEEE Medical Device Code Mapping Table  allows enterprise information systems (i.e. ""Other information Systems/Technologies") to process vital signs and combine those observations with other types of information; it bridges the semantic map between IEEE 11073 10101 conformant medical devices and certified health IT or aligned information systems that use LOINC already for laboratory reports, document taxonomies, standard forms, questionnaires, assessments, social determinants, and screeners. 
    • FDA  cybersecurity recommendations for medical device manufacturers.  
    • Design Considerations and FDA Pre-Market Submission Recommendations for Interoperable Medical Devices.
    • See IHE projects in the Interoperability Proving Ground.
    • Feedback requested

    Comment

    Section I I – N Transmitting Patient Vital Signs from Medical de

    Please make the following changes:

    1.Please add a new row “Implementation Specification” with Standard Implementation/Specification named “Continua Design Guidelines”. The remaining fields are the same as for IHE-PCD in the row above.

    2.Please add a new row “Implementation Specification” with Standard Implementation/Specification named “ITU H.810, H.811, H.812, H.12.5 and H.813”. The remaining fields are the same as for IHE-PCD in the row above.

    3.Within Dependencies for Consideration field, please change the first bullet to IHE-PCD, Continua and ITU IEEE 11073-10101 standard for its nomenclature.

    A Standard Mechanism for Clinical Information Systems to Request Context-Specific Clinical Knowledge From Online Resources


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 4
    Yes
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 3
    Yes
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 3
    Yes
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Feedback requested
    • Feedback requested

    Comment

    Patient Demographic Record Matching


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    No
    Free
    Yes
    Implementation Specification
    Final
    Production
    Rating 5
    No
    Free
    Yes
    Implementation Specification
    Final
    Production
    Rating 5
    No
    Free
    Yes
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Feedback Requested
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Chapter 3 of the HL7 Standard 2.5.1 named "Patient Administration" is the relevant chapter for Clinical and Administrative Domains.
    • NIST Special Publication 800-63, Revision 3 defines technical requirements in each of the areas of identity proofing, registration, authenticators, management processes, authentication protocols, federation, and related assertions. These guidelines can be applied for identity proofing of any user or participant in healthcare such as clinicians, caregivers, patients and others.
    • The Implementation Guide for Expressing Context in Direct Messaging was designed to facilitate inter-organizational patient demographic record matching by standardizing the inclusion of patient demographic metadata in Direct messages. Direct is also listed in several Interoperability Needs in Section III-A.
    • Patient Identity Proofing is outside of the scope of this interoperability need but more information related to this topic is below: 
      • Identity Proofing.  Each Signatory’s security policy shall include the following elements to ensure appropriate identity proofing:
        • (i) End Users (provider).  Each Signatory shall identity proof participating End Users at Identity Assurance Level 2 (IAL2) prior to issuance of access credentials; and
        • (ii) Individuals (patient).  Each Signatory shall identity proof participating individuals at Identity Assurance Level 2 (IAL2) prior to issuance of access credentials; provided, however, that the Signatory may supplement identity information by allowing Participant staff to act as trusted referees and authoritative sources by using personal knowledge of the identity of the individuals (e.g., physical comparison to legal photographic identification cards such as driver’s licenses or passports, or employee or school identification badges) collected during an antecedent in-person registration event.  All collected personally identifiable information collected by the Signatory shall be limited to the minimum necessary to resolve a unique identity.
    • See HL7 V2  IHE, and Direct projects in the Interoperability Proving Ground.
    • 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.

    Comment

    Patient Identity Assurance Level (IAL2)

    I agree completely with the desire to identity proof patients to the level of IAL2.  However, I'm not understanding the last sentence of this consideration: "all collected PII collected by the Signatory shall be limited to the minimum necessary to resolve a unique identity and the Signatory shall not copy and retain such PII".  The Signatory should and in fact MUST be able to copy and retain PII to properly perform identity assurance. 

    One of the elements necessary to perform strong identity proofing is to verify a strong or superior piece of identity evidence (like the patient's drivers license).  During the course of verification the image of the identity evidence may be imaged and sent to a 3rd party to "proof" the authenticity of the document.  Typically the image of the drivers license is kept on file by the Provider along with an image of the insurance card.  Would maintaining a copy or image of the driver's license and insurance card violate the language in this sentence?  It appears that it would.  Also the PII data gleaned from those documents (person's name, address, DOB, etc.) is also "retained".

    This sentence should be revised to state "All collected PII collected by the Signatory shall be limited to the minimum necessary to resolve a unique identity." 

    Implementation Guide for Expressing Context in Direct Messaging

    The Implementation Guide for Expressing Context in Direct Messaging, published by the Direct Project, was designed to facilitate inter-organizational patient demographic record matching by standardizing the inclusion of patient demographic metadata in Direct messages, and should be added to this category. This standard was successfully piloted by the Direct Project community at their October 2017 connect-a-thon. 

    Luis Maas

    CTO, EMR Direct

    Recording Patient Preferences for Electronic Consent to Access and/or Share their Health Information with Other Care Providers


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Final
    Production
    Rating 2
    No
    Free
    Yes – Open
    Emerging Implementation Specification
    Final
    Pilot
    Rating 1
    No
    Free
    N/A
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Emerging Implementation Specification
    In Developement
    Pilot
    Rating 1
    No
    Free
    Yes
    Emerging Implementation Specification
    In Developement
    Pilot
    Rating 1
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • The IHE and CDA-based specifications operate in conjunction with the IHE XDS, XCA, and XDR profiles.
    • IHE BPPC may not support management of patient privacy across governmental jurisdictions which may have different regulations regarding access to patient data by providers, patients, governmental entities, and other organizations.
    • Along with security tokens and consent documents, security labels are the critical third part of the Attribute-Based-Access-Control and SLS for this interoperability need. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at https://www.hl7.org/fhir/security-labels.html 
    • Carequality is working to develop a technical method for distributing and identifying consent forms to be used as part of their Patient Consent Framework
    • See IHE and FHIR projects in the Interoperability Proving Ground.
    • 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).
    • User Role – identifies the role asserted by the individual initiating the transaction.
    • Purpose of Use - Identifies the purpose for the transaction.
    • Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed. 

    Comment

    Reporting Antimicrobial Use and Resistance Information to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    No
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 1
    Yes
    Free
    No
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • This is a national reporting system to CDC. Stakeholders should refer to implementation guide for additional details and contract information for enrolling in the program.
    • See CDA projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to-server 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.

    Comment

    Reporting Cancer Cases to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    Yes
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 2
    Yes
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Production
    Rating 1
    Yes
    Free
    Yes
    Implementation Specification
    Final
    Production
    Feedback Requested
    No
    Free
    No
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting cancer reporting date as there may be jurisdictional variation or requirements. Some jurisdictions may not support cancer case reporting at this time.
    • Note that the NAACCR specification listed has not been vetted through a Voluntary Consensus Standards Body (VSCB), however it references the HL7 V 2.5.1 standard and LOINC, and has been sponsored by a number of organizations working in the cancer registry space. 

    • See CDA and IHE projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to-server 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.

    Comment

    Case Reporting to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Production
    Rating 4
    Yes
    Free
    Yes
    Implementation Specification
    Final
    Feedback requested
    Rating 2
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 2
    No
    Free
    Yes
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Electronic case reporting involves reporting to State and/or Local jurisdictions and is not yet widespread.
    • Structured Data Capture Implementation Guide does not currently restrict vocabulary to standard vocabulary sets, and may require further implementation guidance for case reporting purposes. 
    • The IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation Implementation Guide does not support automated initiation of sending of case reports. It can support manual entry into an electronic form as follow-up to an initial case report submission. 
    • Some additional implementation guides related to public health reporting follow. Reporting is often captured under a specialized registry with associated standards when not specified as a separate measure. These include:
    • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
    • See FHIR and IHE projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to-server 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.
    • FHIR Security Labels support compliance with laws, policies, and consent directives governing HIPAA PHI and specially protected information (SPI)

    Comment

    Electronic Transmission of Reportable Lab Results to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 2
    Yes
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 4
    Yes
    Free
    Yes
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Feedback Requested
    No
    Free
    No
    Emerging Implementation Specification
    In Developement
    Pilot
    Rating 1
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting ELR as there may be jursidictional variation or requirements.
    • The Emerging Implementation Specification: “HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public health, Release 2 (US REALM), Draft Standard for Trial Use, Release 1.1" listed above was in a Draft Standard for Trial use status, but was not renewed or balloted as normative. However, a recommendation was received to leave it listed here until there is wider adoption/experience with other listed specifications. 
    • See HL7 V2 projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to-server 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.

    Comment

    Link updated

    Thank you for bringing this to our attention. The link has been updated. 

    Sending Health Care Survey Information to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 2
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 2
    Yes
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Secure Communication – create a secure channel for client-to-server 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.

    Comment

    Exchanging Immunization Data with Immunization Registries


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    Yes
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 5
    Yes
    Free
    Yes
    Implementation Specification
    Final
    Production
    Rating 3
    Yes
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting immunization registry data as there may be jurisdictional variation or requirements.
    • HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 – Addendum is also available.
    • See HL7 V2 projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to-server 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.

    Comment

    Thank you for bringing this…

    Thank you for bringing this to our attention. The link to the test tool has been updated. 

    Reporting Syndromic Surveillance to Public Health (Emergency Department, Inpatient, and Urgent Care Settings)


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Final
    Production
    Rating 5
    Yes
    Free
    No
    Implementation Specification
    Final
    Production
    Rating 4
    Yes
    Free
    Yes
    Emerging Implementation Specification
    Final
    Pilot
    Rating 1
    Yes
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting syndromic surveillance data as there may be jurisdictional variation or requirements.
    • An Erratum to the CDC PHIN 2.0 Implementation Guide was issued in August, 2015. Implementers should refer to this guide for additional information and conformance guidance.
    • See HL7 V2 projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to-server 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.

    Comment

    Data Submission for Title X Family Planning Annual Reporting


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Emerging Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • Feedback requested.

    Comment

    Reporting Death Records to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • Feedback requested. 
    • Feedback requested. 

    Comment

    Reporting Newborn Screening Results to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Limitations, Dependencies, and Preconditions for Consideration
    Applicable Security Patterns for Consideration
    • Use of the listed test tool requires digital certificates. Contact laura.rappleye@altarum.org for digital certification information.
    • There is current work to update the listed "ambulatory" implementation guides to include hospital reporting capabilities and Zika-related information.

    Feedback requested.

    Comment

    Reporting Birth and Fetal Death to Public Health Agencies


    Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
    Standard
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    No
    Implementation Specification
    Balloted Draft
    Pilot
    Rating 1
    No
    Free
    Yes
    Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
    • Use of the listed NIST test tool requires digital certificatesContact laura.rappleye@altarum.org for digital certification information.

    Feedback Requested. 

    Comment