|
The Patient Administration ES bundle uses application-to-application (A2A) services to seamlessly integrate SAP Patient Management (based on SAP ERP 6.0) with the many third-party systems typically deployed in today's healthcare facilities in the areas of Patient Identification and ADT (Admission, Discharge, Transfer). Rather than forcing customers to discard their old user interfaces in favor of new ones, the Patient Administration ES bundle provides enterprise services that easily integrate SAP functionality into existing interfaces. These enterprise services follow an important industrywide integration initiative called Integrating the Healthcare Enterprise (IHE, at www.ihe.net). IHE provides implementations for standards such as HL7 and DICOM. Using the services in the Patient Administration ES bundle provides for seamless integration with existing standards-based systems, including clinical, lab, financial, patient administration, and scheduling systems, among others. The services in the Patient Administration ES bundle support the following IHE actors:
|
|
Audience
Any industry, large or small, that is engaged in providing public or private healthcare will benefit from the services in the Patient Administration ES bundle, particularly hospitals and rehabilitation centers.
 | For details on Service Operations, Business Objects and Process Components, please check the ES Workplace. |
How To Use This ES Bundle
In the past, integrating the numerous clinical systems in a hospital with SAP ERP 6.0 and SAP Patient Management was handled using Business Application Programming Interfaces (BAPIs). Alternatively, the systems were not integrated, meaning that information might have to be entered in multiple systems sometimes or that finding out where a certain patient was or whether he had been admitted might entail a phone call to another department.
Now, with the introduction of the Patient Administration ES bundle, healthcare professionals have at their disposal a method of integrating their myriad systems that offers easier, standards-based integration, allowing SAP applications to be integrated with existing user interfaces seamlessly. Furthermore, because of the flexibility of enterprise services, such integrations can be used to transform business processes and increase efficiency.
Using the Patient Administration ES bundle, healthcare professionals can integrate functions such as:
- Creating and updating patient identity records
- Merging dual patient identity records
- Assigning beds to patients
- Admitting patients for inpatient stays or outpatient visits
- Documenting leaves of absence
- Admitting patients for emergencies
- Transferring patients from one location to another
- Discharging patients
When a patient arrives at a hospital or rehabilitation center, either for a standard visit or for an emergency, attendant personnel can create or update the patient's identity record such that their detailed personal information is available to personnel working in other, related departments. For example, after an initial examination, a patient may be sent to the radiology department for an X-ray or CAT scan. The technician there can access the patient's record on demand and then modify it according to the services rendered. The charges for these services are automatically propagated to the institution's financial backend, where the resulting data is available for viewing by the accounting department.
Once a patient has been admitted to a facility and consequently examined, a clerk, nurse, or doctor may discover that two records on file are for the same patient. The Patient Administration ES bundle provides users with the means to reconcile such discrepancies by merging the two records into one following the Merge Patient Identifiers IHE process flow. A message is automatically sent to relevant systems in all pertinent departments, informing them of the merge.
For a nurse to ensure that a patient is assigned to a bed and that the equipment used by the patient is properly registered and billed, she must first enter various data into the system and then search for the patient on a shortlist of recently admitted patients. This list displays the medical record number of each patient, thus enabling to nurse to select the proper record. If patients can identify themselves, the nurse can use their name and other personal information, such as their social security number or home address, to locate them on the list. For those patients who cannot identify themselves, the nurse can locate them by entering their identification number into the respective equipment, either manually or by scanning a bar code on the patient record. Subsequent data is available for use in all related systems.
Often patients are required to stay in a healthcare facility for extended periods. Before the patient can be admitted, however, the means by which they intend to pay their bill must be verified. For instance, if the patient is no longer insured by the same insurance company, a new one must be added to his record so that all of the services he receives will be accurately billed. On the other hand, it may be that the patient still has outstanding bills from services already rendered. If this is the case, attendant personnel can work with the patient to make alternate arrangements. After the party responsible for addressing the invoice has been validated, the hospital must publish the information to all systems relevant for billing.
Each of the following use cases will show how different outcomes can be achieved by using the enterprise services in different combinations. Note that these examples may refer to users directly invoking enterprise services. This illustrates the flow of the service operations; in fact, service operations are invoked by an application, by an application's user interface, or by another service operation.
While these use cases illustrate a few of the ways that this ES bundle could be used, the intention is to show the flexibility and reusability of these business objects and enterprise service operations so that you will have a clearer understanding of how to best deploy them in your own environment. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Patient Administration ES bundle.
Use Case 1: Creating and Updating a Patient
| IHE Profile | PAM (Patient Administration) |
|---|---|
| IHE Transaction | Patient Identity Feed |
| IHE Process Flow | Update Patient |
| IHE Actors | Patient Demographics Source, Patient Demographics Consumer |
An unconscious patient has just been brought to a hospital to receive treatment for a wound, but he is without identification. Before he can be treated, however, he must have a patient record. The admissions clerk can create one from scratch with a minimum of information and then update it later, if necessary.
To create a new patient record, the admissions clerk, whose system plays the role of the IHE Patient Demographics Source, can invoke the Create Patient service operation, which uses the Patient business object. As a follow-up step, the Create Patient service operation in turn invokes the Inform of Patient Creation enterprise service. This service sends messages to systems deployed by other pertinent departments, which are known in IHE terms as Patient Demographics Consumers, updating them using the asynchronous request-confirmation Maintain Patient service operation providing an application acknowledgement. The required acknowledgment will be returned through the Confirm Patient Maintenance service operation.
Later, one of the patient's family members arrives to provide the admissions clerk with more information about the patient, such as his name, date of birth, home address, phone number, and insurance provider. The clerk simply adds this data to the existing patient record and then triggers the Update Patient service operation. Via the bundle's A2A functionality, the Inform of Patient Change service operation automatically propagates the new information to all related systems.
The following table summarizes these steps and the related enterprise services:
| Step | Enterprise Service Invoked |
|---|---|
| Step 1: The admissions clerk admits the patient and enters available data for the patient | Create Patient |
| Step 2: The system sends messages to other departments, informing them of the newly admitted patient | Inform of Patient Creation |
| Step 3: The systems in other departments update their records to include the new patient | Maintain Patient |
| Step 4: The systems in other departments send a confirmation back to admissions that this work was done | Confirm Patient Maintenance |
| Step 5: A family member provides more information about the patient to the admissions clerk | Update Patient |
| Step 6: The admissions system sends messages to systems in other departments | Inform of Patient Change |
Use Case 2: Admitting a Patient for an Inpatient Stay
| IHE Profile | PAM (Patient Administration Management) |
|---|---|
| IHE Transaction | Patient Encounter Management [ITI-31] |
| IHE Process Flow | Admit Inpatient |
| IHE Actors | Patient Encounter Supplier (SAP Patient Management) and Patient Encounter Consumer (ancillary systems) |
When admitting a patient for a stationary encounter, all other ancyllary systems (Radiology, Laboratory, Departmental systems, etc.) should be informed of this event, in order to ease future administrative tasks on those systems (booking of examinations, tests, etc.)
In this case, SAP Patient Management will trigger an Outbound service that will in most cases be mapped into an A01 HL7 Event (and corresponding ADT_A01 message) and then broadcasted to the several departmental systems.
The following table summarizes these steps and the related enterprise services:
| Step | Enterprise Service Invoked |
|---|---|
| Step 1: The ward clerk searches to see if this patient exists | Performed locally, no service invoked |
| Step 2: Patient is found, from a previous visit, and clerk creates a new inpatient case | Performed locally, no service invoked |
| Step 3: The clerk enters the data relevant to the patient encounter - ward, bed, etc. - and saves the newly created case | Inform of Patient Encounter Record |
Use Case 3: Merging a Patient
| IHE Profile | PAM (Patient Administration) |
|---|---|
| IHE Transaction | Patient Identity Feed |
| IHE Process Flow | Merge Patient Identifiers |
| IHE Actors | Patient Demographics Source, Patient Demographics Consumer |
In the previous use case, a patient was admitted to a hospital and subsequently treated for a wound. Because the patient was unconscious at the time of admission, however, the admissions clerk was unable to search her database for a possibly preexisting record and so created a new one.
The next day a nurse searches for the patient using Find Patient by Basic Data and discovers there are two similar records. She selects each record to look at the details, invoking the Read Patient enterprise service in the process.
Upon reviewing the records, the nurse discovers that the two records are for the same patient and should be merged. To do so, he triggers the Merge Patient service operation, which uses the Patient business object. The nurse's application in this case is playing the role of Patient Demographics Source, so a notification of the change must also be created using the Inform of Patients Merged enterprise service operation. The Patient Demographics Consumers, in this case the systems in all pertinent departments, perform the asynchronous Merge Patient service operation in order to reflect the change in their system. The required application acknowledgment will then be returned through the Confirm Patient Merge service operation.
The following table summarizes these steps and the related enterprise services:
| Step | Enterprise Service Invoked |
|---|---|
| Step 1: The nurse searches for a patient previously admitted | Find Patient by Basic Data |
| Step 2: The search returns two patient records that may be for the same patient | (no enterprise service is invoked during this step) |
| Step 3: The nurse selects a record to review the details | Read Patient |
| Step 4: The nurse selects selects the second patient record | Read Patient |
| Step 5: The nurse compares the two records and decides they should be merged | (no enterprise service is invoked during this step) |
| Step 6: The nurse selects both records and chooses the option to merge them | Merge Patient |
| Step 7: The application confirms the merging of the patient records | Confirm Patient Merge |
Use Case 4: Selecting a Patient from a List of Admitted Patients
| IHE Profile | PDQ (Patient Demographics Query) |
|---|---|
| IHE Transaction | Patient Demographics Query |
| IHE Process Flow | Entering patient information at bedside |
| IHE Actor | Patient Demographics Supplier |
The nurse in an intensive care unit has received a patient whom she needs to provide with a bed and a variety of equipment crucial to his recovery. In this case, the patient is able to verbally convey the information, such as his name or social security number, that is required to generate a list of recently admitted patients and their concomitant medical record numbers. The nurse can search on a variety of criteria, including partial or complete patient name (printed on the patient record or told by the patient), patient ID (from a printed barcode, a bedside chart, and so on), and date of birth/age range. Providing one or more of these elements, the nurse then invokes the Find Patient by Basic Data service operation, which uses the Patient business object.
The list of patients who have been admitted but not yet assigned a bed is relatively short, making it easier for the nurse to make a selection. The short list of patients returned includes the patient's medical record number (MRN), full name, age, sex, room, and admission date. When the nurse selects a patient from the list, the Read Patient service operation is invoked.
The following table summarizes these steps and the related enterprise services:
| Step | Enterprise Service Invoked |
|---|---|
| Step 1: The nurse in the ICU searches for recently admitted patients | Find Patient by Basic Data |
| Step 2: The nurse selects the patient from the list | Read Patient |
Use Case 5: Admitting a Patient for an Emergency Visit
Since an emergency patient has arrived at a clinic in the middle of the night, the clerk who admits patients during standard business hours is not present. Nevertheless, the patient must be admitted, so a nurse captures the patient's basic data (from an insurance card if available) in the Emergency Room (ER) system. The ER system is integrated with SAP Patient Management and invokes the Find Patient by Basic Data service operation to see whether she has an existing record. The search criteria can include the patient's first and last name, birth date, postal code, and insurance number, among others.
Unable to locate a record, the nurse must import the information from the patient's insurance card (again, if available) and create a new patient record and encounter that includes the proper care unit specifications. To do so, she can trigger the Create Patient service operation.
The final step in admitting the patient is to create an encounter. This is done by triggering the Create Patient Encounter service operation.
The following table summarizes these steps and the related enterprise services:
| Step | Enterprise Service Invoked |
|---|---|
| Step 1: The emergency room clerk searches to see if this patient exists | Find Patient by Basic Data |
| Step 2: The search returns no matching results | (no enterprise service is invoked during this step) |
| Step 3: The ER clerk enters data to create the patient record | Create Patient |
| Step 4: The ER clerk enters data to create the patient encounter. | Create Patient Encounter |
Future Directions
This bundle is the first of a number of healthcare-related bundles and it provides basic functionality for them all. Because of its foundational role, significant enhancements to this bundle are not currently anticipated.
Connectivity
The Patient Administration ES bundle connects to SAP Patient Management and SAP ERP 6.0. Because of the standards-based communication offered by enterprise services, the ES bundle supports the Integrating the Healthcare Enterprise (IHE) initiative, which provides guidance for deploying standards such as HL7 and enabling the to integrate with those third-party systems typically deployed in the healthcare industry.
System Requirements
- SAP ERP 6.0
- SAP Enhancement Package 5 for SAP ERP 6.0
- SAP NetWeaver Process Integration (formerly XI)
Related ES Bundles
- Resource Planning and Scheduling
- Medical Documentation and Coding
- Medical Activities, Patient Billing and Invoicing
- Resource and Supply Chain Planning for Healthcare Providers
Links
SDN and SAP Links
Links to SAP Healthcare Blogs
"How to find & test Enterprise Services for Healthcare" by Bettina Lieske
"Engineering a Business Process Platform for Healthcare Part 5 - How To Provide Value" by Claudius Metze
"Engineering a Business Process Platform for Healthcare Part 4 - Here's the beef" by Claudius Metze shows the wiki for Patient Administration.
