Request Type
The request type represents the technical mapping of request forms and determines the properties of a request. You define the request type for a performing organizational unit (OU) (e.g. service facility) and for the desired request options. In the request type you define the appearance of the request and what content it should contain.
If the service range of an OU is very varied, you must define several request types, where the services refer to a specific disease pattern or a specific situation.
System administration determines the request types for the performing OUs and assigns them to the requesting OUs.
A user in the Requester role sees the request types assigned to his OU in the selection list of request and order types. He selects the request type and the services from the list. Depending on the request type the user must enter additional information for the service performance (e.g. sample substances and quantities, contraindications).
Note
The clinical order is also available in parallel to the request. The selection list contains both request types and clinical order types. Depending on the user’s selection, the system will branch to the data screen of the request or the clinical order.
Structure
You determine the properties of a request type using the following tab pages:
Availability
Tab PageYou enter which OUs (e.g. care units) can request services from the hit list of this request type of the performing OU. You can also determine that the requesting OU can only request services from the hit list.
You can also determine whether the requesting OU can also allocate appointments for the services, or whether this right is reserved by the performing OU (service facility).
You control if and for which services a requesting OU can allocate appointments, by not setting the appointment allocation indicator for the performing OU in the following basic data:
Appointment allocation indicator of OU
Appointment allocation indicator of service in service range
Appointment allocation indicator in request type
NoteYou should note that the requesting OU can only allocate appointments if no appointment allocation indicators contain an entry.
End of the note.Structuring
Tab PageYou determine which tab pages contain the selection list of request and order types of the request type and therefore its services.
NoteThe
Endoscopy
request type should only be contained in and selectable in theInternal
tab page.End of the note.You first define the tab pages of the request hit list in the implementation guide under
Industry-Specific Component Clinical System
Service Management
Requests
Set Up Tab Pages for Request Hit List
.You then assign the desired tab pages of the corresponding requesting OU in the implementation guide under
Industry-Specific Component Clinical System
Service Management
Requests
Assign Tab Page to Requesting Organizational Unit
.Surgery/Treatment
Tab PageYou control which services the performing OU should be offered to the requester and in what sequence (priority). To do this you define a hit list of all services (request hit list) which the performing OU offers based on its range of services.
The request hit list should contain all services in the service range of the performing OU which have the Requestable indicator set. You can also add service groups in the request hit list in order to improve the structuring.
You control the sequence of the services in the request hit list with the priority. The request hit list will display the services with higher priority first.
NoteUsing the hit list you can provide the services of the service range within the request type, e.g. according to the frequency of their request.
The definition of a request hit list is an optional step. If you enter no services for the request type, you will receive the service range of the performing OU as the request hit list.
End of the note.On the
Availability
tab page you can determine, for an OU, whether only services from the hit list of the request types are allowed when the request is checked and in the input help.
ExampleA subsystem knows only a portion of the service range and you do not wish to create a separate service facility.
End of the example.On this tab page you also determine the characteristic of the request.
NoteThis specification controls the dialog behavior for various types of service request e.g. surgery request.
End of the note.Further Specification
Tab PageYou control which information the user must enter in the request, in addition to the services. Some requests must contain the problem, while others require a short anamnesis.
You can also define the required entry fields depending on the status.
ExampleThis means that the problem must be entered by the employee who confirms the request, while the services to be performed must be entered by the employee entering the unconfirmed request.
End of the example.When you save or confirm (send) the request, the system will check which fields are required entry fields for this request type, and display a corresponding error message if these fields are not filled.
You can also define a technical document and specify in the request type, that this document must be created during a request.
ExampleFor this request, other information is required, in addition to the requested services, which is required for the performance of the service (e.g. data concerning sample quantities, substances, number of sample phials).
End of the example.
CautionThe system differentiates between technical and medical documents: Medical documents are contained in the document overview. If you create a technical document for the request, this document is not displayed in the document overview for the patient.
End of the caution.
Integration
You must make the following settings before creating the request type:
Define number ranges for each request type
Assigning an Interval to Number Range Object