ePrescribing_2_0_Software_Design_Document_v1_0_FINAL.pdf

IHS e-Prescribing 2.0 Local and Central Ensemble Productions

BEPR

Software Design Document (SDD)

July 30, 2012 Document Version 1.0

Office of Information Technology RPMS Program Management Office

Tucson, Arizona

IHS e-Prescribing 2.0 Software Design Document Page 2 Version 1.0

Change Control The following information is used to control and track modifications made to this document.

Date Revision Description Author of Change Section Page Number

7/30/2012 1.0 Initial Revision Stacy Henderson All All

Surescripts is a registered trademark of Surescripts, L.L.C.

Ensemble is a registered trademark of InterSystems Corporation

NCPDP is a registered trademark of the National Council for Prescription Drug Programs, Inc.

HL7 is a registered trademark of Health Level Seven (HL7), Inc.

IHS e-Prescribing 2.0 Software Design Document Page 3 Version 1.0

Table of Contents

1 Introduction

1.1 Organization Profile

1.2 Purpose

1.3 Scope

1.4 Use Cases

1.5 Constraints

1.6 References

2 Design

2.1 Local Ensemble Production Changes

2.1.1 Reporting

2.1.2 Message Management

2.1.3 Ensemble Version 2012.1

2.1.4 Role-Based Security

2.1.5 HL7 Message Changes

2.2 Central Ensemble Production Changes

2.2.1 Reporting

2.2.2 Message Management

2.2.3 Ensemble version 2012.1

2.2.4 Role-Based Security

2.2.5 Alerts

2.2.6 Performance Monitoring

2.2.7 Supervisor Field

2.2.8 Refill Request/Response workflow

2.2.8.1 Refill Request

2.2.8.2 Refill Response

2.2.9 HL7 Special Characters

2.2.10 Surescripts 10.6 Requirements

2.2.10.1 Prescription Routing General Requirements

2.2.10.2 Freestanding ERROR Messages

2.2.10.3 UTC Date/Time Format

2.2.10.4 Refill Response Message - Refill Quantity

2.2.10.5 Refill Response Message - Refill Qualifier

2.2.10.6 NewRx - Relates To Message ID

2.2.10.7 Refill Response – Relates To Message ID

2.2.10.8 Message Reference Number

2.2.10.9 Dialogue Reference

2.2.10.10 Prescriber Order Number

2.2.10.11 Refill Response message – Response Type

2.2.10.12 Refill Response Message – Return Data

2.2.10.13 Street and Number Box

2.2.10.14 Communication Number

2.2.10.15 Reference Qualifier

2.2.10.16 Drug Segment

2.2.10.17 Refill Response Message - Refill Qualifier

IHS e-Prescribing 2.0 Software Design Document Page 4 Version 1.0

2.2.10.18 Refill Response Message – Refill Quantity

2.2.10.19 Long Drug Names

2.2.10.20 Compound Drugs

2.2.10.21 XML Special Characters

IHS e-Prescribing 2.0 Software Design Document Page 5 Version 1.0

1 Introduction

1.1 Organization Profile

The Indian Health Service is dedicated to the service of American Indians and Alaska Natives as follows:

Mission: to raise the physical, mental, social, and spiritual health of American Indians and Alaska Natives to the highest level.

Goal: to assure that comprehensive, culturally acceptable personal and public health services are available and accessible to American Indian and Alaska Native people.

Foundation: to uphold the Federal Government's obligation to promote healthy American Indian and Alaska Native people, communities, and cultures and to honor and protect the inherent sovereign rights of Tribes.

1.2 Purpose

Indian Health Services (IHS) e-Prescribing software is a component of the IHS Resource and Patient Management System (RPMS) that provides facilities with a mechanism for transmitting prescriptions electronically to third parties via the IHS Central Ensemble production and Surescripts. Messages transmitted between the RPMS system and the Ensemble production will be in HL7 version 5.1 format.

Message transmitted between the Surescripts and Ensemble production will be in XML version 1.0 format.

The purpose of this Software Design Document is to describe the implementation of the e-Prescribing

2.0 functional specifications that are listed within the e-Prescribing 2.0 Software Requirements Specification (SRS) document.

1.3 Scope

Implementation of e-Prescribing 2.0 serves the following important business goals:

• Updates to meet the Surescripts 10.6 standard, which is based on the National Council of Prescription Drug Programs (NCPDP) Script version 10.6 standard

• Updates that will allow Surescripts certification

• Addition of Refill Request/Response transaction type

• Provide better reporting

• Provide more detailed information in alerts

• Upgrade the Central Ensemble production to Ensemble version 2012.1

• Ensure that the Local Ensemble production runs properly under Ensemble version 2012.1

IHS e-Prescribing 2.0 Software Design Document Page 6 Version 1.0

• Provide enhanced performance and security

• Support for the supervisor information between the RPMS and Surescripts systems

1.4 Use Cases

The e-Prescribing 2.0 application adds or modifies four different Surescripts transaction types: NewRx;

RefillRx; Directory Download; and Surescripts Provider ID (SPI). The workflows for RefillRx and Directory Download are documented in Figures 1 and 2, respectively.

Figure 1: RefillRx (Refill Request) workflow

IHS e-Prescribing 2.0 Software Design Document Page 7 Version 1.0

Figure 2: Directory Download workflow

1.5 Constraints

While this design document is considered complete, it may require additional modifications due to:

• ongoing conversations with Surescripts to clarify the Surescripts documentation

• the completion of the Electronic Health Record (EHR), IHS Pharmacy Medication Package (APSP), and BEHO analysis

IHS e-Prescribing 2.0 Software Design Document Page 8 Version 1.0

1.6 References

e-Prescribing 2.0 Software Requirements Specification v1.2 Published by GDIT July 20, 2012

Surescripts Prescription Routing Implementation Guide Published by Surescripts, L.L.C.

November 4, 2011

Surescripts Prescriber Directories v 4.4 Test Scenarios Published by Surescripts, L.L.C.

IHS e-Prescribing 2.0 Software Design Document Page 9 Version 1.0

2 Design

2.1 Local Ensemble Production Changes

2.1.1 Reporting

The e-Prescribing 2.0 application shall include reporting capabilities on the local Ensemble production.

The user will select a report from a drop down list of reports, the start date for the report from a drop down calendar and the end date for the report from a drop down calendar. The Prescriber selection and the Facility selection boxes will only be shown when the report selected is dependent on its entry. Once a report is run, the user will have the option to save the report as a comma-delimited file.

Report Selection process:

(screen shots to be added once developed)

The available reports shall be:

1. Order Request Messages Received by Prescriber o The user will select a single prescriber or choose to run the report against all prescribers o The report shall be sorted by the prescriber SPI, if the report is ran against all prescribers o The Report will look similar to the following design:

(a design diagram to be included once developed)

2. Order/Result Message Summary by Prescriber o The user will select a single prescriber or choose to run the report against all prescribers o The report shall be sorted by the prescriber SPI, if the report is ran against all prescribers o The report will look similar to the following design:

3. SPI Request Message Summary for all Prescribers o The report shall be sorted by the prescriber information

IHS e-Prescribing 2.0 Software Design Document Page 10 Version 1.0

2.1.2 Message Management

To prevent performance degradation and disk space issues, analysis will be done on the local Ensemble instance. The future disk space requirement will be based on the expected message volume and message size. Periodically the method chosen for the Message Management will need to be re-evaluated utilizing any new data available.

The initial options for message management include:

1. No change to the storage method

2. Message compression as messages are currently stored in the Ensemble database

3. The archiving of the messages into another database location

4. Long term storage of the messages into another location on the server hosting the Ensemble instance

5. Some other method of long term storage not yet identified

The choice of Message Management will allow for the capability of continuous message access for reporting and auditing needs.

2.1.3 Ensemble Version 2012.1

The local Ensemble production is currently running on an Ensemble 2010.2 instance. To ensure that the local production will properly operate within the Ensemble 2012.1 environment, the following steps will be done:

1. The current production classes and associated files will be imported into an Ensemble 2012.1 test instance.

2. Resolve any compilation errors

3. Testing:

o Messages will be sent to the Surescripts system through a central Ensemble 2010.2 production o Messages will be sent to the Surescripts system through a central Ensemble 2012.1 production

4. Export the local 2012.1 Ensemble production into a new XML file for use with sites running Ensemble 2012.1

2.1.4 Role-Based Security

A new security feature based on user roles will be added to the local Ensemble production when it is upgraded to run within the Ensemble 2012.1 environment. Users will be given access to message options based on their user credentials. As the local Ensemble security upgrade is further defined and implemented, this section of the document will be updated accordingly.

2.1.5 HL7 Message Changes

The Health Level Seven (HL7) message structures within the BEPR namespace will include definitions for messages generated by APSP P1016 and HER P12. The HL7 message definitions are stored within

IHS e-Prescribing 2.0 Software Design Document Page 11 Version 1.0 the IHS_Rx_2.5.HL7 file. There are no modifications needed for the local ensemble HL7 definition at this time.

2.2 Central Ensemble Production Changes

2.2.1 Reporting

The e-Prescribing 2.0 application shall include reporting capabilities on the central Ensemble production. Reports will be available through a URL for users with Ensemble access. The user will select a report from a drop down list of reports, the start date for the report from a drop down calendar and the end date for the report from a drop down calendar. The Prescriber selection and the Facility selection boxes will only be shown when the report selected is dependent on its entry. Once a report is run, the user will have the option to save the report as a comma-delimited file.

Figures 3 through 6 show the Report Selection criteria:

Figure 3: Report Selection - Select the Report from the drop-down list

IHS e-Prescribing 2.0 Software Design Document Page 12 Version 1.0

Figure 4: Report Selection - Select the Ending Date from the drop down calendar

IHS e-Prescribing 2.0 Software Design Document Page 13 Version 1.0

Figure 5: Report Selection - Select a Provider from the drop down list

IHS e-Prescribing 2.0 Software Design Document Page 14 Version 1.0

Figure 6: Report Selection - Select a Facility from the drop down list

IHS e-Prescribing 2.0 Software Design Document Page 15 Version 1.0

The available reports shall be:

1. Order/Result Message Summary by Site o The user will select a single site or choose to run the report against all sites o If a user selects a single site, a drop down list of sites will be displayed for selection o If the report is ran against all sites, the report shall be sorted by the site name or number o The report will look similar to the design shown in figure 7:

Figure 7: Order/Result Message Summary by Site

IHS e-Prescribing 2.0 Software Design Document Page 16 Version 1.0

2. Order/Result Message Summary by Prescriber o The user will select a single prescriber or choose to run the report against all prescribers o If the report is ran against all prescribers, the report shall be sorted by the prescriber SPI, if the report is ran against all prescribers o The report will look similar to the design shown in figure 8:

Figure 8: Order/Result Message Summary by Prescriber

3. Stored SPI Summary o The report shall be sorted by the prescriber SPI

4. Stored Facility Summary o The report shall be sorted by the site number

IHS e-Prescribing 2.0 Software Design Document Page 17 Version 1.0

5. Transmission Error Summary o The user will select a single site or choose to run the report against all sites o If the report is ran against all sites, the report shall be sorted by the site name or number

6. Script Errors by Medication o If the report is ran against all sites, the report shall be sorted by the site name or number

7. SPI Request Detail o If the report is ran against all sites, the report shall be sorted by the site name or number

8. Order/Result Detail by Pharmacy o The report will be sorted by the receiving pharmacy name

9. Error List Detail by Site o If the report is ran against all sites, the report shall be sorted by the site name or number

10. Drug List Detail o If the report is ran against all sites, the report shall be sorted by the site name or number

11. Error List Detail by Prescriber o The user will select a single prescriber or choose to run the report against all prescribers o If the report is ran against all prescribers, the report shall be sorted by the prescriber name or

SPI number

IHS e-Prescribing 2.0 Software Design Document Page 18 Version 1.0

2.2.2 Message Management

To prevent performance degradation and disk space issues, analysis will be done on the central Ensemble instance. The future disk space requirement will be based on the expected message volume, average message size, and the expected number of local Ensemble productions that will send messages to the central Ensemble production. As the number of local Ensemble productions increase, the method chosen for the Message Management will need to be re-evaluated utilizing the new data available.

The initial options for message management include:

1. No change to the storage method

2. The compression of messages as they are currently stored in the Ensemble database

3. The archiving of the messages into another database location

4. Long-term storage of the messages into another location on the server hosting the Ensemble instance

5. Some other method of long term storage not yet identified

The choice of Message Management will allow for the capability of continuous message access for reporting and auditing needs.

2.2.3 Ensemble version 2012.1

The central Ensemble production is currently running on Ensemble 2010.2 instance. To ensure that the central production will properly operate within the Ensemble 2012.1 environment, the following steps will be done:

1. The current production classes and associated files will be exported from the 2010.2 Ensemble environment

2. Import the central Ensemble production into an Ensemble 2012.1 test instance

3. Resolve any compilation errors

4. Testing:

o Messages will be sent from the RPMS system through the local Ensemble 2010.2 production o Messages will be sent from the RPMS system through the local Ensemble 2012.1 production

5. Export the central Ensemble production into a new XML file for use when the central Ensemble production is upgraded to the 2012.1 version

2.2.4 Role-Based Security

A new security feature based on user roles will be added to the central Ensemble production when it is upgraded to run within the Ensemble 2012.1 environment. Users will be given access to message options based on their user credentials. As the security upgrade is further defined and implemented, this section of the document will be updated accordingly.

IHS e-Prescribing 2.0 Software Design Document Page 19 Version 1.0

2.2.5 Alerts

Some of the current alerts being sent within the central Ensemble production of the e-Prescribing application will be enhanced to contain more specific information concerning the error or issue encountered. Currently the central Ensemble production does not generate an alert when a returned message from Surescript indicates there was an issue with message content. An alert enhancement to allow for specific returned values from Surescripts to produce an alert within the central Ensemble production, such values will include:

• Missing NCPDP code

• Rx request was for a controlled substance

The enhancement will also allow for an alert to be sent for the following reasons:

• A Facility is removed from the Facilities database

• A message sent to the production environment is for a demo patient

• Communication between the central Ensemble productions and the local Ensemble production is not available

• Communication between the central Ensemble production and the Surescripts system Is not available

2.2.6 Performance Monitoring

The e-Prescribing 2.0 application shall include performance monitoring in order to track system performance on a continuous basis. Output will be in a comma-delimited file, which will be analyzed in Excel® so that the performance can be benchmarked and tracked.

The mgstat task has been added to the task manager of the central Ensemble instance, gathering information on a continuous basis. Currently the information gathered from the mgstat tool indicates that there are no current issues with the central production environment. As message volume is increased and sites are added to the e-Prescribing network, the statistical information provided by the mgstat task will be used to identify issues.

Figures 9 and 10 show example output from the mgstat task

IHS e-Prescribing 2.0 Software Design Document Page 20 Version 1.0

Figure 9: RawData tab of the mgstat output file (global references)

IHS e-Prescribing 2.0 Software Design Document Page 21 Version 1.0

Figure 10: RawData tab of the mgstat output file (physical writes)

IHS e-Prescribing 2.0 Software Design Document Page 22 Version 1.0

2.2.7 Supervisor Field

The Supervisor tag within the NewRx XML message will be populated using the Rx.NewRx.RequestDTL.Data Transformation Language (DTL) class. If the incoming HL7 message has the VerifiedBy fields populated, the VerifiedBy field within the Common Order (ORC) segment of the OMP^O09 HL7 message will populate the Supervisor tag components.

Below is a code excerpt from the Rx.NewRx.RequestDTL that will be used to populate the Supervisor tag elements of the NewRxXML message:

<if condition='..Not(source.{ORCgrp(1).ORC:VerifiedBy(1).IDNumber}="")'> <true> <assign property='target.Body.RefillResponse.Supervisor.Identification.SPI' value='source.{ORCgrp(1).ORC:VerifiedBy(1).IDNumber}' action='set'/> </true> </if>

<if condition='..Not(source.{ORCgrp(1).ORC:VerifiedBy(1).FamilyName}="")'> <true> <assign property='target.Body.NewRx.Supervisor.Name.LastName' value='source.{ORCgrp(1).ORC:VerifiedBy(1).FamilyName}' action='set'/> <assign property='target.Body.NewRx.Supervisor.Name.FirstName' value='source.{ORCgrp(1).ORC:VerifiedBy(1).GivenName}' action='set'/> <assign property='target.Body.NewRx.Supervisor.Name.MiddleName' value='source.{ORCgrp(1).ORC:VerifiedBy(1).SecondandFurtherGivenNamesor}' action='set'/> <assign property='target.Body.NewRx.Supervisor.Name.Suffix' value='source.{ORCgrp(1).ORC:VerifiedBy(1).Suffix}' action='set'/> <assign property='target.Body.NewRx.Supervisor.Name.Prefix' value='source.{ORCgrp(1).ORC:VerifiedBy(1).Prefix}' action='set'/> </true> </if>

IHS e-Prescribing 2.0 Software Design Document Page 23 Version 1.0

2.2.8 Refill Request/Response workflow

The RefillRx workflow consists of four message structures - two XML and two HL7.

• XML message structures o RefillRequest o RefillResponse

• HL7 message structures o RDE^O25 o RRE^O26

2.2.8.1 Refill Request

• The request process is initiated when Surescripts sends a RefillRequest XML message using the secure HTTPS POST method to the staging.surescripts.ihs.gov URL. The server hosting the central Ensemble instance is running IIS 7.0 to facilitate the secure communication between the central Ensemble production and the Surescripts server. When IIS receives a request from Surescripts, IIS directs the request to the SureScriptsInbound.csp page. The csp page imports the requestcontent into the XML RefillRequest message. If the import fails, an error reply is sent to the Surescripts system. If the import is successful, the XML message is sent to the SureScripts Inbound Business Service to begin processing the message. After the central Ensemble production finishes processing the message, a reply is sent back to the Surescripts system via the CSP page indicating success or failure.

• The RefillRequest message received within the SureScripts Inbound Business Service is sent to the XML Business Process. The XML Business Process has a class definition of Rx.XML.Router and uses the RPMSRequestDTL.DTL class to transform the XML RefillRequest message into an HL7 RDE^O25 message. The providers’ SPI number within the XML message, is used to obtain the facility IP address and Port number that will be used to send the message. If HL7 message is not successfully created, then the reply message sent back to Surescripts indicates there was an error with the content of the XML message received. If the HL7 message creation is successful, the message is sent to the HL7 Outbound Business Operation.

• The HL7 RDE^O25 message is sent to the receiving local Ensemble production via the HL7 Outbound Business Operation. The HL7 Outbound Business Operation has a class definition of Rx.Operation.RPMS which has an adapter class of EnsLib.HL7.Adapter.TCPOutboundAdapter.

A TCP/IP connection is made with the local Ensemble production to facilitate the delivery of the HL7 message, if a failure occurs in delivering the HL7 message the reply message sent back to Surescripts indicates a communication error. Upon a successful delivery the reply message sent back to Surescripts indicates a successful transaction.

IHS e-Prescribing 2.0 Software Design Document Page 24 Version 1.0

2.2.8.2 Refill Response

• The response process is initiated when the local Ensemble production sends an HL7 RRE^O26 message to the central Ensemble production via TCP/IP to the HL7 Inbound Business Service.

The HL7 Inbound Business Service has a class definition of EnsLib.HL7.Service.TCPService which has utilizes the EnsLib.HL7.Adapter.TCPInboundAdapter to receive messages.

• The HL7 RRE^O26 message received by the HL7 Inbound Business Service is sent to the HL7 Message Router Business Process. The HL7 Message Router Business Process has a class definition of EnsLib.HL7.MsgRouter.RoutingEngine. The HL7 Message Router Business Process determines the message type received and sends the message to the appropriate Business Process for processing.

• The HL7 RRE^O26 message received by the HL7 Message Router Business Process is sent to the RefillRx Business Process. The RefillRx Business Process has a class definition of Rx.NewRx.BProcess and utilizes two DTL classes to build the XML RefillReponse message.

The first DTL, SSRequestDTL.DTL class, transforms the HL7 RRE^O26 message into the XML RefillResponse message while the second DTL, SSRequestDTL2.DTL class, adds information to the XML RefillResponse message from the associatedXML RefillRequest message received from Surescripts.

• The XML RefillResponse message is sent to the Surescripts system via the To SureScripts Business Operation. The To SureScripts Business Operation has a class definition of Rx.Operation.SureScripts which has an adapter class of EnsLib.HTTP.OutboundAdapter.

2.2.9 HL7 Special Characters

The SSRequestDTL class replaces separator characters with escape sequences for the data it places into the HL7 RDE^O25 message from the received XML Refill Request message. The function used to perform this operation is the Escape function that is available from the EnsLib.HL7.Segment class.

The RPMSRequestDTL class removes any escape sequences from the data it places into the XML Refill Response message it received from HL7 RRE^O26 message The function used to perform this operation is the Unescape function that is available from the EnsLib.HL7.Segment class.

2.2.10 Surescripts 10.6 Requirements

The e-Prescribing application shall be updated to ensure the Surescripts 10.6 requirements are met.

Subsections 2.2.10.1 through 2.2.10.21 describe in detail how each of the Surescripts 10.6 requirements will be met.

2.2.10.1 Prescription Routing General Requirements

Requirement: The e-Prescribing 2.0 application shall verify that syntactically valid maximum and minimum populated messages pass through the Ensemble production (as described in Section 2.2.1 of the Surescripts Prescription Routing Implementation Guide).

Design: XML messages populated with the maximum or minimum amount of valid data will be translated using the appropriate Data Transformation Language (DTL) translation. Each

IHS e-Prescribing 2.0 Software Design Document Page 25 Version 1.0

XML message structure consists of data tags (fields) that are required or optional and has an associated maximum size. The central Ensemble production will process a message if it is valid according to the XML message data structure. A valid message will contain only the tags defined within the message structure and the data within these tags meet the tag size limitation.

Maximum and Minimum Populated Message

A syntactically valid maximally populated message will be sent from the Surescripts system to verify that there are no limitations within the central Ensemble production for this type of message.

A syntactically valid minimally populated message will be sent from the Surescripts system to verify that there are no limitations within the central Ensemble production for this type of message.

Table 1: Maximum and Minimum Message description

2.2.10.2 Freestanding ERROR Messages

Requirement: The e-Prescribing 2.0 application shall accept freestanding ERROR messages from

Surescripts, deliver the message to RPMS, and respond to Surescripts with a VERIFY message (as described in Sections 2.4 and 5.9 of the Surescripts Prescription Routing Implementation Guide).

Design: The Surescripts freestanding ERROR message is sent using the secure HTTPS post method to the staging.surescripts.ihs.gov URL. IIS handles the delivery of messages between Surescripts and the CSP page. Code added to the CSP page delivers the freestanding ERROR message to the SureScripts Inbound Business Service., The current code sends the VERIFY message as a response to the HTTPS request. Within the XML Business Process, the ERROR message received will be used to identify the original XML message delivered to Surescripts. This original XML message is then used to identify the HL7 message associated with it. An HL7 reply message, either an ORP^O10 or a RRE^O26, is created with an indication than an error was sent from Surescripts and delivered to the appropriate RPMS system.

IHS e-Prescribing 2.0 Software Design Document Page 26 Version 1.0

2.2.10.3 UTC Date/Time Format

Requirement: The e-Prescribing 2.0 application shall send all date/time fields to Surescripts using the

Coordinated Universal Time (UTC) format (as described in Sections 3.6.1 and 6.4 of the Surescripts Prescription Routing Implementation Guide).

Design: The date/time fields within the HL7 message received from RPMS that are not in the UTC format, will be transformed using the HL7ToUTCTime method of the Rx.Prod.DTLFunctions class. The HL7 fields that will be transformed using this process will be added to Table 2 as they are identified.

Message Type Field to be transformed

Table 2: HL7 Transformed Fields

2.2.10.4 Refill Response Message - Refill Quantity

Requirement: The e-Prescribing 2.0 application shall send a non-zero value for the refill quantity in an

Approved and Approved with Changes Refill Response (as described in Section 5.2.6 of the Surescripts Prescription Routing Implementation Guide).

Design: The incoming HL7 RRE_O26 message is translated into an XML Refill Response using the Rx.RefillRx.RPMSRequestDTL. DTL class. The response type is determined by the value received in the OrderControl field of the ORC segment of the HL7 message. The refill quantity field is populated using the value received in the NumberOfRefills field of the RXO segment of the HL7 message. When the quantity element of the refill tag within a XML Refill Response message is zero and the response type is Approved or Approved with Changes, an error will be generated within the RefillRx workflow and sent to the RPMS system.

2.2.10.5 Refill Response Message - Refill Qualifier

Requirement: The e-Prescribing 2.0 application shall respond to RPMS with an error message if the refill qualifier field is not populated in the RPMS HL7 message when the message is a Refill Response message (as described in Section 5.2.6 of the Surescripts Prescription Routing Implementation Guide).

Design: The Rx.RefillRx.RPMSRequestDTL.DTL class extracts information from the RRE^O26 HL7 message and places it into a RefillResponse XML message. The Qualifier component of the Refills tag is currently being set to a temporary value of “R” until it is determined where the value will be placed in the incoming HL7.

IHS e-Prescribing 2.0 Software Design Document Page 27 Version 1.0

2.2.10.6 NewRx - Relates To Message ID

Requirement: The e-Prescribing 2.0 application shall respond to RPMS with an error message if the

Relates to Message ID field of the NewRx message is not populated when the message is in response to a Refill Response message that contained a denial response of Denied New to Follow (as described in Section 6.3 of the Surescripts Prescription Routing Implementation Guide).

Design: When the OMP^O09 HL7 message is in response to an RDE^O25 HL7 message that was denied with a DeniedNewToFollow response, an indicator (the refill request MessageID) needs to be included in the OMP^O09 HL7 message. This information is not currently provided within the OMP^O09 HL7 message sent by the RPMS system, without this information a determination of message error cannot be determined. Once a decision is made on where this information will be placed in the HL7 message structure, this section will be updated accordingly.

2.2.10.7 Refill Response – Relates To Message ID

Requirement: The e-Prescribing 2.0 application shall populate the Relates to Message ID field of the

Refill Response with the MessageID of the corresponding Refill Request (Section 6.3).

Design: The value received in the MessageControlID field of the MSA segment (MSA:1 ) of the RRE^O26 HL7 message will be used to populate the RelatesToMessageID tag within the Refill Response XML message. If the MessageControlID field is not populated, an error is returned to the RPMS system. The translation used to populate the RefillResponse XML message from the RRE^O26 HL7 message is done by the Rx.RefillRx.RPMSRequestDTL.DTL class.

2.2.10.8 Message Reference Number

Requirement: The e-Prescribing 2.0 application shall extract the RxReferenceNumber from the HL7 message sent by the Local Ensemble Production and place it in the XML message sent to Surescripts (Section 6.4).

Design: The RxReferenceNumber tag of the NewRx XML message sent to the Surescripts system is populated with the FillerOrderNumber field within the ORC segment of the OMP^O09 HL7 message. The Rx.NewRx.RequestDTL class will copy the HL7 field value, if it is populated, into the XML tag.

2.2.10.9 Dialogue Reference

Requirement: The e-Prescribing 2.0 application shall send the Dialogue Reference information to

Surescripts when the message being sent is in response to a request from Surescripts that contained the Dialogue Reference field (Section 6.4).

Design: If the incoming RefillRequest XML message includes the Dialogue Reference information, the RefillResponse XML reply message will include this information. As

IHS e-Prescribing 2.0 Software Design Document Page 28 Version 1.0 the RPMS system does not have the Dialog Reference information, the original RefillRequest message stored on the Central Ensemble Production will be used to retrieve and populate this information within the RefillResponse message.

2.2.10.10 Prescriber Order Number

Requirement: The e-Prescribing 2.0 application shall extract the Prescriber Order Number from the

HL7 message sent by the Local Ensemble Production and place it in the XML Refill Response message sent to Surescripts (Section 6.4).

Design: For the RefillResponse XML message the PrescriberOrderNumber tag will be populated using the value in the PlacerOrderNumber field of the ORC segment within the RRE^O26 HL7 message received. This is done within the Rx.RefillRx.RPMSRequestDTL.DTL class.

For the NewRx XML message, the PrescriberOrderNumber tag will be populated using the value in the PlacerOrderNumber field of the ORC segment within the HL7 OMP^O09 message received. This is done within the Rx.NewRx.RequestDTL.DTL class.

2.2.10.11 Refill Response message – Response Type

Requirement: The e-Prescribing 2.0 application shall extract the Order Control field of the HL7 message and convert it to a response type of Denied, DeniedNewPrescriptionToFollow, Approved or ApprovedWithChanges in the Refill Response message. If the Order Control field cannot be converted, an error response is returned to RPMS (Section 6.6).

Design: The translation is done through the Rx.RefillRx.RPMSRequestDTL.DTL class. The RefillResponse XML message will include one of the following Response tags:

Approved; Denied; DeniedNewPrescriptiontoFollow or ApprovedWithChanges. The OrderControl field of the ORC segment within the RRE^O26 HL7 message is used to determine which Response is included in the RefillResponse message.

The association is in Table 3:

Order Control Value within the HL7 message

Response tag within the XML message

AF Approved

DF Denied

RP DeniedNewPrescriptionToFollow

CF ApprovedWithChanges Table 3: Order Control / Response Tag Association

IHS e-Prescribing 2.0 Software Design Document Page 29 Version 1.0

2.2.10.12 Refill Response Message – Return Data

Requirement: In a Refill Response message with a response type of Approved, Denied, DeniedNewPresciptionToFollow, or ApprovedWithChanges, the e-Prescribing 2.0 application shall return the Patient, Drug, Prescriber and Pharmacy segment information that was received in the original Refill Request message from Surescripts (Section: 6.6).

See section 2.2.8 above for additional information.

Design: The RefillRequest XML message received from the Surescripts system contains information that is not included in the RDE^O25 HL7 message and thus the RRE^O26 HL7 message received from RPMS in response to the RefillRequest may not contain information that is needed to create a fully populated RefillResponse message. To include all the information from the original RefillRequest message in the RefillResponse message, the original RefillRequest XML message is retrieved and used by the Rx.RefillRx.RequestDTL2.DTL class to pull information not contained in the RRE^O26 message..

2.2.10.13 Street and Number Box

Requirement: The e-Prescribing 2.0 application shall reject a message sent by the Local Ensemble

Production that has Post Office (PO) Box information in the AddressLine1 field of the Prescriber, Site or Pharmacy segment and return an error message to RPMS (Sections 6.8, 6.11, 6.12).

Design: If a Prescriber or Pharmacy address contains a PO box then an error will be created and sent to the RPMS system. Note that since the RPMS system does not provide information within the OMP^O09 HL7 message or the RRE^O26 HL7 message to populate the Facility tag (called Site in the requirements) within the NewRx XML message or the RefillResponse XML message, the Facility/Site tag does not need to be verified.

Table 4 and 5 show the fields that will be checked:

OMP^O09 HL7 Segment:field

Prescriber ORC:OrderingProviderAddress(1).StreetAddress.StreetorMailingAddress

(ORC:24.1.1)

Pharmacy RXO:ITEM01682.StreetAddress

(RXO:33.1)

Table 4: OMP^O09 Message Fields

RRE^O26 HL7 Segment:field

Prescriber ORC:OrderingProviderAddress(1).StreetAddress

(ORC:24:1)

Pharmacy RXE:DispensingPharmacyAddress.StreetAddress

(RXE:41.1)

IHS e-Prescribing 2.0 Software Design Document Page 30 Version 1.0

Table 5: RRE^O26 Message Fields

2.2.10.14 Communication Number

Requirement: The e-Prescribing 2.0 application shall send Communication Number fields in the proper format in the Prescriber, Facility, Pharmacy and Patient tags. The proper format of the phone number is 5552223333X4444, where 555 is the area code, 2223333 is the main number and X4444 is the extension (Sections 6.8, 6.11, 6.12, 6.13).

Design: When the Rx.NewRx.RequestDTL.DTL class creates the NewRx XML message from the OMP^O09 HL7 message, it utilizes the StripPhone method defined within the Rx.Prod.DTLFunctions class to format the phone numbers correctly. For the RRE^O26 HL7 message received from the RPMS system, the phone number fields are already in the Surescripts format and do not need to be formatted by the StripPhone method.

Table 6 shows the fields that will be formatted:

XML

Number Tag

HL7 Segment:field

Prescriber ORC:OrderingFacilityPhoneNumber(1).TelephoneNumber

(ORC:23.1)

Pharmacy RXO:PharmacyPhoneNumber.TelephoneNumber

(RXO:36.1)

Patient PID:PhoneNumberHome(1).TelephoneNumber

(PID:13.1)

Table 6: Phone Number Fields that are Formatted

2.2.10.15 Reference Qualifier

Requirement: The e-Prescribing 2.0 application shall translate the National Provider ID (NPI), if it is populated, between the HL7 message from RPMS and the Reference Qualifier element of the Pharmacy tag in the XML message in Surescripts (Section 6.12).

Design: The NewRx XML message is created from the OMP^O09 HL7 message received from RPMS system using the Rx.NewRx.RequestDTL.DTL class. The translation uses the DispensingPharmacy.Identifier field of the RXO segment to populate the Pharmacy.Identification.NCPDPID tag.

If the RefillRequest XML message received from Surescripts system contains the Pharmacy.Identification.NCPDPID tag, this value is placed into the ITEM1681.NCPDPID sub-field of the RXE segment within the RDE^O25 HL7 message delivered to the RPMS system using the SSRequestDTL.DTL class.

The RefillResponse XML message is created from the RRE^O26 HL7 message received from RPMS using the Rx.RefillRx.RPMSRequestDTL.DTL class. The translation uses

IHS e-Prescribing 2.0 Software Design Document Page 31 Version 1.0 the DispensingPharmacy.Identifier field of the RRE segment to populate the Pharmacy.Identification.NCPDPID.

2.2.10.16 Drug Segment

Requirement: The e-Prescribing 2.0 application shall translate and validate the MedicationPrescribed elements and fields between the RPMS HL7 message and the Surescripts XML message.

If a field is invalid, an error shall be returned to the sending application. The MedicationPrescribed elements are: Drug Description; DrugCoded.ProductCode;

DrugCoded.Strength; FormCode; Strength; Quantity.Value; Potency Unit Code;

Directions; Dosage.Directions; Date or Quantity; Product/Service Substitution Coded;

and Note (Section 6.14).

Design: The components of the MedicationPrescribed tag within the NewRx XML message is populated using the Rx.NewRx.RequestDTL.DTL class. Table 7 shows how the HL7 fields sent by RPMS are mapped to the Medication Prescribed tag. Note that the DrugCoded.Strength, DosageForm, Strength, PotencyUnitCode, DosageDirections, DaysSupply, components are not being used within our configuration of the MedicationPrescribed tag at this time, so there is no mapping of these fields.

HL7 Segment:field MedicationPrescibed Tag

RXO:RequestedGiveCode.Text (RXO:1.2) Drug Description RXO:RequestedGiveCode.Identifier

(RXO:1.1)

DrugCoded.ProducCode

RXO:RequestedDispenseAmount (RXO:11) Quantity.Value RXO:ProvidersAdministrationInstr(1).Text

(RXO:7.2)

Directions

RXO:AllowSubstitutions

(RXO:9)

Substitutions

RXO:ProvidersPharmacyTreatmentIn(1).Text

(RXO:6:2)

Note

Table 7: Drug Segment mapping

2.2.10.17 Refill Response Message - Refill Qualifier

Requirement: The e-Prescribing 2.0 application shall extract Qualifier and Quantity fields from the incoming HL7 message and populate the appropriate elements of the XML message in the Refill Response (Section 6.14.2).

Design: The Rx.RefillRx.RPMSRequestDTL.DTL class extracts information from the RRE^O26 HL7 message and places it into a RefillResponse XML message. The Qualifier component of the Refills tag is currently being set to a temporary value of “R” until it is determined where on the incoming HL7 message the value will reside. The Quantity component of the Refills tag is being set to the value sent in the NumberOfRefills field of the RXO segment of the HL7 message.

IHS e-Prescribing 2.0 Software Design Document Page 32 Version 1.0

2.2.10.18 Refill Response Message – Refill Quantity

Requirement: The e-Prescribing 2.0 application shall set the number of refills in the XML message to zero when the Refill Response response type is ‘Denied’ or ‘Denied New to Follow’ (Section 6.14.2)

Design: When the Refills.Quantity elements is not zero and the Response tag has a component of Denied or DeniedNewToFollow, either an error will be generated within the RefillRx workflow and sent to the RPMS system or the Refills.Quantity element will be set to zero and sent to the Surescripts system. Once a decision is made on how the message should act, this section will be updated accordingly.

2.2.10.19 Long Drug Names

Requirement: The e-Prescribing 2.0 application shall translate long drug names sent by HL7 into the appropriate XML element(s). If the drug name exceeds 105 characters, an error will be returned to RPMS (Section 6.14.5).

Design: The current DrugDescription tag within the NewRx SML message and the RefillResponse XML message has a length of 105 characters. If the value of the RXO:RequestedGiveCode.Text field within the OMP^O09 or the RRE^O26 message exceeds the 105 character limit then an error is returned to the RPMS system indicating that there was an issue with the length of the RequestGiveCode field value and that the message was not delivered to the Surescripts system.

2.2.10.20 Compound Drugs

Requirement: The e-Prescribing 2.0 application shall enhance the NewRx and RefillRx workflows to handle compound drugs (Section 6.14).

Design: Currently, the RPMS system is undergoing a modification to enable the sending of compound drugs within the OMP^O09 and RRE^O26 HL7 message structures. It has been suggested that the CompoundDrug component information be sent using the RXC segment within the HL7 message structure, but a final determination has not been made.

Once the HL7 design is complete, this section will be updated with the translation information for the CompoundDrug components.

IHS e-Prescribing 2.0 Software Design Document Page 33 Version 1.0

2.2.10.21 XML Special Characters

Requirement: The e-Prescribing 2.0 application shall encode and decode the XML special characters in the incoming and outgoing XML messages (Appendix A).

Design: In creating the XML message, the Rx.NewRx.RequestDTL and the Rx.RefillRx.RPMSRequestDTL classes will encode the XML special characters for the message going to Surescripts

In creating the HL7 message, the Rx.RefillRx.SSRequestDTL class will decode the XML special characters for the message going to RPMS.

Table 8 shows the ASCII character and the associated XML Escape Sequence to be used

ASCII Character XML Escape Sequence quote (“”) &quot;

apostrophe (‘) &apos;

ampersand (&) &amp;

less than (<) &lt;

greater than (>) &gt;

Table 8: XML Special Characters