Changing Prescription Information

This page will explain how to add, change or remove a provider's Drug Enforcement Agency (DEA) Number, Surescripts Provider Identifier (SPI) Number or their USB Authentication Token. Two separate users that are not the provider whose information is changing will be required for this process.

Permission to Propose or Confirm Changes

Before any prescription-related credentials can be changed, permission to make changes must be assigned on a User level. To assign this permission, modify the intended user by going to Properties and Users, then go to the e-Prescribing tab. Only two types of users can assign this permission: A provider, and any user that currently has this permission. A user cannot alter their own e-Prescribing permission.

Once this permission has been given, this authorized user can either initiate or confirm/deny a change request to a provider's DEA Number, SPI Number, or their USB Authentication Token.

ChangeRequestPermission.png

Propose Change Request

Only an authorized non-provider user can propose a Change Request. To propose a change to a provider's DEA Number, SPI Number or their USB Authentication Token, go to the e-Prescribing tab and select Providers/Users, select your provider, and click the Propose Change Request button. You will be shown the provider's current DEA Number, SPI Number and USB Authentication Token status, with the option to update or remove the DEA or SPI Number, or Authenticate or remove the USB Token. When finished, click Save; At this point, it will be up to a separate authorized user to respond to a request, as you cannot respond to your own request, and the request also cannot be responded to by the provider whose record is being changed. You also cannot request another change for that provider until the earlier change request has been processed.

ChangeRequest1.png

Respond to Change Request

For a single provider practice, only an authorized user that is not the proposing user or the affected provider can respond to a change request. For a practice with two or more doctors, if a DEA-registered provider can respond to a change request, they must be the one to respond; DEA regulation states that the responder should be a DEA registrant and have the USB token when available. This requirement of needing a USB token provider to respond to changes is referred to as two factor authorization. To respond to a change request, go to the e-Prescribing tab and select Pending Change Requests, choose the change request, and click the Respond to Change Request button. You will be shown the proposed changes to the provider's record, and will have the option to approve or deny this proposal, with the ability to add a comment on your decision. Once the decision has been made, click Save, and completed Change Request will be moved to Completed Change Requests, where you can see a history of all approved or denied change requests.

ChangeRequest3.png

USB Token Authentication

During a change request, when authenticating a provider's USB token, that token must be inserted into the computer at that time, and the SafeNet software must be running. Pressing the Authenticate button will prompt the user to enter their SafeNet password token before continuing.

If a provider with a USB token is responding to a change request, they must insert their own USB token and enter their SafeNet password when they attempt to approve or deny the change request for another provider's USB token authentication.

Change Request Workflows

Below are a list of workflows to process a change request varying on how many providers are in the system.

Single Provider

A minimum of two non-provider users will need permission. Since there are no providers that can propose a change request or respond to their own change request, a user may respond instead.

Two Providers

If both providers have a USB token, then a minimum of one user and both providers will need permission. One non-provider user will propose a change request, and each provider responds to the other provider's request.

If only one provider has a USB token, then the provider without the token requires one user to propose a change request and the provider with the USB token may respond to the request. The provider with the USB token requires one user to propose a change request and another user or the other provider to respond to the request.

If neither provider has a USB token, then a minimum of two or more users or providers will need permission. One non-provider user may propose a change request, and either another non-provider user or the other provider respond to the request. Since there are no providers that can perform a two factor authorization, a user may respond.

Multiple Providers

If at least two providers have USB tokens, then a minimum of one user and two providers must have permission. The minimum of two providers applies as providers can't propose their own change requests and will be relied upon to respond to requests for each other. This does not mean that all providers with USB tokens must have permission, but at least two providers with USB tokens would need the permission.

If one provider has a USB token, then one or more users and the provider with the USB token must have permission. Providers without the token require one authorized user to propose a change request and the provider with the USB token to respond to the request. The provider with the token requires one authorized user to enter the change request and another authorized user or another provider to respond to the request. Since there are no other providers that can perform a two factor authorization, a user may respond.

If no providers have a USB token, then a minimum of two or more users or providers must have permission. One authorized user may propose a change request, and another another authorized user or provider that is not the affected provider may respond to the request. Since there are no providers that can perform a two factor authorization, a user may respond.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License