Bidder Questions and Answers_Final_PDF.pdf

REQUEST FOR RESPONSE

RFR # SP26-OAT-Breath Alcohol Database-L01

Breath Alcohol Database

COMMBUYS # BD-26-1084-POLCL-FIMAY-125244

Note to Bidders: Written answers in this Forum are provided for the sole purpose of assisting the bidders in responding to this RFR. Forum answers are not intended to modify or interpret the terms of the RFR and shall not be used to modify or interpret the terms of this RFR, either before or after the award of a contract. Please refer to the Commonwealth Terms and Conditions, (Definition of “Contract”).

The complete Bidders Questions and Answers Forum are contained in this document. This document can be found as an attachment to the bid solicitation, (COMMBUYS BD-26-1084-

POLCL-FIMAY-125244).

1. Question Subject - Interface/Integration. What are the different interfaces you will need?

The one for the breath test, what is your ERP? and RMV? Is that it?

Answer: This needs to be integrated with the RMV and with an electronic discovery portal, and the Office of Alcohol Testing (“OAT”). That is the extent of the integration.

2. Question Subject - Number of users. How many employees will be using the system?

Answer: The Department estimates a range, 10 – 25 employees will use the system.

3. Question Subject – Location. How many sites?

Answer: The Department interprets this question to mean how many sites will access the system. The Department estimates one site: the Maynard Crime Laboratory.

4. Question Subject – Workflow. Will the devices have data stored then be transferred once it arrives to a specific location or do you need real time interface?

Answer: Devices do store some limited data. Device data will be transferred to the proposed system in real time. The devices are stationary and maintain a constant connection to the system.

5. Question Subject – Data. What data elements do you need from us?

Answer: All data elements generated by the 9510-breath system plus some OAT specific data requirements.

6. Question Subject – Reports. What reports or reporting requirements will you need?

Answer: The Department will need Ad Hoc reporting. Additionally, some of the reports that we may require include, but not be limited to, Breath Tests and Refusals by instrument, location, and date.

7. Question Subject – Data. Will you need data migration to have all legacy data available on new software?

Answer: Yes, data migration, all legacy data needs to be accessible. Data will be coming in from the existing system and will need to be incorporated live into the new database.

8. Question Subject – Cloud Hosting V On-prem. Does the Commonwealth prefer a cloud hosted solution in NLETS with a Soc 2 Type II Audit or an on-premises deployment?

Answer: The Commonwealth prefers a cloud hosted environment, however not in NLETS.

Any vendor, regardless of hosting on-prem or in the cloud, will be subject to a security review, including but not limited to a SOC 2 Type audit.

9. Question Subject – Implementation Strategy. Does the Commonwealth prefer a staged delivery process?

Answer: Yes.

10. Beyond replacement of the smart card and card reader infrastructure, can the

Department clarify the primary business objectives driving this procurement (e.g., risk mitigation, operational efficiency, evidentiary defensibility, modernization of infrastructure, cybersecurity improvements, or long-term digital transformation)?

Answer: The primary motivation is the modernization of infrastructure and operational efficiency.

11. What key outcomes or performance improvements would define a successful implementation 12–18 months after go-live?

Answer: Seamless integration with the 9510 BT system and unimpeded access to BT data on demand.

12. Can the Department describe the primary technical and operational limitations of the current SQL and Microsoft Access environment referenced in the RFR?

Answer: Microsoft Access will no longer be supported on Commonwealth devices.

13. Does the Department anticipate a full retirement of the current on-premises SQL infrastructure upon implementation, or should vendors plan for coexistence during a transition period?

Answer: Both systems will be operational during the transition period while the firmware in the 9510 BT instruments are being updated. Additionally, the current system will need to feed into the new system in real time.

14. Are there specific Commonwealth hosting requirements (e.g., Commonwealth-controlled cloud tenancy, MAGNet alignment, CJIS compliance) that must be incorporated into solution design?

Answer: Yes, the Commonwealth does have both cloud hosting requirements and CJIS compliances that will need to be adhered to as part of the design.

15. How are the approximately 404 Draeger Alcotest 9510 units currently connected (e.g., wired network, VPN, cellular, isolated networks, batch upload via physical media).

Answer: Data is transmitted electronically through an encrypted and secure wired network.

16. Are there device locations with limited or no real-time network connectivity that would require offline or delayed synchronization capabilities?

Answer: There are instruments without a data connection, but the data is transmitted in real time once the connection is re-established.

17. Does the Department or Draeger provide a documented API, SDK, or integration guide for interfacing with the Draeger Alcotest 9510 units?

Answer: This would need to be coordinated with Draeger.

18. Is the Department seeking immediate elimination of smart card dependencies at go-live, or would a phased decommissioning approach be acceptable?

Answer: The smart cards would not be eliminated until the entire fleet of instruments is updated.

19. Can the Department confirm the primary system user groups (e.g., OAT forensic scientists, Officers-in-Charge, Breath Test Operators, RMV personnel, public discovery users)?

Answer: OAT Forensic scientists are the primary user groups. Also, RMV personnel.

20. What are the most significant workflow inefficiencies or manual processes in the current system that the Department seeks to eliminate?

Answer: Aging infrastructure.

21. What is the current average time required to fulfill a discovery request, and are there specific challenges in meeting discovery obligations?

Answer: No more than 90 days. There are no current challenges to meeting discovery obligations.

22. Are there specific audit logging, evidentiary chain-of-custody, or immutable logging requirements that must be met beyond baseline Commonwealth security standards?

Answer: We require a date/time field in the data to document when the data was inserted into specific data tables. There are other audit log-in requirements based on other system functionality (i.e. RMV data transmission and error logging). Instrument chain of custody is currently handled using a separate LIMS system.

23. Are there defined role-based access control requirements tied to rank structure, agency hierarchy, or external agency access (e.g., RMV)?

Answer: All Department access is the same. External agencies (e.g. RMV) have limited access.

24. Can the Department provide an estimated volume (years and approximate data size) of legacy data that must be migrated into the new platform?

Answer: Since 2011. Approximately 30 GB.

25. Are there known data inconsistencies between the SQL and Microsoft Access systems that vendors should anticipate during migration?

Answer: Only formatting of certain data fields.

26. What are the most critical reporting use cases (e.g., OUI reporting, compliance reporting, operational metrics, legislative reporting)?

Answer: OUI reporting, metrics (arrest data), export of data to electronic discovery portal and RMV.

27. What is the current method of transmitting data to the Registry of Motor Vehicles (e.g., API, batch file, secure file transfer)?

Answer: Secure File Transfer (i.e. SFTP).

28. Can the Department clarify the current electronic discovery portal environment and whether integration must occur with an existing Commonwealth system?

Answer: Yes, integration must occur with an existing Commonwealth system. A subset of the total data must be integrated with the existing Commonwealth electronic discovery portal.

29. Does the Department prefer a phased implementation (e.g., pilot deployment followed by statewide rollout) or a single statewide go-live?

Answer: The Department prefers a phased implementation.

30. What level of system downtime, if any, would be acceptable during transition from the legacy system to the new platform?

Answer: None since both systems will run concurrently until completion of the project.

31. What internal MSP technical or operational resources will be available to support implementation and testing?

Answer: OAT Forensic scientists, Commonwealth IT personnel.

32. Are there National Highway Traffic Safety Administration (NHTSA) or grant-related deadlines that impose specific implementation timelines?

Answer: The project is grant funded. Timelines will be addressed with the selected vendor.

33. Does the Department anticipate expanding this platform in the future to include additional forensic or evidentiary data domains?

Answer: Not at this time.

34. Will formal system performance measures (e.g., uptime, response time, reporting latency, discovery turnaround time) be defined as part of the final Statement of Work?

Answer: Yes.

35. Does the Department require cryptographic hashing, digital signatures, or other tamper-evident controls at the record level to ensure evidentiary integrity of breath test results and certification records?

Answer: Yes, the current smart cards provide cryptography decryption. Data encryption both at rest and in transit will need to be incorporated.

36. Is the Department open to modern event-driven or message-queue-based ingestion architectures for device communication, or does the solution need to conform to a batch-processing model similar to the current environment?

Answer: The department is open to modern event driven / message-queue based ingestion as long as this methodology is compatible with the Draeger systems architecture.

37. Are there defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) that the new platform must meet, and is geographic redundancy required?

Answer: Yes, the department will require a security audit which will include both an IRP (Incident Response Plan) and a BC&DR (Business Continuity and Disaster Recovery) plan.

38. Does the Department require device-level authentication and certificate-based validation for breath test instrument communications, consistent with zero-trust security models?

Answer: Yes. Data encryption both at rest and in transit will need to be incorporated.

39. Question Subject - Alcotest 9510 Integration Documentation- Will the Commonwealth provide the necessary Draeger Alcotest 9510 integration documentation, interface specifications, encryption/decryption protocol details, and authorization required for direct integration? Or is the selected vendor expected to independently obtain integration rights from Draeger?

Answer: The selected vendor would be expected to obtain this information from Draeger.

40. Question Subject - Encryption Key Ownership & Smart Card Process- Does the

Commonwealth currently possess ownership or administrative control over the encryption keys used in the smart card decryption process? If not, will coordination with Draeger be required to implement an alternative decryption mechanism?

Answer: The selected vendor would be expected to obtain information and coordinate with Draeger.

41. Question Subject - Decryption Responsibility & Workflow - Is the selected vendor expected to perform cryptographic decryption of evidentiary records directly, or will decrypted data continue to be provided by an existing Commonwealth-managed process?

Answer: The vendor is expected to do so, working with Draeger.

42. Question Subject - Test Instrument & Sandbox Access - Will the Commonwealth provide access to a test instrument and sandbox environment for integration development and validation?

Answer: Yes, the Commonwealth will provide electronic access to a test instrument on premises, and work with the vendor and Draeger to establish a sandbox environment for development.

43. Question Subject - Forensic Validation Requirements - Will modifications to the communication or decryption workflow require formal validation by the Office of Alcohol Testing or additional forensic certification processes?

44. Question Subject - Current System Architecture Documentation - Will the Commonwealth provide architecture documentation of the current breath test data flow, including communication pathways, database schema, and smart card decryption workflow?

45. Question Subject - Legacy Data Volume & Migration Scope - What is the estimated volume (records and storage size) of legacy data that must be migrated into the new system?

Answer: Approximately 30GB of legacy data.

46. Question Subject - Custom Built - Is the department looking for an out of the box product, or would they be open to a custom-built solution?

Answer: The Commonwealth prefers a COTS system.

47. Question Subject - Data Access & API Availability - Does the Commonwealth currently possess, or will it provide, a documented Application Programming Interface (API) or Software Development Kit (SDK) for the Draeger Alcotest units to facilitate third-party database integration?" The Goal: To determine if the "connection" is a standard handshake or if it requires proprietary Draeger "insider" knowledge.

Answer: The selected vendor would be expected to work with Draeger.

48. Question Subject - Hardware-Software Decoupling - Is the Commonwealth open to a middleware solution that standardizes data formats from various breathalyzer models, or must the proposed database communicate directly and exclusively via Draeger’s proprietary protocols?" The Goal: To see if they are willing to abstract the software layer away from the hardware brand.

Answer: The Commonwealth is open to a middleware solution that standardizes data formats. It must conform with the Draeger proprietary protocols.

49. Question Subject - Data Ownership and Export - Can the Commonwealth confirm that all data generated by the Alcotest units is the sole property of the Commonwealth?

Furthermore, will the current hardware provider be required to cooperate with the successful software bidder to ensure a seamless data 'push' or 'pull' mechanism?" The Goal: To force the state to acknowledge that a hardware vendor shouldn't be allowed to "gatekeep" public data.

Answer: The Commonwealth owns all data. The current hardware vendor will be required to work with the software vendor on data transmission.

50. Question Subject - Data Access & API Availability - Does the Commonwealth currently possess, or will it provide, a documented Application Programming Interface (API) or Software Development Kit (SDK) for the Draeger Alcotest units to facilitate third-party database integration?" The Goal: To determine if the "connection" is a standard handshake or if it requires proprietary Draeger "insider" knowledge.

Answer: The selected vendor would be expected to work with Draeger.

51. Question Subject - Data Push vs. Pull: "Does the Alcotest 9510 hardware currently support an automated data 'push' to an external IP/URL via its Ethernet port, or must the database platform actively 'pull' data from the device using a proprietary polling method?" The Goal: To determine the method of data I/O communication.

Answer: The instruments do not currently automatically push the data. The selected vendor would be expected to work with Draeger on the communication method.

52. Question Subject - Alternative to Smart Cards: The RFR mentions an 'alternative communication method without smart cards.' Does the Commonwealth have a preferred protocol for this (e.g., RFID, Biometric, or unique PIN-based OAT authentication) that the database must support?" The Goal: To decouple officer authentication from physical, high-maintenance hardware.

Answer: The smart cards decrypt the data from breath test instrument. The Commonwealth is requiring decryption be done by software.

53. Question Subject - The Smart Card Problem - A card might say an officer is certified, but if their certification was revoked yesterday, the card still works until it is physically updated. The Goal: A "Live" check. When an officer logs into the Draeger unit (via PIN, RFID, or Biometrics), the unit queries your database to see if that specific Operator ID is currently active in the BTO Registry.

Answer: The smart cards decrypt the data from breath test instrument. The Commonwealth is requiring decryption be done by software. The smart cards are not used as an authentication method for the BTO.

54. Question Subject - Proprietary Lock-in - If the hardware manufacturer (Draeger) refuses to provide technical specifications to a third-party software contractor, how does the Commonwealth intend to facilitate the 'Required Specification' for hardware integration?" The Goal: To protect your business from a "Catch-22" scenario: being contractually obligated to deliver a working integration while being denied the technical tools (by Draeger) to actually build it.

Answer: Draeger is contracted by the Commonwealth to provide the necessary information for integration.

55. Question Subject - Budget Scope - The estimated first-year expenditure is $300k–$350k.

Does this figure include the cost of any proprietary Draeger licensing fees required for integration, or are those covered under a separate statewide hardware contract?" The Goal: To protect profit margins and ensure you aren't accidentally underbidding due to hidden third-party costs.

Answer: The Commonwealth contracts separately with Draeger.

56. Question Subject - Teaming Partners to work on this Bid - Can I use teaming Partners to work on this bid? The Goal: To provide best overall scalable cost effective solution.

Answer: Use of Subcontractors is addressed on page 29 of the RFR, “Subcontracting Policies.

57. Question Subject - Data Integrity & Evidentiary Standards - Does the Commonwealth require the software to generate a unique cryptographic hash for every test record at the moment of ingestion to ensure data has not been altered? Furthermore, will the Commonwealth provide the 'business rules' for identifying and flagging 'invalid' or 'incomplete' test sequences for discovery purposes?" The Goal: To understand the level of "Forensic Audit" capability you need to build. This isn't just a database; it’s a legal evidence vault.

Answer: Data encryption both at rest and in transit will need to be incorporated. For the 2nd part of the question, all test sequences are discoverable, even if they are invalid or incomplete, and must all be available in real time.