BP -ISH en SAP.pdf

1

2

3

4

1

2

3

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4,

Business Function SAP Patient Management Rearchitecture BP/OM(ISH_BP_OM),

you can migrate the proprietary SAP Patient Management business partner to the

new SAP standard and central functions SAP Business Partner (SAP BP)

Before the new functions can be used, the system must be upgraded to SAP ECC

6.0,Industry Extension Healthcare, Enhancement Package 4.

Please note the following changed and new terminology as of SAP ECC 6.0, Industry

Extension Healthcare, Enhancement Package 4, Business Function SAP Patient

Management: Rearchitecture BP/OM (ISH_BP_OM):

In relation to the previous business partner in SAP Patient Management (in texts

about the migration from the previous to the new concept generally referred to as 'IS-

H business partner' and/or 'HC business partner'), the German term 'Rolle' in the

documentation was translated with the English term 'function'. Note that for the new

concept SAP Business Partner for Healthcare (SAP BP-HC), the English translation

'role' is used.

4

Benefits using Business Partner

One central object for all business partner interactions.

Uniform look and feel for maintenance of all business partner roles

Synergies for customers already using other roles of SAP BP, for example,

in the area of SAP for Higher Education & Research (SAP for HE&R)

(students are business partners)

Reducing duplicate data entry

Easy access and integration to other parts of the SAP Business Suite.

Connection to Customer Relationship Management (CRM) customer, for

example, combining and synchronizing patient data with CRM customer

data

Bi-directional synchronization: SAP BP - Financial Accounting (FI) customer

Existing integration between Human Capital Management (HCM) person

and SAP business partner

Open infrastructure.

Easy Enhancement Workbench (EEW) - allows you to extend the data

model of SAP BP and its relationships by adding new fields and tables

Business Data Toolset (control tool) for maintaining master data and simple

transaction data

Integration via business concepts

5

6

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business

Function SAP Patient Managment Rearchitecture BP/OM(ISH_BP_OM), you can

migrate the proprietary SAP Patient Management organizational and building structure

to the new SAP standard and central function Organizational Management (OM).

The organizational and building structures are used to describe a healthcare provider's

organizational structure. For example:

Hospitals

Clinics

Medical departments

Wards

X-ray rooms

Hospital beds

Before the new functions can be used, the system must be upgraded to SAP ECC

6.0,Industry Extension Healthcare, Enhancement Package 4.

7

Benefits of using SAP Organizational Management One central tool to maintain all units of organizational hierarchies, including

building units. Uniform look and feel for maintenance of all organizational objects Less duplicate data entry Synergies for customers already using OM, for example, in the area of personnel

planning

Drag-and-drop when reorganizing company structure (merger or acquisitions) is much faster than the manual process involving the functions for maintaining organizational and building structures in SAP Patient Management

Mapping of multiple institutions in one client Using structural authorization can help to reduce the number of

authorization profiles required Future Benefits (planned): Integrated appointment planning Start with a CRM contact in the Interaction Center in CRM. Find an open time slot for an organizational unit in SAP Patient

Management. Find a resource (for example, a physician, nurse, or technician) in HCM

which fits the following criteria: Is available Is able to provide the necessary service

8

9

10

11

12

13

14

15

1

2

3


Business Function SAP Patient Management: Rearchitecture BP/OM

(ISH_BP_OM), the BPs are maintained using SAP BP, which provides central

management for them. In SAP BP, BPs are classified as 'roles', depending on

their functions. Data which is common to all BPs (name, title, address and

communication data, identification details) is stored centrally. Furthermore,

each role has data specific to its function, for example, a HC Physician has

details about his or her specialization.

BP data can be created, changed, and deleted using the SAP BP transactions.

An integrated user interface is available for data entry and modification of all BP

data.

A partner in SAP BP can simultaneously exist in many roles belonging to a

particular category. Relationships amongst BPs can also be maintained. For

example, one insurance provider can be the head office of another insurance

provider.

4

For SAP Patient Management, the roles required are:

HC Insurance Provider

HC Hospital

HC Employer

HC Customer

HC Employee, HC Physician, and HC External Physician



(ISH_BP_OM), separate roles are maintained with SAP Business Partner (SAP

BP) for the business partners: HC Employee, HC Physician, and HC External

Physician. Hence, six new transactions (in addition to the three transactions

used before this release) are used to maintain them. These transactions are

described below:

Transactions NG04E, NG05E, and NG06E (New): Create, change, and

display business partner role HC External Physician.

Transactions NG04I, NG05I, and NG06I (New): Create, change, and

display business partner role HC Physician.

Transactions NG04, NG05, and NG06 (Existing): Create, change, and

display business partner role HC Employee.

5



(ISH_BP_OM), the following changes are made in the user interface used for

the maintenance of the business partners (BPs):

The search locator is embedded within the user interface.

The central and role-specific data for each BP is displayed in a tab page

format on the user interface.

You can access general data, relationship data, and FI-specific data by

choosing the relevant option on the title bar. The option for FI-specific data

appears only for the role HC Customer.

The blocking details are now available as fields on the user interface. You

can unblock blocked BPs by removing the blocking dates.

A deletion indicator is provided on the user interface.

You can access the comments specific to the role from the user interface.

SAPscript texts are used to store comments for BP roles.

6



(ISH_BP_OM), you can search for business partners (BPs) using a

customizable locator search. Before creating a BP, use this search to check

whether it already exists in the system.

The search locator allows you to search for BPs based on their categories

(person, organization, or group). After you choose the category, you can limit

the search using various search criteria, such as partner number, address, and

name. Hits are listed beneath the search area.

The search locator has been extended to provide a different search criterion for

each of the BP roles available. This keeps the search screen for each BP

similar to that provided by SAP Patient Management before this release.

Note: depending on the search criteria you provide, it is possible to search for

BPs that are blocked or have their deletion indicator set, or that are both

blocked and have their deletion indicator set.

7

After creation of a BP additional roles can be added to the general BP role via

Change mode.

8

9

A business partner relationship represents the business connection between

two business partners.

In order to create a relationship between two business partners you have to

assign a business partner relationship category to the business partner

relationship. The business partner relationship category describes the

characteristics of the business partner relationship.

You can assign attributes (such as a firm’s address for the contact person

relationship) to a relationship, which prevents data being stored redundantly.

You can limit a relationship in time by entering the start date and end date of

the relationship. This means that it is possible to get an overview of the periods

in which certain business partners were assigned to each other.

10



(ISH_BP_OM), business partner (BP) relationship control is used to establish

relationships between the BPs. A relationship between two BPs can be

characterized by a relationship category.

Assign four types of relationship between HC Insurance Providers:

Is Form Recipient of

Is HC SC Head Office of

Is Invoice Recipient of

Is Head Office for Data Exchange acc. to P301 SGB V (DE) of

You can also:

Assign an HC Insurance Provider to an HC Employer acting as the accident

insurance provider.

Assign an HC Insurance Provider to any BP acting as a responsible PPA.

You can show the relationships between BP in the following formats:

List

Hierarchy

Network

11

With the help of relationship categories you can define temporary contact persons and contact persons for

a company, as well as certain data on members of a shared living arrangement or marriage. The latter

might be necessary for liability reasons.

‘Relationship’ is the term used if a relationship category contains information on concrete business

partners.

The business partner relationship categories that can be selected depend on the business partner

category and on the BP role.

A distinction is made between one-way (unidirectional) and two-way (bi-directional) relationship

categories.

In the case of a one-way relationship category, a relationship exists from a business partner (1) to a

business partner (2), but not the other way round.

Example:

The enterprise Miller & Co (BP 1) has the employee Mr. Smith (BP 2); Mr. Smith, however, does not

have the employee Miller & Co.

In the case of a two-way relationship category, a relationship exists from a business partner (1) to a

business partner (2), and the other way round.

Mr. and Mrs. Meyer are married. Mrs. Meyer is married to Mr. Meyer and Mr. Meyer is married to

Mrs. Meyer.

An extension of relationship categories by adding attributes is possible. You can also create your own

relationship categories. You make the necessary settings in the Implementation Guide (IMG) in

Customizing of the Business Partner under Business Partner Relationships Basic Settings Properties

of Business Partner Relationship Categories.

12

13

14

15

As of SAP ECC 6.0 Industry Extension Healthcare, Enhancement Package 4, Business Function SAP Patient Management: Rearchitecture BP/OM (ISH_BP_OM), the Business Address Service (BAS) performs address validation and a check on postal code correctness. BAS provides an address validation tool via regional structure, which ensures that the address you provide exists and the data is consistent. The following fields are relevant for the check: Street Postal Code City

BAS carries out the check depending on the country key. Note: The address search mechanism of SAP Patient Management will not been used in BP any more. That’s why the address master data must be configured in BAS now. BAS can be found in SPRO -> SAP Netweaver -> Application Server -> Basis Services -> Address Management Address Data can be imported via SAP LSM Workbench (Release 1.0 or higher). The procedure is described in note 132948. To Activate Address validation for a certain country: SPRO -> SAP Netweaver -> General settings -> Set countries -> Set country specific checks Address Determination for BP: SPRO -> Cross Application Components -> SAP Business Partner -> Basic Settings -> Address Determination

16

17

18



(ISH_BP_OM), Master Data Synchronization (MDS) is the module used for

integrating business partners (BPs) with FI customers.

The IS-H customer is the link between the BP in the IS-H system and the

customer in the Financial Accounting (FI) system. The IS-H customer data is a

subset of the customer master data in FI. The FI customer number is stored in

the master record of the IS-H customer.

MDS allows you to integrate SAP applications that make technical use of the

BP in their user interface and use the customer master as a technical basis in

subsequent business procedures. From the BP interface, it is possible to create

and display FI customer data.

The system can be configured to automatically create a corresponding FI

customer when an IS-H customer is created. FI data for the customer can be

displayed from the integrated user interface.

The synchronization process is defined as a one-way process between the

source object type (IS-H customer) and the target object type (FI customer).

This means that changes in the IS-H customer are reflected in the FI customer

but not vice-versa.

19

Invalid FI assignments for IS-H business partner

For IS-H business partners in the Customer function, the reference to the FI

customer can be manually set to any customer in FI, including FI customers

from account groups that are assigned to patients (self-payer). Therefore it is

possible that multiple IS-H customers can be assigned the same FI customer

(n:1). Secondly, if an IS-H customer is maintained for more than one company

code, then a different FI customer can be assigned for each company code

(1:n).

Reasons for need to resolve invalid FI customer assignments

Since Master Data Synchronization (MDS) only supports 1:1 synchronization,

all assignments that are not 1:1 are invalid from the perspective of MDS.

During data migration, a synchronization link between business partners and

existing FI customers will be created from references in IS-H tables to FI

customers. If multiple assignments exist, the migration tool cannot determine

which assignment should be migrated and which ones are invalid. You must

resolve invalid assignments and decide which one should be migrated.

Unresolved assignments cannot be migrated to synchronization links. This will

not affect the billing processes in IS-H, or prevent you from working with the

system. However, changes in SAP Business Partner master data will not be

updated in the related FI customer.

20

21

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4

(IS-H 604), Business Function SAP Patient Management BP/OM

(ISH_BP_OM), you maintain patients and next of kin as SAP BP in the Clinical

Process Builder if you have activated conversion to the SAP Business Partner.

The entry of patient data further will be done in Clinical Process Builder.

To use SAP BP for patients you must specify a business partner grouping to

create patients as SAP business partners.

You must define the business partner grouping for new patients and next of kin

in the Customizing activity Maintain Business Partner Grouping for Patients and

Next of Kin according to the institution:

You can enter a maximum of two groupings for each object: one grouping

with internal number assignment and one grouping with external number

assignment.

You can specify different groupings for patients and next of kin,

respectively.

You can make different entries for each institution.

For more information, see Patient Management -> Patients -> Maintain

Business Partner Grouping for Patients and Next of Kin in Customizing for

Healthcare

22

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4 (IS-H 604), Business

Function SAP Patient Management BP/OM (ISH_BP_OM), you can maintain more than two addresses for

a patient if you have activated conversion to the SAP Business Partner.

An additional dialog box now displays an overview of all the addresses for a patient. You can also access

functions for creating and deleting addresses and for maintaining address details from this dialog box.

The dialog box for editing several telephone numbers for an address now contains two additional fields:

Country for the country code

Comment for entering an additional text on a telephone number

You can maintain one or more address usages for a patient address. An address usage is created when

an address is assigned to an address type.

You can also assign each patient a standard address type. You can use this role-specific address type in

combination with the address usages to control how the main address is displayed and how the

corresponding geographical area is determined.

You can define address types as you wish in Customizing for the SAP Business Partner under

Define Address Types.

Please note that SAP delivers a standard address type XXDEFAULT, which you must not delete.

For more information, see the following documentation:

Customizing under Cross-Application Components -> SAP Business Partner -> Business Partner ->

Basic Settings -> Address Determination

F1 help for the address type patient role.

23

The system is able to store persons assigned to cases also to patients, if the

role of case to person assignment is:

referral physician for inpatient cases (and system parameter GET_EUAR is

maintained)

referral physician for outpatient cases (and system parameter GET_EUAR

is maintained)

family physician

The system will store the following BP relationship categories:

NPPH01 Referring Physician of Inpatient (HC)

NPPH02 External Referring Physician of Inpatient (HC)

NPPH03 Referring Physician of Outpatient (HC)

NPPH04 External Referring Physician of Outpatient (HC)

NPPH05 Family Physician (HC)

NPPH06 External Family Physician (HC)

The external BP relationship categories will be created, if the physician has the

BP role HC External Physician.

24

Next of Kin:


Function SAP Patient Management BP/OM (ISH_BP_OM), you can maintain more than two next of

kin for a patient if you have activated conversion to the SAP Business Partner. An additional dialog

box now displays an overview of all next of kin for a patient. You can also access functions for

creating and deleting next of kin and for maintaining details on next of kin from this dialog box.

Employer:


Function SAP Patient Management BP/OM (ISH_BP_OM), you can record an additional or second

name for the patient's employer if you have activated conversion to the SAP Business Partner.

Death data:


Function SAP Patient Management BP/OM (ISH_BP_OM), a Death Data subscreen is available in

the Clinical Process Builder if you have activated conversion to the SAP Business Partner. You can

incorporate this subscreen in customer-defined variants. You can still maintain death data as before,

by choosing the menu path Extras -> Death Data.

Risk factors:


Function SAP Patient Management BP/OM (ISH_BP_OM), a Risk Factors subscreen is available in

the Clinical Process Builder if you have activated conversion to the SAP Business Partner. You can

incorporate this subscreen in customer-defined variants.

You can still maintain risk information as before by means of the menu path Extras -> Risk Factors

or the transaction codes NP04 (IS-H: Maintain Risk Information) and NP05 (IS-H: Display Risk

Information).

25

The program RNJOIN00 merges patients who have been entered twice in the system with their institution master records, cases, insurance relationships, and risk factors. Once they have been merged, the cases of the inactive patient are assigned to the active patient. The institution master records, insurance relationship proposal pool, and risk information are also copied. The patient who is deactivated is canceled when the patients are merged. A reference to the active patient is also stored in the deactivated one. The BP and it’s roles are not affected by the patient merge. In fact the general BP doesn’t get any information about the merging process.

26

27

28

29

30

31

32

33

1

2

3

4

5

6

7

8

9

Use transaction SM30 to maintain the following views for the assignment

of keys between IS-H and SAP BP:

- V_TNBPMIG03 for the academic titles

- V_TNBPMIG04 for the name prefixes

- V_TNBPMIG05 for the name affixes

- V_TNBPMIG06 for the form of address

- V_TNBPMIG07 for the marital status

If a unique assignment is not possible for all keys, that is, if some source keys or

target keys remain after mapping, you must first generate the relevant entries in

IS-H or SAP BP before you can then use them in the mapping table.

Example:

In IS-H, there is an academic title with the key 'DR.' and the text 'Dr.'. In SAP BP,

such a title is missing. You first follow the Implementation Guide (IMG) path

'Cross-Application Components -> SAP Business Partner -> Business Partner ->

Persons -> Name Components -> Maintain Academic Titles' to create a new entry

with the text 'Dr.' with the key 0001. Then use transaction SM30 to maintain a new

entry with the (IS-H) source key 'DR.' and the (SAP BP) target key '0001' for the

view V_TNBPMIG03.

For more information please refer to SAP Note 1475876.

10

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4 (IS-H 604), Business Function SAP Patient Management: Rearchitecture BP/OM (ISH_BP_OM), there are separate new tables to store the master data. All central data (common data) for all the business partners (BPs), patients, and patients with provisional master data is stored in the BUT000 table provided by SAP Business Partner (SAP BP). BUT000 has foreign-key relationships to the Address (BUT020), Roles (BUT100) and Relationships (BUT050) tables. Table NBUP hosts all data that is common to all IS-H BPs but is not handled by SAP BP (in other words, by BUT000). New tables are created to store the role-specific data for BPs, patients, and patients with provisional master data. The following table gives the relationships between the tables that existed prior to this release and the new tables: For BPs: IS-H BP SAP BP Re-Architecture Description NGPA BUT000 and NBUP General business partner data NDEB NCUS Customer NKRH NHSP Hospital NABG NEPR Employer NPER NPRS Person (Person refers to physicians, external physicians, and employees.) NKTR NINS Insurance provider For patients: IS-H Data Source SAP BP Data Target NPAT BUT000 and NPNT For patients with provisional master data: IS-H Data Source SAP BP Data Target NPAP BUT000 and NPPT The primary keys of master data tables NGPA and NPAT must be stored as references to the old records in the corresponding tables of SAP BP (NBUP and NPNT, respectively). This is necessary for the IS-H programs to distinguish between BPs in non-patient roles and BPs in HC Patient role. The reference also facilitates the update of migrated BPs where their corresponding IS-H object has changed in the meantime (delta migration before switching to SAP BP). The primary key of table NPAP will not be stored in the SAP BP table NPPT as reference. Instead, the old primary key of NPAP and references to this key in other IS-H tables will be updated during migration with the primary key of the SAP BP in role HC Patient w. Prov. Data. The references of the dependent tables for the HC Patient w. Prov. Data (in other words, other tables that store references to the primary key of NPAP) will be updated with the SAP BP keys. The following are also migrated: IS-H BPs with the deletion indicator set, IS-H patients with the cancellation indicator set and IS-H patients with provisional master data with the cancellation indicator set.

11

You can use different methods to extend business partners by adding attributes, for

example:

You can carry out extensions manually using the BDT. In this case you have to

create and include ABAP programs independently.

You can also use the Easy Enhancement Workbench (EEW) for the most important

extension forms. You do not need any knowledge of programming for this.

12

13

14

15

16

17

18

1

2

3

As of SAP ECC 6.0 Industry Extension Healthcare, Enhancement Package4,

Business Function SAP Patient Management Rearchitecture BP/OM

(ISH_BP_OM), with Organizational Management (OM) activated, the institution

semantics for SAP Patient Management have been preserved. The root must

be defined for every hierarchy in the OM framework.

An institution is now an organizational unit which participates as the root unit of

the hierarchy in OM. From the point of the entire Organizational Management

this organizational unit doesn’t need to be the root for the overall Organizational

Structure.

When Organizational Management (OM) is in production use, you must take

the following points into consideration for your organizational structure:

The Org. unit field creates the link to OM.

You can assign an existing organizational unit to the institution, or create a

new organizational unit in OM. This organizational unit represents the root

unit for your hierarchy in OM.

Your institution must be correctly assigned to an organizational unit in OM

to enable your organizational structure to be created and maintained in OM.

If you have created a new organizational unit using this IMG activity, this unit is

retained in the system if you cancel the creation or modification of an institution.

You can still use this OM organizational unit for the assignment to another

institution.

4

The field “Object ID for Institution” contains a unique eight-digit numeric key

that represents the institution organizational unit in OM. This field provides the

mapping for the institution in IS-H and the institution organizational unit in OM.

This assignment can also be done subsequently.

Links to other SAP components will be further stored in the IS-H specific

assignments of the institution like:

Company Code for SAP ERP Financials

Sales Organization for SAP ERP Logistics -> Sales and Distribution

5

An institution is an organizational unit which participates as the root unit of the

HC specific hierarchy in OM.

This organizational unit can also be used in other usages of SAP OM, like

Organizational Management in SAP Human Capital Management.

Example: The institution could represent a hospital in a hospital holding. But

only HC specific relationships will be used by HC specific transactions.

6

7

8

9

10

11

12

13

14

The interface layout of an application created with the help of the hierarchy framework

is divided into left and right screen areas. In the left screen area the object manager is

displayed. The right screen area is divided into a period area, an overview area and an

optional detail area.

The object manager, which is divided into an upper search area and a lower selection

area, is comparable to a 'permanent search help'. When you use Search Tools to

carry out a search for objects, for example organizational units, positions, persons or

cost centers, the system displays the search results in the selection area. You can

process objects from this set of search results on the right side of the screen.

In the overview area, the system displays the object in a hierarchical structure that you

can define over an evaluation path. The hierarchical structure is visualised in a tree,

where for each node, you can display in columns as much additional information as

you like. Above the overview area there is an application toolbar with functions

enabling forwards and backwards navigation and the period area for specifying a

selection date or selection period for time-dependent structures.

In the detail area the system displays an object with its detailed information. The

detailed information is shown on tab pages, typically one infotype per tab page. Each

tab page has a tab page header, which sums up the information on the tab page. You

can define in tables which tab pages are displayed for an object type

15

SAPEVENT:DOCU_LINK/DS:DE.OMSTOOL

16


Business Function SAP Patient Management Rearchitecture BP/OM (ISH_BP_OM),

with Organizational Management (OM) activated, the potential benefits of the OM

framework include transparency and clarity in the management of data.

The user interface contains a simplified view for accessing the hierarchy units at both

overview and detailed level. It also provides a search option to find any unit of interest.

On searching for a particular unit (based on a variety of filtering constraints), all units

matching the criteria appear in the selection area along with their hierarchy units. You

can display the overview of a unit, which contains some basic fields, in the overview

area by double-clicking the unit in the selection area.

In the overview area you can trace the hierarchy above and below the unit of interest.

This gives a clear overall picture of the units participating in the hierarchy, and

relations in the hospital structure. You can view the hierarchy, and hence the relations

of the objects, with different details. You can access this function by choosing the

relationship type from the first option in the overview toolbar. In the overview area, you

can also change the hierarchy at any node by right-clicking the node and choosing the

option to either create a new unit or assign an existing unit from the system. The

details of the same are filled into the detail area and saved. You can display the

information in the detail area by double-clicking a particular unit in the overview area.

The information in the detail area is grouped semantically in various tabs. The screens

in these tabs are similar to the old SAP Patient Management screens.

17

With the search tools for each object type you can search for objects in various

object type-specific techniques. In addition, the object type itself can contain a

search tool. The object types are marked with the respective object type-

specific symbol.

The following search methods exist:

1: Search terms: You search for a name, abbreviation or numeric ID. You

can also search using the entry *

4: Structure Search: In the selection area the system displays all found

objects of the relevant object type in a tree structure, ordered according to

their assignment in the organizational plan

3: Free Search: The Free Search search tool uses the InfoSet Query. You

have to specify the search criteria first

2: Healthcare Search: Here you can search via the HC OU/BU ID

18



(ISH_BP_OM), with Organizational Management (OM) activated, the semantics

of unique ID for organizational units (OUs) and building units (BUs) are, in

general, preserved after the re-architecture.

You find the identification key relevant for SAP Patient Management for OUs in

the field HC OU and for BUs in the field HC BU. Previously, these fields were

technically-named ORGID and BAUID respectively. You can enter values for

these fields during the creation of an OU or BU.

If you are using internal numbering, you can leave this field empty. The system

does not assign internal numbers immediately following the input (as in the

former SAP Patient Management maintenance). Instead, it assigns the internal

numbers when you run the release report for OUs (transaction NB53) or the

release report for BUs (NB43) separately.

For existing OUs and BUs, the system displays the identification key in the

overview area (column name HC OU/BU).

During the creation of any object, the system also generates the identification

key relevant for OM automatically. The system displays this identification key

(technical name OBJID) in the overview area also (column name ID). The

system needs the identification key within the OM transactions to identify the

objects. It has no further relevance for SAP Patient Management.

19

In the framework, you can maintain OUs, BUs and their relationships. In order

to give an oversight of the different relationships, the framework offers the

following views on the hierarchies:

Complete Hospital Hierarchy: Displays the complete hospital hierarchy.

Departmental Assignments to Org. Units: Displays the hierarchy involving

departmental OUs and the BUs assigned to them via departmental

relationship.

Building Unit Hierarchy: Displays the hierarchy involving BU relationships,

showing both primary and secondary relationships.

Organizational Complete Hierarchy: Displays a complete hierarchy

involving interdepartmental relationships between OUs.

Organizational Hierarchy Assignments: Displays an organizational

hierarchy with only assignment relationships.

Organizational Inter-dept. Assignment: Displays an organizational hierarchy

with only interdepartmental relationships.

20

By defining relationships between objects, you create a hierarchy of objects that mirrors your organizational structure. There are many different types of relationships between objects in the component Organizational Management. It is the relationships between objects that give information its value. The relationships between objects will be stored in the Relationship infotype (1001). When you create a new object, the system creates that object’s relationships. Which relationship you can create depends on the selected view (“Complete Hospital Structure” allows to create all HC objects) . The following Relationships will be used for SAP Patient Management: Between OUs and OUs

Hierarchical assignment: Relat’ship 865: SURGERY “Is org. assigned above” WARD1 Interdepartmental assignment: Relat’ship 860: SURGERY “occupies” WARD2

Between OUs and BUs Primary assignment: Relat’ship 862: WARD1 “Occupies primarily” Room E1t Secondary assignment: Relat’ship 863: OUTPAT “Occupies secondarily” Room R1 Departm. Assignment (This relationship replaces the assignment between BUs and

Departments in Planning Characteristics.): Relat’ship 864: SURGERY “Occupies secondarily” Room E2.

Between BUs and BUs Hierarchical assignment: Relat’ship 861: Room R1 “Contains” Bed B1

More information about OM relationships you can find Customizing of OM: Personnel Management -> Organizational Management -> Basic Settings -> Data Model Enhancement ->Relationship Maintenance -> Maintain Relationships

21

An enterprise’s organizational plan is constantly undergoing change. For this

reason, Organizational Management allows you to edit the organizational

structure (assignments) as well as individual objects according to key dates.

A key date and a preview period are always set in the HC views.:

Every time you log on, the current date is set as the key date. You can

change the key date. Data valid on the date you have selected is displayed.

When you logon initially, a preview period of 3 months is set, that is, all

changes to data that happen in this period are displayed. You can change

this preview period. Next time you log on, the preview period which you

selected is set.

When you create an organizational unit in the overview area:

the validity of the object begins with the key date set, this can be moved

forward in the detail area

the assignment begins with the key date set

If you assign an object to another object in the overview area or detail area,

the new assignment applies from the key date to the end of the validity of an

object.

22

Deletion of objects (Org Units and Building Units) can be done via the

“Deletion” button. The system will set the deletion flag in the object. Deleted

objects can not be used anymore.

A deletion of assignments is not allowed for HC assignments. A deletion

would detach the organizational unit from the assigned institution, which is not

permitted. Once created, an IS-H organizational unit must always belong to an

institution and cannot be changed from one institution to another.

An organizational unit can be reassigned to an other organizational unit. To do

this, you have two options:

Right-click on the higher organizational unit, choose Assign, and assign

organizational unit below it.

Drag and drop the organizational unit below the higher organizational unit.

23

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business Function SAP

Patient Management Rearchitecture BP/OM (ISH-BP-OM), with Organizational Management (OM)

activated, organizational units (OUs) and building units (BUs) are assigned an object type in the OM

framework to identify the semantics of the object. The OM framework contains a predefined object type,

'O', for OUs. SAP Patient Management OUs will reuse this type. For BUs, the object type 'N0' is provided

to cater to the needs of SAP Patient Management.

In the backend of the OM framework, infotypes are used to store the data. Infotypes are collections of

semantically-matching objects. For example, an 'Address' infotype caters to the need for address storage,

the 'Basic Data' infotype caters to the need for key information, and so on.

To maintain the data for various OUs and BUs, the OM framework provides a well-managed user

interface providing exhaustive functionalities. The user interface contains a detail area, where

semantically-grouped data fields serve as information entry points. This detail area comes with an

overview area and an object manager, giving complete access to the entire hierarchy and allowing easy

maintenance.

Some infotypes already exist in the OM framework and are reused. These infotypes are common to both

OUs and Bus (Data storage!):

Infotype ID: 1000: Stores the object's basic information such as name, short text, and validity dates.

Infotype ID: 1001: Stores the complete information of relationships. Data that has previously been

stored in the tables TN10H, TN10I, TN11H, and TN11O is now be stored in this infotype table.

Infotype ID: 1002: Description (comments for OUs).

Infotype ID: 1027: Site-Dependent Info (for calendar).

Infotype ID: 1028 : Address: Stores address-related information. Data that has previously been

stored in the tables NADR and NADR2 is now stored in this infotype table.

Infotype ID: 1032 E-mail Address: Stores the e-mail address information that has previously been

stored in the table NADR.

24

The following infotypes are new and are specific to OUs (Data storage!):

Infotype ID: 6080: Key Data: Stores the SAP Patient Management mapping

data. The Healthcare (HC) OU ID and the OU category are stored here.

Infotype ID: 6081: Administrative Data: Stores the blocking, releasing, and

deletion indicator details of NORG.

Infotype ID: 6082: HC Specialty Details & Indicators: Stores specialty

indicator details and other indicators of NORG.

Infotype ID: 6083: Additional Telephone Data

Infotype ID: 6084: Additional Specialty Details

Infotype ID: 6085: Additional Name (language-dependent)

Others for i.s.h.med and other country versions

25

The following infotypes are new and are specific to Bus (Data storage!):

Infotype ID: 6091: Administrative Data: Stores the releasing and deletion

indicator details .

Infotype ID: 6092: Facility Characteristics Data: Stores the data that has

previously been stored in the table TN11A.

Infotype ID: 6093: Planning Characteristics Data: Stores the data that has

previously been stored in the table TN11P.

Infotype ID: 6083: Additional Telephone Data

Previously, in the planning characteristics you could maintain an Organizational

Unit (OU) with regard to departmental assignments between OU and Building

Unit (BU). Now, the relationship between an OU and a BU is defined through

the relationship 865 (Is Org. Assigned Below/Above).

Also, planning characteristics and facility characteristics are now directly

attached to the building unit.

26

Release program for Organizational Units for a certain Institution: Changed or new created OUs must be released also after switch to OM. The program checks the organizational unit hierarchy to ensure that the

assignments of organizational units to each other and to building units is consistent. If no errors are detected for an organizational unit when the check is run, the system sets the release indicator in the master data of this organizational unit. This release indicator means that the organizational unit can be used in the IS-H functions (assignment within a movement, service entry, and so on).

If you have specified internal number assignment for organizational units, this report assigns numbers to all organizational units that do not have a Patient Management "HC-OU" ID. This is done based on your Customizing settings and applies both in test mode and in productive operations.

Release program for Building Structure: Changed or new created BUs must be released also after switch to OM. The program checks the building hierarchy to ensure that the assignments

of building units to each other and to organizational units is consistent. If no errors are detected for a building unit when the check is run, the system sets the release indicator in the master data of this building unit. This release indicator means that the building unit can be used in the IS-H functions (assignment within a movement, and so on).

If you have specified internal number assignment for building units, this report assigns numbers to all buidling units that do not have a Patient Management "HC-BE" ID. This is done based on the settings you make in Customizing and applies both to test mode and productive operations.

27

28

1

2

3

4

5

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business Function SAP Patient Management: Rearchitecture BP/OM (ISH_BP_OM), with OM activated, data relating to the hospital structure is stored in OM database tables. After the changeover, the following tables are replaced: IS-H Database Tables OM Database Tables Organizational Units (NORG) Object (HRP1000) Description (HRP1002) Calendar (HRP1027) Address (HRP1028) HC Identification (HRP6080) Administrative Data OU (HRP6081) Specialties + Indicators (HRP6082) Additional Name OU (HRP6085) Building Units (NBAU) Object (HRP1000) Description (HRP1002) HC Identification (HRP6080) Administrative Data BU (HRP6091) Planning Characteristics (TN11P) Planning Characteristics (HRP6093) Facilities Characteristics (TN11A) Facilities Characteristics (HRP6092) Hierarchy of Organizational Units (TN10H) Relationships (HRP1001) Inter-Dept. Bed Asgnmts (TN10I) Relationships (HRP1001) Hierarchy of Building Units (TN11H) Relationships (HRP1001) Assign Building Units to Org. Units (TN11O) Relationships (HRP1001) Specialty-to-OU Assignment (TNKFO) Additional Specialties (HRP6084)

6

7

Evaluation paths are delivered by SAP an inserted into OM Customizing. HC

specific evaluation paths start with technical name ISH…

An evaluation path is an instruction to the system which determines which

object types and relationship(s) are to be included in an evaluation of your

organizational plan.

One or more relationships are then used as "Navigation paths" for evaluating

structural information in your organizational plan (relating to the organizational

or reporting structures). The sequence of the relationships included in the

evaluation path is decisive in how the results of the evaluation are displayed.

The evaluation path also defines which objects could be created or changed.

Example:

If you select the evaluation path ISH_BLDH (Building structure is used),

you can only display, change or create Building units, because it only

displays objects of type “N0” (building units) assigned via relationship 861

(“Contains”).

If you want to show the whole structure you have to use the evaluation path

“Complete Hospital Structure”.

8

9

10

11

1

2

3

4

If you want to use SAP Business Partner (SAP BP) for maintaining BP and patient data, you must migrate the existing data located in SAP Patient Management. The data that must be migrated can be separated into three categories. The dependencies between the categories (for example, category 3 depends on category 2, and category 2 depends on category 1) determine the sequence in which the data is migrated.

1. Customizing data: Parts of IS-H-specific Customizing for table fields that will be migrated to tables owned by SAP BP, for example Form of Address and Marital Status.

2. Master data: IS-H BPs and BP functions IS-H Patients IS-H Patients with Provisional Master Data

3. Object link data (data modeling relationships between objects) Implicit relationship (for example, the patient's next of kin is stored as free text) Foreign key relationships and references to keys of other objects (for example, reference to

patient's employer) Separate foreign key assignment tables modeling relationships

The data is migrated in the following phases : Phase 0: General Migration Activities for BP Phase 1: Migration Preparation for BP Phase 2: Data Migration for BP During Uptime Phase 3: Data Migration for BP During Downtime

You can access the data migration programs for in Customizing for SAP Healthcare - Industry-Specific Components for Hospitals under Tools -> Migration of Business Partner and Hospital Structure -> Migration of Business Partner

5

This Customizing activity presents a consolidated status of Business Partner (BP) migration. The information is divided into two categories: Master Data Migration Status Execution Status

Master Data Migration Status This section informs you on the status of the Master data. This includes the following categories: Business partners Patients Patients with Provisional Master Data Third Party Payers

You are informed about the number of records migrated, and also the number of records not migrated. For clearer statistics, you are also given the percentage details of the migrated or not migrated records. The application log and the execution status (of the last execution in productive mode) for each category of records are also available. Execution Status This section contains general information about the migration status, which includes the following: Current Migration State: This gives you the current phase details of BP migration. Currently Running Step: This informs you of the step that is currently running (if any). If a step

is running, it provides you with the start date and time. Last Run Step (Prod. Mode): This informs you of the last executed step. In the case of steps

other than 'confirmation steps', you are informed only for the last execution in productive mode.

The application log and the execution status (of last execution in productive mode) are also available

6

This is a preliminary phase for general preparation of the Business Partner (BP) migration. You

complete this phase to confirm the preparatory activities before starting the migration. There are

four confirmatory steps in this phase, which are as following:

Understanding of BP Migration. For more information, see: The documentation for the Customzing activities of the different phases

The information on the various steps of the corresponding phase (click the 'I' button)

The Release Notes for SAP ECC 6.0 Industry Extension Healthcare, Enhancement Package 4,

Business Function SAP Patient Management: Rearchitecture BP/OM (ISH_BP_OM)

Customer Code Adaptation: If the changeover is active, the standard SAP-provided code has

already been adapted to access data from the tables created after SAP ECC 6.0 Industry

Extension Healthcare, Enhancement Package 4. However, you should check if your own

modifications have been adapted. SAP recommends completing all necessary adaptations

before the final changeover to SAP Business Partner (SAP BP) is made. Redirections need to

be done for the following points: Database Access

Reports

There are also two Business Add-Ins (BAdIs), ISH_BP_CV_MIGRATE and

ISH_BP_MIGR_FILL_DETAILS, which are relevant for migration. For more information on

customer code adaptation, please see the release notes.

Test Migration Run: SAP recommends that you perform a migration in the test system before

starting the migration in the production system. The test migration is recommended so that

inconsistent customizing and unclean data can be found and corrected or removed before the

actual migration is carried out.

Training of Users on BP Transaction: Once the migration is complete and the changeover to

SAP BP is made, business partners are maintained with the Maintain Business Partner

transaction (BP). SAP recommends that you are trained on this transaction, and that you

experiment with the various functionalities.

7

This phase consists of the steps to prepare the system for data migration. The

actual migration is carried out in the next two phases (Phases 2 and 3). This

phase can be executed in two modes, called General Mode and Expert Mode.

General Mode is the default mode of execution. You can switch to Expert Mode at

any point by using the toggle button in the application toolbar. These two modes of

execution are interchangeable any time during migration. Expert mode requires

more input from you during execution, and is recommended for expert users.

Some of the steps in this phase are optional, while others are obligatory. SAP

strongly recommend that you execute all the steps in the given sequence. SAP

also recommend that you read the documentation available in the information (i

button) corresponding to each step, before executing that step.

1. Confirm Setting of Migration to Phase 1

2. Confirm Customizing Preparation

3. Run Preparation of HC Specific Customizing

4. Maintain Mapping of Customizing

5. Run Migration of HC Specific Customizing

6. Run Resolution of Multiple FI Assignments

8

If the changeover is active, the standard SAP-provided code has already been

adapted to access data from the tables created after SAP ECC 6.0 Industry

Extension Healthcare, Enhancement Package 4, Business Function SAP Patient

Management: Rearchitecture BP/OM (ISH_BP_OM). However, you should check

if your own modifications have been adapted. SAP recommend completing all

necessary adaptations before the final changeover to SAP Business Partner (SAP

BP) is made. This affects the following areas:

Database access: You must redirect all accesses to the database tables

created before this release, for both business partners (BPs) and patients, to

the SAP BP and Health Care Role-Specific tables created for SAP ECC 6.0

Industry Extension Healthcare, Enhancement Package 4, Business Function

SAP Patient Management: Rearchitecture BP/OM (ISH_BP_OM). Please

refer to the release notes for more details.

Reports: SAP has already adapted all standard reports. SAP recommends the

adaptation of any customer-specific reports accordingly.

BAdIs: The following BAdIs are relevant for BP migration: ISH_BP_CV_MIGRATE (Used to fill country version-specific BP roles)

ISH_BP_MIGR_FILL_DETAILS (Used to change the BP information during Migration)

9

This phase consists of steps which are responsible for master data migration. All master data

related to business partner (BP) roles, relationships, patients and dependent objects is migrated

during this phase. This ensures a short span for Phase 3 (downtime phase for delta records

migration). This results in a shorter downtime for your productive system.

SAP recommends that you complete all steps in Phase 1 before beginning Phase 2. You must

complete the following steps in this phase:

Confirm Setting of Migration to Phase 2

Run Migration of HC BPs and Relationships (available only in General Mode)

Run Migration of HC Business Partners (available only in Expert Mode)

Run Migration of Relationships corresponding to HC BPs(available only in Expert Mode)

Run Migration of Patients and Dependent Objects

Run Migration of 3rd Party Payers

Run Migration of Patients with Prov. Data

Ensure that all records (BP roles and relationships, patients and relationships, third party payers,

and so on) are migrated. You are not restricted from proceeding even if all records have not been

migrated, but we strongly recommend that you migrate all the records corresponding to a step

before you do so. In the case of an error, try to resolve it (on the basis of the log messages) and re-

migrate the record(s). If you don't resolve the errors and re-migrate, the record(s) will not be

migrated and you will not be able to maintain them via the BP transaction. However, you will have a

chance to migrate the remaining records in Phase 3. In Phase 3, you will migrate or re-migrate

those objects which were newly-created or changed during Phase 2.

You can execute this phase in either General Mode or Expert Mode. General Mode is the default

execution mode. You can switch to Expert Mode at any time with the toggle button in the

application toolbar. The two modes are interchangeable any time during migration. Expert Mode

requires more details during execution and is recommended for expert users.

10

During this phase the customer's productive system will be down. You must not use the system for any purpose other than migration in this phase. In this phase, data is migrated for those records which are changed, newly-created, or left out during Phase 2. This phase repeats the steps for data migration from Phase 2. It also includes some new steps. Completing this phase with the step Confirm Migration Success activates the changeover to SAP Business Partner (SAP BP). Once this step is completed, you cannot run any of the migration steps. Hence, SAP strongly recommends that you migrate all customer-relevant records corresponding to a step before confirming the migration success. Once you complete Phase 3, you can start the productive system and maintain the BPs via the BP transaction. You must execute all steps in Phase 2 before starting Phase 3. You must execute the following steps during Phase 3: Confirm Setting of Migration to Phase 3 Run Migration of HC BPs and Relationships (available only in General Mode) Run Migration of HC Business Partners (available only in Expert Mode) Run Migration of Relationships corresponding to HC BPs (available only in Expert Mode) Run Migration of Patients and Dependent Objects Run Migration of 3rd party payers Run Migration of Patients with Prov. Data Run Migration of Screen Modification Run Resolution of Multiple FI Assignments Confirm Final Customizing Steps Confirm Migration Success

We recommend that you ensure that all relevant records are migrated during this phase, but you are not be restricted from proceeding even if you have not migrated all records. You can complete the migration process migrating only a few business partners, patients and attached relationships. Hence, it is strongly recommended to migrate all the records corresponding to a step. In the case of an error, try to resolve it using the log messages and migrate the record again. If you don't resolve the errors and re-migrate, those records will not be migrated and you will not be able to maintain those via the BP transaction. Once this phase is completed you will not be able to migrate any non-migrated records.

11

12

You can access the data migration programs for in Customizing for SAP Healthcare - Industry-Specific Components for Hospitals under Tools -> Migration of Business Partner and Hospital Structure -> Migration of Hospital Structure Phase 0: General Migration Activities for OM

During this phase the general preparation will be executed. Here you have to prepare the project team and you have to adapt customer specific coding to the Organizational Management.

Phase 1: Migration Preparation for OM In this phase you will perform those activities which could be executed

before the system down time. The steps involve adapting Customizing for Organizational Management (OM), the maintenance of the mapping of IS-H OUs with OM units and adjusting screen modification data.

Phase 3: Data Migration for OM During Downtime The actions for phase 3 of the migration comprise the key steps in the migration project.

They must be performed during the system downtime in order to prevent inconsistencies that could result from objects being created during the migration. You can only perform the steps in test mode before the start of downtime. Here you run the specific migration programs which migrate IS-H objects (Institutions, Organizational units, Building Units) to the objects of Organizational Management. The execution of consistency checks and release programs are also steps of this phase. In the end of this phase you have to indicate the finalization of OM and BP migration.

Phase 4: Data Migration for OM after migration This phase consists of a final test of the migration to ensure the stability of

the system and a proper go live.

13

Phase 0 consists of steps that are recommended but not mandatory for the implementation of the migration project. You can confirm the various steps. Your confirmation is saved as an application log in the system. You can then access this log either using transaction SLG1 or by choosing the log icon next to relevant step in the phase. SAP recommends the following steps: Understand the Hospital Structure Migration. For more information, see:

the Release Notes for SAP ECC Industry Extension Healthcare 7.0 the system documentation the document for the IMG activities of the different phases the information on the varios steps of the corresponding phase (i icon)

Adapt Custom Code This step is relevant only if you have customer modifications in the master data

environment, or if Business Add-Ins (BAdIs) are used in the master data environment. The following BAdIs are relevant in Organizational Management (OM):

– HRBAS00INFTY – HRBAS00_RELAT – ISH_OM_CUST_DATA_MIGRATE – ISH_OM_MED_NORG_FILL

For more, information, see the respective BAdI documentation

Run Test Migration: SAP recommends that you test the migration of production data in a test system. If you

execute this step, you can estimate the downtime of the production system from the runtime of the different steps and get an overview of the data consistency from the logs.

Train Users on New SAP OM Transaction Once the migration is complete and the changeover to SAP OM is made, Organizational

and Building Units are maintained with the OM transaction. SAP recommends that you are trained on this transaction, and that you experiment with the various functionalities.

14

As Part of the phase 0 of the hospital structure migration it is necessary to adapt customer code. The hierarchy framework provides a set of BAdIs whose implementations allow you to control the system behavior. The relevant BAdIs in OM are HRBAS00INFTY and HRBAS00_RELAT. Depending on how your system is configured, the following adjustments may be necessary: You have to adjust customer-specific modifications to the maintenance of

building units and organizational units using the OM BAdIs specified above. Customer enhancements to the tables NORG, NBAU, and TN11P can be

migrated and managed as follows: The migration of hospital structure data from IS-H offers you the possibility in the

enhancement spot ES_ISH_OM_MIGR with the BAdI IS_OM_CUST_DATA_MIGRATE to migrate customer enhancements of the tables NORG or NBAU or of other master data tables to customer-specific infotypes. For more iformation about this, see the documentation for the BAdI

Customer-specific data can be filled using the BAdIs ISH_OM_CUST_NBAU_FILL, ISH_OM_CUST_NORG_FILL , and ISH_OM_CUST_TN11P_FILL.

The system dynamically performs foreign-key checks on the data elements ORGID and BAUID. You must implement these checks in customer modifications as well.

SAP provides function modules to read out master data from OM. More information you can find in release notes, also for tables containing migrated data.

The following configurations are not affected by the changeover: It is not necessary to adjust modifications to the source code of the movement

data. It is not necessary to make adjustments in print control. Access to the new tables is automatic when you use the new read function

modules. The changeover has not caused the keys for the fields NORG and NBAU to change.

15

In Phase 1: Migration Preparation for OM, the system offers the following steps: Confirm Adaptation of OM Customizing: This step is relevant only if you wish

to change Customizing for Organizational Management (OM) in the customer's system. Here you can, for example perform the following steps: Assign additional SAP standard infotypes in the Healthcare scenario ISH_OM (For more

information about this, see Infotype Maintenance and Maintain Object Types. Assign customer-specific infotypes in the Healthcare scenario Create customer-specific scenarios Create customer-specific relationships Create customer-specific search nodes

Confirm Status of OM Data: With this step, you tell the system whether you are already using Organizational Management (OM) to represent IS-H organizational structures.

Maintain Mapping Table: With this step you run the transaction ON_MIG_PHASE_MAP to maintain: Which institution in IS-H corresponds to which institution in OM Which OU in IS-H corresponds to which OU in OM

Run Migration of Screen Modification (Test): With this step you run program RN_OM_MIGRATE_DYNP_ATTR in test mode. This program allows you to migrate screen modification entries. When you run this program, the system adjusts entries that exist for master data aintenance screens in transaction ON04 for the tab page screens in the hierarchy framework.

Run Migration for Screen Modification (Prod.): With this step you run program RN_OM_MIGRATE_DYNP_ATTR in productive mode (data will be saved)

16

One main step of phase 1 is the Maintenance of the Mapping Table of the existing organizational units (OUs) in SAP Patient Management with those of objects in OM. This caters to the scenario where you are already using OM. You are offered a Customizing view for the purpose of mapping. This view is only accessible if OM already in use is selected in the step Confirm Status of OM Data. This view different functionalities: Propose Values pushbutton which generates a proposal for every SAP Patient Management

OU and institution based on matching the short text of the OU or institution and the abbreviation of an object.

Double-clicking on an SAP Patient Management OU in the view displays the respective details.

Check Consistency pushbutton: System checks the consistency of the generated proposals. Specific consistency messages are shown for reference, but these messages are not logged in the database. The following checks will be executed: You must confirm all rows. Each object ID in OM is allowed to be assigned once only. Only existing object IDs are allowed to be assigned. The validity of the IS-H objects and of the OM objects must be the same. If the validity start and the

validity end of the IS-H object lies outside of the validity of the OM object, the system issues an error message. If the validity start and the validity end of the OM object lies outside of the validity of the IS-H object, the system issues a warning. In the first case, you must bring the validity of the OM objects and that of the IS-H objects in line with one another.

Release Data pushbutton: the specific consistency messages are shown and logged for future reference. Data can only be released successfully when no error message is displayed in the log. Releasing data is one of the prerequisites for downtime. If you need to reset the data release because it was started by mistake, use the RN_OM_RESET_STATUS program. You can use this program to reset the status of the maintenance table as long as downtime has not been started.

The Customizing view allows you to confirm the mapping so that the mapping information is taken into account in the data migration reports of institution data and SAP Patient Management OUs. During release, the system checks if all data is confirmed. Data can only be released if every SAP Patient Management OU is either confirmed to be linked to, or unlinked to, an OM organizational unit.

The logon language is used for matching the SAP Patient Management short text to the OM object abbreviation. If more than one short text is matched to an object abbreviation, only the first match is displayed as a proposal. However, the view has a dialog box indicating that more than one match exists, offering you the possibility to search for other objects and then make a final proposal.

17

The system offers the following steps : Confirm Downtime: This obligatory step marks the downtime of the system to

start the migration of the operative data. Run Consistency Check (Test and Productive Mode): The system checks

whether OM already contains organizational units with the same IS-H ID. It also checks whether the corresponding institution exist.

Migration of Institution Data (Test and Productive Mode): This step runs the program RN_OM_MIGRATE_INSTITUTION. For each institution that

exists in IS-H, the program creates an organizational unit (OU) with the object type "O" in OM.

SAP recommends to run the program in tst mode first (also possible before down time) During data transfer, while creating the infotype 1000 (basic infotype of the object), the

system models an institution in the logon language as an organizational unit with the corresponding abbreviation and name as attributes.

Run Migration of IS-H Data (Test and Productive mode): This step migrates organizational units and building units to Organizational Management

(OM) by means of the RN_OM_OU_BU_MIGR program. For each organizational unit and building unit, the program creates a corresponding object

in OM. In the process, it assigns rganizational units (OUs) to the object type "O" and building units (BUs) to the object type "N0".

SAP recommends to run the program in tst mode first (also possible before down time).

Run Release Program (Test and Productive Mode): This step runs the release program for the OM structure. SAP recommends to run the program in test mode first Datasets for those organizational and building units that are consistent in hierarchy and

attributes are marked to set the release indicators.

Confirm Migration Success: This step activates the Customizing switch that confirms the use of OM for SAP Patient Management hospital structure management.

18

19

Documents

BP -ISH en SAP.pdf