Process Overviews

patient file load 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 in medication history for populations (prescription notifications) are enrolled until the specified end monitoring date docid\ y m hry84btyrd1rgdvht customers can define the end monitoring date (which must be set for a future time period) on the initial load, which automatically stops notifications at that point if no value for end monitoring date is specified, then patient processing will continue until an end monitoring date is loaded patients enrolled for medication history for populations (panel) 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 surescripts generates and posts onto the sftp site the patient response file for retrieval the response file notifies the customer that the patient file load was received and provides details into any errors that were encountered during the validation process the customer should review the patient response file to determine if a file and/or patient resubmission is required due to errors note only resubmit records that have errors 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\ y m hry84btyrd1rgdvht 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 note all patients who are currently being monitored can be unenrolled from prescription notifications with a unr file load (panel does not apply to this feature) see detail information for unenrollment docid\ y m hry84btyrd1rgdvht 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 panel process flow the diagram below illustrates the customer process flow 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 contains 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 the dispensed medication fill database, which is updated regularly by pharmacies connected to surescripts this data contains 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 the customer application requests panel data via the fhir api surescripts responds back to the customer with panel data via the fhir api prescription notification process flow the diagram and process steps described below provides an overall view how the patient file load works with the notifications fhir flow the customer generates a file that identifies which patients they want to enroll for prescription notifications, and then posts that file to the surescripts sftp site 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 patient load file, then generates and posts a validation response file in the sftp folder for retrieval, which notifies the customer that the patient file was received the response file provides details about any errors that were encountered during the file validation populations users should plan to resubmit corrected records for example, a record that was rejected due to invalid zip code format surescripts runs an mpi match against enrolled patient records stored in the populations patient database every four hours surescripts retrieves and gathers available fill data for all patients that were found while processing business rules for prescription notifications to generate alerts the customer’s application requests patient notification data via the fhir api surescripts responds back to the customer with patient notification data via the fhir api prescription notifications fhir api message flow a back end call is made from the customer’s system to retrieve prescription notifications for a specified time period for example, the customer created a notification request to be sent at 12 00 pm (utc), returning all notifications generated over the last six hours (6 00 am to 12 00 pm) get https // fdqn /ext/v1/communication?category=notification& lastupdated=gt 2025 01 20t06 00 00z & lastupdated=it 2025 01 20t11 59 59z & count=1000 the customer’s system sends the patient notification request to surescripts via the fhir api surescripts receives the notifications operation request, and sends all prescription notifications that fit the time request window a subsequent back end call is generated from the customers system to retrieve prescription notifications for a specified time period ( beginning where the previous request time ended ) for example, the customer created a notification requests to be sent at 6 00 pm (utc) to return all notifications generated over the last six hours (12 00 pm to 6 00 pm) get https // fdqn /ext/v1/communication?category=notification& lastupdated=gt 2021 01 20t12 00 00z & lastupdated=it 2021 01 20t17 59 59z & count=1000 the customer’s system sends the patient notification request to surescripts via the fhir api surescripts receives the notifications operation request, and sends all prescription notifications that fit the time request window this process repeats indefinitely for each notification time window request message and file validation surescripts ensures that customers are in compliance with the message and file specifications outlined in this guide during integration testing and will continue to enforce these requirements once in production at a minimum, surescripts validations include sender identification and authentication recipient identification syntax compliance, including field lengths required fields data types number of repeats code values surescripts business rules and applicable requirements