Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(b)(3) Electronic prescribing

Updated on 07-08-2024
Regulation Text
Regulation Text

§ 170.315(b)(3) Electronic prescribing.

(ii) For technology certified subsequent to June 30, 2020:

  1. Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(1) as follows:
    1. Create new prescriptions (NewRx).
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
    3. Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
    5. Receive fill status notifications (RxFill).
    6. Request and receive medication history (RxHistoryRequest, RxHistoryResponse).
    7. Relay acceptance of a transaction back to the sender (Status).
    8. Respond that there was a problem with the transaction (Error).
    9. Respond that a transaction requesting a return receipt has been received (Verify).
  2. Optionally, enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:
    1. Create and respond to new prescriptions (NewRxRequest, NewRxResponseDenied).
    2. Send fill status notifications (RxFillIndicator).
    3. Ask the Mailbox if there are any transactions (GetMessage).
    4. Request to send an additional supply of medication (Resupply).
    5. Communicate drug administration events (DrugAdministration).
    6. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm).
    7. Recertify the continued administration of a medication order (Recertification).
    8. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
    9. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, and PACancelResponse).
  3. For the following prescription-related transactions, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>:
    1. Required transactions
      1. Create new prescriptions (NewRx).
      2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
      3. Request to cancel prescriptions (CancelRx).
      4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
      5. Receive fill status notifications (RxFill).
      6. Receive medication history (RxHistoryResponse).
    2. Optional transactions:
      1. Request to send an additional supply of medication (Resupply)
      2. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse)
      3. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
      4. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse).
  4. Optional. For each transaction listed in paragraph (b)(3)(ii)(C) of this section, the technology must be able to receive and transmit reason for prescription using the <IndicationforUse> element in the Sig segment.
  5. Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).
  6. Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.
Standard(s) Referenced

Paragraph (b)(3)(i)

§ 170.205(b)(1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

§ 170.207(d)(3) RxNorm, September 8, 2015 Full Release Update (Adoption of this standard expires on January 1, 2026.)

§ 170.207(d)(1): RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022 Full Monthly Release (This standard is required by December 31, 2025.)

 

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their version of RxNorm as outlined in paragraphs (b)(3)(i).

Certification Dependencies

Conditions and Maintenance of Certification Requirements

Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of
Certification.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(b)(3). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(b) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (b) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, an exception exists for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and § 170.315(e)(2) “Secure messaging,” which are explicitly stated.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
1.1

Updated testing tool from NCPDP to new Electronic Prescribing (eRx) tool.
07-08-2024
Regulation Text
Regulation Text

§ 170.315(b)(3) Electronic prescribing.

(ii) For technology certified subsequent to June 30, 2020:

  1. Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(1) as follows:
    1. Create new prescriptions (NewRx).
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
    3. Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
    5. Receive fill status notifications (RxFill).
    6. Request and receive medication history (RxHistoryRequest, RxHistoryResponse).
    7. Relay acceptance of a transaction back to the sender (Status).
    8. Respond that there was a problem with the transaction (Error).
    9. Respond that a transaction requesting a return receipt has been received (Verify).
  2. Optionally, enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:
    1. Create and respond to new prescriptions (NewRxRequest, NewRxResponseDenied).
    2. Send fill status notifications (RxFillIndicator).
    3. Ask the Mailbox if there are any transactions (GetMessage).
    4. Request to send an additional supply of medication (Resupply).
    5. Communicate drug administration events (DrugAdministration).
    6. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm).
    7. Recertify the continued administration of a medication order (Recertification).
    8. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
    9. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, and PACancelResponse).
  3. For the following prescription-related transactions, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>:
    1. Required transactions
      1. Create new prescriptions (NewRx).
      2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
      3. Request to cancel prescriptions (CancelRx).
      4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
      5. Receive fill status notifications (RxFill).
      6. Receive medication history (RxHistoryResponse).
    2. Optional transactions:
      1. Request to send an additional supply of medication (Resupply)
      2. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse)
      3. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
      4. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse).
  4. Optional. For each transaction listed in paragraph (b)(3)(ii)(C) of this section, the technology must be able to receive and transmit reason for prescription using the <IndicationforUse> element in the Sig segment.
  5. Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).
  6. Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.
Standard(s) Referenced

Paragraph (b)(3)(i)

§ 170.205(b)(1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

§ 170.207(d)(3) RxNorm, September 8, 2015 Full Release Update (Adoption of this standard expires on January 1, 2026.)

§ 170.207(d)(1): RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022 Full Monthly Release (This standard is required by December 31, 2025.)

 

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their version of RxNorm as outlined in paragraphs (b)(3)(i).

Certification Dependencies

Conditions and Maintenance of Certification Requirements

Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of
Certification.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(b)(3). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(b) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (b) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, an exception exists for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and § 170.315(e)(2) “Secure messaging,” which are explicitly stated.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Testing
Testing Tool

Electronic Prescribing (eRx) Testing Tool

Criterion Subparagraph Test Data
(b)(3)

Refer to Electronic Prescribing (eRx) Testing Tool
Revision History
Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
1.1

Updated testing tool from NCPDP to new Electronic Prescribing (eRx) tool.
07-08-2024

This Test Procedure illustrates the test steps required to certify a Health IT Module to this criterion. Please consult the most recent ONC Final Rule on the Certification Regulations page for a detailed description of the certification criterion with which these testing steps are associated. ONC also encourages developers to consult the Certification Companion Guide in tandem with the test procedure as it provides clarifications that may be useful for product development and testing.

Note: The test step order does not necessarily prescribe the order in which the tests should take place.

Testing components

No Documentation Icon Visual Inspection Icon Test Tool Icon ONC Supplied Test Data Icon No SVAP Icon

Paragraph (b)(3) - (Conditional - For Modules with Existing Certification to (b)(3))

System Under Test
Required by December 31, 2025

A Health IT Module currently certified to the § 170.315(b)(3) Electronic prescribing will attest directly to the ONC-ACB to conformance with the updated § 170.315(b)(3) requirements outlined in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. 

Test Lab Verification
Required by December 31, 2025

The ONC-ACB verifies the health IT developer of a Health IT Module certified to § 170.315(b)(3) Electronic prescribing attests conformance to § 170.315(b)(3) criterion update requirements. 

   

System Under Test Test Lab Verification
Required by December 31, 2025

A Health IT Module currently certified to the § 170.315(b)(3) Electronic prescribing will attest directly to the ONC-ACB to conformance with the updated § 170.315(b)(3) requirements outlined in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. 
Required by December 31, 2025

The ONC-ACB verifies the health IT developer of a Health IT Module certified to § 170.315(b)(3) Electronic prescribing attests conformance to § 170.315(b)(3) criterion update requirements. 

   

Paragraphs (b)(3)(ii)(A)(1-5, 7-9) Send and receive

System Under Test
  1. The health IT developer creates new prescriptions (NewRx) in accordance with (b)(3)(ii)(A)(1) and (b)(3)(ii)(A)(2) request and respond to change prescriptions (RxChangeRequest, RxChangeResponse), and (b)(3)(ii)(A)(5) fill status notifications (RxFill).
  2. The health IT developer creates new prescriptions (NewRx) in accordance with (b)(3)(ii)(A)(1) and (b)(3)(ii)(A)(3) request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
  3. The health IT developer creates new prescriptions (NewRx) in accordance with (b)(3)(ii)(A)(1) and (b)(3)(ii)(A)(4) request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
  4. The health IT developer relays acceptance of a transaction back to the sender (Status) in accordance with (b)(3)(ii)(A)(7).
  5. The health IT developer responds that there was a problem with the transaction (Error) in accordance with (b)(3)(ii)(A)(8).
  6. The health IT developer responds that a transaction requesting a return receipt has been received (Verify) in accordance with (b)(3)(ii)(A)(9).
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following required transactions:
    1. Create and send new prescription (NewRx);
    2. Receive prescription change request (RxChangeRequest);
    3. Create and send prescription change response (RxChangeResponse); and
    4. Receive fill status notification (RxFill).
  2. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following required transactions:
    1. Create and send new prescription (NewRx);
    2. Send request to cancel prescription (CancelRx); and
    3. Receive response to request to cancel prescription (CancelRxResponse).
  3. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation reports for the following required transactions:
    1. Create and send new prescription (NewRx);
    2. Receive request to renew prescription (RxRenewalRequest); and
    3. Create and send response to renew prescription (RxRenewalResponse).
  4. The tester verifies the Health IT Module supports Status, Error and Verify transactions.
System Under Test Test Lab Verification
  1. The health IT developer creates new prescriptions (NewRx) in accordance with (b)(3)(ii)(A)(1) and (b)(3)(ii)(A)(2) request and respond to change prescriptions (RxChangeRequest, RxChangeResponse), and (b)(3)(ii)(A)(5) fill status notifications (RxFill).
  2. The health IT developer creates new prescriptions (NewRx) in accordance with (b)(3)(ii)(A)(1) and (b)(3)(ii)(A)(3) request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
  3. The health IT developer creates new prescriptions (NewRx) in accordance with (b)(3)(ii)(A)(1) and (b)(3)(ii)(A)(4) request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
  4. The health IT developer relays acceptance of a transaction back to the sender (Status) in accordance with (b)(3)(ii)(A)(7).
  5. The health IT developer responds that there was a problem with the transaction (Error) in accordance with (b)(3)(ii)(A)(8).
  6. The health IT developer responds that a transaction requesting a return receipt has been received (Verify) in accordance with (b)(3)(ii)(A)(9).
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following required transactions:
    1. Create and send new prescription (NewRx);
    2. Receive prescription change request (RxChangeRequest);
    3. Create and send prescription change response (RxChangeResponse); and
    4. Receive fill status notification (RxFill).
  2. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following required transactions:
    1. Create and send new prescription (NewRx);
    2. Send request to cancel prescription (CancelRx); and
    3. Receive response to request to cancel prescription (CancelRxResponse).
  3. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation reports for the following required transactions:
    1. Create and send new prescription (NewRx);
    2. Receive request to renew prescription (RxRenewalRequest); and
    3. Create and send response to renew prescription (RxRenewalResponse).
  4. The tester verifies the Health IT Module supports Status, Error and Verify transactions.

Paragraph (b)(3)(ii)(A)(6) Send and receive - medication history

System Under Test
  1. The health IT developer requests and receives a patient’s medication history (RxHistoryRequest, RxHistoryResponse) in accordance with (b)(3)(ii)(A)(6).
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following required transactions:
    1. Send a request for a medication history (RxHistoryRequest); and
    2. Receive a response to a request for a medication history (RxHistoryResponse).
    3. Receive a Status message (Status) in response to a request for a medication history (RxHistoryRequest) and receive a response to a request for a medication history (RxHistoryResponse).
System Under Test Test Lab Verification
  1. The health IT developer requests and receives a patient’s medication history (RxHistoryRequest, RxHistoryResponse) in accordance with (b)(3)(ii)(A)(6).
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following required transactions:
    1. Send a request for a medication history (RxHistoryRequest); and
    2. Receive a response to a request for a medication history (RxHistoryResponse).
    3. Receive a Status message (Status) in response to a request for a medication history (RxHistoryRequest) and receive a response to a request for a medication history (RxHistoryResponse).

Paragraph (b)(3)(ii)(C)(1) Send and receive - required transactions

System Under Test
  1. The Health IT Module is able to transmit and receive the reason for the prescription using the <Diagnosis><Primary> or <Secondary> diagnosis elements for the following transactions in accordance with (b)(3)(ii)(C)(1):
    1. Create new prescriptions (NewRx);
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse);
    3. Request to cancel prescriptions (CancelRx);
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse);
    5. Receive fill status notifications (RxFill); and
    6. Receive response to medication history requested (RxHistoryResponse).
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the reason for the prescription using the <Diagnosis><Primary> or <Secondary> diagnosis elements for all transactions, using the test data specified with the selected test case via the test tool:
    1. Create new prescriptions (NewRx);
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse);
    3. Request to cancel prescriptions (CancelRx);
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse);
    5. Receive fill status notifications (RxFill); and
    6. Receive response to medication history (RxHistoryResponse).
System Under Test Test Lab Verification
  1. The Health IT Module is able to transmit and receive the reason for the prescription using the <Diagnosis><Primary> or <Secondary> diagnosis elements for the following transactions in accordance with (b)(3)(ii)(C)(1):
    1. Create new prescriptions (NewRx);
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse);
    3. Request to cancel prescriptions (CancelRx);
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse);
    5. Receive fill status notifications (RxFill); and
    6. Receive response to medication history requested (RxHistoryResponse).
  1. The tester verifies the Health IT Module sends and receives the reason for the prescription using the <Diagnosis><Primary> or <Secondary> diagnosis elements for all transactions, using the test data specified with the selected test case via the test tool:
    1. Create new prescriptions (NewRx);
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse);
    3. Request to cancel prescriptions (CancelRx);
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse);
    5. Receive fill status notifications (RxFill); and
    6. Receive response to medication history (RxHistoryResponse).

Paragraph (b)(3)(ii)(E) Liquid medications

System Under Test
  1. The Health IT Module is able to prescribe all oral liquid medications in only the metric standard units of milliliter (mL) (i.e., not cubic centimeter (cc) or teaspoon) in accordance with (b)(3)(ii)(E).
  2. Negative Testing: The health IT developer attempts to prescribe an oral liquid medication using non-metric standard units.
Test Lab Verification
  1. The tester verifies that the Health IT Module limits the ability to prescribe all oral liquid medications in metric standard units of milliliter (mL).
  2. Negative Testing: The tester verifies through visual inspection of the System Under Test that the Health IT Module does not have the ability to prescribe oral liquid medications using non-metric standard units (i.e., cubic centimeter (cc), teaspoon).
System Under Test Test Lab Verification
  1. The Health IT Module is able to prescribe all oral liquid medications in only the metric standard units of milliliter (mL) (i.e., not cubic centimeter (cc) or teaspoon) in accordance with (b)(3)(ii)(E).
  2. Negative Testing: The health IT developer attempts to prescribe an oral liquid medication using non-metric standard units.
  1. The tester verifies that the Health IT Module limits the ability to prescribe all oral liquid medications in metric standard units of milliliter (mL).
  2. Negative Testing: The tester verifies through visual inspection of the System Under Test that the Health IT Module does not have the ability to prescribe oral liquid medications using non-metric standard units (i.e., cubic centimeter (cc), teaspoon).

Paragraph (b)(3)(ii)(F) e-Prescriptions

System Under Test
  1. The Health IT Module inserts leading zeroes before the decimal point for all amounts less than one when a prescriber prescribes medication in accordance with (b)(3)(ii)(F).
  2. The Health IT Module does not allow trailing zeroes after a decimal point when a prescriber prescribes medication.
Test Lab Verification
  1. The tester verifies through visual inspection of the System Under Test that leading zeroes are inserted before the decimal point for all amounts less than one when a prescriber prescribes medication.
  2. The tester verifies through visual inspection of the System Under Test that there are no trailing zeroes after a decimal point when a prescriber prescribes medication.
System Under Test Test Lab Verification
  1. The Health IT Module inserts leading zeroes before the decimal point for all amounts less than one when a prescriber prescribes medication in accordance with (b)(3)(ii)(F).
  2. The Health IT Module does not allow trailing zeroes after a decimal point when a prescriber prescribes medication.
  1. The tester verifies through visual inspection of the System Under Test that leading zeroes are inserted before the decimal point for all amounts less than one when a prescriber prescribes medication.
  2. The tester verifies through visual inspection of the System Under Test that there are no trailing zeroes after a decimal point when a prescriber prescribes medication.

Paragraph (b)(3)(ii)(B)(1) Optional

System Under Test
  1. The health IT developer receives the transaction creating a request for a new prescription and denies the request (NewRxRequest, NewRxResponseDenied) in accordance with (b)(3)(ii)(B)(1).
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following transactions:
    1. Receive request for a new prescription (NewRxRequest); and
    2. Send denial for a request for new prescription (NewRxResponseDenied).
System Under Test Test Lab Verification
  1. The health IT developer receives the transaction creating a request for a new prescription and denies the request (NewRxRequest, NewRxResponseDenied) in accordance with (b)(3)(ii)(B)(1).
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following transactions:
    1. Receive request for a new prescription (NewRxRequest); and
    2. Send denial for a request for new prescription (NewRxResponseDenied).

Paragraph (b)(3)(ii)(B)(2) Optional

System Under Test
  1. The health IT developer sends a fill status indicator change (RxFillIndicator) in accordance with (b)(3)(ii)(B)(2).
Test Lab Verification
  1. The tester verifies the Health IT Module sends the RxFillIndicator transaction and completes all required test tool interaction steps and verifies the validation report.
System Under Test Test Lab Verification
  1. The health IT developer sends a fill status indicator change (RxFillIndicator) in accordance with (b)(3)(ii)(B)(2).
  1. The tester verifies the Health IT Module sends the RxFillIndicator transaction and completes all required test tool interaction steps and verifies the validation report.

Paragraph (b)(3)(ii)(B)(3) Optional

System Under Test
  1. The health IT developer asks the mailbox if there are any transactions (GetMessage) in accordance with (b)(3)(ii)(B)(3).
Test Lab Verification
  1. The tester verifies the Health IT Module tests the GetMessage transaction and completes all required test tool interaction steps and verifies the validation report.
System Under Test Test Lab Verification
  1. The health IT developer asks the mailbox if there are any transactions (GetMessage) in accordance with (b)(3)(ii)(B)(3).
  1. The tester verifies the Health IT Module tests the GetMessage transaction and completes all required test tool interaction steps and verifies the validation report.

Paragraph (b)(3)(ii)(B)(4) Optional

System Under Test
  1. The health IT developer sends the transaction to request to send an additional supply of medication (Resupply) in accordance with (b)(3)(ii)(B)(4).
  2. The Health IT Module is able to transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
Test Lab Verification
  1. The tester verifies the Health IT Module sends the Resupply transaction and completes all required test tool interaction steps and verifies the validation report.
  2. The tester verifies the Health IT Module transmits the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
System Under Test Test Lab Verification
  1. The health IT developer sends the transaction to request to send an additional supply of medication (Resupply) in accordance with (b)(3)(ii)(B)(4).
  2. The Health IT Module is able to transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
  1. The tester verifies the Health IT Module sends the Resupply transaction and completes all required test tool interaction steps and verifies the validation report.
  2. The tester verifies the Health IT Module transmits the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.

Paragraph (b)(3)(ii)(B)(5) Optional

System Under Test
  1. The health IT developer sends the transaction to communicate drug administration events (DrugAdministration) in accordance with (b)(3)(ii)(B)(5).
Test Lab Verification
  1. The tester verifies the Health IT Module sends the DrugAdministration transaction and completes all required test tool interaction steps and verifies the validation report is complete with the required elements.
System Under Test Test Lab Verification
  1. The health IT developer sends the transaction to communicate drug administration events (DrugAdministration) in accordance with (b)(3)(ii)(B)(5).
  1. The tester verifies the Health IT Module sends the DrugAdministration transaction and completes all required test tool interaction steps and verifies the validation report is complete with the required elements.

Paragraph (b)(3)(ii)(B)(6) Optional and for pharmacy only

System Under Test
  1. The health IT developer completes the request and response to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm) in accordance with (b)(3)(ii)(B)(6).
  2. The Health IT Module is able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following transactions:
    1. RxTransferRequest;
    2. RxTransferResponse; and
    3. RxTransferConfirm.
  2. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
System Under Test Test Lab Verification
  1. The health IT developer completes the request and response to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm) in accordance with (b)(3)(ii)(B)(6).
  2. The Health IT Module is able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following transactions:
    1. RxTransferRequest;
    2. RxTransferResponse; and
    3. RxTransferConfirm.
  2. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.

Paragraph (b)(3)(ii)(B)(7) Optional

System Under Test
  1. The health IT developer sends the transaction to recertify the continued administration of a medication order (Recertification) in accordance with (b)(3)(ii)(B)(7).
Test Lab Verification
  1. The tester verifies the Health IT Module sends the Recertification transaction and completes all required test tool interaction steps and verifies the validation report is complete with the required elements.
System Under Test Test Lab Verification
  1. The health IT developer sends the transaction to recertify the continued administration of a medication order (Recertification) in accordance with (b)(3)(ii)(B)(7).
  1. The tester verifies the Health IT Module sends the Recertification transaction and completes all required test tool interaction steps and verifies the validation report is complete with the required elements.

Paragraph (b)(3)(ii)(B)(8) Optional

System Under Test
  1. The health IT developer completes the Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse) in accordance with (b)(3)(ii)(B)(8).
  2. The Health IT Module is able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation reports for the following transactions:
    1. Create and send REMS Initiation Request (REMSInitiationRequest);
    2. Receive REMS Initiation Response (REMSInitiationResponse);
    3. Create and send REMS Request (REMSRequest); and
    4. Receive REMS Response (REMSResponse).
  2. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the diagnosis elements <Diagnosis><Primary> or <Secondary>.
System Under Test Test Lab Verification
  1. The health IT developer completes the Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse) in accordance with (b)(3)(ii)(B)(8).
  2. The Health IT Module is able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation reports for the following transactions:
    1. Create and send REMS Initiation Request (REMSInitiationRequest);
    2. Receive REMS Initiation Response (REMSInitiationResponse);
    3. Create and send REMS Request (REMSRequest); and
    4. Receive REMS Response (REMSResponse).
  2. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the diagnosis elements <Diagnosis><Primary> or <Secondary>.

Paragraph (b)(3)(ii)(B)(9) Optional

System Under Test
  1. The health IT developer completes the electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse) in accordance with (b)(3)(ii)(B)(9).
  2. The Health IT Module is able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
Test Lab Verification
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following transactions:
    1. Create and send PA Initiation Request (PAInitiationRequest);
    2. Receive PA Initiation Response (PAInitiationResponse);
    3. Create and send PA Request (PARequest);
    4. Receive PA Response (PAResponse);
    5. Create and send PA Appeal Request (PAAppealRequest);
    6. Receive PA Appeal Response (PAAppealResponse);
    7. Create and send PA Cancel Request (PACancelRequest); and
    8. Receive PA Cancel Response (PACancelResponse).
  2. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
System Under Test Test Lab Verification
  1. The health IT developer completes the electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse) in accordance with (b)(3)(ii)(B)(9).
  2. The Health IT Module is able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.
  1. The tester verifies the Health IT Module sends and receives the following transactions and completes all required test tool interaction steps and verifies the validation report for the following transactions:
    1. Create and send PA Initiation Request (PAInitiationRequest);
    2. Receive PA Initiation Response (PAInitiationResponse);
    3. Create and send PA Request (PARequest);
    4. Receive PA Response (PAResponse);
    5. Create and send PA Appeal Request (PAAppealRequest);
    6. Receive PA Appeal Response (PAAppealResponse);
    7. Create and send PA Cancel Request (PACancelRequest); and
    8. Receive PA Cancel Response (PACancelResponse).
  2. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>.

Paragraph (b)(3)(ii)(D) Optional

System Under Test
  1. The Health IT Module receives and transmits the reason for the prescription using the <IndicationForUse> element in the Sig segment. The reason for the prescription should be consistent with the International Statistical Classification of Diseases and Related Health Problems (ICDs) sent in the diagnosis element(s) for all optional transactions as listed in (b)(3)(ii)(C) in accordance with (b)(3)(ii)(D).
Test Lab Verification
  1. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the <IndicationForUse> element in the Sig segment. The reason for prescription should be consistent with the ICDs sent in the diagnosis element(s) for all applicable transactions and test data specified with the selected test case via the test tool.  Consistency may be evaluated by visual inspection if not systematically supported.
System Under Test Test Lab Verification
  1. The Health IT Module receives and transmits the reason for the prescription using the <IndicationForUse> element in the Sig segment. The reason for the prescription should be consistent with the International Statistical Classification of Diseases and Related Health Problems (ICDs) sent in the diagnosis element(s) for all optional transactions as listed in (b)(3)(ii)(C) in accordance with (b)(3)(ii)(D).
  1. The tester verifies the Health IT Module receives and transmits the reason for the prescription using the <IndicationForUse> element in the Sig segment. The reason for prescription should be consistent with the ICDs sent in the diagnosis element(s) for all applicable transactions and test data specified with the selected test case via the test tool.  Consistency may be evaluated by visual inspection if not systematically supported.
Updated on 07-08-2024
Regulation Text
Regulation Text

§ 170.315(b)(3) Electronic prescribing.

(ii) For technology certified subsequent to June 30, 2020:

  1. Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(1) as follows:
    1. Create new prescriptions (NewRx).
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
    3. Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
    5. Receive fill status notifications (RxFill).
    6. Request and receive medication history (RxHistoryRequest, RxHistoryResponse).
    7. Relay acceptance of a transaction back to the sender (Status).
    8. Respond that there was a problem with the transaction (Error).
    9. Respond that a transaction requesting a return receipt has been received (Verify).
  2. Optionally, enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:
    1. Create and respond to new prescriptions (NewRxRequest, NewRxResponseDenied).
    2. Send fill status notifications (RxFillIndicator).
    3. Ask the Mailbox if there are any transactions (GetMessage).
    4. Request to send an additional supply of medication (Resupply).
    5. Communicate drug administration events (DrugAdministration).
    6. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm).
    7. Recertify the continued administration of a medication order (Recertification).
    8. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
    9. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, and PACancelResponse).
  3. For the following prescription-related transactions, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>:
    1. Required transactions
      1. Create new prescriptions (NewRx).
      2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
      3. Request to cancel prescriptions (CancelRx).
      4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
      5. Receive fill status notifications (RxFill).
      6. Receive medication history (RxHistoryResponse).
    2. Optional transactions:
      1. Request to send an additional supply of medication (Resupply)
      2. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse)
      3. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
      4. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse).
  4. Optional. For each transaction listed in paragraph (b)(3)(ii)(C) of this section, the technology must be able to receive and transmit reason for prescription using the <IndicationforUse> element in the Sig segment.
  5. Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).
  6. Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.
Standard(s) Referenced

Paragraph (b)(3)(i)

§ 170.205(b)(1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

§ 170.207(d)(3) RxNorm, September 8, 2015 Full Release Update (Adoption of this standard expires on January 1, 2026.)

§ 170.207(d)(1): RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022 Full Monthly Release (This standard is required by December 31, 2025.)

 

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their version of RxNorm as outlined in paragraphs (b)(3)(i).

Certification Dependencies

Conditions and Maintenance of Certification Requirements

Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of
Certification.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(b)(3). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(b) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (b) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, an exception exists for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and § 170.315(e)(2) “Secure messaging,” which are explicitly stated.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
1.1

Updated testing tool from NCPDP to new Electronic Prescribing (eRx) tool.
07-08-2024
Regulation Text
Regulation Text

§ 170.315(b)(3) Electronic prescribing.

(ii) For technology certified subsequent to June 30, 2020:

  1. Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(1) as follows:
    1. Create new prescriptions (NewRx).
    2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
    3. Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
    4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
    5. Receive fill status notifications (RxFill).
    6. Request and receive medication history (RxHistoryRequest, RxHistoryResponse).
    7. Relay acceptance of a transaction back to the sender (Status).
    8. Respond that there was a problem with the transaction (Error).
    9. Respond that a transaction requesting a return receipt has been received (Verify).
  2. Optionally, enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:
    1. Create and respond to new prescriptions (NewRxRequest, NewRxResponseDenied).
    2. Send fill status notifications (RxFillIndicator).
    3. Ask the Mailbox if there are any transactions (GetMessage).
    4. Request to send an additional supply of medication (Resupply).
    5. Communicate drug administration events (DrugAdministration).
    6. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm).
    7. Recertify the continued administration of a medication order (Recertification).
    8. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
    9. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, and PACancelResponse).
  3. For the following prescription-related transactions, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>:
    1. Required transactions
      1. Create new prescriptions (NewRx).
      2. Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
      3. Request to cancel prescriptions (CancelRx).
      4. Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
      5. Receive fill status notifications (RxFill).
      6. Receive medication history (RxHistoryResponse).
    2. Optional transactions:
      1. Request to send an additional supply of medication (Resupply)
      2. Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse)
      3. Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
      4. Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse).
  4. Optional. For each transaction listed in paragraph (b)(3)(ii)(C) of this section, the technology must be able to receive and transmit reason for prescription using the <IndicationforUse> element in the Sig segment.
  5. Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).
  6. Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.
Standard(s) Referenced

Paragraph (b)(3)(i)

§ 170.205(b)(1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071

§ 170.207(d)(3) RxNorm, September 8, 2015 Full Release Update (Adoption of this standard expires on January 1, 2026.)

§ 170.207(d)(1): RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022 Full Monthly Release (This standard is required by December 31, 2025.)

 

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their version of RxNorm as outlined in paragraphs (b)(3)(i).

Certification Dependencies

Conditions and Maintenance of Certification Requirements

Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of
Certification.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(b)(3). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(b) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (b) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, an exception exists for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and § 170.315(e)(2) “Secure messaging,” which are explicitly stated.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Revision History
Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
1.1

Updated to reflect new Electronic Prescribing (eRx) tool.
07-08-2024
Testing
Testing Tool

Electronic Prescribing (eRx) Testing Tool

Criterion Subparagraph Test Data
(b)(3)

Refer to Electronic Prescribing (eRx) Testing Tool

Certification Companion Guide: Electronic prescribing

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Regulations page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.

The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.

 

Base EHR Definition Real World Testing Insights Condition SVAP Requires Updates
Not Included Yes No No Yes
Certification Requirements
Technical Explanations and Clarifications

Applies to entire criterion

Clarifications:

  • A transaction being “optional” for the purposes of certification does not mean and should not be interpreted as “optional” for Medicare Part D e-prescribing program compliance.
  • The intended scope of this certification criterion is the ability of health IT to electronically exchange information with external recipients. 
  • The criterion does not require prescriptions of controlled substances to be supported to demonstrate compliance with its requirements. Drugs and other substances that are considered controlled substances under the Controlled Substances Act (CSA) have been removed from the test data.
  • With the exception of which test data elements might be required, this certification criterion applies equally to both inpatient and ambulatory settings.
  • Errors received during testing related to the max field requirement can be treated as a warning. This does not remove the requirement from a surveillance perspective nor the general need for mandatory fields to be populated with data as required by the standard. Please consult with ONC regarding the Electronic Prescribing (eRx) tool's interpretive requirements.
  • It is beyond the scope of this certification criterion to require the capability to ensure that a provider is actively alerted when an electronic prescription fails. [see also 77 FR 54200] Health IT developers are advised, but not required, to include in its disclosures whether and how failed electronic prescriptions are presented to the end-user. Health IT developers are also advised to incorporate how failed electronic prescriptions are presented to the end-user in its end-user training materials.

Clarifications:

  • A transaction being “optional” for the purposes of certification does not mean and should not be interpreted as “optional” for Medicare Part D e-prescribing program compliance.
  • The intended scope of this certification criterion is the ability of health IT to electronically exchange information with external recipients. 
  • The criterion does not require prescriptions of controlled substances to be supported to demonstrate compliance with its requirements. Drugs and other substances that are considered controlled substances under the Controlled Substances Act (CSA) have been removed from the test data.
  • With the exception of which test data elements might be required, this certification criterion applies equally to both inpatient and ambulatory settings.
  • Errors received during testing related to the max field requirement can be treated as a warning. This does not remove the requirement from a surveillance perspective nor the general need for mandatory fields to be populated with data as required by the standard. Please consult with ONC regarding the Electronic Prescribing (eRx) tool's interpretive requirements.
  • It is beyond the scope of this certification criterion to require the capability to ensure that a provider is actively alerted when an electronic prescription fails. [see also 77 FR 54200] Health IT developers are advised, but not required, to include in its disclosures whether and how failed electronic prescriptions are presented to the end-user. Health IT developers are also advised to incorporate how failed electronic prescriptions are presented to the end-user in its end-user training materials.

Paragraph (b)(3)(ii)(A) Send and receive

Technical outcome – A user can send and receive the specified prescription transactions electronically per the SCRIPT Standard Implementation Guide Version 2017071 and using RxNorm vocabulary codes.

Clarifications:

  • RxNorm is considered a minimum standard code set under the Certification Program, and developers are permitted to upgrade their products to comply with a newer version of RxNorm without adversely affecting a product’s certification status pursuant to 45 CFR 170.555(b)(2) as long as no other law prohibits such action. [see 85 FR 25680]
  • ONC intends for the RxNorm concept unique identifiers (RXCUIs) to be used as drug qualifiers. [see also 77 FR 54199]
  • All medications may not yet have an equivalent RxNorm code. Where no RxNorm code exists, nothing prohibits another allowable code from being used. However, where corresponding RxNorm codes exist, health IT must be able to use those codes. [see also 77 FR 54199]
  • Health IT developers have flexibility in determining how message notifications are presented to users. ONC recommends health IT developers and providers work together to determine whether batch-notification is preferable to real-time messaging alerts. Note that the notifications will differ based on the message type. [see also 80 FR 62642]
  • Errors received during testing related to synonymous RxNorm term types can be treated as a warning. 
  • The scope of the medication history transaction requires sending a single request and receiving a single response to a request. Multiple medication history requests/responses are not required in the technical outcome.
  • Health IT modules certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the following medication renewal transactions (NewRx, RxRenewalRequest and RxRenewalResponse) and verify their validation reports. If the application meets these requirements, then a notable exception is granted to use a Replace instead of Approved response and the system should pass certification.

Technical outcome – A user can send and receive the specified prescription transactions electronically per the SCRIPT Standard Implementation Guide Version 2017071 and using RxNorm vocabulary codes.

Clarifications:

  • RxNorm is considered a minimum standard code set under the Certification Program, and developers are permitted to upgrade their products to comply with a newer version of RxNorm without adversely affecting a product’s certification status pursuant to 45 CFR 170.555(b)(2) as long as no other law prohibits such action. [see 85 FR 25680]
  • ONC intends for the RxNorm concept unique identifiers (RXCUIs) to be used as drug qualifiers. [see also 77 FR 54199]
  • All medications may not yet have an equivalent RxNorm code. Where no RxNorm code exists, nothing prohibits another allowable code from being used. However, where corresponding RxNorm codes exist, health IT must be able to use those codes. [see also 77 FR 54199]
  • Health IT developers have flexibility in determining how message notifications are presented to users. ONC recommends health IT developers and providers work together to determine whether batch-notification is preferable to real-time messaging alerts. Note that the notifications will differ based on the message type. [see also 80 FR 62642]
  • Errors received during testing related to synonymous RxNorm term types can be treated as a warning. 
  • The scope of the medication history transaction requires sending a single request and receiving a single response to a request. Multiple medication history requests/responses are not required in the technical outcome.
  • Health IT modules certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the following medication renewal transactions (NewRx, RxRenewalRequest and RxRenewalResponse) and verify their validation reports. If the application meets these requirements, then a notable exception is granted to use a Replace instead of Approved response and the system should pass certification.

Paragraphs (b)(3)(ii)(B) Send and receive - optional

Technical outcome –  A user can send and receive the specified prescription transactions electronically per the NCPDP SCRIPT Standard Implementation Guide Version 2017071 and using RxNorm vocabulary codes.

Clarifications:

  • The intent for the optional transaction (b)(3)(ii)(B)(2) Receive fill status notifications, specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3), is to be RxFillIndicatorChange and not RxFillIndicator. Health IT Modules should be able to send and receive RxFillIndicatorChange transactions.

Technical outcome –  A user can send and receive the specified prescription transactions electronically per the NCPDP SCRIPT Standard Implementation Guide Version 2017071 and using RxNorm vocabulary codes.

Clarifications:

  • The intent for the optional transaction (b)(3)(ii)(B)(2) Receive fill status notifications, specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3), is to be RxFillIndicatorChange and not RxFillIndicator. Health IT Modules should be able to send and receive RxFillIndicatorChange transactions.

Paragraph (b)(3)(ii)(C) Send and receive

Technical outcome – For all transactions in provision (b)(3)(ii)(C), health IT can send and receive the reason for the prescription using the Diagnosis elements in the Medication Segment.

Clarifications:

  • Health IT Modules certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the reason for the prescription using the Diagnosis elements in the <Diagnosis><Primary> or <Secondary> elements, or optionally, the technology must be able to receive and transmit the reason for the prescription using the <IndicationForUse> element, and be consistent with the International Statistical Classification of Diseases and Related Health Problems (ICDs) sent in the diagnosis element(s). The <IndicationforUse> element defines the indication for use of the medication as meant to be conveyed to the patient, and is included in the Sig. This requirement applies to the following transactions: NewRx, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, RxRenewalResponse, RxFill, RxHistoryResponse, Resupply, RxTransferRequest, RxTranferResponse, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.

 

Technical outcome – For all transactions in provision (b)(3)(ii)(C), health IT can send and receive the reason for the prescription using the Diagnosis elements in the Medication Segment.

Clarifications:

  • Health IT Modules certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the reason for the prescription using the Diagnosis elements in the <Diagnosis><Primary> or <Secondary> elements, or optionally, the technology must be able to receive and transmit the reason for the prescription using the <IndicationForUse> element, and be consistent with the International Statistical Classification of Diseases and Related Health Problems (ICDs) sent in the diagnosis element(s). The <IndicationforUse> element defines the indication for use of the medication as meant to be conveyed to the patient, and is included in the Sig. This requirement applies to the following transactions: NewRx, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, RxRenewalResponse, RxFill, RxHistoryResponse, Resupply, RxTransferRequest, RxTranferResponse, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.

 

Paragraph (b)(3)(ii)(D) Optional

Technical outcome – Optional – For all transactions in provision (b)(3)(ii)(C), health IT can send and receive the reason for the prescription using the Indication elements in the SIG segment.

Clarifications:

  • Health IT Modules certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the reason for the prescription using the Diagnosis elements in the <Diagnosis><Primary> or <Secondary> elements, or optionally, the technology must be able to receive and transmit the reason for the prescription using the <IndicationforUse> element, and be consistent with the International Statistical Classification of Diseases and Related Health Problems  (ICDs) sent in the Diagnosis element(s). The <IndicationforUse> element defines the indication for use of the medication as meant to be conveyed to the patient, and is included in the Sig. This requirement applies to the following transactions: NewRx, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, RxRenewalResponse, RxFill, RxHistoryResponse, Resupply, RxTransferRequest, RxTranferResponse, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.

Technical outcome – Optional – For all transactions in provision (b)(3)(ii)(C), health IT can send and receive the reason for the prescription using the Indication elements in the SIG segment.

Clarifications:

  • Health IT Modules certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the reason for the prescription using the Diagnosis elements in the <Diagnosis><Primary> or <Secondary> elements, or optionally, the technology must be able to receive and transmit the reason for the prescription using the <IndicationforUse> element, and be consistent with the International Statistical Classification of Diseases and Related Health Problems  (ICDs) sent in the Diagnosis element(s). The <IndicationforUse> element defines the indication for use of the medication as meant to be conveyed to the patient, and is included in the Sig. This requirement applies to the following transactions: NewRx, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, RxRenewalResponse, RxFill, RxHistoryResponse, Resupply, RxTransferRequest, RxTranferResponse, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.

Paragraph (b)(3)(ii)(E) Liquid medications

Technical outcome – Oral liquid medications can only be electronically prescribed using “mL” units.

Clarifications:

  • ONC clarifies that the volume for oral liquid medications must be prescribed using “mL” units. Testing and certification do not address the concentration of active ingredients, which is the amount of active ingredient per unit of volumetric measure (e.g., 5 mg per mL). When needed, health IT developers should represent concentrations of active ingredients using the appropriate units of measurement. E-prescribing of oral liquid medications using cc units will not be allowed for certification. [see also 80 FR 62643]

Technical outcome – Oral liquid medications can only be electronically prescribed using “mL” units.

Clarifications:

  • ONC clarifies that the volume for oral liquid medications must be prescribed using “mL” units. Testing and certification do not address the concentration of active ingredients, which is the amount of active ingredient per unit of volumetric measure (e.g., 5 mg per mL). When needed, health IT developers should represent concentrations of active ingredients using the appropriate units of measurement. E-prescribing of oral liquid medications using cc units will not be allowed for certification. [see also 80 FR 62643]

Paragraph (b)(3)(ii)(F) e-Prescriptions

Technical outcome – For all e-prescribed medications, the health IT always inserts leading zeroes before the decimal point for amounts less than one and never allows trailing zeroes after a decimal point.

Clarifications:

  • No additional clarifications.

Technical outcome – For all e-prescribed medications, the health IT always inserts leading zeroes before the decimal point for amounts less than one and never allows trailing zeroes after a decimal point.

Clarifications:

  • No additional clarifications.

Archived Version:

2015 Edition Archived CCG