Process Overview

process flow the graphic below depicts the process flow between customers in this process the following steps depict the process flow the customer generates and posts the patient file load (onto the sftp site) that identifies which patients they want to enroll for medication history for populations patients enrolled for medication history for populations panel management are enrolled for a one time medication history response note if a patient does not grant access to their data, then the customer is responsible for excluding the patient from the patient file load surescripts validates the submitted file and generates and posts a validation response file in the sftp folder for retrieval this response notifies the customer that the patient file was received the response file also provides details into any errors that were encountered during the input panel validation the panel user should plan to resubmit the records with errors after correcting the error for example, a record rejected due to invalid zip code format note to avoid a duplicative response charge, please ensure you are only resubmitting those records with errors do not correct the errors and resubmit the full file (i e if you submit a request with 100 patients and 25 errors were returned, the correction file should only contain 25 revised records) surescripts locates patients using the master patient index (mpi) for patients found the medication history request is routed to the appropriate pbm/payer for processing this data will contain any claim on file for medications where the pharmacy benefit may be used and may be reversed if the medication is returned to stock the medication history request also calls on our dispensed medication fill database, which is updated regularly by pharmacies connected to surescripts this data will contain records for dispensed medications and includes both cash and coupon pay surescripts retrieves and aggregates available dispensed fill data and claims medication history data for all successfully loaded patients listed on the patient file surescripts generates and posts the panel history file for the customer to access in the sftp folder the customer retrieves flat format panel history file from the sftp folder patient file load the medication history for populations patient file load process via the sftp folder is used by customers to enroll patients note please make sure to contact your surescripts resource to assure you have met the requirements described in this section name description timing panel user will determine the timing of sending the file to surescripts sftp folder file locations incoming files location – /to surescripts (permission upload) outgoing files location – /from surescripts (permission download, delete) sftp tips clients will post files to the ‘to surescripts’ folder clients have download, delete rights on the ‘from surescripts’ folder this folder contains the surescripts response files clients could remove files permanently; else, the surescripts system will automatically purge files that are older than 14 days file validation surescripts will ensure that customers are in compliance with the file specifications outlined in this guide during integration testing and will continue to enforce once in production at a minimum, surescripts validations include the sender identification and authentication the recipient identification syntax of the message, including field lengths, data types, and code values surescripts business rules patient file load details patient file naming the following topics describe the required naming convention patient file load naming the file load naming convention is \<customername> pma \<yyyymmdd xx> \<compressionformat> surescripts recommends compressing the file prior to transmitting it to surescripts the current zip protocols that are supported are gzip, bzip2 and zip example acocompany pma 20201204 01 gz patient response file naming the naming convention is < inputfilename sans extension > < sstimestamp > < sstimestamp > rsp example acocompany pma 20201204 01 20201204012025 20201204012025 rsp patient file load format the patient file load format will be pipe delimited (hex7c) each field is delimited by the pipe character (|) if a pipe character (hex7c) is used in field data, it must be escaped with \f\\ for example, main | street would be listed as main \f\ street each line is to be separated by a new line (hex0a) character for detailed field information, refer to the request file elements docid\ h431pesmxpnbwxc4iiohm and patient file load examples docid\ ea2xedqydefaqsxut 419 sections you may also refer to file load validation and error code details docid\ il6t4h86hp1ossln smsg for more information note if mandatory fields are not included, the patient file load and/or patient record will not pass validation, and the patient will not be loaded or monitored all conditional fields must be accounted for, either with data, or a placeholder delimiter patient response file format each patient response file will contain an overall file load status code, including description, within the header record this code indicates if the file loaded with either partial or full success (i e , patients were loaded from the file), and/or if errors were encountered in addition, there will be a record containing an error code and description for every error found in the file these records will include the line number of the incoming file that had the related error line number starts with 1 for the header record and is incremented by 1 for every record in the incoming file line number 1 will indicate an error on the incoming file header line numbers 2 n will indicate errors on subsequent records in the incoming file there may be multiple records listing an error code and description for the same line number from the incoming file the patient response file format is pipe delimited (hex7c) each field is delimited by the pipe character (|) if a pipe character (hex7c) is used in field data, it will be escaped with \f\\ for example, main | street will be listed as main \f\ street each line will be separated by a new line (hex 0a) character for detailed field information, refer to the response file elements docid\ h431pesmxpnbwxc4iiohm and patient file load examples docid\ ea2xedqydefaqsxut 419 sections you may also refer to file load validation and error code details docid\ il6t4h86hp1ossln smsg for more information patient file load maintenance enrolled patients across panel management and prescription notifications are designated through the use of patienthashid, which is generated from the following fields submitted in the enrollment request patient first name patient last name date of birth patient id npi (for treatment based use case only) a patient is counted once as an enrolled for each unique combination of these fields a change to any of these fields in a subsequent file, without prior unenrollment, will result in a new unique record being counted for more information on unenrollment, see deleting a previously enrolled patient below prescription notifications recipient and patient identity prescription notifications uses the following to identify a notification recipient and each patient that recipient has enrolled intended recipient of a notification sender id npi patient the recipient is monitoring assigning authority patient id note sender id is from the file header (hdr) record the rest of the fields are from the patient detail record updating a previously enrolled patient to change data for a patient, submit the patient in a patient file using the updated information for the patient updates can be made to any data in the patient details other than patient name, patient date of birth, npi, assigning authority, and patient id updates can include change of patient demographics (address fields and gender) adding / removing notifications requested for this patient changes to the end monitoring date deleting a previously enrolled patient it is not possible to delete an enrolled patient; however, customers can stop receiving notifications for a patient this is accomplished by updating the end monitoring date docid\ efi3elhry4hsppgfbu as of the patient to a desired future date once the update is processed by surescripts and the date is reached, no notifications will be generated for the patient enrolling or adding a new patient or notification recipient please consider the following when enrolling or adding a new patient or notification recipient new patients (assigning authority plus patient id) received in a patient file load will be validated and loaded new recipients (sender id, npi) with associated patient detail (pma) records will be validated and loaded a new recipient for a patient already monitored by a different recipient will be validated and loaded independently from the original recipient record surescripts considers the combination of sender id, npi, assigning authority, and patient id to be the unique keys to a record being monitored for notifications