Ansicht
Dokumentation
N1_MIGPRG - Migrate Preregistrations to Clinical Orders
ROGBILLS - Synchronize billing plans SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3upThis documentation is copyright by SAP AG.
Purpose
The program migrates preregistrations to clinical orders with preregistered order items.
For the migration of the transaction data, the system uses the order types that were created during the migration of the preregistration types. A clinical order with order item and/or treatment item is created for each preregistration. Most of the preregistration data is retained. Appointments, services, and movements are exceptions. The preregistration data for these objects is reassigned to the new clinical order or to the respective order items.
Note that you must run this program after the first upgrade of your system to Release 4.72 or later. If your initial use of i.s.h.med is as of Release 4.72, it is not essential to run this program.
Integration
Prerequisites
The following criteria must be satisfied prior to running the program in production mode:
- Patch 2 is imported for the release upgrade to 4.72.
- The preregistration types were migrated to the "clinical orders" order type in the course of the upgrade. Do not modify the generated types before migrating the transaction data.
- You can run this program at your convenience without having to interrupt normal operation. When possible, prevent the use of preregistrations and clinical orders during the migration.
Runtime/Memory Requirements
Depending on hardware performance, approximately 120-150 preregistrations a minute can be migrated.
Since this generally means that the default runtime for dialog applications is exceeded, it is recommended that you start the program as a background application.
The program reserves approximately 5 kB of main memory for each preregistration to be migrated, i.e. 5 MB for 1000 preregistrations. Make sure that the general system load allows the program to reserve this memory. If this is not the case, migrate the preregistrations in appropriate batches. (A parallel migration could result in data deadlocks (for example, patient locked).
Features
Selection
The following selection criteria are provided to control program execution:
- VKGIDIN: preregistration (VKGID) to be migrated, or start of interval for the preregistrations to be migrated.
- VKGIDMX: End of interval for the preregistrations to be migrated.
- TESTONLY: Selects execution in test mode
- ALLVKGS: Selects the migration of all preregistration (overrides VKGIDIN, VKGIDMX)
- SHSTORN: Selects the display of canceled preregistrations in the migration log (canceled migrations are not migrated).
Standard Variants
Output
The program creates a migration log. For each preregistration, the migration log shows the successful migration or the reason for unsuccessful migration. The number of preregistrations processed and the duration of the migration in seconds is shown at the foot of the log.
Activities
First run the program in test mode. The program returns a log containing all of the preregistrations that could not be migrated (mainly due to inconsistencies in the original data). Take necessary actions to correct the data records concerned.
If necessary, run the program in test mode again, and check whether the corrected data records could now be migrated.
After completing corrective action, run the program in production mode. A corresponding log is output.
Original data records that still contain errors are identified by '@#NOK#@' in the STUSR field.
You can further process these data records. Delete the entry in STUSR, and run the program again in test or production mode.
Example
CL_GUI_FRONTEND_SERVICES - Frontend Services rdisp/max_wprun_time - Maximum work process run time
This documentation is copyright by SAP AG.
Length: 4131 Date: 20240531 Time: 114704 sap01-206 ( 73 ms )
