Ansicht
Dokumentation
ISH_TC_OVERVIEW - Global Data for Treatment Authorization
Fill RESBD Structure from EBP Component Structure CL_GUI_FRONTEND_SERVICES - Frontend ServicesThis documentation is copyright by SAP AG.
A treatment authorization is required so that those involved in the treatment of a patient have access to the patient's medical data. When a user attempts to access patient data, the system runs a global check in SAP Patient Management (IS-H) and the clinical system (i.s.h.med) to determine whether the logon user has treatment authorization for the selected patient. The user can be authorized to access all the patient's data or only data relating to the current case.
The treatment authorization does not prevent the user from entering data for a patient. They have access to the create functions for the following data:
- Admission
- Transfer
- Outpatient visit
- Appointment
- Preregistration
- Clinical order
- Request
The system checks for treatment authorization for specific dates, based on rules defined in Customizing relating to the following:
- The user's OU jurisdiction for departmental, treatment, and nursing organizational units (OUs)
- The patient's OU relationship with departmental, treatment, and nursing OUs
If the patient-OU relationship matches the user's jurisdisction, the system issues the treatment authorization and the user can access the patient's medical data according to the SAP authorizations he or she is assigned. The system checks and issues treatment authorizations in line with the OU constellation in background processing.
A patient's relationship with an OU derives from a planned or existing movement that has been entered in the system. This can be an admission, a transfer, or an outpatient visit. The patient also has an OU relationship in the following cases:
- Appointment
- Preregistration
- Clinical order
- Request
The start and end of the patient-OU relationship are derived from the absence period or time specified in the case data, or from the time or period of a planned movement. An OU relationship also comes into being independently of an appointment, relative to the date on which the following are created:
- Preregistration
- Clinical order
- Request
A user's treatment authorization is only valid for as long as the patient has an OU relationship with the user's OU jurisdiction. If a follow-up time has been defined in Customizing, this begins for the same OU constellation directly after the end of the treatment authorization. The follow-up time gives the user access to the data for postprocessing.
If the follow-up time is past and an application period has been defined in Customizing, the user can make a temporary application for treatment authorization for specific dates within this period, provided he or she previously had treatment authorization.
If a user requires temporary treatment authorization for a patient who is no longer present but is unable to apply for it him or herself, the application can be delegated to another user who is specially authorized as initiator; this is only possible if the initiator himself has a treatment authorization within the follow-up time or is authorized to make a temporary application during the application period.
NOTE
If a patient is not present in any of the organizational units in the hospital and a follow-up period
for existing medical data has not been defined, the system does not automatically issue a treatment authorization when a user accesses this data.
If this user is not allowed to request temporary treatment authorization according to the Customizing
settings and delegation by another user is not possible, the system prevents access to the patient's existing medical data.
If a patient who is not currently present in the hospital has a medical emergency, a user may need to access the medical data in the system. The system does not display the data to the user because the treatment authorization cannot be determined or requested temporarily due to the Customizing settings.
We recommend that you do not restrict the request period for issuing a temporary treatment request for users who can be involved in treating patients in medical emergencies.
[ END OF NOTE ]
If a user does not have treatment authorization for a patient who is present, he or she can always apply for a temporary treatment authorization in case of emergencies.
The system logs applications and delegations. Report RN1TC_REPORTING allows you to evaluate the logs.
A temporary or delegated treatment authorization is valid until midnight on a given date.
If you use the i.s.h.med treatment authorization for documents, we recommend deactivating this function once you have activated the treatment authorization function for IS-H and i.s.h.med. However, it is possible to use both functions.
Table maintenance in Customizing for assigning OU jurisdictions to roles is protected by special security mechanisms. For this purpose, your authorizations contain the authorization object S_TABU_DIS with the attributes nu and nc.
You make the following settings in the Customizing activities for the treatment authorization:
The functions of the treatment authorization are activated automatically when you specify a security level in the global settings. When you activate a treatment authorization at security level "Permitting" ON, this has no effect for users who are not assigned an OU jurisdiction.
Maintain Activity 01 in the authorization object N_TC_DG for users who are to act as initiators when delegating a treatment authorization.
Since the system checks the treatment authorization every time a user accesses patient- or case-related data, optimizing performance is very important. For this reason, the system stores all positive check results for each user, together with the date, in a buffer table. This means it is only necessary to check whether the user has treatment authorization once a day. The check results are deleted automatically from the database the next day. When switching to a different security level, you must empty the buffer in the Customizing activity Empty Treatment Authorization Buffer, so that the checks are run again based on the new rules.
rdisp/max_wprun_time - Maximum work process run time Vendor Master (General Section)
This documentation is copyright by SAP AG.
Length: 8081 Date: 20240425 Time: 101710 sap01-206 ( 143 ms )
