Integration & Production
The following section defines related technical and support elements needed to achieve certification for moving into production, along with our Integration, Compliance, and Certification processes.
Integration Process
When a customer begins integrating a Surescripts product into their application(s), they will be provided access to all the Surescripts documentation pertaining to the product being implemented. In addition, customers will be provided access to the staging environment to design, develop and test the product integration within their application.
Note: The time frame of the project can vary depending on the customer's resource allocation for the project.
Meeting Requirements
During Integration, customers will ensure their system has met all product requirements. The message validation testing will focus on message format, application workflow and display in accordance with Surescripts documentation. Upon successful completion of message validation and, when applicable, other pre-production network requirements (e.g., Identity Proofing, Attestations, DEA audit), customers will be enabled in production.
For requirements, consider the following:
- To ensure high-quality transactions, Surescripts applies additional business rules above and beyond the schema defined requirements that will cause a message to be successful or rejected.
- Surescripts test cases do not cover all possible scenarios in production. Customers are responsible for testing any other applicable scenarios specific to their production environment.
- In accordance with the customer’s legal agreement with Surescripts, each customer is responsible for ensuring compliance with all applicable laws including, but not limited to, local and state laws/regulations where doing business.
Transition to Production
Once certification testing is complete and the contract is approved by the Surescripts Certification Review Board, the customer is ready to move into production. Surescripts will configure the production connection and ensure successful operations with the customer. Prior to the transition to production, Surescripts Account Management will work with the customer and internal Surescripts teams to discuss the following:
- Production support contacts (Escalation Matrix - A tool that helps the customer know exactly who to contact and how issues will be escalated if initial support cannot resolve them.)
- Support process and training
- Support availability
Surescripts Terminology Usage
For terminology usage throughout this guide, consider the following:
Term | Term usage |
|---|---|
must | Requirements that are enforced as part of the production code or Surescripts business rules. |
shall | The requirements customers are required to meet in order to be certified on the Surescripts network. These requirements will be enforced as part of certification. |
should | Used for guidance and best practices to produce superior results and enhance electronic messaging. Best practices can also be found in Best Practice sections. Customers are encouraged, but not required, to meet best practices in order to be certified on the Surescripts network. |
Communication Rules
Please refer to the Connectivity and Authentication Guide for details regarding communication and security protocol requirements as well as references to all links and IP addresses associated with Surescripts services. For the network to be reliable, there are communication rules to which all customers must adhere.
Note: For authentication, requests will use mTLS where the client will provide a client certificate.
Secure FTP
Contact your Surescripts resource for Secure FTP requirements.
UTC Time Format
By using Coordinated Universal Time (UTC), the receiver of a message will know the time regardless of their time zone. For example: If a message was sent from Boston at 5:30PM EDT (Eastern Daylight Time), the time would be sent as 21:30 UTC time. If this message was received in Chicago CDT (Central Daylight Time), the 21:30 UTC could be converted to the local CDT time of 4:30PM. Refer to http://en.wikipedia.org/wiki/Coordinated_Universal_Time, or http://www.w3.org/XML/ for more information. UTC time must be synchronized with NIST (National Institute of Standards and Technology) and the difference must be less than one minute. Drift of no more than one minute will be acceptable.
When sending only a Date (not Date and Time), it should be sent in your local time zone, and the receiver should interpret it in their local time. Neither party should attempt to convert the Date to UTC.
All standard programming languages should have a function for generating a date in the UTC time zone or displaying a date in the local time zone. The format of the date/time fields in the XML schema must use the xsd:dateTime format. Examples of that format are: CCYY-MM-DDTHH:MM:SS.FZ, where the UTC time zone may be specified as Z, + 00:00, or - 00:00. For example, 2013-01-01T16:09:04.5Z, or 2013-01-01T16:09:04.5-00:00, or 2013-01-01T16:09:04.5+00:00, where 16:09:04.5Z would be 16 hours, 09 minutes, 04 seconds, 5 fractional seconds. UTC time is denoted by either the “Z” in the first example or the “-00:00” in the second example, or the “+00:00” in the third example. The fractional seconds is not required. Refer to xsd:dateTime for more information.
For simple date fields that do not include the time portion, the format is: CCYY-MM-DD.