Messages Overview

message descriptions rxhistoryrequest the provider sends patient demographic information in the rxhistoryrequest message providers can request for up to 12 months of history from the date of the request note in an acute setting, if the patient encounter spans multiple days, medication history requests should be sent no more than twice during the patient’s stay rxhistoryresponse the rxhistoryresponse message returns information about outpatient prescriptions that the patient’s pbm/payer has paid for over a selected period of time and contains retail fill data from pharmacies connected to surescripts for medication history up to 300 medications are returned within the dates requested within the last 12 months, starting with the most recent see requesteddates in the rxhistoryrequest xml requirements docid 7d 9qydsyyeljjcchfhw section for more information note when more medications are available to be returned to the provider vendor within the timeframe requested, the rxhistoryresponse will include a more medications available indicator in the response/approved/reasoncode (aq more medication history available) and then another rxhistoryrequest can be sent by the provider vendor to obtain additional medication history iin (issuer identification number) truncation per ncpdp, since 8 digit iins are now being assigned, use the first 6 digits of the iin as the bin even if the first digit(s) is a zero once new version of the ncpdp telecommunication standard is adopted, truncation will no longer be necessary refer to ncpdp processor id (bin) https //www ncpdp org/ncpdp/media/pdf/resources/ncpdp processor id (bin) pdf?ext= pdf for more information for example, an iin that is 8 digits (e g , 12345600) will be truncated to include the first 6 digits (e g , 123456) medication history request/response message flow the graphic below depicts the optimal message flow between customers the following steps depict the basic workflow of a medication history message 1 medication history for ambulatory the eligibility request (270) is sent by the provider vendor system to surescripts to obtain eligibility information the interchange control number (isa13) from the eligibility response (271) is sent in the rxhistoryrequest note this also applies to medication history for reconciliation customers who perform an eligibility request (270) 2\ provider vendor system sends an rxhistoryrequest message to surescripts 3\ provider vendor system receives a status 010 response from surescripts acknowledging receipt 4\ pbm/payer system receives an rxhistoryrequest message from surescripts 5\ pbm/payer system sends a synchronous rxhistoryresponse message to surescripts 6\ surescripts fill database receives an rxhistoryrequest message from surescripts 7\ surescripts fill database sends a synchronous rxhistoryresponse message to surescripts 8\ provider vendor system receives an asynchronous aggregated rxhistoryresponse message (including both fill and claim records) from surescripts note in cases where the patient was found and no medications were available, the provider vendor system will receive an asynchronous rxhistoryresponse message from surescripts with response/approved/reasoncode = ‘dj’ and note = "although a patient record was found, no medications were available ” 9\ provider vendor system sends a synchronous status 010 response to surescripts acknowledging receipt example response scenarios for multiple sources of data example 1 valid rxhistoryrequest example mpi (master patient index) returns pbm/payers and/or prescription fill patient records rxhistoryrequest data sources rxhistoryresponse (aggregated response) surescripts data source 1 data source 2 description response segment additional messaging elements successful processing medications no medications rxhistoryresponse all medications found approved successful processing medications error encountered potentially causing some medication records to have been unavailable rxhistoryresponse all medications found approved rxhistoryresponse/response/ approved/reasoncode = "dm" and note = "not all medication history sources were accessible at this time successful processing medications error encountered additional requests will continue to error, with no likelihood of medications being returned rxhistoryresponse all medications found approved successful processing no medications error encountered additional requests will continue to error with no likelihood of medications being returned rxhistoryresponse no medications approved rxhistoryresponse/response/ approved/reasoncode = "dj" and note = "although a patient record was found, no medications were available ” successful processing no medications error encountered potentially causing some medication records to have been unavailable rxhistoryresponse no medications approved rxhistoryresponse/response/ approved/reasoncode = "dm" and note = "a processing error occurred no medication history was returned " successful processing no medications no medications rxhistoryresponse no medications approved rxhistoryresponse/response/ approved/reasoncode = "dj" and note = "although a patient record was found, no medications were available ” error encountered potentially causing some medication records to have been unavailable no medications no medications rxhistoryresponse no medications approved rxhistoryresponse/response/ approved/reasoncode = "dm" and note = "a processing error occurred no medication history was returned " successful processing error encountered potentially causing some medication records to have been unavailable error encountered additional requests will continue to error with no likelihood of medications being returned rxhistoryresponse no medications approved rxhistoryresponse/response/ approved/reasoncode = "dm" and note = "a processing error occurred no medication history was returned " example 2 valid rxhistoryrequest no mpi records returned rxhistoryrequest data sources rxhistoryresponse (aggregated response) surescripts data source 1 data source 2 description response segment additional messaging elements successful processing n/a n/a rxhistoryresponse no medications approved rxhistoryresponse/response/ approved/reasoncode = "dj" and note = "patient not found " medication history features surescripts has created a number of optional features for partners to configure to enhance their medication history experience to enable, please contact your account manager with interest and any questions below provides an overview of our optional offerings data deduplication and augmentation information data deduplication and augmentation are optional features and require no additional configurations or certification by the provider vendor in certain use cases, the customer may opt in to one or both features information provided through the medication history response may have been enhanced (cleansed, translated, augmented, and remediated) using an algorithm designed and executed by a third party or surescripts, with the goal of improving data quality it is possible, however, for mistakes to occur it is the responsibility of the treating health care provider (not the responsibility of surescripts) to verify this information through other means, for all patients, before relying on the information to diagnose or treat the patient or to bill for goods or services notes surescripts will never over write or replace existing data from data suppliers the complete set of medication dispense records, prior to data deduplication, will be available for review within the customer’s surescripts workbench message search account logic used to identify duplicates and data fields augmented is subject to change please work with a surescripts account manager or surescripts resource for more information sig iq surescripts translates free text sigs into structured and codified (s\&c) formats using the ncpdp standard, prescription data, and pharmacist review this helps standardize dosing instructions and improves clinical clarity a partner must first create a mapping table of snomed codes based off the ncpdp script structured and codified sig format implementation guide for the outgoing newrx and then ourthe surescripts sig iq database can be applied extensibility extensibility was added to allow trading partners a consistent way to include additional information in the messages it was created to enable the integration of extra information in messages in a safe and meaningful way, it can help streamline testing of new data elements, maintain the standard's simplicity while accommodating uncommon use cases, and most importantly, paves a quicker path to introducing new features that benefit patients, providers, pharmacies, and payers surescripts will not validate data in extensions beyond the schema requirements it is recommended that partners do not reject transactions that include an extension that is not expected and instead ignore the information when using extensions, the following rules must be observed the core schema must be followed extensions must not contradict the base standard extensions must not alter content from the base standard extensions must not be used when standard fields are available external code list values cannot be modified by extensions surescripts has created two extensions with the roll out e out of the script standard 2023011 therapeutic class acute vs maintenance medication note please work with your surescripts account manager or surescripts resource for more information acknowledgement messages this section contains acknowledgment details, workflows, and scenarios status status is used to indicate to the sender that the message was accepted for processing a status is always a synchronous response notes surescripts returns a status 010 to the provider vender upon receipt of the rxhistoryrequest indicating that the request was accepted for message processing provider vendors are required to send a status 010 in response to an rxhistoryresponse indicating that the message processing is complete and was successful data suppliers do not send status messages status best practice descriptioncode is an optional element that contains codes suitable for use on error messages only descriptioncode element should not be used on a status message error indicates that an error has occurred an error can be generated when there is a communication problem or when an error occurs during the processing of the message surescripts only sends errors synchronously to provider vendors note surescripts does not support an asynchronous error message sent from the data supplier when surescripts receives a synchronous error message from the provider vendor upon receipt of the asynchronous rxhistoryresponse, surescripts adds a log code on the audit of the message indicating an error was returned acknowledgment message table message type code meaning(s) as sender as receiver status 010 confirms successful delivery and acceptance of a message to its final destination the final acknowledgement message to close the transaction workflow no further acknowledgement message should follow synchronous response indicates the process is complete subsequent acknowledgement message should not be expected error 600, 601, 602, 700, 900 can be generated when there is a communication problem or when an error occurs during the processing of the message closes the transaction workflow subsequent acknowledgement messages should not be expected send to communicate that the transaction failed do not send if a transaction workflow has already been closed (status 010) after receiving an error, do not expect subsequent acknowledgement messages do not respond to an error message with an error message error codes for a full list of ncpdp error codes (e g transactionerrorcode) and their descriptions, see the online ncpdp external code list or ncpdp xml schema error text table (immediately returned to requester from surescripts) the error codes below are tied to codes from the ncpdp external code list when applicable, surescripts will send the code along with an error message the table below details example error messages note the table below does not capture every error situation error descriptions are subject to change code error description 900 found {#} ncpdp 2023011 schema validation error {{s}} {description of the schema errors} 900 sender id not in directory 900 sender portal is inactive 900 sender portal not authorized to send rxhistoryrequest messages 900 sender organization is inactive 900 sender not authorized to send this type of message 900 portal config not found for sender 900 no active medhistory portal config found for sender specified version 900 portal configuration error, please contact support 900 the received message type is an invalid message type for this service 900 the message format is not recognized as valid for this service 900 rxhistoryrequest requires an eligibility interchange control number (isa 13) in the benefitscoordination/payeridentification/mutuallydefined field 900 invalid recipient identifier used in the rxhistoryrequest 900 date of birth is required 900 full patient lastname is required 900 full patient middlename is required if initial is sent in the firstname field 900 consent not given 900 requested startdate cannot be in the future or more than one year in the past 900 requested startdate cannot be after enddate 900 facility npi is required 900 npi in facility is not a valid npi 900 npi in prescriber is not a valid npi 900 either prescriber or facility must be included in the request 900 prescriber must be included in medication history for ambulatory rxhistoryrequest 900 authorization failed sender account not authorized to send with this certificate 900 authentication failed no valid account matches sender certificate 900 {#} url format error{{s}} {description of the errors} 900 url id parameter value of {id from url} does not match message id value of {id from message header} from message header 900 surescripts messaging version specified in the url {version from url} does not match version of the message {version from message} 900 medication history requests sent directly to pbms are not supported at surescripts 900 sender portal not authorized to send medication history for ambulatory rxhistoryrequest messages 900 sender portal not authorized to send medication history for reconciliation rxhistoryrequest messages 900 sender portal not authorized to send medication history for ltpac messages 602 surescripts system error message workflow scenarios the following workflows depict various scenarios in response to an rxhistoryrequest message scenario 1 – message errors at surescripts 1a) provider vendor system sends an rxhistoryrequest message to surescripts 1b) provider vendor system receives an error response from surescripts scenario 2 – surescripts has no patient record 2a) provider vendor system sends an rxhistoryrequest message to surescripts 2b) provider vendor system receives a status 010 response from surescripts acknowledging receipt 2c) provider vendor system receives an asynchronous rxhistoryresponse message from surescripts with response/approved/reasoncode = ‘dj’ and note = “patient not found” 2d) provider vendor system sends a status 010 response to surescripts acknowledging receipt scenario 3 – surescripts unable to connect to pbm/payer 3a) provider vendor system sends an rxhistoryrequest message to surescripts 3b) provider vendor system receives a status 010 response from surescripts acknowledging receipt 3c) pbm/payer system receives an rxhistoryrequest message from surescripts 3d) surescripts is unable to connect to the pbm/payer system 3e) provider vendor system receives an asynchronous rxhistoryresponse message from surescripts with response/approved/reasoncode = 'dm' and note = "a processing error occurred no medication history was returned " note if some medications are returned but not all sources were accessible, provider vendor system will receive an asynchronous aggregated rxhistoryresponse message from surescripts with response/approved/note = "not all medication history sources were accessible at this time " 3f) provider vendor system sends a status 010 response to surescripts acknowledging receipt message validation surescripts will ensure that customers are in compliance with the message specifications outlined in this guide during testing and will continue to enforce once in production at a minimum, surescripts validations include xml schema validation syntax of the message, including field lengths, data types, and code values the sender identification and authentication surescripts business rules note surescripts acrs are not enforced as part of validations, but instead through the certification process