MODIFICATION
D -- RFI for Message Transformation Tool
- Notice Date
- 1/23/2008
- Notice Type
- Modification
- NAICS
- 518210
— Data Processing, Hosting, and Related Services
- Contracting Office
- Department of Veterans Affairs;Cleveland Business Center;Building 3, Second Floor;10000 Brecksville Road;Cleveland OH 44141
- ZIP Code
- 44141
- Solicitation Number
- V776-08-312
- Response Due
- 2/24/2008
- Archive Date
- 3/25/2008
- Point of Contact
- Jun Ji Contract Administrator 10000 Bay Pines Blvd, Bldg 2, Rm 336 Bay Pines, FL 33744-5005 Phone: 727-320-1817 Fax: 727-319-1110
- E-Mail Address
-
Email your questions to Contract Specialist
(jun.ji@va.gov)
- Small Business Set-Aside
- N/A
- Description
- Message Transformation Tool Request For Information - Details 1. Description THIS IS A REQUEST FOR INFORMATION (RFI) AND NOT A REQUEST FOR PROPOSAL (RFP) 2. Vendor Requirements Vendors shall provide detailed information about the features of their message transformation tools. If shortlisted, then the vendor is responsible for providing a demonstration of the tool. Vendors shall also provide information about how their tool will fit in with the existing Veteran Health Information Technology (VHIT) architecture. 3. Introduction Software Engineering and Integration (SE&I) is seeking a vendor for a commercial off the shelf (COTS) tool to provide message transformation of Health Level Seven (HL7) version 2.x messages from ER7 (delimited encoding) encoding to HL7 XML encoding and transformation of HL7 version 2.x messages from HL7 XML encoding to ER7 (delimited encoding). 4. Size of Organization As of December 30, 2004 , 157 medical centers and 869 ambulatory care and community based outpatient clinics. VA supports approximately 300 clinical laboratories. The demographic information pertaining to the size and function of these laboratories needs to be defined in order to develop the business model and determine the deployment strategy of the Laboratory System Re-engineering product. VA employs over 220,000 personnel with approximately 7,000 laboratory employees. 5. Details The message transformation tool should perform the following requirements are described below. Requirements Business Rationale The transformation tool shall support the transformation of messages that conform to the Health Level Seven (HL7) Standard. The Health Level Seven (HL7) Standard is one of the protocols supported by the messaging system. The transformation tool shall support the transformation of messages that conform to the National Council for Prescription Drug Programs (NCPDP) Standard. The National Council for Prescription Drug Programs (NCPDP) Standard is one of the protocols supported by the messaging system. The transformation tool shall support the transformation of messages that conform to the American Society for Testing and Materials (ASTM) Standard. The ASTM Standard is one of the protocols supported by the messaging system. The transformation tool shall support the transformation of messages that conform to the Digital Imaging and Communications in Medicine (DICOM) Standard. The DICOM Standard is one of the protocols supported by the messaging system. The transformation tool shall support the transformation of messages that conform to the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12 Electronic Data Interchange (EDI) Standard (the EDI X12 Standard). The EDI X12 Standard is one of the protocols supported by the messaging system. The transformation tool shall support the transformation of messages that conform to the Health Level Seven (HL7) Clinical Document Architecture (CDA) Standard. The HL7 CDA Standard is one of the protocols supported by the messaging system. The transformation tool shall transform fragmented messages. A single logical message to be physically split across multiple messages for transmission. The transformation tool must be able to provide perform transformations on messages that have been fragmented, which will probably involve assembling the single message from fragments, performing the transformation, and refragmenting the message for transport to the destination application.. The transformation tool shall transform batch messages. Some applications produce batch messages that may require transformation prior to delivery to a target application. The transformation tool shall perform datatype transformations when the datatype of an element in a message type to be transformed is different than the datatype required by the target message type. The datatype of an element may be different when the element is contained in different message types or message versions. The change in datatype of an element between the source message and target message must be accounted for in a transformation. The transformation tool shall perform logic-driven data manipulations (e.g., transformation of non-coded values to coded values, transformation between different coded value sets). Logic driven transformations are required to perform sophisticated transformations that are more elaborate than simple mapping of data between different formats. The transformation tool shall support the character delimiters contained in HL7 message headers (to include MSH, BHS, and FHS segments) in accordance with the HL7 standard. Support for HL7 character delimiters is necessary in order to correctly transform HL7 messages. The transformation tool shall support the specified character set and the alternate character set handling scheme specified in the HL7 Standard. Support for HL7 character sets is necessary in order to correctly transform HL7 messages. The transformation tool shall transform HL7 messages between different 2.x versions of the HL7 Standards. Since different applications use different 2.x versions of the HL7 Standard, the transformation tool must provide transformation services so that applications using different 2.x versions of HL7 can communicate with each other. The transformation tool shall transform HL7 version 2.x messages from ER7 (delimited encoding) encoding to HL7 XML encoding. Because some applications use ER7 encoding and DoD and some applications use the HL7 XML encoding, the transformation tool must provide transformation services so that applications and systems can communicate with one another. The transformation tool shall transform HL7 version 2.x messages from HL7 XML encoding to ER7 (delimited encoding). Because some applications and DoD use the HL7 XML encoding and some applications use ER7 encoding, the transformation tool must provide transformation services so that applications and systems can communicate with one another. The transformation tool shall support transformations that constrain and localize the HL7 Standard for a specific implementation. Constraints and localizations are used to extend HL7 message structures within the message production rules of the HL7 Standard (i.e., to define Z-segments). That is, the transformation tool must support implementation-specific (e.g., at different sites) transformations. The transformation tool shall import HL7 conformance profiles for use in validating and transforming HL7 messages. Conformance to a HL7 profile guarantees interoperability between applications exchanging HL7 messages. The transformation tool shall recognize the conformance statement id and apply the conformance statement id in the validation of HL7 message headers (to include MSH, BHS, and FHS segments.) Use of the conformance statement id ensures that the transformation tool uses the correct conformance profile in the validation of a HL7 message prior to an after performing a transformation on the message. The transformation tool shall validate that each message it receives is well-formed and compliant with the minimal requirements of the standard applicable to the type of message. Validation of the structure of messages for well-formedness provides an indication of invalid messages that will not be able to be transformed correctly. The transformation tool shall provide validation for messages in all of the protocols specified in the transformation tool requirements. The transformation tool shall validate a message to be transformed against a message profile prior to transforming the message and validate the message output from a transformation against a message profile after transforming the message. Validation against a message profile ensures that a message has all the attributes required to be transformed and that the message was properly transformed. The transformation tool shall generate an error for each message that fails validation against a message profile prior to being input to a transformation or after output from a transformation. Failure to validate is an error. The system in which the error occurred must generate an error for use by the messaging system to be handled in accordance with all of the error-handling requirements defined in the messaging system specification. The transformation tool shall be capable of interfacing with the transformation and content-enrichment service interfaces exposed by the messaging system. The transformation tool must interface with the messaging system in order to receive messages that require transformation and to deliver transformed messages to their destinations. The transformation tool shall run on a minimum of the Microsoft and Redhat Linux operating systems. The VA possesses hardware that runs Microsoft and Linux operating systems. The transformation tool shall run on a SUN solaris 10 platform. VBIT has a requirement to support the SUN solaris 10 platform. The transformation tool shall provide a graphical user interface to design the information mapping and transformations specified. Ideally the tool should be based on the Eclipse framework. Eclipse is the VA's IDE. Application developers need an interface, which is integrated into the Eclipse IDE that allows them to define transformations. The transformation tool shall provide user interfaces that are compliant with Section 508 of the Rehabilitation Act. Compliance with Section 508 of the Rehabilitation Act is a regulatory requirement. The transformation tool shall provide the capability to compress messages prior to sending the messages. The ability to compress messages is needed as a form of risk mitigation to handle future bandwidth problems. The transformation tool shall provide the capability to decompress compressed messages before delivering the messages to a receiving application. The ability to decompress compressed messages is a complementary requirement to the requirement to provide the capability to compress messages. The transformation tool shall provide a configurable message compression/decompression capability. The ability to configure the message compression/decompression capability is required to enable optimization of the use of message compression and decompression. Compression/decompression configuration also provides the capability to turn message compression and decompression on and off as appropriate. The transformation tool shall transform 100 HL7 messages between ER7 version 2.x and XML formats per second. A rate for performance of message transformations is required to ensure that message transformations do not bog down messaging system performance. Bi-directional transformation is required - "between" includes both transformation from ER7 version 2.x to XML and from XML to ER7 version 2.x. The transformation tool shall provide a reliability that enables the messaging system to provide 99.9 percent successful delivery of messages on the first try. A rate for successful delivery of messages is required to minimize the amount of error handling, and associated troubleshooting, required to operate the messaging system. The transformation tool reliability that supports a 99.9 percent reliability for the entire messaging system needs to be determined by a reliability expert. The transformation tool shall support failover to a backup component in support of the recovery of the failure of a component. The transformation tool must be able to adapt to failovers that the messaging system performs in order to continue operating in the event of hardware failures. The transformation tool shall provide documents for the planning, implementation, configuration, management, operation, and support of the messaging solution and its components. The system documents should also include accessible electronic documentation (which can be "standard" vendor offerings) for trouble-shooting and support and training materials for the management and operation of the solution components. These shall serve as input for a VA-specific system management guide, system operations guide, system configuration, system inventory, implementation plan, and migration plan. The documentation is required for VA to efficiently and effectively apply internal personnel resources toward the initial and continued implementation, configuration, operation, and support of the included systems. The transformation tool shall include vendor commitment to support deployed products and versions for a length of time advantageous to the Department. The acceptable amount of support time is a minimum of three years after purchase of any and all major components in the solution, pending purchase of option years of support. The transformation tool must have long-term value in terms of maintained supportability. The transformation tools shall support value set mapping (e.g. from local value sets to the standard value sets). Coded clinical and administrative concepts are often using local ad-hoc code sets. To ensure interoperability, these local codes must be mapped to code sets based on The transformation tools must be able to load message structure definitions encoded in XML using HL7 Message Profile schema The specification that describes the segments, fields, components, and subcomponents implemented in a specific The transformation tools must be able to transform HL7 ASCII encoded (ER7) messages to any XML format and to transform XML-encoded payloads to HL7 ER7. HL7 V2 messages are the way legacy systems exchange information with new systems that rely on CDA documents. XML-encoded HL7 Version 3 messages, or VHIM messages. Generalized Versioning Requirement Transformation tool must be configurable in order to manage multiple active versions of input and output domain messages and their respective transformations. The transformation tool shall include a user interface for importing mapping files. Tool shall have import facilities for mapping. VHIM, HL7, and other internal message structures will have multiple active versions being sent inside the VHA. In order to support the transformation, the tool must be configurable and flexible enough to identify messages version during runtime and select appropriate transformation based on message version. HL7 to VHIM mapping files are complex, vetted and ensured to be accurate. Rework of this mapping effort would be duplication of effort. Generalized Mapping Import requirement Transformation proprietary mapping language must be text based to support potential code generation solutions and automation to overall mapping development. Current transformations required are HL7 ER7 2.4 and 2.5 TO/FROM VHIM 4.x. The transformation tool should support released versions of HL7 and VHIM. Proprietary, if the tool can handle multiple version of XML schema. Multiple versions of inputs and multiple versions of outputs. VHA will have numerous messages defined along with transformations. In order to control the complexity and resource intensive activity of maintaining mapping logic, code generation and other potential automation solutions will be explored. The transformation tool will need to accept generated text as input to transformation runtime processing. The are more versions of HL7 that have been approved but not used in the VA. External data such as commercial off-the-shelf (COTs) products like lab may use HL7 v2.3 DoD may be upgrading to HL7 version 2.5.1. VHIM is planning on scheduled releases of VHIM. CDS plans to support multiple VHIM versions are they are released. The message transformation tool should be able to perform the transformation based on the runtime information. Versions or format of the target message may be arbitrarily depended on the client that receives the transformed message and so needs to be specified at runtime. The transformation tool should be able to split and reconstruct a message that can contain a single or multiple messages. e.g. A large message may need to be split into multiple pieces depending on the recipients. It may also need to reconstruct multiple messages prior to transforming the payload TO/FROM HL7 and VHIM. CHDR sends CDS a query that yields a large result set that spans domains (e.g. the complete medical record for a patient), CDS returns one large VHIM template (the result of the query) that spans domains, this VHIM template needs to be transformed into separate HL7 messages for each supported domain and wrapped into a batch response and returned to CHDR. Perform The transformation tools shall support message sizes of 40 MB XML and VHIM messages are 10 fold the size the HL7 ER7 messages. Perform The transformation tools shall take 30 milliseconds or less per transformation, with a transaction volume of 1000 per second for message size of 2.5 KB, with a maximum size of 500 KB for a single message. These are in a "flat file" format (HL7 ER7). Need to confirm from VHIM about XML message size. BHIE and Cheddar These are CDS performance requirements. Support of VistA 1.0 and the HDR project should expect high volume of messages and transformations. The transformation tool should be capable of participating in a distributed transaction. A transaction is a mechanism to ensure that transformation have occurred and sent or received by an application. The transformation tool should be deployable in a Continuation Of operations framework. Application to be able to participate in a 5-9 environment. The tool shall be available 24/7/365.5. 5-9 All SOA are required to have a COOP strategy. The Transformation shall return the status of a transformation with sufficient (recovery potential information) detail. The error detail in asynchronous message must be sufficient to allow correlation with the original message. The TS tool's integration requirements shall facilitate keeping the TS tool's performance independent from the messaging system's performance. This is to avoid TS tool performance loads or problems from critically impacting the remainder of the messaging system. For example, if the TS tool fails, it should not bring down the rest of the messaging system. The transformation process must support inbound HL7 2.x/ER7 encoded messages/content. VHA Enterprise Applications will continue to create HL7 2.x messages and the tool must support the message structure natively. The transformation process must support outbound HL7 2.x/ER7 encoded messages/content. VHA Enterprise will continue to have clients expecting HL7 2.x messages and the tool must support the message structure natively. The transformation process must support inbound XML messages/content The format of VHA Enterprise messages of the future will be XML. The tool will need to support the xml message structure natively The transformation process must support outbound XML messages/content The format of VHA Enterprise messages of the future will be XML. The tool will need to support the xml message structure natively The transformation tool's proprietary transformation/mapping language must support complex programmatic logic to support HL7 2.x transformation HL7 2.x message structure typically contains complex recurring data structures. In order to process these structure effectively - programmatic features such as loops and recursion will need to be supported. NICE TO HAVE Requirements: The tool must be able to persist the contents of XML-encoded message content to a relational database management system The tools must be able to create XML-encoded messages from the contents of a relational database management system The tool must be able to persist the contents of HL7-encoded message content to a relational database management system This is a nice-to-have feature to enable HL7 interface implementation. This is a transitional capability for the VA enterprise. The tools must be able to create HL7-encoded messages from the contents of a relations database management system This is a nice-to-have feature to enable HL7 interface implementation. This is a transitional capability for the VA enterprise.
- Record
- SN01490852-W 20080125/080123224025 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |