Overview and use case

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.

Use case

The following sections describe the use cases implemented in WebSphere Business Integration Collaborations for Healthcare.

Static Compliance Reporting

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.

Actors

The Static Compliance use case has at least three actors

Course

The following tables describe the main course and the alternate courses that can be followed in the Static Compliance Reporting use case:

Main course
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
Alternate course
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

Business examples

The following business examples show situations where the Compliance use case is realized.

Compliance Report Inquiry with accurate data

  1. A user requests a report for specific diagnostic codes over a specific date range.
  2. A message is routed to the system of truth.
  3. Report results are returned.
  4. Results are loaded into the report database.
  5. An e-mail containing the URL for a report display portlet is issued

Compliance Report Inquiry with invalid data

  1. A user requests a report for specific diagnostic codes over a specific date range.
  2. A message is routed to the System of Truth
  3. System of Truth reports a failure
  4. An e-mail containing a failure indication is issued

Electronic Medical Record

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.

Actors

The EMR use case has at least three actors

Course

The following tables describe the main course and the alternate courses that may be followed in the EMR use case:

Main course
# 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  
Alternate course
# 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

Business examples

The following business examples show situations where the EMR use case is realized.

EMR Drug order with accurate data

  1. A physician examines a patient's EMR and issues a request for a new medication.
  2. A message is routed to a queue.
  3. The order is stored.
  4. The insurance payer is queried on patient coverage.
  5. The insurance payer responds with patient covered message.
  6. The order is sent to a workflow to manage the processing of the pharmacy order.
  7. The order is processed.
  8. The order is examined for compliance alert processing (for example, anthrax).
  9. Order information is added to the patient's EMR.
  10. An e-mail containing a notification of the updated EMR is sent.

EMR Drug order with accurate data

  1. A physician examines a patient EMR and issues a request for a new medication.
  2. A message is routed to a queue.
  3. The order is stored.
  4. The insurance payer is queried on patient coverage.
  5. The insurance payer responds with patient not covered message.
  6. An e-mail containing the failure is sent. This e-mail includes the reason for the failure.

Cascading Orders

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.

Actors

The Cascading Order use case has at least three actors:

Course

The following tables describe the main course and the alternate courses that may be followed in the Cascading Orders use case:

Main course
# 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  
Alternate course
# 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

Business examples

The following business examples show situations where the Cascading Order use case is realized.

Cascading order with accurate data on known patient

  1. EMS calls in patient information (for this example, a head trauma). The information includes the patient name.
  2. An emergency room staff member enters information into the system.
  3. The patient information is retrieved.
  4. CAT scan, x-ray, and operating room are reserved.
  5. A neurosurgeon is notified of the possible head trauma.
  6. The patient arrives at emergency room.
  7. An ER physician assesses the patient and concurs with the head trauma diagnosis.
  8. The system orders blood work.
  9. Next of kin are notified.
  10. The organ bank is notified.
  11. ER staff handles the patient.

Cascading order with inaccurate data on known patient

  1. EMS calls in patient information (again, a head trauma). The information includes the patient name.
  2. An emergency room staff member enters information into the system.
  3. The patient information is retrieved.
  4. CAT scan, x-ray, and operating room are reserved.
  5. A neurosurgeon is notified of the possible head trauma.
  6. The patient arrives at emergency room.
  7. An ER physician assesses the patient and does not concur with the head trauma diagnosis.
  8. The system frees the CAT scan, x-ray, and operating room.

Copyright IBM Corp. 2002, 2003