FI Lab Support available at https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&id=ef198032296a94dc4f3ed2621e6c47e3Solicitation Number: TMA-iEHR-RFI-06-2012Agency: Other Defense Agencies
Office: TRICARE Management Activity
Location: Contract Operations Division - Falls Church General InformationNotice Type: Sources SoughtPosted Date: June 12, 2012 Response Date: Jul 12, 2012 5:00 pm Eastern Archiving Policy: Automatic, 15 days after response dateArchive Date:July 27, 2012Original Set Aside: N/ASet Aside: N/AClassification Code:D -- Information technology services, including telecommunications servicesNAICS Code: 541 -- Professional, Scientific, and Technical Services/541511 -- Custom Computer Programming Services
This Request for Information (RFI) is to solicit preliminary information from vendors who can advise the Department of Defense (DoD) and the Department of Veterans Affairs (VA) on solutions for a critical need related to the integrated Electronic Health Record (iEHR) Clinical Laboratory and Anatomic Pathology initiative. A joint Laboratory Information System (LIS) is needed to support Clinical Laboratory and Anatomic Pathology business processes for DoD/VA. Currently DoD and VA manage lab test orders, specimen collection, processing and lab test results reporting using separate Information Technology (IT) systems, with separate data repositories and complex sharing processes that do not allow for access to full record of a patient’s laboratory results for clinical care. The goal of this initiative is to provide the ability for a joint DoD/VA lab system to enable lab services without any degradation to existing functionality. The system will provide access to the patient’s full electronic health record for clinical decision support to include but not be limited to receiving the specimen and/or test order, analyze, validate the results and report/notify providers. The results are also input into the patient’s iEHR health record and must be available enterprise wide.
THIS IS A REQUEST FOR INFORMATION IAW FAR 15.201(e). This notice is solely for market research and planning purposes and does not constitute a request for proposal, request for quote, or invitation for bid, nor does its issuance in any way restrict the Government to its ultimate acquisition approach. No award will be made from this Request for Information (RFI) and the Government will not pay for any effort expended in responding to this notice.
The Department of Defense (DoD) Military Healthcare System (MHS) and Department of Veterans Affairs (DoD/VA) is jointly implementing an integrated Electronic Health Record (iEHR) that allows for full interoperability of patient’s health care information between the two departments, in order to support the delivery of health care by 59 military hospitals and 152 VA hospitals. The use of multiple IT systems also leads to duplicative, non-associated documentation within an individual’s laboratory history, with the potential for unnecessary and duplicate tests, increased cost, inventory waste, and potential health care delivery issues.
3.0 iEHR ARCHITECTURE
DoD and VA have agreed upon an iEHR conceptual architecture characterized by many common elements. The architecture is intended to align with the Departments’ objectives to improve patient safety, clinician and patient satisfaction, and lower operating costs through joint investments in health IT. Table 1 contrasts the current state Departments health Information Technology architectures with the iEHR architecture. While previous both Departments have focused on interoperability between the each other, the iEHR architecture is a single unified architecture.
Current VA & DoD Health IT Architecture Characteristics
iEHR Architecture Characteristics
Separately maintained requirements, business models, and business process flows
Common requirements, business reference model and target process flows
Separate presentation layers and Graphic User Interfaces (GUIs) for the same types of users and needs
Common presentation layer and GUIs for the same types of users and needs
Separately developed and maintained IT applications and services. Often multiple systems providing the same functions and services.
Common Applications and Services, supplemented by Department-unique capabilities only if they service a truly Department-unique business function.
Separately maintained interface standards
(requires need for specially-constructed inter-Department interoperability systems)
Common interface standards
(eliminates need for specially constructed inter-Department interoperability systems)
Various infrastructure systems and connections developed to meet the needs of each developed system/function (i.e., few common services)
A Common Services Broker that is based on standards, distribution, loose coupling and business process representation. A set of common infrastructure services that includes an Enterprise Service Bus (ESB) and other common infrastructure services
Separate data centers
Common data centers
Independent information frameworks with some interoperability agreements developed and maintained for specific interoperability needs
Common information frameworks, limiting the long-term need for interoperability agreements and translation services
Disparate measures of effectiveness and performance
Common measures of effectiveness and performance
Table 1 Current State Health IT Architectures
Figure 1 provides a graphical representation of the iEHR conceptual architecture, and conveys many of the characteristics described above. The Common Services Broker and the associated common interface standards serve a key role of providing interconnections among the various applications and services. They also provide the Presentation/Common GUI with access to the various applications, services, and data. The common GUI and Common Services Broker play a vital role in the successful transition from the current state to the target iEHR state:
The Common GUI insulates the iEHR user community from the current complexity of multiple health IT systems that serve the same functions, and may be changing throughout the phases of the iEHR initiative. The common GUI also unifies the end user experience across the broad range of user communities (i.e., providers, specialists, support employees, patients/beneficiaries, and external partners). Unifying the end user experience facilitates the pursuit of common process flows as the iEHR initiative replaces various legacy systems.
The Common Services Broker, which will include an ESB and other infrastructure services, allows for multiple internal and external systems to exchange information with each other. The common services broker also exposes new systems to iEHR data and services in a consistent fashion (i.e., common interface standards, common information exchange standards, and common data standards).
Figure 1: iEHR Architecture
iEHR plans to achieve the objective architecture in phases. The Departments are currently establishing the Interagency Program Office (IPO) that will guide this long-term initiative. iEHR plans to leverage commercial components whenever possible and cost effective. Thus, in the near term, the iEHR enterprise will be characterized by a mix of commercial components and disparate DoD and VA legacy applications and services. In many cases, the Departments will have multiple applications providing similar business functions and data in the near term.
Figure 2: Proposed ESB/SOA capabilities
The iEHR is looking to use industry standards when communicating between the lab and other systems. Current standards are:
- 3M HDD, HITSP standards, meaningful use, HL 7 CCOW patient and user context
- Current Procedural Terminology (CPT-4)
- Health Level 7 (HL7) v2.5 and v2.5.1
- Health Level 7 (HL7) Clinical Document Architecture (CDA) Release 2.0
- HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1
- Health Level Seven (HL7) Version 3.0 Privacy Consent related specifications
- IETF, RFC 1305 Network Time Protocol (Version 3)
- International Classification of Diseases, 10th Revision, Clinical Modifications (ICD-10-CM)
- International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS)
- IHTSDO Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)
- Logical Observation Identifiers Names and Codes (LOINC)
- NUBC Uniform Bill Version 1992 (UB-92) Current UB Data Specification Manual Field 22, Patient Discharge Status, Codes
- OASIS Security Assertion Markup Language (SAML) Version 2.0
- OASIS WS-Trust Version 1.3
- OASIS WS-Federation Version 1.1
- OASIS eXtensible Access Control Markup Language (XACML) Version 2.0
- Unified Code for Units of Measure (UCUM)
The DoD/VA want to gather information from industry on establishing a Lab Capability that includes a Commercial of the Shelf (COTS) Clinical Laboratory and Anatomic Pathology System with a common services broker, utilizing common data standards, common interface standards, and a common data center which supports a secure and effective cloud computing model.
The goal is to gain knowledge of potentially qualified sources that can provide total life cycle support of this acquisition for the following: software and licensing, maintenance, integration, testing, training, accreditation, implementation and sustainment services. Requirements discussed below are discussed for functional requirements and professional services to support the functional capability discussed. The COTS product should leverage the iEHR Architecture as discussed in Section 3.0
The government is also interested in the capability of the Clinical Laboratory and Anatomic Pathology (AP) COTS vendor to host the COTS application in a data center and provide all systems management support according to agreed upon service level agreements, operations and maintenance, capacity planning, system security, network connectivity, testing support, test and training environments, and application management support; OR provide all systems management support according to agreed upon service level agreements, operations and maintenance, capacity planning, system security, network connectivity, testing support, test and training environments, and application management support for the Clinical Laboratory and Anatomic Pathology COTS application hosted in a government data center.
4.1 Functional Requirements
The Laboratory solution includes Clinical and Anatomic Pathology capabilities. This solution will support management tools, such as Patient, Clinical Order, Specimen, Quality Control, Reports, Training, Billing, and Materials management. It will also provide support for Clinical Studies, Microbiology, General Laboratory, Histopathology, Cytopathology, Autopsy Pathology, Surgical Pathology, Immunology and robust Interoperability. There are also specialized laboratories that are devoted to Molecular Diagnostics (viral load testing), Toxicology, Flow Cytometry, and Electron Microscopy. The Laboratory solution will leverage configurable tools to manage complex testing workflows; maintain regulatory compliance; enforce rules-based actions; promptly format and deliver laboratory results to providers by their preferred method; store, track, and distribute bio-specimen; manage accessioning and provide result review and verification; support automated instrumentation; and manage reporting and issues/query management for clinical and anatomic pathology specimens. The Laboratory solution shall interact with a blood bank system or other source to support orders for blood products or other biologics including discontinuance orders.
The Laboratory solution is used to request tests for patients, keep track of patient and specimen histories, and manage test results for patients and providers. Records must be kept of every laboratory test and includes patient information, potential diagnosis, the tests performed, type of specimen collected, time the specimen was collected, and any specific instructions or precautions. The entire laboratory history must be viewable in a patient's medical record. Patients are identified at the time of arrival and the specimens are uniquely identified that links specific specimens with the related patient. An additional function is support for specimen collection, which ensures the accuracy of specimen collection, and positive identification of the patient and specimen. The provider is notified in real-time of potential collection errors such as wrong patient, wrong specimen type, wrong means of collection, wrong site, and wrong date and time. Specimens taken at bedside in a hospital and sent to the laboratory also require proper identification within the capability. Laboratories may exist within hospitals or clinics, or may exist as separate facilities.
The Anatomic Pathology portion of the Laboratory solution includes the ability to analyze and process information on the diagnosis of diseases based on the examination of tissues and organs. It is a medical specialty that is concerned with the diagnosis of disease based on the gross, microscopic, chemical, immunologic, and molecular examination of organs, tissues, and whole bodies. Pathology and laboratory medicine services provide the principle medical diagnostic laboratory testing and transfusion functions, and set the standards for quality, test methods, and procedures for laboratory testing for patient care in the medical center and supported clinics, which may include deployed labs. This capability EXLUDES blood bank and transfusion.
The Anatomic Pathology capability shall interact with a blood bank system or other source to support orders for blood products or other biologics including discontinuance orders. Blood bank or other functionality that may come under jurisdictional law or other regulation (e.g. by the FDA in the United States) is not required; functional communication with such a system is required.
An additional function of the Anatomic Pathology capability is support for accurate specimen collection, which ensures the accuracy of specimen collection, and positive identification of the patient and specimen. The provider is notified in real‐time of potential collection errors such as wrong patient, wrong specimen type, wrong means of collection, wrong site, and wrong date and time.
4.1.1 High level functional process flow
Defined below are the six proposed process area high level overview of Laboratory Information System. Appendix A provides graphical view of each.
- Create Orders for tests-
An order may be placed electronically or paper based and will include essential information such as patient demographics; collection date; specimen description; the submitting physician’s name; and other physician contact information. Significant clinical data/diagnosis is expected, but does not constitute a specimen deficiency if not provided.
- Accession Orders:
When an order and the appropriate specimen(s) are received in the laboratory, the order will be acknowledged and accessioned to create unique specimen identification label(s) that links the specimen(s) to the patient order. The label will be placed on the specimen per policy. If an order is received without an accompanying specimen, the order will be acknowledged and accessioned to create unique specimen identification label(s) that links the specimen to the patient order. The specimen(s) will be collected and labeled per policy. If the specimen has already been accessioned, the laboratory receives the specimen into the laboratory. Specimens will be checked for acceptability prior to moving to the next step in the process. If they are not acceptable per policy they will be rejected and a notification will be sent that will indicate the rejection and the reason for rejection.
- Prepare Specimen: Prepare Specimen for Analysis
This process begins when a specimen has been accessioned and is ready to be processed. The Laboratory Staff prepares the specimen for the ordered test according to policy. Then the decision is made whether the specimen is to be processed in-house or sent out to an external laboratory. If it is to be processed in-house, a Pathologist or Cytologist will be assigned as appropriate per policy and the specimen will be forwarded for analysis. When the specimen is to be sent out for processing, it must be determined if the entire specimen will be sent out or just a portion of it creating a spit sample. The in-house portion of the split sample will be handled as aforementioned. Specimens to be sent out to an external laboratory will be shipped according to policy.
- Analyze Test: Represents the analysis of the test; entering of initial test results prior to validation and certification.
The Analyze Test process starts after specimen are processed. Laboratory staff identifies whether to perform a test on the specimen manually or on automated instrumentation.
If a manual test is required, the test is performed and the results are manually inputted into the system for validation and certification to be performed. When tests are performed on automated instrumentation the results may be entered either electronically or manually for validation and certification to be performed.
Test results may be returned/received from the external laboratory. Once the Laboratory Staff receives the test results it addresses whether the results of the test were electronically inputted into the system. If not, the results are manually inputted into the system for validation and certification. If the results are already in the system results proceed to validation.
- Validate Test Results: Check validity; check critical values, check reference ranges; May be performed manually or automated; enter results of the lab test; update order status.
The Validate Results process involves the evaluation of the established test results, to determine if any additional actions are required before certifying or finalizing the results. The Laboratory Staff reviews the results and may order reflex tests, perform quality control, issue preliminary test results, and/or perform delta checks. Ultimately, test results deemed acceptable are interpreted and certified in the system. Data/documentation flows in and out of the process based on activities performed, and may include intermediate, amended, appended, and final results.
- Report Test Results: Notify provider the results are available; enter discrepancy results
Upon certification, test results and other notifications must be reported appropriately. In some scenarios, certain requirements may necessitate immediate notification of the test result to the Provider. Alternatively, test results and/or other information are reported routinely. Throughout the Joint Report Results process, test results and notification data are created as outputs. An additional (secondary) order may be created or the order may be updated, if requested by the Provider. This marks the end of the Clinical and Anatomic Pathology process.
4.1.2 Lab Functional Requirements
- All modules supporting Clinical pathology and Anatomic Pathology should be configurable (i.e. specimen collection management, blood bank specimens, Accession management, orders management, quality control, quality assurance, data verification, specimen handling, microbiology system, point of care)
- Shall support multiple configurations across DoD/VA. Configure functionality to support multi-divisional sites so each lab site is unique. For example, multiple labs of various sizes may be located at a single geographic area, but need different and independent configurations.
- Configurable management of non-patient data such as referral, environmental, sterilizer, and research specimens/patients per each lab site
- Rules based configuration must be configurable per each lab site for each lab test
- Rules based alerts/notifications to providers and lab staff
- Rules based configuration for process flow and data verification One example would be a lab test reports within normal ranges, the results can be sent to the provider, but if the lab results are not in normal range, it must be validated prior to certification
- Order Management for all areas in lab that allows for manual and automatic entry, modification, merging, deletion, and cancellation of orders and all associated data
- Results management that allows for manual and automated entry, individual results entry, batch results entry, amended results, appended results, and intermediate and final results
- Ability to send alerts and notification to users using secure messaging , maintain a log of alerts sent.
- Quality Assurance System for all applicable clinical and anatomic pathology laboratory sections and areas
- Laboratory Information System Interfaces
- Site-to-site within the DoD and VA (e.g., orders placed at one location can be accessioned and resulted at another location, digital pathology systems, etc.)
- Commercial laboratories (e.g., orders placed at a DoD/VA site can be electronically forwarded to a commercial lab for testing and other non-organizational providers (e.g., outside providers).
- Results from the commercial laboratory can be electronically sent back to the DoD/VA site, and with other government laboratories.
- Print labels as needed or in batches, Labels shall print with a bar code that is compatible with all standard coding capabilities and interoperable
- Print from one lab to another lab, regardless of geographic location e.g. manifest
- Print reports and screen shots
- Tumor Registry
- Tissue tracking and management
- Track chain of custody of specimen(s)
- Track workload
- Tracking of Specimens from point of origin, to receipt, testing, storage and disposal of the specimen
- Comments field available for free text and canned comment documentation per lab test performed available during each of the process
- Edit checks for all data entry errors
- Online documentation (i.e help, procedure manuals, collection manuals, quality control, medical journals, knowledge database, previous results)
- Clinical Decision Support capability for functionality such as secondary testing, duplicate order checks, test utilization options
- Reports Generation
- Provide standard lab reports on a recurring schedule used daily, weekly, or monthly
- Provide ability to customize (ad hoc) lab reports
- The system shall comply with the Health Insurance Portability and Accountability Act (HIPAA). The system shall meet the Privacy and Security standards within Meaningful Use and comply with the requirements of the Nationwide Health Information Network (NwHIN).
- Support lab capability in a theater operations, that has minimal communication/connectivity
- Support lab capabilities aboard ships that have no communications while out to sea
- Communication only occur when ship is docked
- Additional Requirements
- HIPAA, Privacy and Security
- DoD Specific Requirement
4.1.3 Professional Services
The following Professional Services are required: Installation and Configuration, Development, Testing, Integration Support, Implementation, Documentation Requirements, Sustainment, and Training/SDKs.
- Project Management (Schedule, Communications, Risk, Quality Assurance)
- Architecture and Topology
- Implementation Management: Implementing the individual components of the Lab products.
- Accreditation Support: Support the iEHR in obtaining an Authority to Operate (ATO)
- Configuration Management of Configurable Items
- Change Management
- Environment Management
- Software and Systems Management
- Design, Configuration/Build
- Data Synchronization and Mapping
- Interface Services
- Integration Support: Working with an integrator to implement the Lab into the iEHR architecture.
- Testing: Provide support for initial lab capabilities testing in the iEHR infrastructure to validate lab works as designed. Continue to provide testing support as new capabilities are integrated into the iEHR to ensure the end to end functionality continues to perform as expected
- Release Management
- Training Support: Provide training materials and “super users” training to iEHR training community that can be leveraged for end user training.
- Maintenance and Support Services
- License Software Maintenance and Support
- Business Process and Accreditation Support
- Installation and Configuration: Setting up the Lab product, installing and configuring software at an enterprise level.
There is a requirement for support services in terms of personnel, product upgrades, and software enhancements. The potential vendor shall be capable of patching, accreditation, and sustainment from a DoD/VA perspective.
Interested vendors are requested to submit a maximum 10 page statement of their knowledge and capabilities to meet the following functional requirements, non-functional requirements, standards and perform the following:
In addition, please provide any other information you feel would be valuable in assessing the value/capability/applicability/service solution of the Lab capability in support of the iEHR Software Infrastructure Product Suite to develop the joint Department of Defense Military Healthcare System (MHS)/ Department of Veterans Affair (DoD/VA) IiEHR program.
This RFI is issued solely for information and planning purposes and does not constitute a solicitation. Neither unsolicited proposals nor any other kinds of offers will be considered in response to this RFI. Responses to this notice are not offers and will not be accepted by the Government to form a binding contract. Responders are solely responsible for all expenses associated with responding to this RFI. All information received in response to this RFI that is marked proprietary will be handled accordingly. Responses to the RFI will not be returned.
Interested parties are asked to respond to this RFI and submit a capability statement, recommended approaches, past experience with contracts of similar scope and magnitude, ORCA registration, and contract vehicles offered. No written solicitation document is available at this time. Telephone requests will not be honored. Potential offerors are requested to direct all questions via e-mail to the Point of Contact (POC) listed below in Section 6.0.
All responses should be complete; in 12-point font; and not exceed 10 pages total, including tables, graphics and appendices, but excludes attached excel spreadsheet. Please provide response to the specific question in the Excel spreadsheet. File size should not exceed 5MB unzipped.
Responses should state organizational experience with performing similar work in scope and magnitude, ability to meet initial proposed technical requirements and include all other pertinent procurement information, detailed description of the work, explanation of how work relates to potential future requirements, annual and total dollar value of contracts, contract number, points of contact and phone number, and list any other pertinent information which would enable the Government to assess the firm’s capabilities. Firms should also include information that demonstrates past performance history. An innovative but proven approach to providing product licensing and hardware, implementation and support services is the desired outcome. It is imperative that firms respond with the required information so that the capabilities and approaches can be assessed accurately and that they will receive a solicitation from the Government.
A Request for Proposal is anticipated which may result in a task order which includes services necessary for the Contractor to manage its own staff, resources, products, and schedules in performing work; however, the actual contract type has yet to be determined. This RFP is expected to be released in the near future.
Responses to this RFI are due by 4:00 PM EST on July 12, 2012. See Section 4.0 for further information. All feedback and information received may be used to determine the appropriate acquisition plan and strategy for possible future acquisitions. Please do not request a copy of a solicitation because one has not been completed at this time.
Responses to RFI: Please submit written responses via e-mail in Microsoft Office 2003 format by 4:00 PM EST on July 12, 2011. Please entitle the subject line: Company Name – Response – RFI iEHR Laboratory Capability
All responses must be sent to the following e-mail address: firstname.lastname@example.org and email@example.com. No hardcopies will be accepted. No inquiries on any potential future acquisition activities or timelines will be accepted.
Appendix A Processes Overview Charts
Prior to the following process flows the first step is to Create Orders for tests-
An order may be placed electronically or paper based and will include essential information such as patient demographics; collection date; specimen description; the submitting physician’s name; and other physician contact information. Significant clinical data/diagnosis is expected, but does not constitute a specimen deficiency if not provided.
- Accession Orders
- Prepare Specimen
- Analyze Test
- Validate Test Results
- Report Test Results
Appendix B Data Object Descriptions
Data Object Name
Data Object Description
Includes: Patient Name, Date/Time, Patient ID (Medical Record Number), Specimen Type, Specimen ID, Barcode
Certified Results of Specimen Analysis
Results that have been endorsed as to be true and accurate after specimen analysis
Clinical Decision Support Inputs
Clinical Decision Support Inputs link health observations, heath information, and health knowledge to influence health choices by clinicians for improved healthcare. Health information includes Reports, Policies, or Alert(s), which may be based on age, immunization schedule, and/or policy that a person should have an immunization.
Critical checks and other verification checks to ensure that the test was correct.
Messages sent to MHS, VHA and/or external site as required.
This refers to data generated by the execution of an order. The exact nature of the results depends on the type of order. If appropriate, consent and/or authorization information is also sent.
Clinical Laboratory: Update the order with the completion status & notes as needed.
ACCESSION: Additional tests and studies may be ordered if clinically indicated, and/or if required by regulation, and/or if requested by Service Medical Waiver Review Authority. These can be obtained from an MTF, Veteran Administration Medical Center (VAMC), or other contract facility (public or private). Occasionally, DoDMERB may request a particular test be conducted by MEPS.
Patient Health Record
This represents the entire health record of the patient. The information from an immunization that is updated in the Patient Health Record may include patient weight, lot number, manufacturer, etc.
Specimen/Test Order results sent out to provider
Information to prepare a specimen per guidelines and SOP.
Provider Assigned is the staff member who is assigned to a specific task for completion.
Order reviewed for quality related concerns and updates made.
Notification to the provider of the rejected fill request, based on business rules (provider may not be notified of all rejections).
Sample collected from patient either in the Lab or outside of Lab to be tested.
Specimen Analysis Guidance - Protocol(s)
Specimen Analysis Guidance - Protocol(s)
When a specimen is tested or analyzed.
Specimen Shipping Information
Information needed to ship specimen out for analysis.
Specimen Shipping List
Groups of specimen to be sent externally for processing.
Specimen Type (serum, etc)
Clinical Laboratory: Specimen Type (serum, urine, CSF,etc)
Test Order is signed by a licensed provider to perform a laboratory test. It is the order initiating the lab activity.
System downtime orders are created in one step with the results.
Results of the analysis.
Application Architecture and Functionality
- Is your product extensible or has the ability to custom design plug-ins? Do you provide a Software Development Kit (SDK)?
- Does your product use open source frameworks? What open source frameworks, if applicable, does your application utilize/support?
- Does your product have an API used between the presentation layer and the business layer.
- Please provide any additional architectural details that you feel will help us understand the design and functionality of your product.
- What type of database(s) does your product use?
- Does your product provide GUIs that are HL7 Clinical Context Object Workgroup (CCOW) compliant?
- Does your product’s GUI follow recognized user interface standards? If so, which ones?
- Is the user interface capable of being a portlet or widget in a portal framework?
- Tell us how you measure reliability, provide your historical reliability metrics, etc.
- How do you provide end to end performance support? i.e. from the initial engagement to the completion of the order.
- Give examples of what some of the services you will need to interface with an integrated electronic health record such as orders, alerts.
- What is your licensing structure?
- Would the IPO be required to separately obtain licenses through third party vendors?
- How are licenses structured for maintenance and support for future releases? Is there any cost adjustments for major or minor upgrades?
- Please describe application software, client access licensing structure as it pertains to user/device licensing model. In a thin client architecture with your application leased per user session, is the license released at the termination of each session and available for the next session request?
- Are there limits to the number of facilities/users that are accessing the system at any given time, before seeing degrades in performance?
- Interfacing/Data Sharing
- Does the product have standard, documented interfaces and support for interfaces?
- Does your product have an ability to interface with an external clinical record service that serves as the authoritative source of patient laboratory information?
- Does your product have an ability to interface with an external patient demographics service that serves as the authoritative source of patient demographic information?
- Does your product have an ability to interface with an external materiel management system that serves as the authoritative source for ordering and receipt of the pharmaceutical commodity?
- Is the database(s) configured as distributed or centralized?
- Does your system support report generation at local and enterprise levels?
- "How does your software handle the following?
- Single Sign-On
- Data confidentiality
- Data integrity
- Does your software adhere to any security standards?
- Do you use any third party or open source security solutions, and if so, which ones?
- Does your product store security and audit logs on a separate system?
- Does your product provide support for integrating into any specific privacy, security or Public Key Infrastructure (PKI) environment? If so, what capabilities are provided?
- Can your system support patient identity management provided thorugh an ESB/SOA service and patient information passed via a web-service?
- "How are user capabilities controlled in your product (i.e., what level of control is available for types of users and how are users authorized for different levels of system activities)?
- How many types of access controls can be supported?"
- Does your product support attribute-based access control (ABAC)?
- What type of code checking and security scanning do you peform on your product?
- Does your project have a new major version in development? Describe any planned changes in your product architecture (e.g., new APIs, supporting new platforms) for the next two years.
- How long do you plan on offering support for the current version of the software?
- Will new releases of the software be backwards compatible? If not, please describe your typical upgrade path in detail.
- How easy is your product modified to correct faults, improve performance or other attributes, adapt to a changed environment (like an upgraded OS or a new OS)?
- Describe any of your standard support packages that will provide support after the product is installed, deemed operational, and being used in a production environment.
- How are software defects discovered, reported and corrected?
- What is your current release cycle? Describe past history release cycles. Describe the anticipated future release cycle.
- Are there any third party licenses required for your product? If so, please list them
- Deployment Architecture and Functionality
- What is a typical deployment configuration? Include typical specifications of the configured systems used. What are the platforms of the equipment needed to make the system operational?
- Discuss potential deployment environments, for instance application servers, Type 1 Hypervisor compatibility, operating systems, etc.
- Is your application compatible with thin computing technologies to include streaming, virtualization, and server process (thin clients)?
- Provide information on database capacity and flexibility in your typical configuration. This information includes how much space is set up in the database for each table (i.e., number of records that each table can hold, etc.), flexibility in relation to database expansion, flexibility in database configuration processes and utilities.
- List types of tools that can be used to test your product(s) in an integrated environment. Can the following tools be used with your product to provide meaningful test results? Mercury Winrunner, Loadrunner, Wiley Introscope, Rational TestManager.
- Is your product scalable? Please give examples of your smallest and largest installations.
- What are the bandwidth characteristics of the application?
- What are the performance characteristics or requirements of the middleware, if applicable?
- What methods are used by the system to ensure 24/7 access to functionality and data and what is the recommended disaster recovery solution?
- If redundancy is used in the architecture, how long does it take for a failover to occur?
- What is the average downtime associated with routine system updates, support upgrades, maintenance, and backups? What is the frequency of system updates and/or backups?
- Compatibility with Operating Environment
- What operating systems, database management systems, application platforms, scripting languages, and Web browsers does your product(s) support?
- Describe how your product(s) operates in a Web-client environment with transaction computing, flexibility in deployment, without a high sensitivity to WAN latency.
- List contracts vehicles this capability can be reached as you, the proposer, as the prime.