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 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 and the associated application certification requirements (acrs) 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 acrs are required to be met to achieve production status on the surescripts network and will be enforced as part of certification surescripts business rules are data validations applied by surescripts beyond the schema 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 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 transition to production once and the contract are complete and 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 note the transition to production is concluded with a lessons learned discussion and/or satisfaction survey 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 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 c ### this designates a pmbc workflow application certification requirement communication rules please refer to the connectivity and authentication guide for additional connectivity and authentication information for the network to be reliable, there are communication rules to which all customers must adhere timeouts for timeouts, consider the following when sending a message to surescripts, the initiator should set the http timeout to 30 seconds the receiving system must reply with a valid status/error response within 24 seconds when a status 000 is sent as a reply to a clinical message, the receiving system must follow up with a verify or error message within 55 minutes, because surescripts may return a timeout error if no verify or error message has been received 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 character set the character set contains ascii values 32 – 126, which include symbols ! " # $ % & ' ( ) + , / ; < = > ? @ \[ \ ] ^ ` { | } numerals ø to 9 letters, upper and lower case a to z, a to z unprintable characters, such as control characters, are not used within the field sets defined unprintable characters are used as delimiters utf 8 is the required character encoding for xml other encoding formats are not supported by surescripts it is recommended that customers declare their utf 8 formatting in the message header handling optional fields customer shall be able to process any valid message request or response that they are certified on (conditional/optional, valid data elements and values shall not cause processing failure of the message) numeric representation the decimal point is represented by a period and shall be used as follows only when there are significant digits to the right of the decimal when there is a digit before and after the decimal point not with whole numbers for example, consider the following possible values correct 2 515 251 5 25 15 2515 0 2515 2 5 incorrect 2515 2515 3 00 requirement designation segmnet attributes code description m required/mandatory the segment must be used c situational/conditional the segment must be used if conditions are met some fields may not have specific conditions data should be sent if available where comments are "not used by surescripts", information will be passed on, but not used, by surescripts for processing nu not used or for future use note elements that are grouped together in a composite may be marked as mandatory; however, if the group itself is marked as conditional, then these are only required if you use the group in the example below, the documenttype and documentdata are mandatory only if the file is sent element name code comments file conditional this type of attachment can be used by the send to include a file attachment documenttype mandatory if a file attachment is included, then a documenttype must be specified and should be a valid mime type for example application/pdf documentversion conditional optional version number for the document type documentdata mandatory the base64 encoded string of the file attachment compliance surescripts goal is efficiency and consistency across the network so that all customers can meet the highest measures of patient safety, end to end reliability, and quality to ensure that customers comply with, and adhere to, the approved certification requirements, surescripts initiates a remediation process for identified compliance issues monitors customers in production to ensure all network customers remain in compliance with certification requirements and contractual terms customers agree to notify surescripts when they have altered, reconfigured, or disabled any portion of a surescripts certified software product or module, before moving such changes into production, as they may create a circumstance of non compliance with the surescripts certification issued in those instances, surescripts will work with the customer to perform a timely re certification, if required, to ensure network compliance and safety this guide is intended for certification on our network only and is not intended to ensure compliance with state and federal law in accordance with the customer’s legal agreement with surescripts, each customer is responsible for conducting its own due diligence to ensure compliance with all applicable laws and requirements, including, but not limited to, local and state laws and regulations in which the customer’s application is deployed and used as a reminder, surescripts conducts certification with customers to ensure the application adheres to network requirements surescripts will enforce mandatory fields as required by the standards body and surescripts guide requirements to maximize interoperability, customers are recommended to support optional fields that have been created to address gaps in discrete data needs and the many solutions that are in place for the benefit of the receiver surescripts encourages, but does not guarantee, the use of optional discrete fields to support end user workflows