Product Integration & Production

integration process once surescripts assigns an integration resource, customers will be contacted to begin the project(s) and will be guided through the surescripts integration process the integration resource will provide surescripts documentation, product education, access to the surescripts staging environment, assistance during design and development milestones, and testing to prepare for the integration resource will perform testing and, once successful, will provide the customer access to the surescripts production environment note the time frame of the project can vary depending on the customer's resource allocation for the project meeting requirements during integration, customers undergo testing to demonstrate all requirements are met focuses on message format and, when appropriate, application workflow and display in accordance with surescripts documentation upon successful completion of and, when applicable, other pre production network requirements (e g , identity proofing, dea audit), customers will be enabled in production for requirements, consider the following surescripts business rules are data validations applied by surescripts based upon the schema defined syntax rules 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 all 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 surescripts terminology usage requirements that are enforced as part of the production code are denoted as “must” and will have to be met to successfully complete validation “should” is used for guidance or best practices see the following chart for terminology usage in this implementation guide term term usage must requirements that are enforced as part of the production code should used for guidance and best practices best practices can also be found in best practice sections customers are encouraged, but not required, to meet best practices to be certified on the surescripts network transition to production once the customer contract is complete and the is approved by the surescripts certification review board, the customer is ready to move into production surescripts will configure the production connection and validate 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) support process and training support hours secure ftp contact your surescripts integration 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 http //en wikipedia org/wiki/coordinated universal time , or http //www w3 org/xml/ http //www w3 org/xml/ for more information synchronize utc time with nist (national institute of standards and technology) 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