Frequently Asked Questions

Questions

Answers

Where do I send questions about the test procedures?

Questions about the applicability of the initial set of standards, implementation specifications, and certification criteria should be directed to ONC at ONC.Certification@hhs.gov. Questions about the test procedures should be directed to NIST at hit-tst-fdbk@nist.gov. Note that NIST automatically forwards to ONC at the address above any questions regarding the applicability of the standards, implementation specifications, and certification criteria.

Back to top

Will test procedures be modified to be domain or specialty specific? How will domain or specialty specific test data be handled?

The Test Procedures are not modified to be domain or specialty specific. The ONC Certification Program addresses how an Authorized Testing and Certification Body (ATCB) can consider unique aspects of domain and specialty systems.

Back to top

Who is the ‘Tester’?

The use of the term ‘Tester’ does not necessarily mean the person operating the keyboard. An ATCB may do remote testing and allows for a remote keyboarder. The ATCB will incorporate the use of remote testing into the ATCB’s Quality System to ensure that the integrity of the testing process is maintained. The Test Procedures require that the Tester enter the test data into the EHR technology being evaluated for conformance. The intent is that the Tester fully control the process of entering the test data in order to ensure that the data are correctly entered as specified in the test procedure. If a situation arises where it is impractical for a Tester to directly enter the test data, the Tester, at the Tester’s discretion, may instruct the Vendor to enter the test data, so long as the Tester remains in full control of the testing process, directly observes the test data being entered by the Vendor, and validates that the test data are entered correctly as specified in the test procedure.

Back to top

How are questions related to certification criteria and implementation specific comments being addressed?

NIST will not comment on the suitability of any particular implementation to meet the criteria. Questions focused primarily on the application of the Final Rule criteria are forwarded to the HHS/ONC Certification Program for consideration.

Back to top

What is the definition of modify?

Modify can mean edit, correct, update, adjust or change. The Test Data for each test procedure provide the Tester/Vendor clues to the definition used by NIST for the specific test procedure. In addition if the criterion uses the word “modify” and the test procedure includes Modify test steps, the Informative Test Description in the test procedure includes the following statement:

“The test procedure is not prescriptive about the method used to modify X. For example, modifying X does not require modifying an existing instance of X. Modification can be accomplished through changing the status of an existing X or entering a new X.”

Back to top

Why are laboratory and radiology/imaging orders included in the CPOE test procedures when these types of orders are not included in the CMS Final Rule?

Laboratory and radiology/imaging orders are included in the CPOE test procedures because these types of orders are included in the CPOE criterion in the ONC Final Rule

Back to top

How are standard codes associated with text descriptions (for example problems and smoking status) supposed to be tested if they are not displayed to the end-user?

Tester shall verify that the data entered or viewed during the test are associatedwith the required codes or standard terminologies. Validation methods include, but are not limited to:

  • verifying that the appropriate code is displayed along with the text description when the user is recording or viewing the data; or
  • verifying that the EHR includes the capability to cross-reference (map) the displayed text description when the user is recording or viewing data; or
  • verifying that the data stored in the EHR contains the appropriate codes

Back to top

Public Health Surveillance: The adopted implementation guides do not seem appropriate for the standards referenced in the criteria.

ONC has determined that the implementation specifications were adopted in error. On October 13, 2010, ONC published an interim final rule in the Federal Register (75 FR 62686) with an immediate effective date to remove the implementation specifications adopted at 45 CFR 170.205 (d)(2). NIST has updated and published the revised test procedure (version 1.2) based on the interim final rule.

Back to top

What does the EHR need to do in order to satisfy the ePrescribing medications vocabulary requirement?

The medications vocabulary requirement can be satisfied by populating the /MedicationPrescribed/DrugDBCode and /MedicationPrescribed/DrugDBCodeQualifier fields with the appropriate RxNorm codes or the appropriate codes from any source vocabulary incorporated in RxNorm, as defined by the National Library of Medicine.

Back to top

Will there be an XML version of the ePrescribing test procedure?

With NCPDP’s assistance, NIST has expanded the test procedure to include the XML versions of the SCRIPT v8.1 and v10.6 NEWRX messages.

Back to top

Who is doing the ePrescribing testing?

The ATCB’s will do the testing. ONC will identify the ATCBs.

Back to top

If our EHR has already been certified by Surescripts, does it still have to be tested?

Yes, the EHR will still need to be tested by an ONC-designated ATCB using the NIST test procedure

Back to top

Why doesn’t the NIST ePrescribing test include the Surescripts requirements?

The NIST test procedure includes only those requirements identified by ONC as necessary for Stage 1 of the Meaningful Use program.

Back to top

Why does the ePrescribing test procedure only require transmission of the NEWRX message but not receipt of the Verify, Status or Error messages which a pharmacy would send back to the EHR in response to a NEWRX message?

The ONC requirements do not specify the required behavior of the EHR upon receiving these messages. The Meaningful Use legislation does not apply to pharmacy systems, therefore the test procedure cannot impose any requirements on the pharmacy systems to send these messages.

Back to top

ePrescribing: Alternate formats for Sender/Receiver information in XML.

NCPDP has confirmed that various patterns may be utilized in the and portions of the XML Header:

1. If the mailto: pattern is asserted in the portion of the header, the qualifiers are included within the mailto pattern where the xxxxxxx value is the identifier, and ncpdp is the qualifier in the example below:

		 <To>mailto:xxxxxx.ncpdp@surescripts.com </To>
 		 <From>mailto:xxxxxxxx.spi@surescripts.com </From>

If the Vendor utilizes the mailto: pattern, then the ATCB may consider the conformance requirement for 060-S002-02-0007 and 070-S003-02-0007 in the UIB segment of Appendix A to have been met

2. Another valid format in the August 2010 v8.1 schema for the identifier and qualifier is:

		<transport:To Qualifier="P">7701630</transport:To>
		<transport:From Qualifier="C">77777777</transport:From>

If the Vendor utilizes this pattern, then the ATCB may consider the conformance requirement for 060-S002-02-0007 and 070-S003-02-0007 in the UIB segment of Appendix A to have been met.

Back to top

ePrescribing: Differences between October 2006 v8.1 XML schema and August 2010 v8.1 XML schema

NCPDP has published two slightly different versions of the v8.1 XML schema. Per NCPDP guidance, implementers may use either version, as determined by trading partner agreements. NCPDP has advised NIST that the October 2006 version of the v8.1 schema does not include the following qualifier attributes listed in the UIB segment of Appendix A.

  • 060-S002-02-0007 Level one identification code qualifier
  • 070-S003-02-0007 Level one identification code qualifier

The October 2006 version of the v8.1 schema does not include the following qualifier attribute listed in the DRU segment of Appendix A.

  • 020 I009 03 1131 Code List Qualifier

Therefore, if a Vendor claims conformance to the October 2006 schema, an ATCB should consider the conformance requirement to be "no equivalent in XML" for these fields.

Back to top

I noticed some apparent differences in the definitions for the HITSP template for Allergies and the required IHE template for Allergies (including inherited templates). Is this a known issue?

Yes. The following text is taken from the HITSP Public Comment Tracking System:

"This comment is an example of the issue of defining multiple templates within the CCD when they were not necessarily built as constraints one on top of the other. In this case, often the IHE and CCD/HITSP templates are in conflict. at a minimum, they often require data be present in multiple locations in the coded entry to meet the requirements of both IHE and CCD/HITSP.

"The CCD requires the AlertTypeCode in the allergy Observation / value element; the HITSP/C83 requires the Adverse Event Type in the allergy Observation / code element. They use different value sets (though the CCD may be a parent in the SNOMED CT hierarchy). HOWEVER, the IHE Allergies and Inolerances Observation (1.3.6.1.4.1.19376.1.5.3.1.4.6) paragraph indicates that the <value> is a description of the allergy or adverse reaction. there is no really good definition of what that means and there are no examples, but since the IHE A&I definition indicates the code observation / code represents the kind of allergy observation made, it can be assumed to not be the same def'n as the CCD Allergy Observation / value of AlertTypeCode.

"The CCD and HITSP/C83 IGs indicate that the problem/condition and allergy statuses are to be provided in a relatedEntry Observation. However, the IHE Concern template 1.3.6.1.4.1.19376.1.5.3.1.4.5.1 requires an Act.statusCode='active|suspended|aborted|completed'. these values are valid for all IHE Concern models include Problems & Allergies. while it's one thing to duplicate the information in order to be conformant with all 3 templates (CCD/HITSP/IHE), they do not support the same value sets. The CCD/HITSP ProblemStatusCode value set is 'Active|Inactive|Chronic|Intermittent|Recurrent|Rule out|Rules out|Resolved' (admittedly some are not statuses) and the AlertStatusCode value set is 'Active|Prior History|No Longer Active'"

This item is listed as "Open" in the HITSP Public Comment Tracking System.

Back to top

What additional specifications/profiles/guidelines are used by HITSP/C32v2.5 and how are they referenced? Where do I find them?

The document (1) HITSP/C32 directly references (2) HITSP/C83 and (3) HITSP/C80. See Section 2.1.1 of HITSP/C32 v2.5. The latest released version by HITSP of HITSP/C83 and HITSP/C80 are v2.0.

HITSP/C83 directly references (4) HL7's Continuity of Care Document (CCD) Specification. Many of the the Sections and Entries defined in HITSP/C83 are build upon existing CCD templates. See the individual sections and entries for the links to CCD.

HL7's Continuity of Care Document (CCD) is built upon (5) HL7's Clinical Document Architecture -- Release 2 (CDA R2). Section Section 1.1 - 1.3 of CCD.

HITSP/C83 directly references (6) HITSP/C154 and (already referenced) HITSP/C80. See Section 2.1.1 of HITSP/C83. HITSP/C154 is a data dictionary and defines the data elements which are used by HITSP/C83.

HITSP/C83 directly references the IHE PCC Medical Documents specification in C83-[CDA-2], a conformance statement which states: "A clinical document created using this specification SHALL contain the <templateid> element with a value of 1.3.6.1.4.1.19376.1.5.3.1.1.1 in the root attribute and no extension attribute indicating that it conforms to the IHE PCC Medical Documents specification".

Further, individual sections and entries in HITSP/C83 point to IHE PCC templates. Please see the individual sections and entries for the links. The PCC templates are defined and described in (7) Volume I and (8) Volume II of the IHE PCC Technical Framework. As of the time of writing, the latest version of these documents is Revision 5.0. These documents are available on the IHE website: http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_5-0_Vol_1_-2009-08-10.pdf and http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_50_Vol_2_2009-08-10.pdf.

Also, many templates are also defined in a supplement to the PCC Technical Framework called (9) Content Modules Supplement. This document can be found: http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Content_Modules_TI_-2009-08-10.pdf.

The IHE PCC Medical Documents template (1.3.6.1.4.1.19376.1.5.3.1.1.1) required by HITSP/C83 references parts of HL7's (10) CDA for Common Document Types History and Physical Notes (CDA4CDT). See Section 6.3.1.1 of Volume II of the IHE PCC Technical Framework. This document can be found: http://www.hl7.org/documentcenter/ballots/2007SEP/support/CDAR2_HPRPT_DSTU_2008AUG.zip. See specifically Section 6.3.1.1.3 of Volume II of the IHE PCC Technical Framework for information on which parts of CDA4CDT are required by your realm.

All of the above mentioned specifications are normative. Implementors may also be interested in reading HITSP TN901 Clinical Documents and HITSP TN903 Data Architecture for more descriptive information (informative sources)

HITSP specifications can be read at www.hitsp.org

IHE specifications can be read at: http://www.ihe.net/Technical_Framework/index.cfm

HL7 specifications can be read at: http://www.hl7.org

Back to top

Meaningful Use requires a medication section. The HITSP/C32 / HITSP/C83 Medication Section requires a Medication Module. However, a sample patient has no medication information (they are not on medication or we do not know). How do I code a lack of medication?

(Note that this is not necessarily the only correct way to code this type of information.)

In HL7 CCD we have the following statement: "CONF-299: The absence of known medications SHALL be explicitly asserted." (Section 3.9 Medications). However, at the CCD we are not given guidance as to how to do this in an entry-level.

So, we start at the section level. This is straightforward to code:

<section>
    <templateId root="2.16.840.1.113883.3.88.11.83.112" 
assigningAuthorityName="HITSP/C83"/>
   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.19" 
assigningAuthorityName="IHE PCC"/>
    <templateId root="2.16.840.1.113883.10.20.1.8" 
assigningAuthorityName="HL7 CCD"/>
   <code code="10160-0" codeSystem="2.16.840.1.113883.6.1" 
codeSystemName="LOINC" displayName="History of medication use"/>
   <title>Medications
   <text>
      <content ID="nomeds">Patient not on any medication
    </text>
</section>

Obviously, the text can be more clinically relevant than our above example.

We now need an entry. We start with the basics:

<entry typeCode="DRIV">
    <substanceAdministration classCode="SBADM" moodCode="EVN">
       <templateId root="2.16.840.1.113883.3.88.11.83.8" 
assigningAuthorityName="HITSP C83"/>
       <templateId root="2.16.840.1.113883.10.20.1.24" 
assigningAuthorityName="CCD"/>
       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7" 
assigningAuthorityName="IHE PCC"/>
       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1" 
assigningAuthorityName="IHE PCC"/>
       <id root="4edd8de0-66e3-4ca6-b287-f0736022f2b3"/>
       <statusCode code="completed"/>
       <consumable>
          <manufacturedProduct>
             <manufacturedMaterial>
             </manufacturedMaterial>
          </manufacturedProduct>
       </consumable>
    </substanceAdministration>
</entry>

(Note that consumable, manufacturedProduce and manufacturedMaterial are required by schema.)

The IHE Template 1.3.6.1.4.1.19376.1.5.3.1.4.7 (Section 6.3.4.16 in Volume II of the IHE PCC Technical Framework) states that the code on the substanceAdministration is the location for this type of information. Please read Section 6.3.4.16.7 of Volume II of the IHE PCC Technical Framework. Our example now looks like:

<entry typeCode="DRIV">
    <substanceAdministration classCode="SBADM" moodCode="EVN">
       <templateId root="2.16.840.1.113883.3.88.11.83.8" 
assigningAuthorityName="HITSP C83"/>
       <templateId root="2.16.840.1.113883.10.20.1.24" 
assigningAuthorityName="CCD"/>
       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7" 
assigningAuthorityName="IHE PCC"/>
       <templateid root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1" assigningauthorityname="IHE PCC">
       <id root="4edd8de0-66e3-4ca6-b287-f0736022f2b3"/>
       <code code="182849000"
                  codeSystem="2.16.840.1.113883.6.96"
                  displayName="No Drug Therapy Prescribed"
                  codeSystemName="SNOMED CT" />
       <statusCode code="completed"/>
       <consumable>
          <manufacturedProduct>
             <manufacturedMaterial>
             </manufacturedMaterial>
          </manufacturedProduct>
       </consumable>
    </substanceAdministration>
</entry>			

However, we are still not conformant with HITSP/C83 Medications as both the HITSP templates and the IHE templates on the substanceAdministration require additional templates. HITSP C83 Medications requires Medications Information (2.16.840.1.113883.3.88.11.83.8.2) and IHE PCC Medications requires Product Entry (1.3.6.1.4.1.19376.1.5.3.1.4.7.2). We fill those in (plus the CCD template which is required by both the templates):

<entry typeCode="DRIV">
    <substanceAdministration classCode="SBADM" moodCode="EVN">
       <templateId root="2.16.840.1.113883.3.88.11.83.8" 
assigningAuthorityName="HITSP C83"/>
       <templateId root="2.16.840.1.113883.10.20.1.24" 
assigningAuthorityName="CCD"/>
       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7" 
assigningAuthorityName="IHE PCC"/>
       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1" 
assigningAuthorityName="IHE PCC"/>
       <id root="4edd8de0-66e3-4ca6-b287-f0736022f2b3"/>
       <code code="182849000"
                  codeSystem="2.16.840.1.113883.6.96"
                  displayName="No Drug Therapy Prescribed"
                  codeSystemName="SNOMED CT" />
       <statusCode code="completed"/>
       <consumable>
          <manufacturedProduct>
             <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2" 
assigningAuthorityName="IHE PCC"/>
             <templateId root="2.16.840.1.113883.3.88.11.83.8.2" 
assigningAuthorityName="HITSP C83"/>
            <templateId root="2.16.840.1.113883.10.20.1.53" 
assigningAuthorityName="CCD"/>
            <manufacturedMaterial>
            </manufacturedMaterial>
          </manufacturedProduct>
      </consumable>
    </substanceAdministration>
</entry>

We are getting closer, but still not yet fully conformant. CCD requires the manufacturedMaterial to contain a code and originalText. ("CONF-358: A manufacturedMaterial in a product template SHALL contain exactly one manufacturedMaterial / code." and "CONF-363: A manufacturedMaterial i n a product template SHALL contain exactly one Material / code / originalText, which represents the generic name of the product.") In addition to the CCD requirements, in the required IHE PCC Product Entry template we have the following requirement: "In a CDA document, the <originaltext> shall contain a <reference> whose URI value points to the generic name and strength of the medication, or just the generic name alone if strength is not relevant." We now include a pointer here to the human readable portion in the section. This gives us a section and entry which look like:

<section>
    <templateId
root="2.16.840.1.113883.3.88.11.83.112"assigningAuthorityName="HITSP/C83"/>
    <templateId
root="1.3.6.1.4.1.19376.1.5.3.1.3.19"assigningAuthorityName="IHE PCC"/>
    <templateId root="2.16.840.1.113883.10.20.1.8" 
assigningAuthorityName="HL7 CCD"/>
    <code code="10160-0" codeSystem="2.16.840.1.113883.6.1" 
codeSystemName="LOINC" displayName="History of medication use"/>
    <title>Medications
    <text>
       <content ID="nomeds">Patient not on any medication
    </text>
    <entry typeCode="DRIV">
       <substanceAdministration classCode="SBADM" moodCode="EVN">
          <templateId root="2.16.840.1.113883.3.88.11.83.8" 
assigningAuthorityName="HITSP C83"/>
          <templateId root="2.16.840.1.113883.10.20.1.24" 
assigningAuthorityName="CCD"/>
          <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7" 
assigningAuthorityName="IHE PCC"/>
          <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1" 
assigningAuthorityName="IHE PCC"/>
          <id root="4edd8de0-66e3-4ca6-b287-f0736022f2b3"/>
          <code code="182849000"
codeSystem="2.16.840.1.113883.6.96"
displayName="No Drug Therapy Prescribed"
codeSystemName="SNOMED CT" />
          <statusCode code="completed"/>							
          <consumable>
             <manufacturedProduct>
                <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2" 
assigningAuthorityName="IHE PCC"/>
                <templateId root="2.16.840.1.113883.3.88.11.83.8.2" 
assigningAuthorityName="HITSP C83"/>
                <templateId
root="2.16.840.1.113883.10.20.1.53"assigningAuthorityName="CCD"/>
                <manufacturedMaterial>										
                   <code>
                      <originalText>
                         <reference value="#nomeds">
                      </originalText>
                   </code>										
                </manufacturedMaterial>
             </manufacturedProduct>
          </consumable>
       </substanceAdministration>
    </entry>
</section>

Whether it is also appropriate to have a second link to the #nomeds in the substanceAdministration/code/originalText/reference/@value is an exercise left to the reader.

Also note that IHE PCC Medications recommends two other SNOMED-CT codes to use for no/unknown medications:

  • 182904002 -- Drug Treatment Unknown
  • 182849000 -- No Drug Therapy Prescribed
  • 408350003 -- Patient Not On Self-Medications

Again, note that this solution is not necessarily the only correct way to code this type of information.

Back to top

Meaningful Use requires a allergies/alerts section. The HITSP/C32 /HITSP/C83 Allergies and Other Adverse Reactions Section requires an Allergy/Drug Sensitivity module. However, a sample patient has no allergy information (a patient has no known allergies, or we do not know if the patient has allergies). How do I assert a lack of knowledge?

(Note that this is not necessarily the only correct way to code this type of information.)

From HL7 CCD CONF-268: "The absence of known allergies SHOULD be represented in an alert observation by valuing Observation / value with 160244002 “No known allergies” 2.16.840.1.113883.6.96 SNOMED CT STATIC."

Adding in the information required by the HITSP templates (and the required IHE PCC templates) gives us a section which looks like:

<section>
    <templateId root="2.16.840.1.113883.10.20.1.2"/>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.13"/>
    <code code="48765-2" codeSystem="2.16.840.1.113883.6.1"/>
    <title>Allergies, Adverse Reactions, Alerts
    vtext>
       <content ID="noallergies">No allergies or drug sensitivities.
    </text>
    <entry typeCode="DRIV">
       <act classCode="ACT" moodCode="EVN">
          <templateId root="2.16.840.1.113883.10.20.1.27"/>
          <templateId root="2.16.840.1.113883.3.88.11.83.6"/>
          <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>
          <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.3"/>
          <id root="f6fd6f86-4265-4dcb-95cf-7799100b54ad"/>
          <code nullFlavor="NA"/>
          <statusCode code="active"/>						
          <effectiveTime>
             <low nullFlavor="NA"/>
          </effectiveTime>							
          <entryRelationship typeCode="SUBJ" inversionInd="false">
             <observation classCode="OBS" moodCode="EVN">
                <templateId root="2.16.840.1.113883.10.20.1.18"/>
                <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.6"/>
                <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>
                <templateId root="2.16.840.1.113883.10.20.1.28"/>
                <id root="2b37be6b-9b1c-4069-bbca-1caf5fe1937d"/>
                <code code="420134006" codeSystem="2.16.840.1.113883.6.96"
displayName="Propensity to adverse reactions (disorder)"
codeSystemName="SNOMED CT"/>
                <statusCode code="completed"/>
                <effectiveTime>
                   <low nullFlavor="UNK"/>
                </effectiveTime>
                <value xsi:type="CD" code="160244002"
codeSystem="2.16.840.1.113883.6.96"
displayName="No Known allergies" codeSystemName="SNOMED CT">
                   <originalText>
                      <reference value="#noallergies"/>
                   </originalText>
                </value>
             </observation>
          </entryRelationship>
       </act>
    </entry>
</section>

See the observation/value which is set to the value recommended by HL7 CCD.

Note that the effectiveTime/low in the act is required by the IHE PCC Concern Entry template. It is set to NA because it does not apply in the case of no/unknown allergies. The effectiveTime/low/@nullFlavor set to UNK in the observation is from IHE PCC Problem Entry.

IHE PCC Problem Entry also gives more guidance for other codes to use for no/unknown allergies. See Volume II of the IHE PCC Technical Framework, Section 6.3.4.14 Problem Entry. Specifically the table in Section 6.3.4.14.11 which defines the value element.

  • 409137002 -- No Known Drug Allergies -- To indicate that there are no known Drug allergies for this patient.
  • 160244002 -- No Known Allergies -- To indicate that there are no known allergies for this patient.
  • 64970000 -- Substance Type Unknown -- To indicate the state where there is a known allergy or intolerance to an unknown substance.

These are all SNOMED-CT codes.

Back to top

Meaningful Use specifies Vocabulary X, but the HITSP specifications only allow Vocabulary Y. How do I encode something that satisfies both?

Starting with HITSP/C83 v2.0 there is text in the specification describing how to get around the fact that HITSP has specified required vocabularies and MU has specified different required vocabularies. This language was added specifically because of ARRA. This following text comes from Section 1.4.3 (Use of Vocabulary Recommended to Support ARRA HITECH) of HITSP/C83 v2.0:

1.4.3 USE OF VOCABULARY RECOMMENDED TO SUPPORT ARRA HITECH This HITSP Component has been modified to support vocabularies allowed for meaningful use and other American Recovery and Reinvestment ACT (ARRA) HITECH requirements for all Components that rely upon it. In almost all cases, coded values in the HITSP/C83 specifications are either optional (O) or required if known (R2) instead of required (R). In these cases, it is permissible to include a (code) element using a nullFlavor of UNK indicating that the information is unknown, and include (translation) elements which indicate codes from other code systems.

Let's take Problem List as an example. HITSP requires that a SNOMED-CT code be used. Meaningful Use allows SNOMED-CT or ICD-9. If you do the following (use SNOMED-CT), you are compliant with both:

<observation classCode="OBS" moodCode="EVN">
            [...]
    <value xsi:type="CD" code="37796009" displayName="Migraine"
     codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96"/>
[...]
</observation>

However, if you try to use an ICD-9 value in the same way:

<observation classCode="OBS" moodCode="EVN"> 
            [...]
     <value xsi:type="CD" code="346.9" displayName='Migrane'
     codeSystem="2.16.840.1.113883.6.103"
     codeSystemName="ICD-9-CM" />
[...]
</observation>

...you violate the rule in HITSP/C83 which states that HITSP/C83 Condition Problem Code SHALL be coded as specified in HITSP/C80 Section 2.2.3.1.1 Problem. In this instance, the SHALL requirement is on the cda:observation/cda:value[@code and @codeSystem]. So the ICD-9 is a violation.

The method to get around this and to be compatible with both Meaningful Use and HITSP is to use the format stated in 1.4.3:

<observation classCode="OBS" moodCode="EVN"> 
            [...]
     <value xsi:type="CD" nullFlavor="UNK">
            <translation code='346.9' displayName='Migraine'
               codeSystem='2.16.840.1.113883.6.103'
               codeSystemName='ICD-9-CM'/>            
     </value>
[...]
</observation>

The nullFlavor of value is set to UNK and the Meaningful Use vocabulary (ICD-9 in this case) is used in the translation tag under the value. Please see the entirety of HITSP/C83 Section 1.4.3 USE OF VOCABULARY RECOMMENDED TO SUPPORT ARRA HITECH contains more detailed information.

Back to top

The HITSP documents describe an Drug Allergy Type and state that it shall be coded to SNOMED-CT. What does this data element mean and what are the allowed codes? What should I do if the information is unknown?

This is one of the very few places in HITSP/C32 / HITSP/C83 which requires a specific value set be used. In most places, even if the HITSP document requires a specific code system, there is language that will get you around the requirement. But that language specifically does not apply to Adverse Event Type.

In the spec, the Adverse Event Type is required and the allowed SNOMED-CT values are (from HITSP/C80):

  • 420134006: Propensity to adverse reactions (disorder)
  • 418038007: Propensity to adverse reactions to substance (disorder)
  • 419511003: Propensity to adverse reactions to drug (disorder)
  • 418471000: Propensity to adverse reactions to food (disorder)
  • 419199007: Allergy to substance (disorder)
  • 416098002: Drug allergy (disorder)
  • 414285001: Food allergy (disorder)
  • 59037007: Drug intolerance (disorder)
  • 235719002: Food intolerance (disorder)

There is also language that states: "6.02 Adverse Event Type, producers who are unable to classify allergies according to the HITSP vocabulary SHALL use the code 420134006 Propensity to adverse reactions as the code instead of using nullFlavor='UNK' value. In the context of adverse reactions, this code indicates the presence of an adverse reaction of an unknown type to an unknown substance and is preferable to (and equivalent in meaning to) the use of nullFlavor='UNK'"

Back to top

Location of NIST Meaningful Use testing tools.

The NIST Meaningful Use testing tools have recently changed servers. To access the testing tools, the following are updated URLs by test procedure:

Back to top