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 'ISH 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

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, 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 As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business Function SAP Patient Management: Rearchitecture BP/OM (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

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business Function SAP Patient Management: Rearchitecture BP/OM (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

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 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

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business Function SAP Patient Management: Rearchitecture BP/OM (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

As of SAP ECC 6.0, Industry Extension Healthcare, Enhancement Package 4, Business Function SAP Patient Management: Rearchitecture BP/OM (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:  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 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:  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 record an additional or second name for the patient's employer if you have activated conversion to the SAP Business Partner. Death data:  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), 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:  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), 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

16

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, 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 typespecific 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

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, 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

  

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 OUs and BUs

 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 Organizational Units (NORG)

OM Database Tables 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 remigrate 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