Design and Development
1. The solution needs to support the proposed SOA/ESB reference architecture where the ESB is single point of integration for all the organizations requirements for communicating to internal systems and external systems. The tool sets used for the proposed solution needs to be interoperable from development perspective. For example the BPM tool needs to be integrated with development tool set.
2.The solution needs to be able cater and extend to alternative frameworks to SOA such as Model Driven Architecture and Event Driven Architecture.
3.The solution needs to adhere to a typical development lifecycle. The product suite needs to provide tools for design, development, testing, deployment and support.
4. The solution needs to provide tool sets to support XML, XSD authoring, XSLT (XML Transformation) and XPath.
5. The product suite used for the ESB needs to quicken development using off-the-shelf frameworks and support for health care standards such as HL7 , ASTM , DICOM etc.
Solution Framework
1.The ESB solution needs to support variants of HL7V2.x to support communication of local systems within an organization. The ESB needs to support backward compatibility of HL7V2.x messages by selective validation of message segments as per the version.
2.The HL7V2.x message types that need to be supported by the ESB primarily are ADT, Inbound Orders, Outbound Orders, Inbound Results, Outbound Results and Scheduling.
3.The HL7V2.x messages will contain user defined Z-Segments apart from standard segments originating from clinical applications and other existing systems. These messages need to be validated by the ESB against the standard specifications and rejected with a response back to the target system for possible resubmission.
4.The ESB needs ensure that messages from each clinical application are routed correctly to the target system.
5.The ESB needs to support persistent and transient connections from and to the organizations applications.
6.The ESB needs to support message sequencing and deliver the HL7V2.x messages to the clinical applications in the order they arrive at the ESB.
7.The ESB needs to provide duplicate elimination without compromising the ability to process messages faster.
8.The ESB needs to ensure message accuracy. Accurate means that the content and structure of a Message is maintained from the moment of receipt or generation of the Message by the ESB to the moment of Transfer, or completion of all required processing, of the Message by the system till it is delivered to target system.
9.The ESB needs to support Remote Invocation Form (RIF) that is derived from standard client-server methods. The model is inherently synchronous from the perspective of the human actor in that the actor is “blocked” waiting for a response. For RIF the ESB needs to keep the connection open till the response is back and do not allow a message to be fired with the same message id by the user. Allow the user to fire the same message with different message if a SOAP HTTP 2xx indicating failure for the first message comes back
10.The ESB needs to support State Exchange Form (SEF) that is used to synchronize business processes. In SEF application persists the data and sends the message to target system. The ESB needs to close of the connection. When the target system responds back it may be a success or failure. The success needs to conveyed back to application but not the failure. The failure needs to be logged by ESB for it to be investigated
11.The ESB needs to support ebXML mode for asynchronous messaging to applications. The ESB needs to build HL7 wrappers and validate payload from applications. The ESB needs to include HL7 wrapper and payload within a SOAP envelope, and transport the full message over HTTPS. The information behavior for MHS needs to be in sync with Oasis ebMS V2.0
12.The ESB needs to support both Single Mode and Intermediary mode for ebXML asynchronous messages.
13.The ESB needs to support SOAP-WS for synchronous messages to applications. The Web Services Mode of ESB is delivered by considering the target systems integration layer as a standard Web Service provider. The service provider MAY produce a WSDL definition for each web service. However, the WSDL is not warranted to generate web service stubs. This is due to the diversity of tools and the inability to guarantee that the WSDL will operate correctly in all environments. Implementers may use the WSDL to build product-specific WSDL, or implement the service interfaces in some other manner.
14.The ESB needs to support integration of legacy systems using different communication protocols like TCP-IP , MQ , FTP , HTTP , Web Services
15.The ESB needs to support proprietary queuing methods like variants of JMS and other queuing mechanisms.
16.The ESB needs to support sending of alerts to users using variety of communication methods – SMS , e-mail(SMTP) and Paging
17.The ESB should provide standard adapters of the product and its licensing policies associated with them. The adapters should cover communication protocols , database connectivity , transformation , message transport and message
18.The ESB needs to support LDAP and the ability to query LDAP for retrieving contract properties , CPA and possible reference data and route the responses to appropriate system.
19.The ESB needs to support message patterns – asynchronous and synchronous messaging –publish and subscribe – store and forward- push and pull mechanism.
20.The ESB should support internal interfaces which need not be HL7 v3 compliant interfaces and the HL7 v3 compliant interfaces and communication with the applications so that communications can take place between IT systems where one IT system is within the organizations boundary of responsibility and the other IT system is outside the organizations boundary of responsibility.
21.The ESB needs to support multiple versions of HL7V3 message interactions. The ESB needs to support the concept of sending a single HL7V3 message to multiple target systems.
Deployment
1.The ESB needs to be deployable in distributed and federated fashion with ability to monitor and support from a uniform platform.
2.The ESB need to have minimum downtime requirement for configuration changes and upgrades.
High Availability and Scalability
1.The ESB need to support large data volumes including large message sizes and high through put. Please mention the ability the solutions ability to support multi-threading without consuming infrastructure resources to support increase in volumes.
2.The ESB need to support different High Availability options using load balancing, clustering and failover methods without any loss of messages. The High Availability expected for the ESB is 99.9
Security
1.The proposed solution framework needs to be ensure that all messages sent over the internet need to be secure. The solution needs to ensure that there is no user based access to the ESB from external data sources other than via the defined messaging interfaces.
2.The ESB needs to provide Security Framework and Infrastructure with ability to encrypt and decrypt messages and support for creation, installation and deployment of Certificates.
Service Management and Support
1.The ESB needs to be provided a framework to log message attributes such as the message creation date/time, message identifier, referenced message identifier (for response messages), the message interaction identifier, message status (success or failure) and the unique row identifier into the audit queue where the audit event (HL7 message, SOAP message or ebXML Acknowledgement) is held.
2.ESB needs to log the error codes and the associated text returned in the message responses of failed and unsuccessful messages. A browser based Message Log Viewer needs to be provided and allow a user to search audit log and select to view a specific message from the audit queues.
3.The Message viewer should allow only the message headers to be viewed; the message body should not be allowed to be viewed.
4.The ESB framework need to be support error handling and log communication and mapping errors and should be viewable from the Message Viewer. The error logging framework needs to log alias translation, errant data, and functional errors.
5.The service management framework of ESB needs to be integrated with standard Service Management tools of IBM and CA.
Testing
1.The ESB testing framework needs to acts as test Harness for testing both HL7V2.x and HL7V3.0 messages.
2.The test Harness need to provide a UI (User Interface) with ability for application testers to setup test data needs to be incorporated
3.The test harness needs to be a virtual application providing the responses in sync with the expectation of the ESB.
4.The test harness needs to be readily configured to test all business cases of the organizations applications. The rules configuration also needs to be user interface based instead of using technologies like XPATH
Decoupling Mode Handling
1. The ESB needs to handle delivery of messages when target system is not available manifested by a failed http connection.
2. The ESB needs to handle failed delivery of messages manifested by in the ebXML message mode by non-receipt of the ebXML Acknowledgement following the required number of retries.
3. The ESB needs to operate in slow retry mode after the expiry of retries in ebXML mode
4.The ESB needs to covey to the application of non availability of applications for synchronous messages manifested by non-receipt of the HL7 response.
5. The ESB needs to handle failure to deliver HL7V2.x messages manifested by failed TCP-IP connection and target system not available.
Supplementary Requirements
1. The ESB needs to provide the ability to longitudinally construct patient’s journey with data retrieved from different clinical systems and display in a consistent and fashioned approach to the end user.
2. The ESB needs to support the ability to support presentation layer integration using CCOW and other relevant standards.
No comments:
Post a Comment