iEHR Laboratory RFI solicitation

FI Lab Support  available at https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&id=ef198032296a94dc4f3ed2621e6c47e3

Solicitation 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

 

  1. PURPOSE

 

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.

 

2.0 BACKGROUND

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)

 

4.0 REQUIREMENTS

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
  • Printing
  • Tracking
  • 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
  • Deployment
  • Training Support:  Provide training materials and “super users” training to iEHR training community that can be leveraged for end user training. 
  • Documentation
  • 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. 
  • Sustainment

 

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.

 

5.0 DISCLAIMER

 

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:  millie.mitchell@tma.osd.mil and cornell.house@tma.osd.mil.   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.

 

  1. Accession Orders

 

 

 

  1. Prepare Specimen

 

 

  1. Analyze Test

 

 

  1. Validate Test Results

 

 

  1. Report Test Results

 

 


 

 

Appendix B Data Object Descriptions

 

 

Data Object Name

Data Object Description

Accession Label

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.

Delta Checks

Critical checks and other verification checks to ensure that the test was correct.

Notification

Messages sent to MHS, VHA and/or external site as required.

Order(s)

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.

Preliminary Results

Specimen/Test Order results sent out to provider

Preparation Information

Information to prepare a specimen per guidelines and SOP.

Provider Assigned

Provider Assigned is the staff member who is assigned to a specific task for completion.

Quality Control

Order reviewed for quality related concerns and updates made.

Reject Notification

Notification to the provider of the rejected fill request, based on business rules (provider may not be notified of all rejections).

Specimen

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)

Specimen Analysis

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

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.

Test Results

Results of the analysis.

 

 

QUESTIONS?

Application Architecture and Functionality

General Design

  1. Is your product extensible or has the ability to custom design plug-ins?  Do you provide a Software Development Kit (SDK)?
  2. Does your product use open source frameworks? What open source frameworks, if applicable, does your application utilize/support?
  3. Does your product have an API used between the presentation layer and the business layer.
  4. Please provide any additional architectural details that you feel will help us understand the design and functionality of your product.
  5. What type of database(s) does your product use?
  6. Does your product provide GUIs that are HL7 Clinical Context Object Workgroup (CCOW) compliant?
  7. Does your product’s GUI follow recognized user interface standards? If so, which ones?
  8. Is the user interface capable of being a portlet or widget in a portal framework?
  9. Tell us how you measure reliability, provide your historical reliability metrics, etc.
  10. How do you provide end to end performance support? i.e. from the initial engagement to the completion of the order.
  11. Give examples of what some of the services you will need to interface with an integrated electronic health record such as orders, alerts.

Licenses

  1. What is your licensing structure?
  2. Would the IPO be required to separately obtain licenses through third party vendors?
  3. How are licenses structured for maintenance and support for future releases?  Is there any cost adjustments for major or minor upgrades?
  4. 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?
  5. Are there limits to the number of facilities/users that are accessing the system at any given time, before seeing degrades in performance?
  6. Interfacing/Data Sharing
  7. Does the product have standard, documented interfaces and support for interfaces?
  8. Does your product have an ability to interface with an external clinical record service that serves as the authoritative source of patient laboratory information?
  9. Does your product have an ability to interface with an external patient demographics service that serves as the authoritative source of patient demographic information?
  10. 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?
  11. Is the database(s) configured as distributed or centralized?
  12. Does your system support report generation at local and enterprise levels?

Security

  1. "How does your software handle the following?
    • Single Sign-On
    • Identification/authenticity
    • Data confidentiality
    • Data integrity
    • Authorization"
  2. Does your software adhere to any security standards?
  3. Do you use any third party or open source security solutions, and if so, which ones?
  4. Does your product store security and audit logs on a separate system?
  5. Does your product provide support for integrating into any specific privacy, security or Public Key Infrastructure (PKI) environment? If so, what capabilities are provided?
  6. Can your system support patient identity management provided thorugh an ESB/SOA service and patient information passed via a web-service?
  7. "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)?
  8. How many types of access controls can be supported?"
  9. Does your product support attribute-based access control (ABAC)?
  10. What type of code checking and security scanning do you peform on your product?

Support

  1. 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.
  2. How long do you plan on offering support for the current version of the software?
  3. Will new releases of the software be backwards compatible?  If not, please describe your typical upgrade path in detail.
  4. 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)?
  5. 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.
  6. How are software defects discovered, reported and corrected?
  7. What is your current release cycle? Describe past history release cycles. Describe the anticipated future release cycle.
  8. Are there any third party licenses required for your product? If so, please list them
  9. Deployment Architecture and Functionality
  10. Implementation
  11. 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?
  12. Discuss potential deployment environments, for instance application servers, Type 1 Hypervisor compatibility, operating systems, etc.
  13. Is your application compatible with thin computing technologies to include streaming, virtualization, and server process (thin clients)?
  14. 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.
  15. 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.

System Performance

  1. Is your product scalable?  Please give examples of your smallest and largest installations.
  2. What are the bandwidth characteristics of the application?
  3. What are the performance characteristics or requirements of the middleware, if applicable?
  4. Downtime
  5. What methods are used by the system to ensure 24/7 access to functionality and data and what is the recommended disaster recovery solution?
  6. If redundancy is used in the architecture, how long does it take for a failover to occur?
  7. 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?
  8. Compatibility with Operating Environment
  9. What operating systems, database management systems,  application platforms, scripting languages, and Web browsers does your  product(s) support?
  10. Describe how your product(s) operates in a Web-client environment with transaction computing, flexibility in deployment, without a high sensitivity to WAN latency.

Misc

  1. List contracts vehicles this capability can be reached as you, the proposer, as the prime.
like0

Comments

FROM NextGov

Stephen Hufnagel's picture

FROM NextGov http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-system-managing-medical-tests/56302/

The Defense and Veterans Affairs departments have decided to focus on commercial products for a system to track laboratory work such as blood tests within their integrated electronic health record.

In a request for information issued Tuesday, the Military Health System asked potential vendors to provide information on developing a lab information capability that includes commercial off-the-shelf products.

VA Secretary Eric Shinseki and Roger Baker, the department’s chief information officer, have backed using open source software for the iEHR, which will cost $4 billion to develop and is slated for deployment in 2017. On June 5, VA issued an RFI for an iEHR pharmacy system based on commercial products.

MHS said it would prefer to host the lab system in a vendor data center and government data centers would be its second choice. A draft blueprint for the iEHR that Nextgov obtained said the future health record data infrastructure will end up as a hybrid of public and private data centers.

The pharmacy and lab systems are the first clinical applications that will be incorporated into an early version of the iEHR planned for deployment at Defense and VA hospitals in San Antonio and Norfolk, Va., in 2014.

MHS said it is interested in turnkey system from a vendor that provides all management support, operations and maintenance, system security, and network connection and application management support.

The joint laboratory system will manage lab test orders -- primarily for blood tests -- specimen collection, and processing and reporting of results. It also will incorporate an anatomic pathology system to handle information from biopsy tests and electron microscopes.

The iEHR lab system should be able to manage complex testing work flows; promptly format and deliver laboratory results to clinicians; manage storage, tracking and distribution of specimens; and support automated instrumentation, the RFI said. Lab results must flow into individual patient records. These records must include every test, potential diagnosis, type of specimen collected and time the specimen was collected.

Interested vendors should reply to the RFI by July 12.

like0

iEHR Laboratory RFI solicitation

Nancy Anthracite's picture

This turnkey solution looks like a guarantee for vendor lock-in. How that can
be cost effective for government is beyond me. In the past, the VA was
careful to avoid vendor lock-in to avoid boxing itself into one solution. This
is a metal box with a high security lock!

Open source software is also key to avoiding vendor lock-in and allowing rapid
innovation, yet the probability of having a lab system that is open source and
ready to go for all of the requirements is slim to none.

I hope that Roger Baker's promise not to destroy the current functionality of
VistA will be be continued into the future by his successor or it is going to
make it tougher and tougher to keep costs down for those that don't have a 4
billion dollar budget.

--
Nancy Anthracite

On Monday, June 18, 2012, Stephen.Hufnagel wrote:
> FROM NextGov
> http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-system-
> managing-medical-tests/56302/ [1]
>
> The Defense and Veterans Affairs departments have decided to focus on
> commercial products for a system to track laboratory work such as blood
> tests within their integrated electronic health record.
>
> In a request for information [2] issued Tuesday, the Military Health System
> asked potential vendors to provide information on developing a lab
> information capability that includes commercial off-the-shelf products.
>
> /*VA Secretary Eric Shinseki and Roger Baker, the department’s chief
> information officer, have backed using open source software for the iEHR*/,
> which will cost $4 billion to develop and is slated for deployment in 2017.
> On June 5, VA issued an RFI [3] for an iEHR pharmacy system based on
> commercial products.
>
> MHS said it would prefer to host the lab system in a vendor data center and
> government data centers would be its second choice. A draft blueprint for
> the iEHR that /Nextgov/ obtained [4] said the future health record data
> infrastructure will end up as a hybrid of public and private data centers.
>
> The pharmacy and lab systems are the first clinical applications that will
> be incorporated into an early version of the iEHR planned for deployment
> at Defense and VA hospitals in San Antonio and Norfolk, Va., in 2014.
>
> MHS said it is interested in turnkey system from a vendor that provides all
> management support, operations and maintenance, system security, and
> network connection and application management support.
>
> The joint laboratory system will manage lab test orders -- primarily for
> blood tests -- specimen collection, and processing and reporting of
> results. It also will incorporate an anatomic pathology system to handle
> information from biopsy tests and electron microscopes.
>
> The iEHR lab system should be able to manage complex testing work flows;
> promptly format and deliver laboratory results to clinicians; manage
> storage, tracking and distribution of specimens; and support automated
> instrumentation, the RFI said. Lab results must flow into individual
> patient records. These records must include every test, potential
> diagnosis, type of specimen collected and time the specimen was collected.
>
> Interested vendors should reply to the RFI by July 12.
>
> --
> Full post:
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation [5]
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> [6]
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/793 [7]
>
> [1]
> http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-system
> -managing-medical-tests/56302/ [2]
> https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&id=
> ef198032296a94dc4f3ed2621e6c47e3 [3]
> http://www.nextgov.com/health/2012/06/vendor-tapped-without-competition-ke
> y-parts-defense-va-pharmacy-system/56091/?oref=ng-HPtopstory [4]
> http://www.nextgov.com/cloud-computing/2012/06/defense-va-integrated-elect
> ronic-health-record-could-use-commercial-cloud/56129/ [5]
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation [6]
> http://www.osehra.org/og_mailinglist/subscriptions
> [7] http://www.osehra.org/og_mailinglist/unsubscribe/793

like0

From "simplest" and "most adaptive" to "biggest" and "best"

Tom Munnecke's picture

It's interesting to see the evolution of these systems over the past decades.  We never had that kind of money to deal with.  The ENTIRE initial roll-out of the first version of VistA (DHCP at the time) cost $82 million for 172 hospitals (1985 dollars).  This included the CORE software packages. 

DoD was developing the TRIMIS modules at the time, and had spent $250 million to date.  These were utterly incompatible modules for scheduling, radiology, and pharmacy, running at independent sites at "Interim Operating Capability" levels (We renamed "IOC" to be "Incompatible Operating Capabilities.")  Making things work together was an afterthought, rather than a foundational principle as it was with the VistA metadata-driven approach.

George Timson and I frequently talked about designing a Volkswagen, not a Cadillac.  We wanted to be something that was "good enough" - and connected - rather than gold-plated, and disconnected from everything else.  We wanted to build an evolutionary system, capable of growing and evolving according to the feedback from our clinical users.  We cherished this close collaboration between the clinical and the geeks, and I think it is still a very critical aspect for future development.  P.S.  It is also very cheap.  Docs as employees volunteering their feedback are a whole lot cheaper that outside consultants trying to guess what the employees want.

I thought we were talking about open, agile development for the next generation.  I also thought that we had a lot of corporate experience going back 30 years, from the original software deployment, the organizational transformation that it triggered in Dr. Kizer's era, and all of the neat technology and communications tools and channels opening up to us today.  And looking forward to all the amazing things on the horizon, I thought that we could be in the forefront of large scale systems ready to adapt to mHealth, big Data, genomics, grid computing, personalized medicine, integrated research/clinical practice, and so many other developments.

It's really dissapointing to see the iEHR going backwards like this  It's as if it is continuing its old TRIMIS program, lusting after gold-plated piecemeal elements, with integration an afterthought.

I propose a theme song for iEHR:  Johnny Cash's "One Piece at at Time:

http://www.youtube.com/watch?v=sIuo0KIqD_E

[CHORUS]
I'd get it one piece at a time
And it wouldn't cost me a dime
You'll know it's me when I come through your town
I'm gonna ride around in style
I'm gonna drive everybody wild
'Cause I'll have the only one there is a round.

....

The first day I got me a fuel pump
And the next day I got me an engine and a trunk
Then I got me a transmission and all of the chrome
The little things I could get in my big lunchbox
Like nuts, an' bolts, and all four shocks
But the big stuff we snuck out in my buddy's mobile home.

....

Now, up to now my plan went all right
'Til we tried to put it all together one night
And that's when we noticed that something was definitely wrong.

....

The transmission was a '53
And the motor turned out to be a '73
And when we tried to put in the bolts all the holes were gone.

.....

So we drilled it out so that it would fit
And with a little bit of help with an A-daptor kit
We had that engine runnin' just like a song
Now the headlight' was another sight
We had two on the left and one on the right
But when we pulled out the switch all three of 'em come on.

....

But up there at the court house they didn't laugh
'Cause to type it up it took the whole staff
And when they got through the title weighed sixty pounds.

 

 

like0

iEHR Laboratory RFI solicitation

Stephen Hufnagel's picture

My sense is that the government is inclined to a commercial solution for ancillary services and open source for everything else ...

-----Original Message-----
From: Nancy Anthracite [mailto:nanthracite@earthlink.net]
Sent: Monday, June 18, 2012 11:00 AM
To: architecture@groups.osehra.org; hardhats@googlegroups.com
Cc: Stephen.Hufnagel
Subject: Re: [architecture] iEHR Laboratory RFI solicitation

This turnkey solution looks like a guarantee for vendor lock-in. How that can be cost effective for government is beyond me. In the past, the VA was careful to avoid vendor lock-in to avoid boxing itself into one solution. This is a metal box with a high security lock!

Open source software is also key to avoiding vendor lock-in and allowing rapid innovation, yet the probability of having a lab system that is open source and ready to go for all of the requirements is slim to none.

I hope that Roger Baker's promise not to destroy the current functionality of VistA will be be continued into the future by his successor or it is going to make it tougher and tougher to keep costs down for those that don't have a 4 billion dollar budget.

--
Nancy Anthracite

On Monday, June 18, 2012, Stephen.Hufnagel wrote:
> FROM NextGov
> http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-sy
> stem-
> managing-medical-tests/56302/ [1]
>
> The Defense and Veterans Affairs departments have decided to focus on
> commercial products for a system to track laboratory work such as
> blood tests within their integrated electronic health record.
>
> In a request for information [2] issued Tuesday, the Military Health
> System asked potential vendors to provide information on developing a
> lab information capability that includes commercial off-the-shelf products.
>
> /*VA Secretary Eric Shinseki and Roger Baker, the department’s chief
> information officer, have backed using open source software for the
> iEHR*/, which will cost $4 billion to develop and is slated for deployment in 2017.
> On June 5, VA issued an RFI [3] for an iEHR pharmacy system based on
> commercial products.
>
> MHS said it would prefer to host the lab system in a vendor data
> center and government data centers would be its second choice. A draft
> blueprint for the iEHR that /Nextgov/ obtained [4] said the future
> health record data infrastructure will end up as a hybrid of public and private data centers.
>
> The pharmacy and lab systems are the first clinical applications that
> will be incorporated into an early version of the iEHR planned for
> deployment at Defense and VA hospitals in San Antonio and Norfolk, Va., in 2014.
>
> MHS said it is interested in turnkey system from a vendor that
> provides all management support, operations and maintenance, system
> security, and network connection and application management support.
>
> The joint laboratory system will manage lab test orders -- primarily
> for blood tests -- specimen collection, and processing and reporting
> of results. It also will incorporate an anatomic pathology system to
> handle information from biopsy tests and electron microscopes.
>
> The iEHR lab system should be able to manage complex testing work
> flows; promptly format and deliver laboratory results to clinicians;
> manage storage, tracking and distribution of specimens; and support
> automated instrumentation, the RFI said. Lab results must flow into
> individual patient records. These records must include every test,
> potential diagnosis, type of specimen collected and time the specimen was collected.
>
> Interested vendors should reply to the RFI by July 12.
>
> --
> Full post:
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation [5]
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> [6]
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/793 [7]
>
> [1]
> http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-sy
> stem
> -managing-medical-tests/56302/ [2]
> https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&amp
> ;id=
> ef198032296a94dc4f3ed2621e6c47e3 [3]
> http://www.nextgov.com/health/2012/06/vendor-tapped-without-competitio
> n-ke y-parts-defense-va-pharmacy-system/56091/?oref=ng-HPtopstory [4]
> http://www.nextgov.com/cloud-computing/2012/06/defense-va-integrated-e
> lect ronic-health-record-could-use-commercial-cloud/56129/ [5]
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation [6]
> http://www.osehra.org/og_mailinglist/subscriptions
> [7] http://www.osehra.org/og_mailinglist/unsubscribe/793

like0

I think we should define our terms a bit better

Carol Monahan's picture

Hmmm. "My sense is that the government is inclined to a commercial solution for ancillary services and open source for everything else ..."

I know that Laboratory and Pharmacy have traditionally been referred to as "ancillary services", due to their secondary status with regard to the primary position of the physician, but in terms of an electronic medical record, "ancillary" needs to be reassessed. A truly "ancillary" service in the EHR world would be something that could be added or subtracted as the occasion demands - something not too important to the overall function or success of the operation. I think you'd get agreement if we were talking about things like smartphone apps that let clinicians check or adjust their appointment schedules, or interfaces that allow the use of particular brands of medical equipment.

For our purposes, Laboratory and Pharmacy are hardly "ancillary". A patient record that is removed from test results and medication records would be quite impoverished.

The beauty of an integral system is the depth of support that can be provided by active, connected data. Clinicians drove the development of VistA in the direction they did because they wanted to be able to see the status of the whole patient, with all of their test results and medications -  not just all in one place, but with the right connections being made. If administration of a particular medication indicates the need for a test, or vice versa, an integrated system with logic actively triggered by data (i.e. VistA) can provide that decision support automatically.

If medications are handled by one system, tests by another, and the main patient record by a third?The type of interfaces you'd need to build in order to get such unrelated, separately-developed systems to communicate with enough richness to rival even the current state of VistA would seem, well, implausible.

like0

iEHR Laboratory RFI solicitation

Peter Groen's picture

Again -

Perhaps it should be clarified whether a vendor can also bid an open source solution for which they they provide commercial support. Otherwise this could alienate the open source community and reflect massive hypocrisy on the part of VA management?! Think on this.

-----Original Message-----
From: Stephen Hufnagel <hufnagels@OSEHRA.org>
To: architecture <architecture@groups.osehra.org>
Sent: Mon, Jun 18, 2012 3:17 pm
Subject: RE: [architecture] iEHR Laboratory RFI solicitation

My sense is that the government is inclined to a commercial solution for
ancillary services and open source for everything else ...

-----Original Message-----
From: Nancy Anthracite [mailto:nanthracite@earthlink.net]
Sent: Monday, June 18, 2012 11:00 AM
To: architecture@groups.osehra.org; hardhats@googlegroups.com
Cc: Stephen.Hufnagel
Subject: Re: [architecture] iEHR Laboratory RFI solicitation

This turnkey solution looks like a guarantee for vendor lock-in. How that can
be cost effective for government is beyond me. In the past, the VA was careful
to avoid vendor lock-in to avoid boxing itself into one solution. This is a
metal box with a high security lock!

Open source software is also key to avoiding vendor lock-in and allowing rapid
innovation, yet the probability of having a lab system that is open source and
ready to go for all of the requirements is slim to none.

I hope that Roger Baker's promise not to destroy the current functionality of
VistA will be be continued into the future by his successor or it is going to
make it tougher and tougher to keep costs down for those that don't have a 4
billion dollar budget.

--
Nancy Anthracite

On Monday, June 18, 2012, Stephen.Hufnagel wrote:
> FROM NextGov
> http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-sy
> stem-
> managing-medical-tests/56302/ [1]
>
> The Defense and Veterans Affairs departments have decided to focus on
> commercial products for a system to track laboratory work such as
> blood tests within their integrated electronic health record.
>
> In a request for information [2] issued Tuesday, the Military Health
> System asked potential vendors to provide information on developing a
> lab information capability that includes commercial off-the-shelf products.
>
> /*VA Secretary Eric Shinseki and Roger Baker, the department’s chief
> information officer, have backed using open source software for the
> iEHR*/, which will cost $4 billion to develop and is slated for deployment in
2017.
> On June 5, VA issued an RFI [3] for an iEHR pharmacy system based on
> commercial products.
>
> MHS said it would prefer to host the lab system in a vendor data
> center and government data centers would be its second choice. A draft
> blueprint for the iEHR that /Nextgov/ obtained [4] said the future
> health record data infrastructure will end up as a hybrid of public and
private data centers.
>
> The pharmacy and lab systems are the first clinical applications that
> will be incorporated into an early version of the iEHR planned for
> deployment at Defense and VA hospitals in San Antonio and Norfolk, Va., in
2014.
>
> MHS said it is interested in turnkey system from a vendor that
> provides all management support, operations and maintenance, system
> security, and network connection and application management support.
>
> The joint laboratory system will manage lab test orders -- primarily
> for blood tests -- specimen collection, and processing and reporting
> of results. It also will incorporate an anatomic pathology system to
> handle information from biopsy tests and electron microscopes.
>
> The iEHR lab system should be able to manage complex testing work
> flows; promptly format and deliver laboratory results to clinicians;
> manage storage, tracking and distribution of specimens; and support
> automated instrumentation, the RFI said. Lab results must flow into
> individual patient records. These records must include every test,
> potential diagnosis, type of specimen collected and time the specimen was
collected.
>
> Interested vendors should reply to the RFI by July 12.
>
> --
> Full post:
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation [5]
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> [6]
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/793 [7]
>
> [1]
> http://www.nextgov.com/health/2012/06/defense-and-va-eye-commercial-sy
> stem
> -managing-medical-tests/56302/ [2]
> https://www.fbo.gov/index?s=opportunity&amp;mode=form&amp;tab=core&amp
> ;id=
> ef198032296a94dc4f3ed2621e6c47e3 [3]
> http://www.nextgov.com/health/2012/06/vendor-tapped-without-competitio
> n-ke y-parts-defense-va-pharmacy-system/56091/?oref=ng-HPtopstory [4]
> http://www.nextgov.com/cloud-computing/2012/06/defense-va-integrated-e
> lect ronic-health-record-could-use-commercial-cloud/56129/ [5]
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation [6]
> http://www.osehra.org/og_mailinglist/subscriptions
> [7] http://www.osehra.org/og_mailinglist/unsubscribe/793

--
Full post: http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/793

like0

iEHR Laboratory RFI solicitation

conor dowling's picture

Some of our concerns may be overblown. iEHR has no architecture as yet -
"Common presentation layer and GUIs for the same types of users and needs"
etc isn't architecture. It's beauty pagent stuff, "I like World Peace".

I read these RFI's as fishing to see what established vendors say when
various in-the-moment notions get thrown at them: "3M vocabularies", "cloud
hosting", "patient's full electronic health record" ... Based on responses,
the "architecture" will evolve.

The other pole that will evolve this "architecture" is all the data work
going on all over HHS and elsewhere - the government's no monolith. The
PCAST report is seeping in, driven by some very capable people. Substitute
"... a joint VA, DoD ..." into "any attempt to create a national health IT
ecosystem based on standardized record formats is doomed to failure" and
you see how applicable these notions are.

The rigid "best-of-breed apps", "one patient record model", "SOA-centric"
stuff will get its year or two to play but not much longer than that: "the
times, they are a (slowly) changin" (just adding to Tom's approach).

I think it more important to get a data-centric view of VistA right than
pigeonhole it piecemeal into the hopes of yesterday. VistA's made for what
will be common-sense soon enough.

On Mon, Jun 18, 2012 at 2:24 PM, VISTACarol <vistacarol@gmail.com> wrote:

> Hmmm. "My sense is that the government is inclined to a commercial
> solution for ancillary services and open source for everything else ..."
>
> An "ancillary service" would be something that can be added or subtracted
> as the occasion demands - something not too important to the overall
> function or success of the operation. I think you'd get agreement if we
> were talking about things like smartphone apps that lets clinicians check
> or adjust their appointment schedules, or interfaces that allow the use of
> particular brands of medical equipment.
>
> But Laboratory and Pharmacy are hardly "ancillary". A patient record that
> is in removed from test results and medication records would be quite
> impoverished.
>
> The beauty of an integral system is the depth of support that can be
> provided by active, connected data. Clinicians drove the development of
> VistA in the direction they did because they wanted to be able to see the
> status of the whole patient, with all of their test results and medications
> - not just all in one place, but with the right connections being made. If
> administration of a particular medication indicates the need for a test, or
> vice versa, an integrated system with logic actively triggered by data
> (i.e. VistA) can provide that decision support automatically.
>
> If medications are handled by one system, tests by another, and the main
> patient record by a third?The type of interfaces you'd need to build in
> order to get such unrelated, separately-developed systems to communicate
> with enough richness to rival even the current state of VistA would seem,
> well, implausible.
> --
> Full post:
> http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/793
>

like0

iEHR Laboratory RFI solicitation

Peter Groen's picture

I think quite a few people read a lot more into some of these 'strange' happening. There seem to have been a lot of little slipups where open source gets left out of press releases, speeches, architecture documents, RFI's, etc. It's become more than a coincidence. It has the feel of a planned effort to derail the open source strategy. That's the "impression" that is being created. Who might be orchestrating this? Who's doing the writing? And the review before they are released to the public? Kind of interesting to think about, investigate, and possibly report on in the news.

-----Original Message-----
From: Conor Dowling <conor-dowling@caregraf.com>
To: architecture <architecture@groups.osehra.org>
Sent: Mon, Jun 18, 2012 6:40 pm
Subject: Re: [architecture] iEHR Laboratory RFI solicitation

Some of our concerns may be overblown. iEHR has no architecture as yet - "Common presentation layer and GUIs for the same types of users and needs" etc isn't architecture. It's beauty pagent stuff, "I like World Peace".

I read these RFI's as fishing to see what established vendors say when various in-the-moment notions get thrown at them: "3M vocabularies", "cloud hosting", "patient's full electronic health record" ... Based on responses, the "architecture" will evolve.

The other pole that will evolve this "architecture" is all the data work going on all over HHS and elsewhere - the government's no monolith. The PCAST report is seeping in, driven by some very capable people. Substitute "... a joint VA, DoD ..." into "any attempt to create a national health IT ecosystem based on standardized record formats is doomed to failure" and you see how applicable these notions are.

The rigid "best-of-breed apps", "one patient record model", "SOA-centric" stuff will get its year or two to play but not much longer than that: "the times, they are a (slowly) changin" (just adding to Tom's approach).

I think it more important to get a data-centric view of VistA right than pigeonhole it piecemeal into the hopes of yesterday. VistA's made for what will be common-sense soon enough.

On Mon, Jun 18, 2012 at 2:24 PM, VISTACarol <vistacarol@gmail.com> wrote:

Hmmm. "My sense is that the government is inclined to a commercial solution for ancillary services and open source for everything else ..."
An "ancillary service" would be something that can be added or subtracted as the occasion demands - something not too important to the overall function or success of the operation. I think you'd get agreement if we were talking about things like smartphone apps that lets clinicians check or adjust their appointment schedules, or interfaces that allow the use of particular brands of medical equipment.
But Laboratory and Pharmacy are hardly "ancillary". A patient record that is in removed from test results and medication records would be quite impoverished.
The beauty of an integral system is the depth of support that can be provided by active, connected data. Clinicians drove the development of VistA in the direction they did because they wanted to be able to see the status of the whole patient, with all of their test results and medications - not just all in one place, but with the right connections being made. If administration of a particular medication indicates the need for a test, or vice versa, an integrated system with logic actively triggered by data (i.e. VistA) can provide that decision support automatically.
If medications are handled by one system, tests by another, and the main patient record by a third?The type of interfaces you'd need to build in order to get such unrelated, separately-developed systems to communicate with enough richness to rival even the current state of VistA would seem, well, implausible.

--
Full post: http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/793

--
Full post: http://www.osehra.org/discussion/iehr-laboratory-rfi-solicitation
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/793

like0