bp -ish en sap.pdf
TRANSCRIPT
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
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 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
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
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