Loren Data's SAM Daily™

FBO DAILY - FEDBIZOPPS ISSUE OF JULY 26, 2017 FBO #5724
SOLICITATION NOTICE

D -- Request for Information -- IHS HIT Modernization

Notice Date

7/24/2017
 

Notice Type

Cancellation
 

NAICS

541512 — Computer Systems Design Services
 

Contracting Office

Department of Health and Human Services, Indian Health Service, Division of Acquisition Policy, 801 Thompson, TMP 605, Rockville, Maryland, 20852, United States
 

ZIP Code

20852
 

Solicitation Number

17-236-SOL-00046
 

Archive Date

10/31/2017
 

Point of Contact

Paul B. Premoe, Phone: 3014434470
 

E-Mail Address

paul.premoe@ihs.gov
(paul.premoe@ihs.gov)
 

Small Business Set-Aside

N/A
 

Description

IHS HIT Modernization RFI Department of Health and Human Services (HHS) Indian Health Service (IHS) Office of Information and Technology (OIT) Request for Information (RFI) Reengineering of American Indian's & Alaska Native's Health IT Systems (RAINH) Program Management Office This Request for Information (RFI) is part of a special IHS exploratory market research effort called ‘Reengineering of American Indian's & Alaska Native's Health IT Systems' or ‘RAINH' to assess industry innovations and capabilities that might best address IHS' emerging enterprise healthcare delivery and modernization needs. This is not a Request for Proposal (RFP) and shall not be considered an Invitation for Bid (IB), or a Request for Task Execution Plan (RTEP). Additionally, there is no obligation on the part of IHS to acquire any products or services described in this RFI, nor are responders entitled to payment for direct or indirect costs that are incurred in responding to this RFI. Responders must also understand that a solicitation is not being issued at this time, and this notice shall not be construed as a commitment by IHS to issue a solicitation, nor does it restrict IHS to a particular acquisition approach. Any information provided by industry to IHS as a result of this RFI is strictly voluntary, responses will not be returned, nor will IHS reimburse for the information submitted. While the information obtained from industry responses to this RFI may be used for planning purposes, and/or in the development of an acquisition strategy and future RFP, there is no guarantee that any solicitations will result from this notice. No funds have been authorized, appropriated or received for this effort. Responders are responsible for sufficiently annotating proprietary, restricted or competition-sensitive information contained in their response. I. Introduction The Indian Health Service (IHS), an agency within the Department of Health and Human Services (DHHS) is responsible for providing federal health services to American Indians and Alaska Natives (AI/AN). The provision of health services to members of federally-recognized tribes grew out of the special government-to-government relationship between the federal government and Indian tribes. This relationship, established in 1787, is based on Article I, Section 8 of the Constitution, and has been given form and substance by numerous treaties, laws, Supreme Court decisions, and Executive Orders. The IHS is the principal federal health care provider and health advocate for Indian people, and its mission is to raise their physical, mental, social and spiritual health status to the highest level. The IHS provides a comprehensive health service delivery system for approximately 2.2 million American Indians and Alaska Natives who belong to 567 federally recognized tribes across 36 states. Further IHS profile information germane to this RFI can be found at https://www.ihs.gov/newsroom/factsheets/. Additional program expertise on all matters related to the Indian Self-Determination and Education Assistance Act, Public Law 93-638 as amended (ISDEA) can be found at https://www.bia.gov/WhoWeAre/. In execution of its mission, IHS develops and maintains a comprehensive integrated government-off-the-shelf (GOTS) health information system-of-systems which supports a broad range of clinical and business functions at IHS Federal, Tribal and Urban (I/T/U) hospitals and clinics across the United States. The Resource and Patient Management System (RPMS) is a distant cousin to both the Veterans Health Information Systems and Technology Architecture (VistA) in use at the Veterans Administration, and the Composite Health Care System (CHCS) used in DoD's Defense Health Administration (DHA), having been derived from the same legacy system and sharing many of the same infrastructure and business applications. The RPMS as currently deployed has a MUMPS (InterSystems Caché) database architecture and VA FileMan file structures. A number of graphical user interface (GUI) applications utilizing various languages ranging from Delphi to C#.NET have been developed to support certain business processes, while other applications retain legacy character-based interfaces. RPMS GUI applications principally use a two-tiered architecture utilizing broker-based remote procedure calls, although recent development has focused on a three-tier architecture using web services. HL7 is also currently used as a standard for transmitting data between HIT components such as Lab and Radiology. For more information on the portfolio of supported applications, visit: http://www.ihs.gov/RPMS/ Business functions supported by the RPMS include, but are not limited to: practice management, such as patient registration, scheduling, billing and accounts receivable, release of information; ancillary clinical applications, such as inpatient and outpatient pharmacy, e-prescribing of controlled substances (EPCS), laboratory, radiology, image archiving, consults and referrals, terminology, telemedicine/telehealth, women's care, dentistry, prenatal care, optometry, community care / purchase referred care (PRC); emergency department (ED); and point of care clinical applications for behavioral health, oral health, inpatient and ambulatory care; iCare, diabetes management; and reporting systems such as Clinical Reporting System (CRS), Uniform Data System (UDS), National Patient Information Reporting System (NIPRS) and others found online at the IHS website. Additional key capabilities include electronic medication administration record (eMAR) with bar code assisted technology (BCMA) for inpatient settings, EDs, and/or High Risk Infusion Clinics and Blood Banks; Consolidated Mail Outpatient Pharmacy (CMOP). The RPMS is certified as a Complete Electronic Health Record (EHR) for inpatient and ambulatory settings according to the 2014 version certification criteria published by the Office of the National Coordinator for Health Information Technology (ONCHIT). In recent years, the system has been extended to include a personal health record system (PHR), direct secure messaging, a health information exchange (HIE) service, master patient index (MPI), and supporting middleware services. Ref: https://www.healthit.gov/policy-researchers-implementers/about-onc-health-it-certification-program Though not an exhaustive list, additional system capabilities important to IHS are real-time query, immunization forecasting, Vaccine For Children's (VFC) program inventory tracking, well child, 2D barcoding for immunization administration and Vaccine Information Sheets, transport mechanism used to transport immunization data files, and automated data reporting and receipt of immunization history to and from the states; procedure tracking capabilities, such as Woman's Health (Pap and Mammogram), colon health, bone health, and hepatitis screening; disease specific modules that aid in the tracking and follow up of specific conditions such as diabetes; population health management for outpatients and inpatients - ability to follow by specific conditions, labs, communities, sex, age, referrals, and/or transfers; employee health tracking; security that allows for tracking of who, how, and when a patient's record is accessed (e.g., audit); availability and use of SNOMED Clinical Terms® for problem list documentation and search features; interface terminology with extensive unconditional and conditional maps SNOMED and ICD-10 for both problems and visit diagnoses, an inpatient admission, discharge, and tracking application (ADT); prenatal management, problem list, and tracking features; and case management functions (see http://www.ihs.gov/RPMS/ for additional capability sets). IHS's PRC Program (see https://www.ihs.gov/prc/ for additional information) is similar in many ways to other public health entity's purchased care / community care models; however, it is not an entitlement program. Typical medical and dental care provided at an IHS or tribal health care facility is called ‘Direct Care'. Each visit to a non-IHS health care provider or ‘Indirect Care' and the associated medical bill is considered distinct and must be examined individually to determine PRC eligibility. For example, a patient must meet residency, notification, medical priority of care and use of alternate resources requirements of 42 CFR 136.23, 136.24 and 136.61 in order to be eligible for PRC. In addition, there are referral and authorization processes around which IHS is contemplating further automating as part of this RFI, along with processes supporting third party billing or ‘Alternate Resources' such as Medicare, Medicaid, Veterans Affairs, Private Insurance, and charity. The IHS Health Information Technology (HIT) landscape further expands across the circa 567 sovereign nations to include multiple non-RPMS independently deployed commercial-off-the-shelf (COTS) EHRs such as NextGen, AllScripts, Cerner, Epic, Optum, Athena Health, Greenway Intergy, eClinicalWorks, and electronic dental records (EDR) such as Dentrix, making the ecosystem highly decentralized, highly rural, and at times low communications (‘low comm') or limited connectivity similar to DoD's theater. The challenge of both intra and interoperability becomes exponential given diversity and individuality of the instances, as well as rising operations and maintenance (O&M) costs that result from ‘one-off' instantiations, lack of standardization and configuration management. Over time, the architecture and complexity of IHS health IT systems, as well as their criticality to health care operations, have become one of the many catalysts for IHS to re-evaluate its current approach to software development and deliverance of health IT services to AI/AN stakeholders. To that end, IHS' RAINH objective is an effort to modernize, augment or replace RPMS legacy healthcare systems, including, but not limited to, its clinical, administrative, financial and HIT infrastructure. RAINH will address the current state of IHS, where multiple healthcare legacy systems and disparate data stores, developed over four+ decades, are in need of re-platforming, consolidation and modernization to ensure and enable sustainability, flexibility, intra/interoperability, patient data federation, population health, and clinical quality measures, toward improved continuity of care. The RAINH objective is researching both the architectural approaches and levels-of-effort required to deliver an end-to-end suite of next generation, federated, inpatient / outpatient solutions with modularized software components that would extend and accommodate an EHR-agnostic and device-agnostic design architecture that facilitates access to, provenance of, and sharing of common patient data no matter where that data resides. The implementation and hosting models would likely encompass a combination of on-premises, cloud-based, and other low comm innovations. Given the diversity of the types and sizes of healthcare facilities across IHS (ref source: https://www.ihs.gov/findhealthcare/ ), their varying degrees of connectivity/bandwidth, a ‘one-size-fits-all' COTS EHR approach is likely neither functionally nor economically feasible. This RFI seeks to discover ‘art-of-the-possible' practical COTS solutions (or a combination of COTS/GOTS and HIE) that holistically address IHS needs. II. Questions RFI respondent's input is solicited to the following questions below related to the above introduction along with your experience inside and outside public health settings. Based on the services, products and/or solutions your company offers, you are encouraged to first focus on the questions that highlight what you do best, then answer any others to the best of your ability where it makes sense. It is also understood that respondents may not have answers to each and every question. IHS Mission & Core Values 1. At the core of IHS' mission are people, partnerships, quality, resources; how would your solution(s) best support a Relationship-based Care model (patient centeredness, collegiality, and self-care). 2. How would your solution(s) best address key areas of Patient Engagement, Improving Patient Care, Clinical Care Management, Healthcare Operations Management, and Health and Operational Analytics - all of which contemplate a ‘Supply Chain' system? 3. How would your solution(s) facilitate access to care for AI/AN patients? Project Management/Program Management & SDLC 4. Please briefly describe your approach to project and program management in light of the IHS HIT ecosystem? Would it be any different than your standard approach to commercial or other government engagements? 5. Briefly describe your approach to integrated solution development (e.g., techniques, methodologies, DevOps, performance measures, automated regression testing, continuous integration and deployment (CI/CD))? 6. Given that the IHS environment encompasses multiple geographic and sovereign political boundaries, briefly describe your organization's experience and proposed approach to integration, implementation, and enterprise architecture (EA) across those boundaries. Practice Management 7. How would your solution(s) support practice management capabilities such as revenue generation, purchased referred care/community care processes and policies, financial reconciliation, collection procedures and policies that comply with federal law? 8. How would your solution(s) support a purchased referred care / community care (PRC/CC) paradigm that facilitates electronic patient data exchange both in and out of IHS? Ref sources: https://www.ihs.gov/prc/ 9. How would your solution(s) contemplate implementing an enterprise EDR across IHS as part of an overarching HIT solution? 10. Describe your proposed HIT solution(s) to provide behavioral health care across an IHS continuum? 11. Describe how your solution(s) might help eliminate suicide rates across AI/AN communities? 12. How would your solution(s) best compliment an iCare-style care coordination and management paradigm? 13. How would your HIT solution(s) address employee health in addition to IHS patient care? Clinical Decision Support & Quality Measures 14. How would your solution(s) best support Improvement Science, Quality Improvement, Data Analytics, and Quality Initiatives (e.g. Federal policies) such as the Quality Payment Program - MACRA. To that end, please describe how it addresses Advancing Care Information (ACI) Clinical Quality Measures (eCQM), Appropriate Use Criteria (AUC), and other related initiatives? Ref sources: https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/Value-Based-Programs/MACRA-MIPS-and-APMs/Proposed-rule-fact-sheet.pdf and https://www.youtube.com/watch?v=p0mBO9S7GL8 (slides 1 and 2) 15. How would your proposed HIT solution(s) support condition-specific/scenario-specific information to providers at the point of care (versus cognitive overload of information/data)? 16. AI/AN have different needs, issues, and stressors than the general US population; these issues vary between Indian Nations. Supporting solutions need to be robust in their ability to respond to these changing needs. To that end, please describe from an epidemiological perspective, the ability your solution(s) has/have to incorporate changes to EHRs based on advice from epidemiological evidence (e.g., decision support, added data fields, data monitoring). 17. Does your HIT solution(s) incorporate Natural Language Processing as a decision support tool (e.g., ability to aggregate and filter information based on groups of problems/conditions, which is helpful in filtered displays of information, as well as triggering decision support tools for multiple chronic conditions which are very common even amongst relatively young patients)? 18. Does your HIT solution(s) provide alerts when patient data indicates intervention is recommended? Can one access medical literature, clinical guidelines, etc., at the point of care? Ref source: https://www.healthit.gov/providers-professionals/implementation-resources/vendor-evaluation-matrix-tool 19. Please describe whether or not your solution(s) can accommodate the notion of a "visit wrapper" - i.e., the ability to display data entered during visit and relevant to visit (e.g., surgical history) with an option to "authenticate" where the system should be able to store metadata for each data element (e.g., "signed" if entered by user, "reviewed" if entered elsewhere, "authenticated" if required such as standing orders). 20. How would your solution(s) allow for storage of coded structured data for reuse in decision support, coding tools, etc. (e.g., elements of history and physical (H&P) would be set up as structured data with LOINC/SNOMED)? 21. How would your solution(s) provide or support an ‘adaptive computation and machine learning' enterprise interface terminology capability that includes: a) support of a standard code set; b) mappings of interface terminology to standard codes sets to support data capture, HIE, revenue cycle, and quality measures; c) capture/migration of IHS specific codes sets to a new interface terminology solution; and d) process for extension of the terminology? 22. Does your HIT solution(s) support use of flowsheets? 23. How would your HIT solution(s) and processes best support Usability? 24. Does your HIT solution(s) allow one to multi-task (e.g., create tasks, order labs, etc.) while charting? 25. Please list your solution(s) current ONCHIT certification status. What are your plans for future certification and where do you think the market is trending? 26. Describe plans to continue to upgrade system to meet regulatory standards to include Meaningful Use (MU) and Quality Payment Program requirements. Integration 27. How would your solution(s) integrate and/or co-exist with IHS deployed systems (e.g., RPMS, Cerner, Epic, VistA Imaging)? Or does your solution(s) dictate consolidation and migration around a single EHR instance and system of record? If so, please describe the rationale why only one? If not, please also describe why multiple EHRs could co-exist as part of IHS' HIT ecosystem? 28. Please provide a listing of all supported modules of your proposed HIT solution(s), including modules used for federal reporting; how would you map those to existing IHS needs, and how would it/they integrate with other HIT components if a part of the data flows or work flows? 29. What kinds of web-based services, other enterprise shared services, and/or application programming interfaces (APIs) does your solution(s) provide (e.g., open API platform)? 30. What kinds of web-based or other services must be present for your solution(s) to function properly and intra-operate across IHS, as well as interoperate with community care partners and public health entities? 31. Briefly describe how integration with various biomedical devices would be accomplished in the proposed solution. Will interface support be included in the base package, a one-time fee, and/or an increase in the recurring system charges? 32. Briefly describe the third party revenue capabilities of your solution(s). If included, has there been experience in integrating the system into federal accounting systems similar to the Unified Financial Management System (UFMS), and are there capabilities to integrate the system into other disparate accounting systems that may be in use at Tribal and Urban facilities? 33. Does your solution accommodate bi-directional interfaces for laboratory (in house testing and external reference lab) as well as radiology orders to and reports from an offsite radiologist? (Current interface configurations for lab/rad use HL7 standards.) Does your solution include an auto interface for laboratory test orders and results? 34. Describe any ePrescribing capability your HIT solution contains (e.g., any related certification, capability to transmit via existing e-Prescribing mechanisms, 2-factor authentication/multi-factor authentication (MFA), and/or single sign-on capabilities). Business Configurability 35. How does your solution(s) ensure 508 compliance for IHS users (e.g., 508 compliant vs 508 configurable)? 36. How would you define and to what degree would you describe your proposed HIT solution(s) as being ‘business configurable' versus ‘customizable'; to that end, what type of governance model would you propose IHS use with your solution(s) to optimize its business and IT efforts to improve speed to market for new functionality? 37. How would your solution(s) afford an ever-changing environment where federal mandates are issued with little lead time requiring changes to be made to business processes and/or IT solutions? 38. Does your HIT solution(s) offer the ability to enable/ disable specific components to adapt to the agency's need? General Innovation 39. How would your solution(s) accomplish clinical reconciliation (e.g., problem list, medications, allergies, immunizations, reminders) at the point of care and from disparate systems of record? How would you propose annotating a change, discrepancy or correction in a system of record other than your own (i.e., ‘write-back', e.g., correction to an erroneous allergy entry in another facility's system of record)? 40. Please describe what HIT innovations differentiate your solution(s) from others (e.g., leveraging a microservices architecture (MSA) that supports HIT standards such as FHIR?) 41. In light of public health EHR and HIT trends of late, what approach would you recommend IHS take with regards to its participation in the open source community (e.g., role in OSEHRA)? Will the solution(s) you propose participate in the open source community and if so, to what extent? 42. How would your HIT solution(s) accommodate a variety of form factors (e.g., device-agnostic capabilities that run on self-service kiosks, mobile devices, tablets)? Describe ease of integration with other proprietary COTS products? Describe the procurement and tech refresh approach to obtaining form factors such as patient check-in kiosks (e.g., leasing). 43. How would you best approach and describe the concept of ‘BYOE' (‘bring your own EHR')? 44. Given IHS' commitment to expanding and extending telemedicine services both inside and outside the IHS firewall, how would your solution(s) facilitate remote providers offering those services? 45. How would you approach the need for robust interface terminology services? Specifically address how you would approach mapping terms used for problems and visit diagnoses to SNOMED and ICD-10 that leverages reuse of data, minimizes user input, and accurately captures clinical data? 46. In your general opinion, please summarize what near-term/interim state or long-term HIT solution(s) you would recommend to be the best for IHS and why? Transition & Modernization 47. What RPMS components would you propose replacing in the course of implementing your solution(s), which one(s) would you modernize or keep and why, and what would that transition roadmap and timeline look like from your perspective? 48. What approach would you propose for the transition/migration from existing IHS instantiations to your solution(s) (e.g., data conversion, data migration, run legacy and COTS systems in parallel for x amount of time, data persistence)? 49. What (if any) data migration experience from a Mumps or NoSQL type database does your company have as part of your proposed solution(s)? Please provide one or more examples. 50. To what extent does your proposed solution(s) rely on paperless processes that reduces the need for printed material? 51. What alternatives to written signatures, such as the use of electronic signature pads, does your proposed solution(s) support? Infrastructure 52. How would your solution(s) provide high availability, high performance, scalability, and on-demand elasticity to serve large numbers of patients with millions of health record documents? 53. How would your solution(s) provide ideal HIT application performance and high-availability in a low comm and/or decentralized client environment? 54. How would your solution(s) provide enterprise microservices, data optimization, data federation, deduplication, aggregation and visualization to providers and administrative users on-demand, in real-time, and in high and low comm situations, even ‘no comm' disconnected states? 55. Does your proposed solution offer the ability to scale out (i.e., add new instances and load balance across them), and the ability to scale down (i.e., remove instances and remove them from the load balancer)? 56. How would you propose innovative ways and/or partnerships to introduce or increase broadband to highly rural communities through which enhanced healthcare can be delivered to AI/AN stakeholders, unemployment rates can be reduced, enriched education can be provided, and commerce can be expanded? Implementation 57. Where would your proposed HIT solution(s) operate (e.g., in-house data center, in a commercial data environment, in IHS, centralized, distributed, public cloud, private cloud)? How do you monitor bandwidth utilization for your customers; can you provide examples of reports, including context regarding the size of the engagement (e.g., number of employees, number of patients, minimum bandwidth between sites)? 58. How would data ownership be handled under your recommended HIT solution(s) (e.g., in the event IHS were to decide to move to a different solution)? 59. How would you operate, control, monitor and support the enterprise solution(s) given the diverse IHS ecosystem; what would a general service level agreement (SLA) look like in our case? Would the SLA recognize the sovereign nature of the Federal and Tribal governments that would be a party to those agreements? 60. Does your solution(s) allow for a consumption-based hosting model versus firm-fixed hosting fees? What services would be available in the event the organization could not appropriate funding at the time of renewal (e.g., Continuing Resolution or Government furlough of non-critical resources)? 61. How would your solution(s) handle a diverse user base that resides both inside and outside of the IHS firewall? 62. How would you propose innovative ways to provide both configuration and end user training for initial operating capability (IOC) and ongoing support? 63. How would clinical staff training be addressed as part of migrating to or adopting your proposed solution(s)? Interoperability & HIE 64. How will you ensure that your solution(s) is/are compliant with national HIE requirements, and describe how you would implement new document formats, handle variations in C32 and C-CDA documents, facilitate ‘data liquidity', and deal with exceptions (e.g., improperly formatted exchange records)? 65. How would your solution(s) facilitate the correlation of IHS patients with both internal and external partners, as well as discover and handle previously held correlations that were incorrect? 66. In addition to compliance, how would your solution(s) extend compatibility and interoperability of the standardized healthcare data framework and exchange standards promulgated by ONCHIT to enable the exchange of health data? 67. How would your solution(s) support the 21st Century Cures Act Trusted Exchange Framework and Common Agreement? What challenges/opportunities do you foresee and how would you propose IHS accommodate this initiative? Ref source: http://docs.house.gov/billsthisweek/20161128/CPRT-114-HPRT-RU00-SAHR34.pdf 68. Describe any active/live HIE solutions you have implemented across industry, the volume of data that has been exchanged, and what partners were involved (e.g., IHS healthcare entities). 69. How would your approach to HIT/HIE solution(s) extend the Office of the National Coordinator (ONC) model(s)? 70. How would your HIT solution(s) contemplate use of an MPI given IHS needs described throughout this RFI? 71. MU3/MACRA requires the use of new eRx message types to facilitate better patient care and safer processes; how would your solution(s) include expansion of current eRx functionality? 72. Does your HIT solution(s) provide a PHR capability; if so, to what degree is it integrated with other HIT components? Operations, Maintenance (O&M) & Support 73. What is your approach for incorporating IHS-specific change requests (CRs) to make continual enhancements to your solution(s); describe your product roadmap process and how IHS' CRs would be prioritized against other customer's CRs; and what is your ‘routine' cycle for issuing product updates and upgrades? 74. What level of flexibility is provided to the organization on national, regional or local levels to support the O&M of test environments for the purpose of providing local support, optimization and enhancement of the HIT solution(s)? 75. What is your approach to correcting software defects across the HIT continuum? 76. Describe the ideal integrated IT service management (ITSM) or Customer Relationship Management (CRM) solution to providing tiered level support to users in the field? 77. What type of knowledge management capabilities do you have as part of your ITSM or HIT solution(s)? 78. What are your response times to reported issues that require development or even questions/support tickets that do not necessarily require development, rather just general questions? 79. What features and functions does your proposed solution(s) provide related to application performance measurement and tuning? Business Intelligence (BI) & Analytics 80. Describe one or more proposed enterprise business intelligence and analytics solution(s) that would accommodate automated extract, transfer and load (ETL) capabilities, automated aggregation of data, visualization of data through dashboards, drill-down capabilities, and configurable views. 81. Would your proposed solution(s) be described as data virtualization or data visualization solution(s)? Describe in your opinion the differences between the two and which would be most cost effective for and beneficial to IHS. 82. Via what cloud service models is your BI solution available (e.g., Software-as-a-Service (SaaS), Data-as-a-Service (DaaS), Information-as-a-Service (IaaS), Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS))? 83. Are your data visualization schemas proprietary or would the government have flexibility to visualize that same data via other means outside of your solution(s) without incurring a cost? 84. Does your solution(s) have predictive analytic capabilities that could be used in an IHS healthcare setting? If so, what are the challenges you have experienced implementing such a capability? 85. Can the HIT solution(s) report summarize, de-identify data for public health, research, and other purposes as dictated by law? Security & Privacy 86. What have you done to ensure that data is encrypted in transit and at rest within your solution(s), and to what federal standards have you used to ‘harden' them? 87. Is/Are your proposed hosting solution(s) FedRAMP approved with HIPAA BAA, in process of approval, and if so, at what level(s); or would you need government sponsorship? 88. Is there a US Federal Government Access Point in place at your hosting facility/facilities? If not, are you in the process of implementing one? If one is in process, when is it expected to be in place? 89. Is your proposed hosting capability exclusive for the US Federal Government (physical or logical)? If not, what are the restrictions on the use of your infrastructure? 90. Is your proposed data center (DC) and computing services managed and operated by U.S. citizen staff and have the proper clearances for handling sensitive/Protected Health Information (PHI) and Personally Identifiable Information (PII)? In which states and countries are your DCs located, and what kind of physical security measures are in place? 91. What are the Continuity of Operations and Disaster Recovery (COOP/DR) capabilities for the proposed solution(s)? Does the contingency plan ensure our continuity of operations in the event that the provider becomes insolvent, is subject to a takeover by an entity that precludes FedRAMP approval, or similar event? 92. Describe any built-in special protective mechanisms of your HIT solution(s) (e.g., anti-malware, anti-virus) and how would it/they integrate with an IHS federal enterprise-grade security architecture? 93. Does your HIT solution(s) support E-Authentication (OMB 04-04 and NIST SP 800-63-3, Digital Identity Guidelines)? If so, please briefly describe. Ref source: http://csrc.nist.gov/groups/ST/eauthentication/ 94. Does your HIT solution(s) have an existing System Security Plan listing the appropriate security controls in place for maintaining the confidentiality, integrity and availability of data? 95. Describe the audit functions in your HIT solution(s) in terms of security and privacy including how the information can be used during investigation of reported incidents and eDiscovery. 96. Describe further how your product complies with HIPAA Privacy and Security Rules and other regulatory requirements (Joint Commission, CMS, and state and local laws). 97. Does your HIT solution(s) incorporate role-based access control (RBAC)? 98. Does the system(s) within your HIT solution(s) log all activity including user identity, time and function/change performed? 99. Provide the approximate number of FTEs within your organization dedicated to privacy and security activities compared with industry? 100. Describe your update and patching procedures for both host OS patches and your HIT solution(s). Do these procedures include a testing and approval process that must be followed prior to installation? 101. Does your system(s) within your HIT solution(s) allow for information input validation? If so, please describe how this is accomplished. 102. Does your system(s) within your HIT solution(s) generate error messages that provide information necessary for corrective actions without revealing information that could be exploited? Are these error messages revealed to personnel/roles designated by the buyer? 103. Describe your HIT solution's capability to flag or identify sensitive diagnoses, minors, and other information that should be segregated and handled with care. Risk Management 104. Do your HIT solution(s) licensing model(s) provide for perpetual use if the solution is abandoned by either party? 105. Describe the role(s) your HIT solution(s) would play as part of a wider enterprise risk management system. Based on your experience and lessons learned, describe what risk management approach would best fit IHS' HIT landscape. Investment & Cost 106. What other products would IHS need to acquire in order to implement your solution(s)? 107. What options do you have regarding available licensing models, what are your assumptions, and is there any flexibility built-in? 108. What additional investments would IHS need to contemplate in order to implement your solution(s) to ensure a smooth and comprehensive roll-out (e.g., training, deprecation, consolidation, data migration, help desk, O&M, ‘hidden costs')? 109. Would you recommend a data correlation and migration occur between old and new HIT solution(s), or would you recommend running legacy systems in parallel in a view-only mode? What are the associated costs, timeframes and challenges that you would anticipate in either case given IHS' environment? 110. How would your solution(s) help IHS meet and continue implementing OMB mandates in its day-to-day HIT operations (e.g., Federal Information Technology Acquisition Reform (FITARA))? 111. How would you propose ascertaining IHS' current hardware inventory and infrastructure needs to support your solution(s)? Past Performance 112. How long has your company been in the business of developing and marketing your HIT solution(s)? 113. Can you provide past performance references (including measurement metrics), dollar value, magnitude, and description of the scope of similar efforts? 114. Please describe your alliances and partnerships pertinent to this RFI. 115. Is/Are your solution(s) delivered, hosted (if applicable) and supported by the responding company, or a partner, such as a Value Added Reseller, third party Support Center, etc? Please provide detailed information about the partner(s) and the services provided. 116. Can you provide sample pricing for your recommended HIT solution(s)? 117. Would you be able to describe other customers' environments where your product(s)/solution(s) is/are successfully in operational use in medium-to-large integrated healthcare settings with a variety of clinic types (e.g., small satellite clinics, behavioral health clinics, medium diagnostic clinics, large hospitals)? 118. How many of your clients have achieved Patient Centered Medical Home Certification? Please provide at least 5 facilities and contact information. 119. Provide specific examples of tangible benefits (return on investment) that has been documented by other users/clients of your proposed system. III. Instructions for Submission RFI respondents are encouraged to provide responses and comments to all or a portion of the questions above. Questions can be answered either sequentially and/or annotated throughout your responses. Responses and comments may be utilized in the development of additions or modification to future draft RFP(s). Responses to the RFI must be submitted with the subject header ‘IHS HIT Modernization RFI Response' and ‘your company's name' to HITModernizationRFI@ihs.gov on or before August 11th, 2017 by 5:00 PM Eastern Time. No verbal responses will be accepted. Email responses should not exceed 25MB in size nor exceed a page count of 40 pages. Proprietary information may be submitted; however, RFI respondents are responsible for adequately marking proprietary, restricted or competition sensitive information contained in their response. All submissions will be protected from disclosure outside of the RAINH Program Office. In addition, RFI respondents should be aware that the RAINH Program Office may utilize HHS FFRDC contractor support personnel (under existing contract) to review responses and information submitted. This FFRDC entity and individual employees are bound contractually by Organizational Conflict of Interest (OCI) and non-disclosure agreements (NDAs) with respect to proprietary information, and will take all reasonable action necessary to preclude unauthorized use or disclosure of an RFI respondent's proprietary data. RFI responses MUST clearly state whether or not permission is granted allowing the FFRDC support contractors access to any proprietary information. Qualified vendors from the RFI evaluation results may receive an invitation to an upcoming IHS industry day to demonstrate capabilities and/or services described in their respective responses. Thank you in advance for your input to this process.
 

Web Link

FBO.gov Permalink
(https://www.fbo.gov/spg/HHS/IHS/AMB/17-236-SOL-00046/listing.html)
 

Record

SN04592886-W 20170726/170725085433-d2ac19e33af82519c211ac41a220079c (fbodaily.com)
 

Source

FedBizOpps Link to This Notice
(may not be valid after Archive Date)

---

| FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |