Skip to end of metadata
Go to start of metadata

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:

  • Profile PDQ (Patient Demographics Query):
    • Actor Patient Demographics Supplier; Transaction Patient Demographics Query (ITI-21) (EhP4)
  • Profile PAM (Patient Administration Management):
    • Actor Patient Demographics Consumer; Transactions Patient Identity Feed (ITI-030) (EhP4)
    • Actor Patient Demographics Supplier; Transaction Patient Identity Feed (ITI-030) (EhP4)
    • Actor Patient Encounter Supplier; Transaction Patient Encounter Management (ITI-31) (EhP5)
  • Profile PIX (Patient Identifier Cross-Referencing):
    • Actor Patient Identity Source; Transaction  Patient Identity Feed (ITI-8)  (EhP5)
    • Actor Patient Identifier Cross-Reference Consumer; Transaction PIX Update Notification (ITI-10) (EhP5); supported partially (see details below) 
  • Profile CT (Consistent time)
    • Actor Time Client

Patient Administration (click to enlarge)

Details on the supported actors and HL7 messages can be found in here

Details on the necessary configuration for these IHE profiles can be found in the IHE Configuration Guide.

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.

Business Objects and Service Operations

This Enterprise Services Bundle contains the following interfaces with related service operations:

Service Operations of Component Healthcare Business Partner Data Management 

InterfaceServiceDescription
Manage Patient InCreate Patient

To create an instance of the Patient business object, and confirm that the creation was successful.

Manage Patient InRead Patient

To read the detailed information about a patient.

Manage Patient InRead Patient Private Patient Indicator

To read the private patient indicator of an instance of the Patient business object.

Manage Patient InUpdate Patient

To update an instance of the Patient business object, and confirm that the update was successful.

Patient Action InDeactivate PatientTo deactivate an instance of the Patient business object, and confirm that the deactivation was successful.
Patient Action InMerge PatientTo merge two instances of the Patient business object, and confirm that the merge was successful.
Patient In

Change Patient based on Patient Changed Notification

To change an instance of the Patient business object when notified that it has been changed in a connected system.

Patient In Create Patient based on Patient Created NotificationTo create a Patient business object when notified that it has been created in a connected system.
Patient In Deactivate Patient based on Patient Deactivated NotificationTo deactivate an instance of the Patient business object when notified that it has been deactivated in a connected system.
Patient In Maintain PatientTo maintain an instance of the Patient business object.
Patient In Merge PatientTo merge two instances of the Patient business object.
Patient In Merge Patient based on Patient Merged NotificationTo merge two instances of the Patient business object when notified that they have been merged in a connected system.
Query Patient InFind Patient by Basic DataTo find a patient by searching by basic data.
Query Patient InFind Patient by Identifying ElementsTo find an instance of the Patient business object and inform an external system that the patient is known.
Patient Event OutInform of Patient ChangeTo inform connected systems of a changed instance of the Patient business object.
Patient Event OutInform of Patient CreationTo inform of a created instance of the Patient business object.
Patient Event OutInform of Patient DeactivationTo inform third-party systems about a patient deactivation.
Patient Event OutInform of Patient Identification ChangeTo inform all connected systems that one or more identifiers of a patient have been changed.
Patient Event OutInform of Patient MergeTo inform all connected systems that two instances of the Patient business object have been merged.
Patient OutConfirm Patient MaintenanceTo confirm the maintenance of a patient, in response to the Maintain Patient operation.
Patient OutConfirm Patient MergeTo confirm the merging of two patients, in response to the Merge Patient asynchronous inbound operation.
Query Patient OutFind Patient by Basic DataTo find a patient by searching by basic data.

Service Operations of Component Patient Encounter Management 

InterfaceServiceDescription
Manage Patient Encounter InCancel Patient EncounterTo cancel an instance of the Patient Encounter business object, and return a confirmation that the cancellation was successful.
Manage Patient Encounter InCreate Patient EncounterTo create an instance of the Patient Encounter business object, and send a confirmation that the encounter has been created.
Manage Patient Encounter InRead Patient EncounterTo display the details of an instance of the Patient Encounter business object.
Manage Patient Encounter InUpdate Patient EncounterTo update an instance of the Patient Encounter business object.
Query Patient Encounter InFind Patient Encounter Patient List by ElementsTo find a list of patients that meet certain criteria based on patient encounter information.
Patient Encounter Record InMaintain Surgery based on Patient Encounter Record Surgery NotificationTo maintain the administrative documentation of a surgery based on a notification from a third-party system.
Patient Encounter Record Event OutInform of Patient Encounter RecordTo inform third-party systems about an event that relates to a patient encounter and its related data.

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.

Patient Encounter vs. movement concept in SAP Patient Management

How do the new SOA concepts of Patient Encounter and Billing Patient Encounter Group match to the "old" world?
Encounter versus Movement
SAP Patient Management knows different movements categories like admissions, transfers, start of absence, end of absence, discharges and visits (might they be inpatient or outpatient).
The Business Object "Patient Encounter" however does not represent a moment in time like most of the movements, but a period in time, this means that it represents a time span between two events (e.g. between an admission and a discharge). Details can be found in the help.sap.com documentation.

Billing Patient Encounter Group versus Case
There are actually 3 case types in SAP Patient Management: inpatient, outpatient and daypatient cases.
We consider a case as being a "Billing Patient Encounter Group" (BPEG) as it groups a set of encounter together for billing purposes. Encounters could also be grouped for clinical purposed (this would then result in a Clinical Patient Encounter Group" and rather be supported by a clinical application. The idea behind is that encounters just occur and exist independendly of the later processes (billing, clinical decision making).
A case (or BPEG) typically covers more than one movement (or encounters in the SOA world). This is especially true for outpatient cases that typically last several months or years (in Germany for the duration of 3 Months (Quartal)), but also for inpatient cases. In the later case it depends on the granularity the hospital chooses, some might want to create movements for every department or room change, some just for admission and discharge.

System Requirements

Related ES Bundles

SOA Homepage on SDN

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.

Health Level 7
Integrating the Healthcare Enterprise (IHE)