This file is created on 2018-02-20 04:00:58am

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)

Comments

Permalink

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.

Permalink

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.

Permalink

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.

Comments

Permalink

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

Permalink

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

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.

Permalink

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.

Comments

Permalink

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. 

Permalink

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

Permalink

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)

Comments

Permalink

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

Permalink

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

Comments

Permalink

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.

Permalink

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

Permalink

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.

Permalink

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.

Permalink

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.

Permalink

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

Comments

Permalink

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

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. 

Comments

Permalink

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.

Permalink

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.

Permalink

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. 

Interoperability for Public Health Services


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

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

Comments

Permalink

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

 

Permalink

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

 

 

Permalink

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.

Enable Interoperability for Nutrition Care


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

PHR Interoperability with the HIT Ecosystem


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

Care Service Discovery Within the US


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 Security Patterns for Consideration
  • 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.

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. 

Comments

Permalink

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

Comments

Publish and Subscribe Message Exchange


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
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 3
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • The listed eHealth Exchange Specification will be deprecated in the future in favor of the emerging IHE DSUB specification and/or the equivalent FHIR profile.
  • See 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.

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

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

Comments

Permalink

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

Comments

Transport for Immunization Submission and Query/Response


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
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • Feedback requested
  • Feedback requested

Comments

Permalink

Haven't heard this referenced OUTSIDE of the context of an ISA in the past four years.  SOAP? Really?

 

Exchanging Patient Identification Management Within a Community


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

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

Comments

Permalink

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.

Permalink

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

Permalink

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

 

 

 

Permalink

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.

Listing of Providers for Access by Potential Exchange 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
Yes
Standard
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Production
Rating 2
No
Free
Yes
Emerging Standard
Balloted Draft
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • The IHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial Implementation was proposed, but not adopted for CEHRT 2015. The Health IT community has recognized the value of the underlying data elements and structure of that standard. However, this implementation specification has met with limited adoption due to several concerns. 
  • The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API”
  • The FHIR resources for this interoperability need might be limited to Service Provider Directory Resources within the Administration Module.
  • 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 IHE and FHIR projects in the Interoperability Proving Ground
  • Security Labeling – the health information is labeled with security metadata necessary for access control by the end user.

Comments

Permalink

Just an FYI that there is a IHE profile development process happening now for provider and facility directories via the "Mobile Care Services Discovery (mCSD)".  It will leverage FHIR STU3:
  https://groups.google.com/forum/#!topic/ititech/qPz-ok3AHuk
It is tracking the Argonaut work, as well as intended to include the functionality in the IHE CSD and HPD profiles. 

Volume 1 is being worked on/finalized now.

Cheers,
-carl

Thank you for this helpful information. We'll continue to monitor progress on this work and assess it's readiness for inclusion into the table above as it reaches trial implementation status within IHE.  

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. 

Comments

Permalink

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.

Permalink

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

 

Permalink

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

 

Permalink

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

 

Exchanging Imaging Documents Within a Specific Health Information Exchange Domain


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
No
Free
No
Implementation Specification
Final
Production
Rating 1
No
Free
Yes
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
Implementation Specification
Final
Production
Rating 4
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 Security Patterns for Consideration
  • IHE-PIX and IHE-PDQ are used for the purposes of patient matching and to support this interoperability need.
  • See 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.

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. 

Comments

Permalink

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/

Permalink

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.

Permalink

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

Comments

Permalink

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

Retrieval of Contextually Relevant, Patient-Specific Knowledge Resources from Within Clinical Information Systems to Answer Clinical Questions Raised by Patients in the Course of Care


Push Communication of Vital Signs from Medical Devices


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
$
Yes$
Implementation Specification
Final
Production
Rating 2
No
Free
Yes
Implementation Specification
Final
Production
Rating 3
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • ISO/IEEE 11073 is a family of standards for various medical devices.
  • The IEEE1073 Nomenclature is recognized in the IHE/HL7 record set
  • The ITU implementation specifications are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems.  Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines
  • Feedback requested

Comments

Permalink

Comments:

1.For the 3rd Row (ITU H.810…), please change:

•Standards Process Maturity to Final.

•Implementation maturity to Production.

•Adoption Level to 3 dots.

•Test Tool Availability should be ‘Yes’

•Add ‘H.812.5’ after ‘H.812’ within the series of standards to the ‘Standard Implementation/Specification

All should be equivalent to the first row (for ISO/IEEE 11073) as the 11073 the base protocols of the ITU and Continua Design Guidelines (where the test tool exists and is freely available).

2.There is no mention of IEEE 11073 Nomenclature. This nomenclature is recognized within the IHE/HL7 record-set. Please add a new row for this.

***Please note that several of the comments above were submitted last year but not implemented.*** 

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)

Comments

Permalink

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.

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.

Permalink

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

Remote Patient Monitoring to Support Chronic Condition Management, Patient Education, and Patient Engagement


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
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • These ITU standards are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems.  Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines
  • 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.

Comments

Permalink

Comments:

1.For the 1st Row (ITU H.810…), please change:

•Standards Process Maturity to Final.

•Implementation maturity to Production.

•Adoption Level to 3 dots.

•Test Tool Availability should be ‘Yes’

•Add ‘H.812.5’ after ‘H.812’ within the series of standards to the ‘Standard Implementation/Specification

2.Add a second row for “Continua Design Guidelines by PCHAlliance and include the same as the fields for the ITU above.

 

Representing 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

Representing Path Traversal Expressions


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

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

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

Comments

Permalink

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. 

 

Permalink

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

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)

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)

Support a Transition of Care or Referral to Another Health Care Provider


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
Balloted Draft
Production
Rating 5
Yes
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
Yes
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Final
Feedback requested
Rating 1
No
$
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • There are several specific document templates within the C-CDA implementation specification. Trading partners will need to ensure that their systems are capable of supporting specific document templates.
  • HL7 provides a C-CDA Example repository which contains a set of example C-CDA files that have undergone a review and vetting process to ensure completeness and rigour. 
  • The IHE 360X specification listed is designed to track and manage referrals across health IT platforms. 
  • The NCPDP Specialized Standard supports request/referral for Medication Therapy Management services. 
  • Implementers should explore use of emerging CDA on FHIR and C-CDA on FHIR to support this interoperability need. 
  • See CDA and CCDA projects in the Interoperability Proving Ground.
  • Feedback requested

Comments

Permalink

In Emerging Implementation Specification add the following:

  • NCPDP Specialized Standard supports request/referral for MTM Services may be initiated by the payer, treating or prescribing physician, pharmacist, a hospital or other facility, and/or the patient or caregiver.
  • CCDA R2 is the basis for NCPDP recommendations for Pharmacy Transition of Care, Pharmacy/Pharmacist care notes, and HL7 CDA® R2 Implementation Guide: Medication Therapy Management (MTM) Templates, Release 1 - US also known as HL7 IG for CDAR2: Medication Therapy Management (MTM) Templates, R1", MTM CMR Take-away document; MTM CMS document, CDAR2, MTM
  • Adoption Level should be a 1.

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

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

Document-Level Segmentation of Sensitive Information


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 3
Yes
Free
Yes
Emerging Implementation Specification
Final
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • See CDA projects in the Interoperability Proving Ground.
  • Per 2015 Edition Health IT Certification Criterion for DS4P (§ 170.315(b)(7) and § 170.315(b)(8)), document-level tagging is the scope required for certification.
  • For C-CDA transmission, document level DS4P is required in the C-CDA General Header.  Therefore, adoption levels may be higher for document level tagging (vs. section level).
  • Feedback requested

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

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

Comments

Permalink

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

Permalink

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.

 

Permalink

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.

Registering a Clinical Trial


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
N/A
Standard
Final
Pilot
Rating 5
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • The CDISC Clinical Trial Registry (CTR-XML) is used internationally, but in the US, the primary area for registering Clinical Trials is via ClinicalTrials.gov.
  • Feedback requested

Submission of Clinical Research Data to FDA to Support Product Marketing Applications


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
Yes
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 5
No
Free
Yes
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 3
Yes
Free
N/A
Implementation Specification
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
Yes
Free
N/A
Standard
Final
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • Feedback Requested

Sending a Notification of a Long Term Care Patients 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 Security Patterns for Consideration
  • 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.

Submit Adverse Event Report from an Electronic Health Record to Drug Safety Regulators


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

Comments

Permalink

remove this entry from the table. PRM is not closely related to adverse event submission.

Sending a Notification of a Patients 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 Security Patterns for Consideration
  • 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.

Comments

Permalink

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

 

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 Security Patterns for Consideration
  • 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

Comments

Permalink

  • 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 Security Patterns for Consideration
  • 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

Comments

Permalink

  • 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

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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • See IHE projects in the Interoperability Proving Ground.

  • Feedback requested

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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • Feedback requested

Comments

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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • 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

Comments

Permalink

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

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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • 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

Comments

Permalink

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

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 Security Patterns for Consideration
  • 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

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 Security Patterns for Consideration
  • 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.

Comments

Permalink

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

Permalink

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

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

Comment

Permalink

Dear Madam,
Dear Sir,

On behalf of the IVD Industry Connectivity Consortium we are pleased to provide written comments to the Office of the National Coordinator for Health Information Technology (ONC) in response to the 2017 Interoperability Standards Advisory (ISA).

The IVD Industry Connectivity Consortium (IICC) is a global, nonprofit organization dedicated to creating and encouraging adoption of a unified connectivity standard to reduce the cost and variability of data exchange between IVD devices and healthcare informatics in clinical laboratories. This will improve healthcare efficiency and patient care.

The IICC has collaborated with several government bodies, including the US Food and Drug Administration (DMD/OIR/CDRH), US Centers for Disease Control and Prevention, and US Department of Health and Human Services (HHS) (ONC), National Institutes of Health (NIH), and industry organizations such as IHE International, HL7, Clinical & Laboratory Standards Institute, the College of American Pathologists, the Association of Public Health Laboratories (APHL), the Medical Device Innovation Consortium (MDIC), and the Regenstrief Institute to develop two standards that together allow for true Plug & Play connectivity of IVD instruments to Middleware and Laboratory Information Systems (LIS).

The IVD Industry Connectivity Consortium appreciates the opportunity to leverage our volunteers’ expertise in commenting on the Standards Advisory, and we look forward to continuing our dialogue with ONC on identifying, assessing, and determining the best available interoperability standards and implementation specifications. We feel that this effort will provide the necessary foundation for more rapidly advancing interoperability.

The IVD Industry Connectivity Consortium finds that it would be beneficial if ONC would add the LAW – Laboratory Analytical Workflow Profile and LIVD – Digital Format for Publication of  LOINC to Vendor IVD Test Results standards to the following proposed new sections:

  • Section II: Content/Structure Standards and Implementation Specifications > Interoperability Need: 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

Standard

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

Final

Production

1

No

Free

No

  • Section II: Content/Structure Standards and Implementation Specifications > Interoperability Need: Connectivity between instruments, middleware, and LIS systems

Type

Standard/Implementation Specification

Standards
Process
Maturity

Implementation Maturity

Adoption Level

Federally
Required

Cost

Test Tool
Availability

Standard

LAW – Laboratory Analytical Workflow Profile

Final

Production

3

No

Free

Yes

 

  • LAW – Laboratory Analytical Workflow Profile – The LAW Profile defines the physical connection, message definitions (based on the HL7 Messaging Standard v2.5.1), and workflow definitions between instruments, middleware, and LIS systems in the laboratory. IICC collaborated with the IHE Pathology and Laboratory Medicine (PaLM) domain to develop the LAW Profile. LAW is already implemented by all major IVD companies, including Abbott Laboratories, Beckman Coulter, BD, bioMerieux, Data Innovations, Orchard Software, Ortho Clinical Diagnostics, Roche, Siemens Healthineers, Systelab, Sunquest, and Werfen Group.

For more information on LAW [ click here ]

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

For more information on LIVD [ click here ]

Why are LAW and LIVD important for clinical laboratories?

The LAW Profile and LIVD specifications should have a significant positive impact on laboratory operations. Clinical laboratories are encouraged to ask their instrument, middleware, and LIS vendors about their current or planned support for the IICC/IHE Laboratory Analytical Workflow (LAW) and LIVD. The LAW Profile is currently being implemented by all major IVD companies.

  • LAW and LIVD will significantly reduce the time and cost involved with deploying, connecting, and updating instruments in the laboratory by eliminating the need for vendor customized connectivity implementations, favoring vendors that adopt the specifications and pass the savings to their customers.
  • Addresses all the shortcomings of outdated laboratory connectivity standards such as CLSI LIS1-A (ASTM 1391) and CLSI LIS2 (ASTM E1394).
  • LAW will be a global standard (CLSI AUTO16).
  • LAW and LIVD support federal guidelines on Meaningful Use.
  • Improves the integrity of patient data.
  • The LAW and LIVD specifications are available for download and do not require any licensing or fees for implementation.

The IVD Industry Connectivity Consortium (IICC) would also ask ONC’s support to make both standards “Federally Required” for federal agencies as well as commercial entities.

We appreciate the opportunity to submit comments on the 2017 ISA.  Our comments are intended to recognize the importance of each stakeholder’s role in advancing standards-based interoperability and health information exchange, and ensuring that each domain is invested in overcoming the inherent challenges, while further enhancing health IT’s pivotal role in enabling healthcare transformation.

Please feel free to contact me if you have any questions or to obtain more information.

Sincerely,

Serge Jonnaert, BiD
President, IVD Industry Connectivity Consortium - ivdconnectivity.org
serge.jonnaert@ivdconnectivity.org
+1.949.259.3807
   / Board Member, At-Large - IHE International - ihe.net
   / President, AERTWORKS® LLC – www.aertworks.com

Permalink

Dear Dr. Rucker,

The Premier healthcare alliance is pleased to submit these comments in response to the Office of the National Coordinator’s (ONC) Request for Public Comments regarding the Interoperability Standards Advisory (ISA).

Premier is a leading healthcare improvement company, uniting an alliance of approximately 3,900 U.S. hospitals, hundreds of thousands of clinicians and more than 150,000 other provider organizations. Premier has one of the most comprehensive and largest healthcare databases in the industry. Premier works with its members on utilizing informatics, analytics, and data to improve care quality and patient safety, while achieving cost efficiencies. With integrated data and analytics, collaboratives, supply chain solutions, and advisory and other services, Premier enables better care and outcomes at a lower cost. Premier, a Malcolm Baldrige National Quality Award recipient, plays a critical role in the rapidly evolving healthcare industry, collaborating with members to co-develop long-term innovations that reinvent and improve the way care is delivered to patients nationwide. Specific comments in response to your questions are provided in the attached chart.

Premier shares the vision of achieving health information technology interoperability and the establishment and deployment of core standards and functions of health information technology (HIT) to enable an interoperable, learning health ecosystem. Premier appreciates ONC’s ongoing efforts to develop and enhance the ISA. However, the existence of standards and the publication of the ISA does not by itself ensure that application developers and HIT vendors implement and configure their software using the standards. Certainly, nationwide healthcare data exchange requires standards development and their timely adoption. Beyond exchange of data, however, interoperability requires data usability, understandability and development, recognition and adoption of common data sets, clinical terminologies and vocabularies and data definitions. Additionally, standards are needed for openly accessible electronic health record application program interfaces (APIs) to assure interoperability with other health information technologies and third party applications.

Premier hopes our comments (detailed in the attached letter) are helpful as you continue this important work. Premier stands ready to actively participate in ONC’s ongoing efforts to achieve nationwide interoperability. Please feel free to contact us for participation in your listening sessions, workgroups and other activities.

If you have any questions regarding our comments or need more information, please contact me or Meryl Bloomrosen, Senior Director, Federal Affairs, at meryl_bloomrosen@premierinc.com or 202.879.8012. We look forward to continued participation and dialogue. Thank you again for the opportunity to provide comments.

Sincerely,

Blair Childs

Senior vice president, Public Affairs

Premier healthcare alliance

 

Permalink

  • Modify the first paragraph to the following: Starting with the 2017 ISA, the ISA’s focus has 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).
  • ONC may want to consider adding verbiage around the addition of the administrative/payment oriented transactions.
Permalink

On behalf of the Integrating the Healthcare Enterprise (IHE) Quality, Research & Public Health (QRPH) Domain, I would like to submit the following for addition to the Section II: Content/Structure Standards and Implementation Specifications under the II-R: Public Health Reporting area as an emerging standard.  

Interoperability Need: Requirement to submit data for the Title X Family Planning Annual Reporting process at an encounter level and in real time, in a standard format defined by OPA.

Type:                Emerging Standard

URL: http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_FPv2.pdf

Standards Process Maturity: Balloted Draft

Implementation Maturity:    Pilot

Adoption Level:        1

Federally Required:        No

Test Tool Availability:        Feedback Requested

Cost:                Free

Other Notes for Consideration: OPA is currently engaged in an overhaul of their Family Planning Annual Reporting system, to enable the reporting of encounter level data from all of their Title X sites in a standard format and via a standard methodology. OPA is currently piloting two interoperability standards through this project and is intending to begin collecting data according to this new system in 2019.

 

Permalink

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

Section I:  Vocabulary/Code Set/Terminology Standards and Implementation Specifications

Comment:

The AMA recommends that the ISA include a seventh characteristic to the interoperability need table to inform stakeholders of the presence and inclusion of the terminology’s guidelines.  The use of a terminology’s guidelines is critical for consistent application of the codes and semantic interoperability of the data being exchanged through the terminology.  Consistent use of codes further ensures comparability of data that can better quantify the value of care and determine outcomes.  The following shows how this additional characteristic would be included in the table.

 

Representing Medical Procedures Performed

Type

Standard Implementation/Specification

Guidelines

Standards Process Maturity

Implementation Maturity

Adoption Level

Federally required

Cost

Test Tool Availability

Standard

SNOMED CT®

Yes

Final

Production

Image removed.

 

Yes

 

Free

N/A

Standard

the combination of CPT-4 and HCPCS

CPT-4: Yes

HCPCS: Yes

Final

Production

Image removed.

 

Yes

 

$

N/A

Standard

ICD-10-PCS

Yes

Final

Production

Image removed.

 

Yes

 

Free

N/A

 

 

Permalink

Dear Dr. Rucker,

 

UC San Francisco’s Center for Digital Health Innovation submits these comments on the 2018 Reference Edition of the Interoperability Standards Advisory. We thank you for the opportunity to provide these comments.

 

Very truly yours,

 

Mark Savage

 

Mark Savage

Director, Health Policy

Center for Digital Health Innovation

University of California, San Francisco

 

E. Mark.Savage@ucsf.edu

C. 415.225.1676

O. 415.502.1997

Permalink

Thank you for the opportunity to provide input on the 2018 Interoperability Standards Advisory (ISA) online document. Although the catalog focuses on the implementation needs of healthcare, it will play a role in ONC’s programs that support the 21st Century Cures Act. The Clinical Data Interchange Standards Consortium (CDISC) has engaged in projects with our fellow standards development organizations such as the Regenstrief Institute, IHE and HL7 over the past year to also help support 21st Century Cures Act and other initiatives at the intersection of care and research.

CDISC believes that, in order to realize the full impact of the bill, we as a society must invest in interoperation between existing healthcare and biomedical research standards and infrastructure. We thank the ONC for recognizing the importance of research as part of a learning health system through the inclusion of CDISC standards in the ISA. Our standards provide a consensus-based global language for protocol-driven clinical and translational research. They are also part of a larger tapestry of common research standards.

Many, if not most, major components of cancer-related research infrastructure in the United States are assets of or are being/have been funded by the United States National Cancer Institute (NCI). Their Enterprise Vocabulary Services (EVS) team manages dozens of commonly used semantic structures for research, including but not limited to CDISC terminology, and health. The following recommendations and requests are in support of expanding the ISA to include appropriate semantics to support ONC’s activities toward the 21st Century Cures Act. We recommend the following updates in support of cancer, and broader, research as it pertains to the coordination of multiple agencies involved with human health and research-based evolution:

  1. Section 1-Q Representing Analytic Data for Research Purposes: We request that the existing Clinical Data Interchange Standards (CDISC) Controlled Terminology for Regulatory Standards Hosted by NCI-EVS be updated to Clinical Data Interchange Standards Consortium (CDISC) Controlled Terminology for Data Collection (CDASH, QRS) and Aggregation (SDTM) Standards Hosted by NCI-EVS. This update refers to the specific controlled terminology packages rather than the overview page to all CDISC controlled terminologies. We also request the addition of the CDISC Controlled Terminology for Data Collection for Protocol Hosted by NCI-EVS, as these terms include semantics from academic, federal and industry projects and would support semantic interoperability of research study concepts among systems.
  2. Section 1-Q Representing Analytic Data for Research Purposes: In order to support precision medicine, we recommend that CDISC Controlled Terminology for SDTM Pharmacogenomics Data Aggregation Hosted by NCI-EVS (Enterprise Vocabulary Services) be added to the standard. These terminologies are final and have had modest adoption by the regulated research community. We further recommend that the ISA consider the addition of longstanding and newer ‘omics and phenotype standards that are being adopted by the global genomics community through the Global Alliance for Genomics and Health (GA4GH). HL7's Clinical Genomics group is also very involved in developing standards in this area, coordinating with GA4GH and CDISC. These standards have also been utilized by many diverse genomics efforts funded by the NCI. These include, but are not limited to the Human Phenotype Ontology, HGNC gene (and other molecular) identifiers and other ontologies hosted by the NCI Metathesaurus. These terminologies and ontologies are final, not required by the FDA and have moderate to high adoption.
  3. Section 1-Q Representing Analytic Data for Research Purposes: Many additional terminologies have been utilized by researchers from Cooperative Groups, research consortia and investigator-initiated trials. Cancer-related terminologies from these resources and others are found within the NCI-EVS. The cancer terminologies are bound to common data elements within the NCI caDSR, and these elements can help researchers to construct conformant data capture mechanisms linking data from health systems to research. These terminologies are final, not required by FDA and have moderate to high levels of community adoption.
  4. Section 1-Q Representing Analytic Data for Research Purposes: Terminology also exist for analysis datasets that are submitted to the United States Food and Drug Administration. As such we recommend the addition of the CDISC Controlled Terminology for Analysis Dataset Model (ADaM) Hosted by NCI-EVS. The terminologies are final, required by the FDA and have had high levels of community adoption.
  5. Section II-S: Research - Integrate Healthcare and Clinical Research by Leveraging EHRs and other Health IT Systems while Preserving FDA’s Requirements: We request the addition of required, open and highly adopted CDISC standards – the CDISC Study Data Tabulation Model (SDTM) and the CDISC Study Data Tabulation Model Implementation Guide. These standards have been utilized by diverse research teams from academia, patient advocacy groups, government and industry worldwide to aggregate data from many different real world data sources. In support of the 21st Century Cures Act and other indication-specific areas of integration of healthcare and clinical research data, we also request the inclusion of the implementation specification CDISC Therapeutic Area User Guides, which include multiple solid tumors along with dozens of other indications and conditions. There are multiple projects within the PhUSE, CDISC and other communities to map these implementation specifications to HL7 FHIR and other healthcare standards. These specifications are included in the FDA Technical Conformance Guide, but are not required, and their overall adoption is modest to moderate. Finally, we request the addition of the implementation specification CDISC Pharmacogenomics/genetics (PGx) Implementation Guide, a provisional standard with modest adoption, the maturation of which is occurring in collaboration with HL7 Clinical Genomics Working Group to bridge semantics among clinical genomicists and trialists.
  6. Section II-S: Research - Submission of Clinical Research Data to FDA to Support Product Marketing Applications. We request that the adoption level of the CDISC SEND standard be updated from low to moderate. This required standard is being utilized for submissions to regulators for all pre-clinical genetic toxicology information. We also request the addition of the freely available, non-required standard CDISC Questionnaires, Ratings and Scales (QRS) and the implementation specification CDISC Pharmacogenomics/genetics (PGx) Implementation Guide, a provisional standard with modest adoption.

We appreciate the ONC’s consideration of these requests and suggestions.

 

Lauren Becnel, Ph.D.

VP Strategy & Innovation

Clinical Data Interchange Standards Consortium (CDISC)

 

Permalink

Thank you for allowing us an opportunity to provide comments on the 2017 as you prepare for the 2018 version.  Included within our comments are comments we also received from VHA representatives.  If there are any questions regarding our comments, please let me know.  This document is key to help move the Industry towards a more open and standard's based approach in exchanging Health information.

 

Very Respectfully,

Chris Hills

Permalink

Thank you for the opportunity to provide comments on the 2017 edition of the ISA. We want to start by thanking ONC for their efforts to continually improve the ISA. The evolution of the format greatly improves its usefulness and navigation, especially the web-based layout and in-context comments. 

The added clarity on standards for observations and observation values is also a very important and welcome improvement. Across many interoperability needs, the ISA pairing of LOINC and SNOMED CT is an appropriate and helpful distinction.

Since publication of the 2017 edition, the ISA has expanded considerably in scope. It now includes a new section for Administrative Standards and interoperability needs around research and public health. The spectrum from public health to clinical care (including its administrative component) to clinical research is much more a continuum than discrete domains. We strongly support building towards a common, shared infrastructure across this spectrum and thus having them together in the ISA makes sense. However, the current set of interoperability needs across these domains are not very clearly defined and appear more to be generic labels for existing standards rather than actual use cases. Similarly, it is unclear why Administrative standards needs a separate section, when those standards also have the components of vocabularies and structures (and, perhaps later, models). 

We strongly agree with the suggestions made by the IVD Industry Connectivity Consortium (IICC) that ONC should add two new interoperability needs naming the LAW – Laboratory Analytical Workflow Profile and LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results standards. 

As we previously recommended, there are three high-value, well-established domains where the ISA can recommend additional vocabulary standards. They are a) Clinical measurements and observations, b) Clinical document types, and c) Patient reported outcome measures, survey instruments, and other standardized patient assessments.

There are large scale implementations around the world who have implemented the vocabularies in this way. And this usage has been recommended previously in the U.S. in many contexts, including the CHI initiatives, HITSC, and others.

Specifically, we recommend adding these areas to the ISA Section I: Vocabulary/Code Set/Terminology Standards and Implementation Specifications:

Clinical measurements and observations

Interoperability need: send, receive, and use clinical measurements and observations

Standard for observations: LOINC

Standard: SNOMED CT

Clinical document types

Interoperability need: send, receive, and use clinical documents

Standard: LOINC

Patient reported outcome measures, survey instruments, and other standardized patient assessments

Interoperability need: send, receive, and use patient reported outcomes measures, survey instruments and patient assessments

Standard: LOINC


__
 
Daniel J. Vreeman, PT, DPT, MS, FACMI
Director, LOINC and Health Data Standards, Regenstrief Center for Biomedical Informatics
Regenstrief-McDonald Scholar in Data Standards, Indiana University School of Medicine
Research Scientist, Regenstrief Institute, Inc 

 

 

Permalink

 

SECTION VI: Questions and Requests for Stakeholder Feedback

Section II: Content/Structure Standards and Implementation Specifications

Under “Case Reporting to Public Health Agencies”,

  1. HL7 FHIR Implementation Guide: Structured Data Capture (SDC) Release 1. The page link is broken.

 

Section V: Administrative Standards and Implementation Specifications

  1. Under “V-A: Health Care Claims and Coordination of Benefits”

“Health Care Claims or Equivalent Encounter Information for Retail Pharmacy Claims” is listed twice and one of the two links is broken. It leads to an unavailable temporary link.

 

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. 

 

Comments

Permalink

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.

 

Permalink

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

Comments

Permalink

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:

Comments

Permalink

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

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

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.

Comments

Permalink

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.

 

Permalink

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)

Permalink

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

Comments

Permalink

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.

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.

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 Security Patterns for Consideration
  • See CDA and QRDA projects in the Interoperability Proving Ground.
  • Feedback requested

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 Security Patterns for Consideration
  • 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

Comments

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 Security Patterns for Consideration
  • 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.

Comments

Permalink

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

A Prescribers Ability to Create a New Prescription to Electronically Send to a Pharmacy


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
Yes
$
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • The “New Prescription” transaction is best suited for this interoperability need. 
  • Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange.
  • 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.

Comments

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 Security Patterns for Consideration
  • 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

Comments

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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • 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

Comments

Permalink

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 Security Patterns for Consideration
  • Feedback requested
  • Feedback requested

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 Security Patterns for Consideration
  • 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. 

Data Element Based Query for Clinical Health Information


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
No
Implementation Specification
Balloted Draft
Production
Rating 2
No
Yes
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 1
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API
  • 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.  
  • 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.
  • Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information
    • May be required to authorized access and use of patient information
    • May be required to be sent along with disclosed patient information to
    • advise the receiver about policies to which end users must comply
  • Security Labeling – the health information is labeled with security metadata necessary for access control by the end user.
  • Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.

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

Comments

Permalink

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

Information Model for the Interoperability of Behavioral Health


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

Comments

Exchanging Diet and Nutrition Orders Across the Continuum of Care


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 Security Patterns for Consideration
  • 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.

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 Security Patterns for Consideration
  • 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.

Comments

Permalink

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

I-A: Allergies and Intolerances


II-A: Admission, Discharge, and Transfer


III-A: Push Exchange


V-A: Health Care Claims and Coordination of Benefits


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

Comments

Permalink

SNOMED CT value needs further restriction for Environmental Substances

UNII is really not all that helpful for clinical use.

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

Reporting Patient-level Quality Data for 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 Security Patterns for Consideration
  • See CDA and QRDA projects in the Interoperability Proving Ground.
  • Feedback requested

A Prescribers Ability to Grant a Refill Request to the Pharmacy


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 4
Yes
$
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • The “Refill Request” transaction is best suited for this interoperability need. 
  • Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange.
  • Allows the pharmacist to request approval for additional refills of a prescription beyond those originally prescribed.
  • 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.

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 Security Patterns for Consideration
  • Feedback requested

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 Security Patterns for Consideration
  • 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.

Query for Documents Outside a Specific Health Information Exchange Domain


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
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
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 Security Patterns for Consideration
  • IHE-PIX and IHE-XCPD are used for the purposes of patient matching and to support this interoperability need.
  • While IHE-PIX and IHE-XCPD are best-available standards at this time, the current best-available standards may be insufficient to meet interoperability needs with sufficient accuracy.
  • See IHE projects in the Interoperability Proving Ground.
  • System Authentication  -  The information and process necessary to authenticate the systems involved
  • User Authentication – The information and process necessary to authenticate the end user
  • User Details -  identifies the end user who is accessing the data
  • User Role - identifies the roles and clearances asserted by the individual initiating the transaction for purposes of authorization. E.g., the system must verify the initiator’s claims and match them against the security labels for the functionalities that the user attempts to initiate and the objects the user attempts to access.
  • Purpose of Use - Identifies the purpose for the transaction, and for the purposes for which the end user intends to use the accessed objects
  • Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information
    • May be required to authorized access and use of patient information
    • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply
  • Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.
  • Security Labeling – the health information is labeled with security metadata necessary for access control by the end user.

Information Model for the Interoperability of Diet and Nutrition Orders


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

Comments

Section I: Vocabulary/Code Set/Terminology Standards and Implementation Specifications


I-C: Family Health History

I-F: Imaging (Diagnostics, Interventions and Procedures)

I-H: Industry and Occupation

I-M: Patient Clinical “Problems” (i.e., conditions)

I-P: Race and Ethnicity

I-T: Tobacco Use (Smoking Status)

I-B: Encounter Diagnosis


II-C: Clinical Decision Support


II-B: Care Plan


III-B: Clinical Decision Support Services


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

Comments

Permalink

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.

Permalink

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

Comments

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.

Comments

Permalink

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

A Prescribers Ability to Obtain a Patients Medication History


Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 4
Yes
$
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Security Patterns for Consideration
  • Both the “Medication History Request” and “Medication History Response” transactions need to be implemented for interoperability purposes.
  • Both the prescriber and the receiving pharmacy or pharmacy benefits manager (PBM) must have their systems configured for the transaction in order to facilitate successful exchange. 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- 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.

Comments

Permalink

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

Support the Transmission of a Laboratorys Directory of Services to Providers 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