IBM(R) WebSphere(R) Business Integration Collaborations for Healthcare provides healthcare companies with a method for integrating manual and automated processes in order to efficiently and quickly deliver new revenue-generating services. Through reengineering and streamlining of business processes, WebSphere Business Integration Collaborations for Healthcare assists healthcare service providers in reducing their operating expenses and increasing their profit margins.
The package includes WebSphere Business Integration Collaboration for Healthcare Transaction, a set of collaboration templates that can be used as building blocks in an organization's system, depending on the transactions required. The collaboration templates allow key data elements to be maintained for an overall view of the transactions that are occurring, while passing the business objects to collaboration objects that are custom designed to communicate with existing healthcare applications.
The use cases provided in WebSphere Business Integration Collaborations for Healthcare address areas of interest in the healthcare industry. This version of WebSphere Business Integration Collaborations for Healthcare provides detailed use cases for three specific topics:
These use cases include components that demonstrate the interoperation and integration of a broad range of technologies. Examples include interaction with a Health Insurance Portability and Accountability Act (HIPAA)-compliant insurance/payer entity.
The following sections describe the use cases implemented in WebSphere Business Integration Collaborations for Healthcare.
The Static Compliance scenario is used to collect and organize data required in a sample compliance report. This scenario demonstrates the process followed when a user or an automated process requests the generation of a compliance report. The process begins when the request is made. The compliance workflow picks up the request and uses collaboration objects to interface with HL7-enabled applications in order to collect the requested data. Once the data has been retrieved, it is stored in a report database. The compliance workflow issues an e-mail containing a URL that uses a portlet interface to allow interested parties to display the report.
The Static Compliance use case has at least three actors
The following tables describe the main course and the alternate courses that can be followed in the Static Compliance Reporting use case:
Number | Activity by actor | System activity | Reference |
---|---|---|---|
M1 | Initiator submits a request | Receives request information | |
M2 | Routes request to service collaboration | ||
M3 | Collaboration builds HL7 query for requested data | 1 | |
M4 | System of truth accepts query and responds | ||
M5 | Collaboration extracts response data | 2 | |
M6 | Collaboration loads report database | 3 |
|
M7 | Collaboration builds Workflow response | ||
M8 | Receives response | ||
M9 | Issues e-mail | ||
M10 | End process |
Number | Activity by the actor | System activity | Reference |
---|---|---|---|
1 | Invalid request. Fail flow. | M10 | |
2 | System of truth returns failure | M7 | |
3 | Inability to write database | M7 |
The following business examples show situations where the Compliance use case is realized.
Compliance Report Inquiry with accurate data
Compliance Report Inquiry with invalid data
The Electronic Medical Record (EMR) scenario demonstrates a simple implementation of a patient-centric medical record. In this scenario, a physician examines information in a patient's EMR, issues instructions for application of a new drug, validates that the patient is covered for the new medication and updates the EMR if the medication is approved. A portlet application initially displays the EMR. This portlet also collects the physician input and places the medication request on a queue. The EMR workflow issues an e-mail notifying interested parties that the updated EMR is ready for display.
The EMR use case has at least three actors
The following tables describe the main course and the alternate courses that may be followed in the EMR use case:
# | Activity by actor | System activity | Reference |
---|---|---|---|
M1 | Physician opens a patient EMR | ||
M2 | Physician examines EMR and patient | ||
M3 | Physician issues order for new medicine | ||
M4 | Receives order | 1 | |
M5 | Store order | 2 | |
M6 | Extract drug information and issue a HIPAA 270 coverage message | 3 |
|
M7 | Insurance payer receives HIPAA 270 message | ||
M8 | Insurance payer responds with HIPAA 271 message | ||
M9 | Receives HIPAA 271 message | 4 | |
M10 | Checks for coverage | 5 | |
M11 | Issues Pharmacy order | 6 |
|
M12 | System of truth for pharmacy order receives order and processes accordingly | ||
M13 | Checks for alerts | 7 |
|
M14 | Updates patient EMR | 2 |
|
M15 | Issues e-mail | ||
M16 | End process |
# | Activity by the actor | System activity | Reference |
---|---|---|---|
1 | Invalid physician request. Fail flow. | M16 | |
2 | Inability to write database. Fail flow. | M16 | |
3 | Inability to issue message. Fail flow. | M16 | |
4 |
Invalid response. Fail flow. | M16 | |
5 |
No coverage. Create failure e-mail. | M15 | |
6 |
Inability to read database. Fail flow. | M16 | |
7 |
Alert found. Post business object to ToPort | M14 |
The following business examples show situations where the EMR use case is realized.
EMR Drug order with accurate data
EMR Drug order with accurate data
The Cascading Orders scenario demonstrates the automation of a healthcare process in an emergency setting. This scenario demonstrates the process when a patient is inbound to an emergency room. Initial data provided by Emergency Medical Services personnel is used to issue pending typical orders associated with the reported injury. Once the patient arrives in the emergency room, a physician validates the initial assessment. If the assessment is correct, the pending orders and other associated orders are executed. If the assessment is overridden, the pending orders are canceled.
The Cascading Order use case has at least three actors:
The following tables describe the main course and the alternate courses that may be followed in the Cascading Orders use case:
# | Activity by actor | System activity | Reference |
---|---|---|---|
M1 | EMS personnel report patient status | ||
M2 | Emergency room staff enter patient information into system | ||
M3 | Covered injury | 1 | |
M4 | Known patient | 2 |
|
M5 | Lookup pending tasks | 3 |
|
M6 | Perform tasks | 4 |
|
M7 | Wait for patient to arrive | ||
M8 | Emergency room physician assesses patient | ||
M9 | Initial injury agrees with emergency room physician assessment | 5 |
|
M10 | Lookup execute tasks | ||
M11 | Perform tasks | 4 |
|
M12 | Emergency room staff actions | ||
M16 | End process |
# | Activity by the actor | System activity | Reference |
---|---|---|---|
1 | Manual Process required | M12 | |
2 | Lookup Patient info | M5 | |
3 | Inability to access database. Fail flow | M12 | |
4 |
Inability to perform all tasks. Update status | M6 | |
5 |
ER assessment differs. Lookup cancel tasks | M11 | |
6 |
Inability to perform all tasks. Update status | M12 |
The following business examples show situations where the Cascading Order use case is realized.
Cascading order with accurate data on known patient
Cascading order with inaccurate data on known patient