The file's text, extracted by GovTribe without its formatting.
Appendix C
Electronic Medical Record
Table of Contents 1Contractor Guidelines
2General Instructions
2Spreadsheet Response Instructions
2Accessibility
3Hosting
7Security
10Help Desk and Support
11Transition
12Steady State
12Data Storage and Ownership
14EMR Functional Requirements
29Workflow & Approval
30Auditing
31User Features
31User Management
32Communication & Collaboration
32Reporting
33Service Level Agreement Catalog
Contractor Guidelines
This appendix contains specific functional requirements that the Contractor must meet in order to perform the requested services. The Contractor must respond to the requirements contained in this Appendix according to the instructions provided below. The Contractor’s response must be in the prescribed format.
The Contractor should provide clear, concise and reasonable responses. The Contractor should not postpone a response. “Contractor ABC would be happy to discuss this at a later time” is an example of a postponed response.
General Instructions
The Contractor will use the electronic version of this Appendix (provided with the RFP materials) to respond to the requirements. The Contractor should not make any changes to formatting or text styles in the overall document. It is important that the Contractor not merge any table cells in the document.
The Contractor should save the file as the original filename prefixed with the Contractor’s company name (e.g., “ABC AppendixD SOW.doc”) and return the completed file, with the new file name, as part of its overall response to the RFP.
Spreadsheet Response Instructions The Contractor will respond to Commonwealth requirements contained in this Appendix in only one of the following ways for each of the individual cells:
1. Most of the requirements in the Appendix contain the expected responsibilities of the Contractor. These requirements are intended to elicit the concurrence of the Contractor that its solution will comply with the requirement as written. If the Contractor has read and understood the requirement, and its solution will comply with the requirement exactly as written, the Contractor should
a) Enter a “Y” in the “Comply Y/N” column. (“Y” stands for “Yes” and indicates that the Contractor’s solution will comply with the requirement as written.)
2. If the Contractor’s solution does not comply with a requirement as written, and/or has some modifications to the requirement language, and/or has a different approach to meeting the requirement, the Contractor should do the following:
a) Place the letter “N” in the Comply column. (“N” stands for “No” and indicates Contractor’s solution will not comply with the requirement as written.)
b) The Contractor may add a concise comment or explanation concerning the reason for non-compliance in the Contractor Response column.
c) The Contractor should not view the possibility of requesting changes as an opportunity to re-write the entire RFP. The DOC expects the Contractor to comply with the requirements as written, and the Contractor should make changes only for minor clarifications or if the Contractor’s solution will not comply with the requirement as written.
3. If the Contractor has been asked to describe its response (see italicized Commonwealth requirements), the Contractor should do the following: In the Contractor Response column, provide a brief statement or make reference to the appropriate section in the Contractor’s Technical Solution document.
The following Work Statement Matrix is to clearly define responsibilities between Commonwealth and the contractor.
| Requirements |
| Comply (Y/N) |
| Contractor Response |
Accessibility
| 1. |
| The Contractor’s hosted solution shall be compliant with Section 508 of the Rehabilitation Act Amendments of 1998. Please see ITB ACC001, IT Accessibility Policy and Appendix G1 regarding Accessibility requirements. |
| Hosting |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| The Contractor shall describe an electronic medical records (EMR) solution that provides the DOC the ability to implement a solution that provides for automated tracking and integrated views of sick call, chronic care, nursing and doctor notes, onsite and offsite consults, specialty care, infectious disease, dental panoramics, optometry, opthamology, diagnostics, screenings and assessments, inmate transfer preparations, medications, appointment scheduling, etc. |
| 2. |
| The Contractor shall describe how the EMR will be provided for the DOC. |
| 3. |
| The Contractor shall have the ability to implement a hosted EMR solution that includes: application software, technical infrastructure, training, change and issue management and legacy system transition. |
| 4. |
| The Contractor shall describe any integration with other systems with which the solution is currently integrated and briefly describe the nature of the integration. |
| 5. |
| The Contractor shall describe how the proposed solution integrates with each of the following: 1) Mobile Devices; 2) Applications that use e-mail notifications; 4) LDAP, or Microsoft ActiveDirectory; 5) SAP. 6) Video Conferencing; 7) DOC Desktop and Infrastructure Architecture; 8) Microsoft Office Applications; 9) Microsoft Outlook/Exchange Server; 10) DOC IOCMS Applications; and 11) WebEx. Mobile devices that access and/or store EMR data must be encrypted. |
| 6. |
| The Contractor shall describe its experience with implementing an electronic medical record application. |
| 7. |
| The Contractor shall provide the DOC with thirty (30) days written notice prior to all planned system enhancements and modifications, including upgrades and new versions and releases of the system. The implementation of such system enhancement/modifications shall be scheduled at a date and time agreeable to the DOC. Written notice to the DOC of the system enhancement/modifications shall contain a comprehensive explanation of the scope of the work to be done and/or changes to be made, as well as anticipated amount of application downtime, if applicable. |
| 8. |
| The Contractor shall provide updates and enhancements to the DOC at no additional cost. |
| 9. |
| The Contractor shall work with the DOC to accommodate any end user training that may be needed as a result of system enhancements/ modifications and shall minimize any disruption of operations. The Contractor shall appropriately update all system and end user documentation and system help screens to reflect the enhancements/modifications. |
| 10. |
| The Contractor shall completely test all application software modifications, and test and apply patches for all third party software in a separate and distinct environment from production before applying to the production environment. All critical security patches and updates should be tested and applied as soon as possible. All enhancements and modifications must be approved by the DOC prior to movement to the production system. |
| 11. |
| The DOC shall have access to a testing environment for review and verification of system enhancements and modifications. |
| 12. |
| The Contractor shall supply to the DOC a plan to correct all errors and/or deficiencies, as they are identified. Dates for resolution of the errors and/or deficiencies will be agreed to by the DOC. |
| 13. |
| The Contractor shall provide two (2) weeks advance notice prior to scheduling non-routine maintenance, except for emergency maintenance; Notice shall be given in writing via email, to the DOC. Routine and non-routine maintenance shall be scheduled to occur at a time that is acceptable to the DOC. |
| 14. |
| The Contractor shall describe their procedure for communicating the need for emergency maintenance actions. If possible in an emergency situation, the DOC shall be given advance notice before the system is made unavailable for the emergency maintenance to be completed. |
| 15. |
| The Contractor shall describe the skills it maintains to implement and support its solution as outlined in its response to this RFP. |
| 16. |
| The Contractor shall describe what training of DOC staff will be required or recommended to support the implementation of their EMR application. |
| 17. |
| The Contractor shall describe the availability, reliability, redundancy or duplication and survivability of the solution. |
| 18. |
| The Contractor shall publish the actual system performance results, which shall include system availability information including scheduled maintenance, unscheduled maintenance, and unplanned downtime on a monthly basis to be used for quarterly reporting. |
| 19. |
| The Contractor shall describe its data backup process, which requires data at rest to be encrypted (disk, tape, etc.). Stored media will be kept in an all-hazards protective storage facility. Contractor shall provide off-site storage of EMR and DOC data so as to ensure recovery without data loss. |
| 20. |
| The Contactor shall have and employ reasonable disaster recovery procedures so as to ensure recovery of the EMR within six hours in the event of a disaster, loss of system, or loss of the hosting location. |
| 21. |
| The Contractor shall provide a detailed description of its disaster recovery plan. This should include backup policies and procedures, including time to recovery from types of system failure. |
| 22. |
| The Contractor shall describe its ability to do backup, restore, versioning, scheduling in an automated manner. |
| 23. |
| The Contractor shall describe scalability of the hosted solution as it relates to end-user and storage capacity and/or limitations.(if applicable) |
| 24. |
| The Contractor shall describe the maximum number of users that can access the system concurrently. |
| 25. |
| The Contractor shall support role-based access control as the approach to restricting system access, in whole or in part, to authorized users. |
| 26. |
| The Contractor shall utilize secure FTP and/or web services for data integration with DOC systems. |
| 27. |
| The Contractor shall describe how text/information is imported to the system. All additional hardware and software to support scanning/OCR/external data entry (such as X-Ray reports, notes from consultants and operative reports) shall be detailed by the Contractor. The Contractor shall identify all image formats supported by the EMR. |
| 28. |
| The Contractor shall identify what printers are compatible with the EMR system and ensure current Commonwealth approved printers and copiers are capable of being used. |
| 29. |
| The Contractor shall identify which government, industry, or professional standards have been or are to be utilized in the development of the EMR system (e.g. ANSI X12 (EDI), CEN’s TC/251, EN13606, CONTSYS (EN 13940), HISA (EN 12967), IACOM, HL7, ISO TC 215, open DHR, Smart Platforms, ASTM International Continutiy of Care Record standard, ISO 18308, or ASTM E31.19) |
| 30. |
| Routine maintenance shall be performed during DOC’s planned weekly maintenance period Wednesdays between the hours of 5:00 PM and 9:00 PM Eastern time. The Contractor shall provide two (2) weeks advance notice prior to scheduling all routine maintenance, requesting extended routine maintenance, or requesting approval of non-routine maintenance, except for emergency maintenance; Notice shall be given in writing via email, to the DOC. Non-routine maintenance shall be scheduled to occur at a time that is acceptable to the DOC |
| Network |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| The contractor shall provide an analysis of wide area network (WAN) bandwidth requirements for the EMR application. The analysis must be based upon and include projections for bandwidth consumption by application component and frequency of use at each DOC location. The objective of the analysis is to identify maximum dedicated WAN bandwidth requirements for the EMR application in bits/second at each DOC location. |
| 2. |
| The contractor shall acquire, implement, and fund a Commonwealth of Pennsylvania (COPA) Co-Lo Business Partner (BP) network connection. The COPA BP network connection will establish a private, dedicated, network link between COPA/DOC data networks and EMR systems. |
COPA will provide the contractor rack space in data center(s) located in Harrisburg, PA. Rack space will be provided in a single data center or two different data centers if the contractor seeks a redundant BP solution.
COPA will provide the contractor a 1GB TX Ethernet network connection in each data center for connectivity to COPA/DOC networks.
COPA data center(s) will be equipped with power, environmental conditioning, physical security, cabling required between the rack and the COPA/DOC network interface, and cabling between the rack and service-provider demark interface in the data centers (UTP, Coax, and/or fiber provided by COPA as required by the contractor).
The contractor shall provide telecommunication services between the COPA data center and their EMR IT systems. Both Verizon and Level(3) have existing services in both COPA BP data centers. However, the contractor may use the telecommunication service-provider of their choice. The contractor shall provide the network equipment required to interface between the aforementioned telecommunication services and COPA/DOC network interface.
The contractor shall provision the BP connection with sufficient bandwidth to host all network traffic between EMR IT systems and DOC IT systems. All network traffic between EMR IT systems and DOC IT systems shall traverse the COPA BP network connection. The contractor shall resolve all private network IP addressing conflicts between EMR IT systems and DOC IT systems without the need for DOC IT system changes.
The contractor shall provide a description of there proposed COPA BP solution to include: 1) network design diagram, 2) list of network equipment to be provided in the COPA data center(s), 3) name of service-provider for proposed telecommunication services, 4) description of proposed telecommunication services.
| Security |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| The Contractor shall describe in detail how the security architecture will be implemented and deployed to address compliance with Commonwealth standards and interoperability requirements. |
| 2. |
| The Contractor shall provide services which mitigate or eliminate any impact from denial-of-service (DoS) attacks, intrusion detection, virus or worm propagation, or other targeted service disruptions. |
| 3. |
| The Contractor shall describe all system security measures in place for the hosted system. |
| 4. |
| The Contractor shall report security incidents to the DOC EMR Project Manager and the DOC Chief Information Security Officer (CISO) as well as comply with state and federal data breach notifications regulations. Please reference ITB-SEC024: IT Security Incident Reporting Policy for additional guidance. |
| 5. |
| The Contractor shall provide effective encryption to the hosted application. Please reference ITB-SEC031 - Encryption Standards for Data in Transit, for additional guidance. |
| 6. |
| The Contractor shall provide protection from unauthorized access to and unauthorized use of the system. Please provide an explanation on how this is monitored and what tools are used, i.e. real-time monitoring, or alerts, or post reviews of logs, etc… |
| 7. |
| The Contractor shall provide firewall protection at the application and network layers. |
| 8. |
| The Contractor shall provide protection from denial-of-service attacks. |
| 9. |
| The Contractor shall provide effective encryption data at rest. Please reference ITB-SEC020 - Encryption Standards for Data at Rest, for additional guidance. |
| 10. |
| The Contractor shall be responsible for ensuring all laptops, mobile devices, portable media storage and removable storage devices are encrypted, if they used in any aspect of this project for any reason. |
| 11. |
| The Contractor shall be responsible for network and application security. This includes: host scanning, network vulnerability testing, web application vulnerability scanning, PCI scanning, etc. |
| 12. |
| All required security controls mandated by: laws or regulations, Commonwealth policies, Information Technology Bulletins (ITBs) or Management Directives (MDs) requirements are to be incorporated into the agency’s Web application’s security architecture. |
| 13. |
| The contractor shall be responsible for security requirements in addition to the security requirements established by the OA/OIT policies, ITBs, and MDs, there may also be agency-specific security requirements that are not captured by OA/OIT policy, procedures, and standards. These requirements may be specific to the Department and may have their genesis in such as federal or state laws or regulations, or executive orders (i.e. HIPAA, CHRIA, etc.). |
14.
The contractor shall be responsible for regular Monitoring and Testing Networks – This includes tracking and monitoring all access to network resources and data, and regularly testing security systems and processes. Contractor needs to explain what monitoring and testing will be done on a scheduled and unscheduled basis. Summaries of the monitoring and testing results will need to be provided to the Department’s CISO or designee. This information will need to be available for the CISO or designee for periodic review to ensure compliance.
| 15. |
| The contractor shall re responsible for providing summary reports when patch management and / or and security updates for operating systems have occurred to be provided to the Department’s CISO or designee. This information will need to be available for the CISO or designee for periodic review to ensure compliance. |
16.
The area of Information Security continues to be a moving target for security and maintenance, since the concepts and technologies are always evolving and changing. The contractor shall be responsible for staying abreast of future policies, Management Directives and Information Technology Bulletin (by registering and subscribing to e-alerts from the Office of Administration Office of Information public website: http://www.oa.state.pa.us/portal/server.pt/community/oa_home/401).
17.
The contractor shall be responsible for Email encryption for any emails, if the content contains any “C” classification data. At a minimum it is required when emails are sent out of the host based system or to a user or another system or from a process supporting the host based system.
| 18. |
| The contractor shall be responsible for requesting permission to share and / or disseminate any information or data to anyone other than the Department of Corrections; i.e. other companies, subcontractors, government agencies, or other interested 3rd parties. If permission is granted, data must be encrypted. |
19.
The contractor shall be responsible for implementing strong Access Control Measures. This includes restricting access to data by business need-to-know basis, and assigning a unique ID to each person with computer access. This also includes restricting physical access to data.
| 20. |
| The contractor shall be SAS 70 certified to ensure proper controls for handling sensitive data are defined, suitably designed, and operating effectively. The CW also requires a Type II Service Auditor's Report describing the contractor’s controls, any tests performed on the controls and the test results demonstrating that the control objectives were achieved. |
| Help Desk and Support |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| The Contractor shall describe the help desk standard operating procedures for incident resolution. |
| 2. |
| The Contractor shall provide a consolidated and integrated, 24x7x365 days help desk and toll free number for end users and administrators. |
| 3. |
| The Contractor shall describe the support organization, including the help desk support offering and issue resolution. |
| 4. |
| The Contractor shall provide a comprehensive self-service password management solution that enables end users to securely reset their own passwords with minimal help desk and administrator involvement. |
| 5. |
| The Contractor shall provide online help tools, which include a problem/resolution knowledge base and Frequently Asked Questions and an end-user help forum. |
| 6. |
| The Contractor shall create an EMR end user manual and ensure that it is available for viewing or downloading from the EMR system. The EMR end user manual shall be revised by the Contractor on an ongoing basis in response to enhancements, upgrades and changes to the EMR, and shall be reviewed at least bi-annually to ensure accuracy of the information contained in it. |
| 7. |
| The Contractor shall implement a service management process to support the DOC’s incident and problem management process. The support and implementation of this process will include coordination with the DOC end user community as well as third party vendor systems and processes. |
| 8. |
| The Contractor shall describe the error escalation process in the event that the DOC cannot make contact with the Contractor’s Help Desk, is not satisfied with the resolution process, or if the DOC and Contractor disagree regarding the classification of an error or deficiency. |
| 9. |
| The application shall have the capability to provide real-time help functions from within it, i.e. help functions and troubleshooting is not solely via phone help desk support such as messaging. |
| 10. |
| The Contractor shall provide a monthly statistical report to the DOC EMR Project Manager of help or technical support provided to the DOC, broken down by date/time, agency, subject matter and status. |
| Transition |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| Within 30 thirty business days of issuance of the purchase order, the Contractor will participate in a project kickoff meeting that will take place in Mechanicsburg at 1920 Technology Parkway. |
| 2. |
| The Contractor shall deliver a bi-weekly project status report listing progress on all project activities and transition milestones. The project status report shall note any milestones and/or deliverables past due, or at risk of becoming past due, reasons for same, how such delays may put other deliverable deadlines at risk, and Contractor’s best estimation of means for overcoming. |
| 3. |
| The Contractor shall describe how it will transition all data from all existing manual and automated systems to its EMR solution. |
| 4. |
| The Contractor shall describe how it will implement a phased transition plan developed by the Contractor and the DOC, with a mutually agreed-upon date. |
| 5. |
| The Contractor shall describe how it will provide on-site end user and administrator training and support for all sites during the transition. |
| 6. |
| The Contractor shall describe how it will allow end users to test EMR functionality during the transition. |
| 7. |
| The solution provider must provide a Quality Assurance / Testing plan that addresses all testing performed on the preferred solution and its components prior to production implementation. This plan should address and contain the following core areas: Methodology and Process, Test Cases/Scripts, and other documentation, Execution and Tracking Tools, User Acceptance Testing, Operational Readiness, Test Results and Reports. |
| 8. |
| The solution provider must perform an Operational Readiness Test to ensure that all requirements of the system have been implemented and operate properly for a production environment. Upon the completion of this test, a report will be produced by the solution provider and approval by DOC. |
| 9. |
| The Contractor shall describe how it will provide training/reference resources to be used post-transition. |
| Steady State |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| The Contractor shall describe how it will continue to provide on-site end user and administrator training during steady state. |
| 2. |
| The Contractor shall be responsible for all costs resulting from support and maintenance contracts for the EMR application. |
| 3. |
| The Contractor shall meet with the DOC on a monthly basis to review current system statistics and any outstanding issues during transition and implementation, and as necessary thereafter. |
| 4. |
| The Contractor shall conduct on site quarterly project status/update meetings with DOC EMR Project Manager and other appropriate project team members. |
| 5. |
| The Contractor shall report any problems identified in the EMR and any problems identified by end users of the system. The report shall describe the problem and its impact on the system and DOC operations. The report shall list possible courses of action with advantages and disadvantages of each and provide recommended solutions and rationale. This report shall be provided to the DOC EMR Project Manager within 5 (five) business days following the identification of the problem. |
| 6. |
| The Contractor shall provide a year-end report to the DOC EMR Project Manager and Contract Monitor for each twelve (12) month period after the issuance of the purchase order. The report shall state all accomplished tasks according to this Purchase Order and summarize the activities for the last twelve (12) months of the Purchase Order. |
| Data Storage and Ownership |
| Comply (Y/N) |
| Contractor Response |
| 1. |
| The Contractor shall provide adequate storage capacity for all record keeping needs of the DOC. The Contractor shall provide active and archive storage capacity for all EMR data storage requirements of the DOC. |
| 2. |
| The Contractor’s solution shall be capable of retrieving archived records from the database within five days, of the request of the DOC, and is capable of providing that information to the DOC. The Contractor’s solution is capable of retrieving archived records from the database within five days, of the request of the DOC, and is capable of providing that information electronically to the DOC. |
| 3. |
| All data related to the use of the EMR system by the DOC, including but not limited to system and systems support data, belongs to the DOC. The Contractor shall, at no cost, deliver or facilitate the orderly transition of the Department data to a new application or the DOC upon the termination of this Purchase Order. The Contractor shall export all data, including but not limited to system and systems support data, stored by the Contractor. The Contractor shall upon delivery of the extracted data provide up-to-date and complete documentation and data dictionary describing the data and format of the data provided. The Contractor shall begin this activity a minimum of thirty (30) days prior to the end of this Purchase Order. Data must be provided to the DOC in a nonproprietary format that is acceptable to the DOC. The DOC will not reimburse the Contractor for any purchase or licensing fees incurred. The Contractor will transfer its annual maintenance agreement/fees to the DOC. |
| EMR Functional Requirements |
| Comply (Y/N) |
| Contractor Response |
Patient Record Identification and Maintenance
| 1. |
| The application shall have the capability to create a single logical record for each patient. |
| 2. |
| The application shall have the capability to link and/or merge multiple unique identifiers and the associated records to a single primary identifier (to manage aliases, duplicate records, inmate number changes, etc.). |
| 3. |
| The application shall have the capability mark erroneously-entered information as such in a record and present that information as erroneous in all outputs containing the information. |
| 4. |
| The application shall have the capability to correctly associate erroneous information mistakenly entered in one patient record with the correct patient record. |
| 5. |
| The application shall have the capability to capture and/or receive, store, and display the identification and demographic information of a designated Next Of Kin. |
| 6. |
| The application shall have the capability to generate a new patient record for a new inmate. |
| 7. |
| The application shall have the capability of identifying duplicate patient identifiers. |
Patient Demographics Management
| 8. |
| The application shall have the capability to capture, store (as discreet data elements), and retrieve demographic information as part of the patient record. |
| 9. |
| The application shall have the capability to update demographic information and store historical demographic data. |
| 10. |
| The application shall have the capability to present a standard set of patient identifying information, including the patient photo image, at each interaction with the patient record. |
| 11. |
| The application shall have the capability to import patient demographic data, via web service, data feed provisions, etc. from the PA DOC offender management system. |
| 12. |
| The application shall have the capability differentiate patients with similar names to support a reduction in patient identification errors. |
| 13. |
| The application shall have the capability to prompt users for missing crucial data (name, date of birth, inmate identifier, etc.) and prevent saving of a record until all mandatory data fields are populated. |
Patient History Maintenance
| 14. |
| The application shall have the capability to capture and store pertinent information from each encounter, including the complaint, presenting problem, or other reason(s) for a visit. |
| 15. |
| The application shall have the capability to present laboratory, pharmacy, radiology and procedural history, including dates and results. |
| 16. |
| The application shall have the capability to present laboratory, pharmacy, radiology and procedural history, including dates and results. |
| 17. |
| The application shall have the capability to store and present family and social history. |
| 18. |
| The application shall have the capability to import/capture, present, and store immunization history data. |
| 19. |
| The application shall have the capability to import/capture and store on-site and off-site encounter data. |
Data and Documentation from External Sources
| 20. |
| The application shall have the capability to maintain a current and comprehensive DOC Medical Forms library. End users must have the ability to electronically complete forms, print (as needed), and save the completed version as part of the patient record. |
| 21. |
| The application shall have the capability to receive, store and display diagnostic, pharmacy, and radiology data elements transferred through an electronic interface into the patient record. |
| 22. |
| The application shall have the capability to receive, store, and display scanned documents as images. |
| 23. |
| The application shall have the capability to receive, store, and display other forms of clinical results received from an external source. |
| 24. |
| The contractor shall describe each EMR transaction/process/interface that requires data from or provides data to any external system, including DOC systems and the execution frequency of each. Description shall include (but not be limited to): |
Interface Name
Interface Description
Interface Direction (Incoming/Outgoing)
EMR function requesting/receiving data
Frequency of execution
Data element name
Data element description
Data element type
Data element size
Data element null indicator (yes/no)
Data element values/descriptions, including example data
| 25. |
| The application shall have the capability to interface with Bustleton Radiology (Viztek OPAL PACS) with single sign-on to EMR application, given appropriate authorization. |
| 26. |
| The application shall have the capability to interface with MobileX Radiology with single sign-on to EMR application, given appropriate authorization. |
| 27. |
| The application shall have the capability to interface with BioReference (CareEvolve) Laboratory with single sign-on to EMR application, given appropriate authorization. |
| 28. |
| The application shall have the capability to interface with Sapphire-Health (Diamond Pharmacy Services) Pharmacy System with single sign-on to EMR application, given appropriate authorization. |
| 29. |
| The application shall have the capability to interface with select hospital EMR systems (e.g., Somerset) to allow authorized users to view and capture relevant patient information pertaining to hospital encounters. |
| 30. |
| The contractor shall utilize the WsInmDemoData web service for offender demographic data. |
| 31. |
| The contractor shall have the ability to customize any such interfaces with DOC systems to allow for modifications if and when the DOC systems are replaced by the Integrated Offender Case Management System (IOCMS), which is dependent upon implementation timeframes of the EMR and IOCMS. |
Summary Record of Care
| 32. |
| The application shall have the capability to present summarized views and reports of the patient’s comprehensive EMR or a subset of it, based on sort and filter controls for date/date range, problem, or other clinical parameters. |
| 33. |
| The application shall have the capability generate/print (upon request), a configurable set of patient health information (for example: demographics, current problem list, medication history, history and physical, etc. |
Preferences, Directives, Consents, and Authorizations
| 34. |
| The application shall have the capability to receive/import and make available for clinical decisions patient preferences such as language, religion, spiritual practices, and culture. |
| 35. |
| The application shall have the capability to indicate that an advance directive, living will, durable power of attorney, preferred intervention for known conditions, and/or Do Not Resuscitate Order” exists for patient. |
| 36. |
| The application shall have the capability to indicate that a patient has refused to provide consents and/or authorizations for treatment. |
| 37. |
| The application shall have the capability to document an assent for patients legally unable to consent. |
| 38. |
| The application shall have the capability to view, electronically complete, and print (when necessary) consent and authorization forms. |
Summary Lists
| 39. |
| The application shall have the capability to capture true allergy, intolerance, and adverse reaction to drug, dietary or environmental triggers as unique, discrete entries. |
| 40. |
| The application shall have the capability to deactivate allergy, intolerance, and/or adverse reaction to drug, dietary or environmental triggers as unique, and note reason for deactivation. |
| 41. |
| The application shall have the capability to capture an allergic reaction/intolerance reaction type. |
| 42. |
| The application shall have the capability to capture, display and report patient-specific medication lists. |
| 43. |
| The application shall have the capability to present and print the current medication lists associated with a patient. |
| 44. |
| The application shall have the capability to present the medication history associated with a patient. |
| 45. |
| The application shall have the capability to mark a medication as erroneously captured and excluded from the presentation of current medications. |
| 46. |
| The application shall have the capability to capture, display and report all active problems (completed with date of onset for each) associated with a patient. |
| 47. |
| The application shall have the capability to capture, display and report a history of all problems associated with a patient. |
| 48. |
| The application shall have the capability to capture the source, date and time of all modifications made to the problem list. |
| 49. |
| The application shall have the capability to deactivate a problem. |
| 50. |
| The application shall have the capability to capture, display and report all immunizations associated with a patient. |
| 51. |
| The application shall have the capability to record as discrete data elements data associated with any immunization given including date, type, lot number and manufacturer, including the name of the administrator. |
| 52. |
| The application shall have the capability to display/print a patient-level summary of prior visit physician order status with clickable links to lab results, consultative reports, diagnostic test results, etc. |
Assessments
| 53. |
| The application shall have the capability to create assessments. |
| 54. |
| The application shall have the capability to document using standard assessments germane to the age, gender, developmental state, and health condition as appropriate. |
| 55. |
| The application shall have the capability to access the standard assessment in the patient record. |
| 56. |
| The application shall have the capability to update the problem list by activating new problems and deactivating old problems as identified by conduct of standard assessments. |
| 57. |
| The application shall have the capability to access health assessment data in the patient record. |
| 58. |
| The application shall have the capability to create standard assessments that correspond to the problem list. |
| 59. |
| The application shall have the capability to document reason codes for failure to complete mandatory medical/mental health screening due to inmate non-responsiveness or other causes. |
Treatment Plans, Guidelines, and Protocols
| 60. |
| The application shall have the capability to present current guidelines and protocols to clinicians who are creating plans for treatment and care. |
| 61. |
| The application shall have the capability to capture patient-specific plans of care and treatment. |
| 62. |
| The application shall have the capability to create and use site-specific care plans, protocols and |
guidelines.
| 63. |
| The application shall have the capability to identify, track and provide alerts, notifications and reports about variances from standard treatment plans, guidelines and protocols. |
| 64. |
| The application shall have the capability to identify patients eligible for healthcare management protocols based on criteria identified within the protocol. |
| 65. |
| The application shall have the capability to audit compliance of selected groups that are the subjects of healthcare management protocols. |
| 66. |
| The application shall have the capability to view and print the patient treatment plan generated from the current visit, including in-house and outside referrals, medications, care instructions, etc. |
| 67. |
| The application shall have the capability to support the use of standardized protocols and Nursing Evaluation Tools to drive clinical workflow. |
Orders, Referrals, and Care Management
| 68. |
| The application shall have the capability to capture non-medication patient care orders, including orders for diagnostic tests, and track the status of them. |
| 69. |
| The application shall have the capability to communicate orders including supporting detailed documentation to the service provider of the diagnostic test. |
| 70. |
| The application shall have the capability to capture and communicate referral(s)with supporting clinical details to other care provider(s), whether internal or external to the organization. |
| 71. |
| The application shall have the capability to present captured referral information and note reflect completion of a referral appointment. |
| 72. |
| The application shall have the capability to present order set(s) and order from them at the patient level. |
| 73. |
| The application shall have the capability to create order set templates and maintain them, including version control. |
| 74. |
| The application shall have the capability to identify required order entry components and present an alert or error message if required information is missing. |
| 75. |
| The application shall have the capability to present alerts for a result that is outside of a normal value range. |
| 76. |
| The application shall have the capability to Capability to evaluate pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam). |
| 77. |
| The application shall have the capability to allow clinical, administrative data, diagnostic, and procedure results to be transmitted to the referral clinician. |
| 78. |
| The application shall have the capability to present recommendations for potential referrals based on patient condition and/or diagnosis(es). |
| 79. |
| The application shall have the capability to present information necessary to correctly identify the patient and accurately identify the specimen to be collected including, but not limited to, patient name, specimen type, specimen source, means of collection, date and time. |
| 80. |
| The application shall have the capability to report variation between the type of specimen order placed and actual specimen received. |
| 81. |
| The application shall have the capability to present the details of specimen collection. |
| 82. |
| The application shall have the capability to support provider ordering workflow with configurable menus and screens, encounter checklists, etc. |
| 83. |
| The application shall have the capability to view a date specific (default is the current day) list of onsite and offsite referrals including the current status of each referral. |
| 84. |
| The application shall have the capability to include level of urgency notifications to designated authorized individuals that "critical" or "hypercritical" results have been received. |
| 85. |
| The application shall have the capability to allow for telephone orders and verbal orders. System shall ensure required signature within limits set by law. |
| 86. |
| The application shall have the capability to support electronic referrals for in-house Mental Health services in an institutional setting. |
| 87. |
| The application shall have the capability to support emergent, urgent and routine classification of electronic referrals for in-house Mental Health services. |
| 88. |
| The application shall have the capability to indicate a patient is on suicide watch, within the patient chart. |
| 89. |
| The application shall have the capability to support SOAP-E (education) clinical documentation format. |
| 90. |
| The application shall have the capability to consolidate physician orders into a separate section of the patient record for ease of access and viewing. |
| 91. |
| The application shall have the capability to support "sick call" requests and monitor/report the status of such requests. |
| 92. |
| The application shall have the capability to generate summary reports of patient referral information in support of communicating essential details to consultants and as needed for pre-authorization and utilization review. |
| 93. |
| The application shall have the capability to document reason codes for failure to complete mandatory medical/mental health screening due to inmate non-responsiveness or other causes. |
| 94. |
| The application shall have the capability to document reason codes for missed appointments to support referral tracking and accurate performance measurement. |
| 95. |
| The application shall have the capability to display reminders for events that require compliance with performance intervals per DOC business rules. |
| 96. |
| The application shall have the capability to identify patients on the institutional mental health services roster; for example, label all infirmary discharges and make them distinct on the caseload list. |
| 97. |
| The application shall have the capability to track frequency and type (emergency, urgent, routine) of sick call request by patient. |
| 98. |
| The application shall have the capability to access medical and mental health record, including |
medications and communicable disease test results, to support restorative/transitional and discharge planning in an institutional setting.
| 99. |
| The application shall have the capability to access patient referral history of outside treatment. |
| 100. |
| The application shall have the capability to look-up outcome reports and/or results of referrals and appointments. |
| 101. |
| The application shall have the capability to access patient referral history of outside treatment. |
| 102. |
| The application shall have the capability to refer patients for medical and mental health services with space for comments. |
| 103. |
| The application shall have the capability to create ad hoc referral forms. |
| 104. |
| The application shall have the capability to include data tags on reportable/communicable diseases and associated labs and ICD-9/10 codes to support auto-generation of communicable disease reports to DDC. |
| 105. |
| The application shall have the capability to support documentation of comprehensive gynecological services. |
Documentation of Care, Measurements, and Results
| 106. |
| The application shall have the capability to perform checking for potential adverse or allergic reactions for all immunizations when they are about to be given. |
| 107. |
| The application shall have the capability to capture immunization administration details, including date, type, lot number and manufacturer. |
| 108. |
| The application shall have the capability to route numerical (e.g., lab results) and non-numerical (e.g. interpretive reports) test results to the appropriate provider. |
| 109. |
| The application shall have the capability to filter test/diagnostic results by any variable, such as patient, type of test and date range, results., etc. |
| 110. |
| The application shall have the capability to display numerical results in flow sheets, graphical form, and allow comparison of results. |
| 111. |
| The application shall have the capability to notify relevant providers (ordering provider, consulting provider, "copy to" providers) that new results have been received. |
| 112. |
| The application shall have the capability to capture patient vital signs such as blood pressure, temperature, heart rate, respiratory rate, and severity of pain as discrete elements of structured or unstructured data. |
| 113. |
| The application shall have the capability to capture psychiatric symptoms and daily functioning as structured or unstructured data. |
| 114. |
| The application shall have the capability for providers to annotate a result. |
| 115. |
| The application shall have the capability to capture other clinical measures such as peak expiratory flow rate, size of lesions, oxygen saturation, height, weight, and body mass index as discrete elements of structured or unstructured data. |
| 116. |
| The application shall have the capability to capture clinical documentation (henceforth "documentation") including original, update by amendment in order to correct, and addenda. |
| 117. |
| The application shall have the capability to associate documentation for a specific patient with a given event, such as an office visit, phone communication, e-mail consult, lab result, etc. |
| 118. |
| The application shall have the capability to capture free text documentation. |
| 119. |
| The application shall have the capability to view other documentation within the patient's logical record while creating documentation. |
| 120. |
| The application shall have the capability to attribute, record and display the name and credentials of all users contributing to or finalizing a document or note, including the date and time of entry. |
| 121. |
| The application shall have the capability to support documentation of dental services according to standards set forth by the American Dental Association. |
| 122. |
| The application shall have the capability to capture/store/display consultative reports. |
| 123. |
| The application shall have the capability to reproduce and display a variety of configurable forms to support clinical documentation for a relevant set of treatments and interventions. |
| 124. |
| The application shall have the capability to pre-populate a configurable set of standard forms with relevant patient-level information. |
| 125. |
| The application shall have the capability to capture, store, and display the results of onsite laboratory testing, e.g., Accuchek, urinanalysis, rapid HIV testing, other. |
| 126. |
| The application shall have the capability to support documentation of all medical and surgical, dental, and mental health services. |
| 127. |
| The application shall have the capability to support mass vaccination clinics. |
| 128. |
| The application shall have the capability to provide a progress note template that includes space for entering performed and planned procedures. |
| 129. |
| The application shall have the capability to automatically update other sections of the record with data entered in the progress note. |
| 130. |
| The application shall have the capability to toggle among relevant sections of the active medical record to support SOAP-format documentation. |
| 131. |
| The application shall have the capability to prompt a user for electronic signature on a progress note at the conclusion of an encounter and prevent user from continuing until signature is provided. |
| 132. |
| The application shall have the capability to support barcode scanning as an input device. |
| 133. |
| The application shall have the capability to capture provider credentialing information, e.g., DEA, NPI, license numbers. |
| 134. |
| The application shall have the capability to trigger an alert upon documentation of diagnoses or events required to be reported to outside agencies including the city and state departments of Health and/or Centers for Disease Control and Prevention (CDC) and to notify the ordering provider of the report requirement fulfillment. |
| 135. |
| The application shall have the capability to present information collected from medical devices as part of the medical record as appropriate. |
| 136. |
| The application shall have the capability to document and capture dates and results of TST plants, reads, and TB reviews. |
Health Information Management/Clinical Decision Support
| 137. |
| The application shall have the capability to populate the patient record with the timestamp for "inmate received" from offender management system. |
| 138. |
| The application shall have the capability to support business rules which enforce specific Correctional Certification and DOC business/clinical requirements. |
| 139. |
| The application shall have the capability to provide normal ranges for data based on age and other parameters such as height, weight, ethnic background, gestational age. |
| 140. |
| The application shall have the capability to capture clinical decision support prompts and user decisions to accept or override those prompts. |
| 141. |
| The application shall have the capability to generate instructions pertinent to the patient based on clinical judgment. |
| 142. |
| The application shall have the capability to include details on further care such as follow up, return visits and appropriate timing of further care. |
| 143. |
| The application shall have the capability to prompt the provider with abnormal trends. |
| 144. |
| The application shall have the capability to provide data checking and error messages for critical values whereby entered values, e.g. body temperature, blood pressure, dates of birth, etc. are compared to a range of pre-set values to determine basic feasibility. An error message would be returned for infeasible values. |
| 145. |
| The application shall have the capability to support documentation of provider acknowledgement of alerts and results including capturing comments, e.g., patient refusal, patient advised, action taken, etc. |
| 146. |
| The application shall have the capability to provide notification of outstanding medical record documentation for a core set of configurable requirements. |
Health Maintenance and Preventive Care
| 147. |
| The application shall have the capability to establish criteria for the identification of preventive care and wellness services based on patient demographics (e.g., age, gender). |
| 148. |
| The application shall have the capability to present alerts to the provider of all patient specific preventive services that are due. |
| 149. |
| The application shall have the capability to modify established criteria that triggers alerts. |
This is the start of the file's text. The full file is on GovTribe.