Data Sheet SW Ishmed Basis

®

i.s.h.med

basis (Basic Medical Record) Data Sheet

Table of Contents Solution Definition .............................................. 4 Smart UI Initiative ..................................................... 4

Performance Features ........................................ 5 i.s.h.med basis (07600997) ...................................... 5

Medication Orders ...................................................... 14 Progress Entries......................................................... 14 Medical Services ........................................................ 14 Nursing Services ........................................................ 15 Administrative Services .............................................. 15 Chart ......................................................................... 15 Effects on Existing Data.............................................. 15

Intended Use ................................................................ 5

Health Problem ....................................................... 15

Basic Data Administration......................................... 5

Clinical Order .......................................................... 16

Base Items ................................................................... 6 Categories.................................................................... 6 Material Consumption ................................................... 6 Employees (Business Partners) .................................... 7

Definition of Order Types ............................................ 16 Clinical Order and Appointment Management.............. 17 Process Acceleration and Comfort Functions .............. 17

Implementation Support ........................................... 7 Clinical Work Station ................................................ 7 Patient Record / Patient Organizer ........................... 9 Administrative and Clinical Object Types (Content of Record) ...................................................... 9 Arrangement with Help of Aspects................................. 9 Screen Areas of the Record .......................................... 9 Patient Organizer Functionality.................................... 10 Patient Groups (Smart UI) ........................................... 10 Selection Dialog.......................................................... 10 Views and Displays..................................................... 10 Filters ......................................................................... 11 Graphical Plan ............................................................ 11

Patient Profile (Smart UI)........................................ 11 Patient Header ........................................................... 11 Compact Patient Header ............................................. 12 Task Management (Licensed) ..................................... 12 Applications ................................................................ 12

Patient Record (Smart UI) ...................................... 13 Parameterized Medical Documents (PMD) .................. 14 Examinations.............................................................. 14 Diagnoses .................................................................. 14 Vital Signs .................................................................. 14 Lab Values ................................................................. 14

Data Sheet i.s.h.med basis Page 2 of 35

Service Ordering (Smart UI) .................................... 17 Medical Service Management ................................. 18 Plan Services ............................................................. 18 Document Services .................................................... 18

Appointment Management and Planning ................. 19 Planning Grid ............................................................. 20 Quota-Based Planning................................................ 22 Configuration and Functionality ................................... 23

Clinical Documentation ........................................... 23 Parameterized Medical Documentation ................... 23 Definition of PMD Types ............................................. 23 PMD and SAP Document Management....................... 24 Usage Scenarios ........................................................ 24 Document Creation .................................................... 25 Subdocuments ........................................................... 25 Security, Release and Versioning ............................... 25 Special Indicators ....................................................... 25 Editing Documents ..................................................... 25 Deleting Documents ................................................... 26 Handling of Documents, Lists and Mass Processing Functions ........................................ 26 Findings Inbox............................................................ 26 Dispatch Control......................................................... 26 Document Communication.......................................... 27

Communication with External Systems ................... 27 Message Communication Infrastructure (MCI) ............. 27 Archive Connection..................................................... 27

Diagnosis and Case Processing ............................. 28 DRG and Other Billing Systems.............................. 28 Clinical Case Processing ............................................ 29

Cancel ................................................................... 29 Accident Number.................................................... 29 Outpatient Clinic and Service Facilities ................... 29 Calling Patients .......................................................... 29 Outpatient Treatment .................................................. 29 Outpatient Clinic Folder (Part of SAP ACM – Licensed Product from SAP) ....................................... 30 Treatment Sequence .................................................. 30 Ending Outpatient Treatment ...................................... 30

Application Logging ................................................ 30 Employee Responsible ........................................... 30 Enhancement Framework....................................... 31 Allergy Documentation ........................................... 31 Basic Data.................................................................. 31 Functionality ............................................................... 31

Examination and Laboratory Results ...................... 31 Clinical Evaluations / Statistics ............................... 32

Prerequisites for Implementation .................... 33 Modules ................................................................. 33 Integration .............................................................. 33 HANA ......................................................................... 33

System ................................................................... 33 Smart UI ..................................................................... 33

Other Prerequisites ................................................ 34

Data Sheet i.s.h.med basis Page 3 of 35

Solution Definition i.s.h.med SAP 6.0 EHP 6 - basis (i.s.h.med basis) is the core component of i.s.h.med and contains the most important basis and cross-sectional functions in outpatient clinics, service facilities and care units for communication, planning and documentation in hospitals. These basic functions include the clinical work station, the service request, appointment planning and parameterizable electronic documents. Furthermore, i.s.h.med basis contains the electronic patient record and is the basis for further modules of i.s.h.med (exception: i.s.h.med occupancy management can also be used without i.s.h.med basis).

Smart UI Initiative i.s.h.med SAP 6.0 EHP 6 provides the first elements which resulted from the Smart UI initiative, the redesign of the i.s.h.med architecture (the relevant components are flagged with Smart UI). The architecture of Smart UI consists of three pillars: · Overview - Patient groups (my care unit incl. graphical overview, dynamic filters and tasks) · Patient-specific work - Patient profile (overview of the patient, tasks and patient record) · Activity - Applications incl. new developments and functionality

Fig. 1: Overview of the i.s.h.med und SAP components

Data Sheet i.s.h.med basis Page 4 of 35

Performance Features The components under the umbrella term Smart UI which become available with EHP6 have the following aims: · Reduction of barriers for new users who are not yet familiar with the application · Drastic reduction in operational steps for routine workflows · Faster construction of mental models for the patient’s situation · Direct access to relevant information · Cross-sectional navigation · Flexible support in resolution of medical problems

i.s.h.med basis (07600997) Intended Use i.s.h.med is intended for use by specialist medical staff that enter or call patient information for the purpose of planning, supporting and documenting clinical, medical and nursing care. The entered and displayed patient information includes administrative and medical data (findings, physician’s orders, clinical orders). i.s.h.med is also intended to enable access to data from third party systems. The functions for adapting i.s.h.med (i.e. customizing, e.g. IMG activities) are intended for IT specialists, who adapt i.s.h.med to the specific administrative and organizational requirements.

· Reduction of outlay for implementation and training

Basic Data Administration i.s.h.med is equipped for the use of various clinical functions and modules, as well as those in clinical enhancements to the functionality of SAP Patient Management (licensed product from SAP) with two levels of system maintenance and master data management. These maintenance procedures, some of which are initial, some of which are continual, can generally be divided into: · Customizing · Basic Data Administration

On one hand customizing includes individual parameters at system and institution level, on the other hand basic tabular data, which as a rule remains constant over long periods of time, is maintained here, for example, units of measurement, reason codes, cancellation reasons, input helps for attributing diagnoses, etc. The clinical basic data includes content such as the service master data (and clinical enhancements),

Data Sheet i.s.h.med basis Page 5 of 35

document categories and their structure and much more. Depending on the recommended implementation scenarios, most of this basic data is connected to the SAP transport system (licensed product from SAP) so that formatting and quality assurance can take place on upstream systems, before this data is explicitly used productively. In addition to the configuration functions described in this service description for the individual applications / processes (such as, for example, order types, document categories, etc.) the following data, which is used in various components of i.s.h.med, also exists:

Base Items Base items create the connection between the process-supporting objects of various applications (such as the steps of clinical pathways or the tasks in the care unit (ward) work station or surgery work station) and the individual i.s.h.med documentation objects (such as orders, documents, etc.). · Base items are used by various modules which are based on i.s.h.med. · Base items are defined by the object which assigns them to a specific process step (pathways step, task of a situation in the documentation work station). · Depending on the type, base items enable extensive semantic presetting of the relevant object in i.s.h.med, for example the exact specification of an entire order profile for a certain step within a clinical pathway. · Using the semantics of the preset content, base items also define the actions which should happen to the assigned object, as soon as the concerned calling process step is triggered for the first time or a repeated time (e.g. create a specific document as the initial action, call document in change mode as the repeat action). · In i.s.h.med base items are supported for: Administrative services, requests, medication orders, business add-ins (BAdI), treatment pathways, surgical documentation, diagnoses,

Data Sheet i.s.h.med basis Page 6 of 35

documents, form printing, clinical orders, complications, material entry, medical services, surgery times, problems, procedures, team entry, textual orders, transactions, URLs, progress entries.

Categories Categories represent a way of classifying executed actions, such as steps of a clinical pathway, and therefore being able to evaluate these specifically.

Material Consumption i.s.h.med provides options for posting material consumption on a patient-related basis (specifically: with a case or movement or service reference) or with reference to documented services (in surgery or at service facilities). There are two methods of material consumption documentation: · Material consumption documentation without integration into SAP ERP Materials Management MM (licensed product from SAP): A prerequisite for this method is that materials have been created as services of the material type in service basic data administration. Medical services can therefore be assigned to service-dependent material proposals, which simplify the documentation at the time of the performance. Billing, controlling, etc. are regulated using the usual attributes in the service master. · Material consumption documentation with integration in SAP ERP Materials Management MM is available if SAP MM is used in an institution. To be able to use this form of material documentation, ‘plants’ must be configured and assigned either for each care unit (organizational unit = OU) or, at least, once per institution. The MM article masters have additional medical attributes assigned within basic data management, such as medically better legible labels. Individual materials or entire hierarchy trees are assigned to OUs via specific catalog and material proposal maintenance, whereby servicerelated proposals are also supported. Different proposal lists can be used to simplify documentation, for example OU-related hit lists. Material documentation based on SAP MM optionally enables the automatic posting from the

stock with optional immediate triggering of corresponding ordering and purchasing processes as well as patient-related billing of consumed materials using stored administrative service keys.

Employees (Business Partner)

Implementation Support Implementation support is used to transport customizing data (e.g. order types for the clinical order) and parameterized documents (PMD) in a system landscape.

Employees are business partner as far as the SAP ERP system is concerned (licensed product from SAP). The employees maintained in the system can be offered, for example, for team documentation within surgeries or at service facilities, via various configuration functions.

The two most important components of this function are offered in the ‘Customizing Transfer Manager’:

· Depending on customizing, team documentation offers employees, according to defined tasks and any assigned qualifications, for documentation. As a preliminary step to the actual documentation, team entry can be filled at the time of planning (e.g. of a surgery) and then supports the process (see, for example, service description i.s.h.med surgery).

Data is transferred via any media between independent i.s.h.med systems of the same release state. Data is transferred once from a named source into a specific system. XML files are the technical basis for this data transfer.

· Country-specific versions: The assignment of employees to services controls the transfer of defined documented employee references into the administrative system. Person-related billing steps, for example, can be based on this. · For the documentation of the employee responsible for specific actions in the clinical system i.s.h.med (see below), a correct assignment of the entered employee to an OU is necessary. This assignment is made using the position reference. Shift plans or shift times are not explicitly managed with this tool. · The definition of tasks (e.g. surgeon, assistant, MTRA, etc.) and service-dependent task proposals enables a targeted documentation range at the time the service is performed. · Tasks and employees can be connected if qualifications are determined as connectors.

· Customizing - Export Wizard · Customizing - Import Wizard

On the target system the content selected for installation in the selected installation package can be revised. Content which already exists in the target system can be adapted using different display and processing methods. The installation process and the processing of the content to be installed can be done in sessions and, in case of extensive packages, can be interrupted.

Clinical Work Station The clinical work station is the central organizational instrument for administrative and medical issues. Typically it represents the start transaction of the medical user and is therefore often the first screen with which the user is presented in the HIS. Depending on the object category in the foreground (patients, documents, orders, etc.) special view types are provided. Due to their content, several of these view types are jointly managed by SAP Patient Management (licensed product from SAP) and i.s.h.med.

Data Sheet i.s.h.med basis Page 7 of 35

The following view types are available in i.s.h.med basis: · Occupancy · Arrivals · Departures · Clinical Orders · Documents · Outpatient Clinic / Service Facility · Medical Controlling · Preregistrations · Appointment Planning

The user himself can adapt the clinical work station at runtime, depending on his authorizations (for example concerning data selection). The user can personalize supplied layouts as well as the default layout. A return to presettings is supported. The views of the clinical work station enable automatic refreshing with a definable time interval. A view can be called transferring a specific patient or a selection of objects from another view. This call is possible using drag & relate. In the resulting sequence of views the user can navigate back step-by-step. The selection behavior in the clinical work station can be controlled individually by showing or hiding a row selection button. Columns can be fixed for horizontal scrolling.

The Occupancy and Arrivals or Departures view types can be displayed simultaneously. In these views the allocation of a room or bed via drag & drop is supported.

The view types of the clinical work station provide the entry points to processing functions, which are sensible in the context of the view type. The specific functionality is dependent on the licensed components.

The clinical work station is presented to the user in the form of work environments, which display a role-based grouping of views adapted to the specific work context. This offer is made in the navigation area, which can be shown or hidden at runtime in order to make room for the actual list. An extendable list of favorites is available for calling other transactions without a reference to the objects displayed in the list.

The clinical work station displays content - depending on the definition of the view - for all patients in an overview and is therefore suitable for triggering individual functions.

A specific view of the clinical work station is defined by: · The view type (e.g. Documents or Orders) · The data quantity to be displayed: Selection variant (e.g. orders which are pending confirmation) · The layout of the list, with regard to the columns to be displayed, their width, the sort order: Layout variant · The functionality: Function variant The clinical work station enables the design of specific worklists each with the suitable functionality which can therefore be adapted to the requirements of a specific work situation or role.

Data Sheet i.s.h.med basis Page 8 of 35

Patient-specific working in i.s.h.med is supported by various module-related documentation work station (see relevant descriptions). Functions can be grouped for better clarity. Many cells in the display area of the clinical work station enable hotspots for calling specific processing functions. Content is sometimes displayed directly via icons. The clinical work station can be operated using function keys. The clinical work station can be enhanced with the help of the enhancement framework with content to be displayed and functions.

Patient Record / Patient Organizer In i.s.h.med the patient organizer represents the patient’s electronic record. It is used to gain information and enables both a specific search for suspected or known content as well as a largely non-specific glance through the patient’s medical history, in order to gain an overview. The patient organizer can optionally also be used for all institutions and can therefore display content (e.g. documents), which was created in other institutions (as a rule hospitals of a network or chain) in the same client.

Administrative and Clinical Object Types (Content of Record)

The patient header includes an indication of the patient’s documented risk factors and enables the call of the corresponding detail documentation.

Arrangement with Help of Aspects An aspect is defined by: · Content which is compiled in a selection variant (view) · Structure of its navigation component (e.g. tree display with various grouping criteria and several levels or a list display). In case of a tree display the following grouping options are supported: · Case · Time (days, weeks, months, quarters or years)

· Clinical orders

· Object type (e.g. all discharge summaries)

· Requests

· Health problem

· Diagnoses · Documents · Services · Appointments and movements · Surgeries

· Way in which details on entries of the record are displayed The Patient Appointments is a special version which can be called in i.s.h.med from various places, as a separate aspect of the record.

· Procedures

Screen Areas of the Record

· Medical records

· Range of aspects

· Country-specific version NL: DBC (DiagnoseBehandeling-Combinaties)

· Navigation structure (tree or list)

· Medication orders · Outpatient notes (if SAP ACM is in use – licensed product from SAP) · Treatment pathways · Time grid A call can branch directly into the patient administration function (Clinical Process Builder from SAP Patient Management - licensed product from SAP).

Data Sheet i.s.h.med basis Page 9 of 35

· Detailed information on the selected object (e.g. time stamp of an object, involved employees, descriptive text, etc.) · Detail screen (e.g. PDF view of a document, XML formatting of an order, etc.) The display class can be used to define, at the time of configuring the system, the shape which is presented, for example, a parameterized medical document when the record is called. Document category settings are also taken into account.

Patient Organizer Functionality · Call, access to the patient organizer

clearly using filters or the display can be restricted using these filters, to simplify work on specific groups of patients.

· The patient organizer can be called from various views of the clinical work station for a specific patient.

Selection Dialog

· The patient viewer is integrated into the versions of the patient-specific documentation work stations (DWS), whereby here it is also possible to control which aspect should be displayed in the patient viewer by defining info items, depending on the current work context.

· Department

· If the patient search is called first, the patient organizer can be called directly via a transaction (from the SAP menu, etc.). · Processing functions

The patient groups selection dialog enables the quick and easy determination of patients. The following selection criteria are available:

· Treatment / nursing organizational unit · Current date · Days back (for discharged patients) Individual patient groups can be composed using the following criteria:

· The patient organizer (not the patient viewer) offers basic functions for processing the displayed objects.

· Department

· New objects can be created, existing objects can be changed and canceled.

· User-specific patient groups can be saved (my patient groups). My patient groups means that a user can quickly call patient groups he has configured himself.

· Generic functions · General functions are also offered in a general function toolbar, for example, the call of the cumulative lab findings.

Patient Groups (Smart UI) The patient groups (Smart UI) are a graphic alternative to the occupancy view of the clinical work station. In an optically pleasing form and with a variable degree of detailing, the clinician receives an overview of the patients in his area of responsibility. In the form of patient cards or alternatively a list, these patient groups, which are composed of individual inpatient and outpatient patient contact, provide particularly relevant medical information. The clinician receives information concerning what is going on in his area of responsibility, and what needs to be done. Certain facts (e.g. upcoming surgeries, etc.) or specific tasks which must be executed (currently: service orderings which must be processed) can be highlighted

Data Sheet i.s.h.med basis Page 10 of 35

· Treatment / nursing organizational unit

Views and Displays Various views and displays are available for the display of patient information: · Card view: The system displays the name of the patient as well as important information (e.g. birthdate, gender, allergies, risk factors) on patient cards. The user can choose between five different patient card sizes. The size of the card determines the quantity of displayed information. · List view: In this view the patients are displayed in a tabular form. · Room view: The system displays the building units (e.g. rooms and beds) for each selected treatment / nursing organizational unit (e.g. care units) with the allocated patients in a graphical scheme. Patients who have not been allocated a bed / bed location / room, are displayed separately.

· Department view: The system graphically displays the subordinate treatment / nursing organizational units (e.g. care units) with their building units (e.g. rooms and beds) and the allocated patients for each selected departmental organizational unit (e.g. surgery). Patients who have not been allocated a bed / bed location / room, are displayed separately.

Filters Filters can be used to restrict the determined patient group according to various criteria, e.g.:

In case of multiple occupancy of a bed the system displays the number of patients on the bed icon. The name and case number of the occupying patients can be found in the tooltip of a bed icon. A large patient card can be displayed for each patient who occupies a bed with a click of the mouse. The system separately displays patients who have not been allocated a bed / bed location / room. Filtered patients are highlighted in the graphical plan.

· Surgery Tomorrow (a clinical order of the Surgery type exists for tomorrow)

Patient Profile (Smart UI)

· Today’s Labs (a lab document exists which was created today)

The patient profile can be used to easily and quickly view and process the medical documentation of a patient via an intuitive user interface (Smart UI).

· Planned Discharge (a planned discharge exists) The patients who satisfy the filter criteria are highlighted in the overall list of the determined patients; patients who do not satisfy the filter criteria can be hidden. The labeling and the sequence of the filter can be determined in customizing, as well as the suppression of the display of filters. The user can also implement own filters in the system. The Tasks Exist filter displays all patients, for which at least one task exists for the Physician occupational group (license prerequisite: i.s.h.med task management)

Graphical Plan

The patient profile contains the following components: · Patient header · Tasks · Applications · Patient record with clinical information (reading, writing)

Patient Header The patient header contains the following data for the identification and the case of the patient: · Patient ID · Name of the patient (the name appears as follows: name prefix last name first name. The name affix and title do not appear.)

The graphical plan is the main component of the Department Display and the Room Display. In the List Display and the Card Display the system displays the graphical plan next to the listed patients.

· Sex

For a selected patient the graphical plan displays the allocated organizational unit and building units. Based on the number of occupied beds the system also displays the degree of occupancy of a care unit which contains beds.

· Risk factors (the patient header indicates whether risk factors exist for the patient and, if so, how many. A click on the entry opens the list of entered risk factors.)

Data Sheet i.s.h.med basis Page 11 of 35

· Age · Birthdate

· Allergies (the patient header indicates whether allergies exist for the patient and, if so, how many. A click on the entry opens a list of entered allergies.) The information on allergies is taken from the allergy documentation. · Assigned care unit (ward) · Main diagnosis / diagnoses (if a hospital main diagnosis exists, this is displayed. In all other cases, Diagnoses Exist is displayed and a click on the entry opens the list of entered diagnoses. If this is a provisional or preregistered patient, the diagnoses here are transferred from the clinical order.)

patients. The following information is displayed in the compact patient header: · Patient ID · Name of the patient (name prefix last name, first name) · Age · Sex · Birthdate · Risk factors · Allergies

· VIP indicator (icon)

· Care unit

· Patient Deceased (icon)

· Case number

· Case type - outpatient or inpatient · Case number · Status of movement (e.g. outpatient visit, planned admission, absence, discharge, etc.) is made visible by icons in the patient header. · Admission date · Number of days pre / post-op - this is only displayed if a surgery appointment exists. If the movement status is set to inactive stay, nothing is displayed.

Task Management (Licensed) The i.s.h.med task management component displays the currently outstanding tasks for the occupational group of the user and also for all occupational groups in tabular form. The user can process the tasks of his occupational group directly from the list. Once a task has been completed, it disappears from the list of outstanding tasks. The tasks in the patient profile are a licensed component (i.s.h.med task management).

· Length of Stay indicator (country version Austria: no display)

The tasks for a patient are displayed in two lists:

· Department

· Tasks of all occupational groups

· Room / bed

· Tasks for the user's occupational group

· Indicator for private patient · Attending physician - if an attending physician has been defined for the corresponding departmental stay, he is displayed here.

Currently the clinical order and service ordering are connected to task management. Other tasks can be displayed using BAdIs.

Applications Compact Patient Header For the applications within Smart UI (e.g. service ordering) a compact patient header is available, which is displayed in the upper area of applications in Smart UI, to guarantee a unique assignment of applications to

Under the Hit List application up to 10 quick links are available for directly choosing the applications which are selected most frequently. The following applications are available: · Call Medical Record List

Data Sheet i.s.h.med basis Page 12 of 35

· Edit Allergies · Edit Diagnoses

The applications component is configurable. Functions can be hidden or grouped according to your own criteria. Client-specific functions can also be integrated.

· Create Document · Edit Delivery Data · Call Case Overview

Patient Record (Smart UI)

· Create Clinical Order

The patient record is part of the patient profile. The following elements characterize the operation of the patient record (Smart UI):

· Order Service

· Configurable layout (property of the patient profile)

· Enter Service

· One-Click-Action for frequently required functions

· Subsequently Enter Service

· Call of full screen detail screens

· Edit Medication (prerequisite: i.s.h.med medication license)

· Display of additional information in so-called pop-in areas for specific objects

· Medication: Create Emergency Event (prerequisite: i.s.h.med medication license)

· Full screen option for being able to use the entire display area for a component (e.g. for i.s.h.med Smart Chart - licensed) (property of the patient profile)

· Create Case and Surgery

· Medical Service Processing · Outstanding Patient Items · Create Surgery · Edit Patient Master Data · Display Patient Master Data

· Case and time period selection · Page navigation (property of the patient profile) · i.s.h.med Smart Chart (licensed) is part of the patient record

· Edit Procedures · Edit Risk Factors · Service+Diagnosis Fast Entry - This application is only available in the country version Austria. · Patient Appointments · Plan Appointment · Enter Progress Entry (prerequisite: i.s.h.med progress documentation license) · Create Medication Order (prerequisite: i.s.h.med medication license) · Enter Vital Signs (prerequisite: i.s.h.med vital signs license) · Plan Vital Signs (prerequisite: i.s.h.med vital signs license)

Data Sheet i.s.h.med basis Page 13 of 35

The patient record provides the option of editing objects and creating new objects (e.g. documents and services). The patient record is only integrated into the patient profile and is available within the NetWeaver Business Client (NWBC). This means the patient record itself does not offer the option of searching for patients or toggling to another patient. The mechanisms in i.s.h.med are used to process objects (applications, dialogs, etc.). The patient record enables the user to call processing functions directly via the object. In cases where Smart UI components are available for displaying and processing objects (e.g. interactive chart, service ordering) these are used, in other cases the classic processing functions are called.

Actions which refer to an existing object (e.g. change, cancel) can be executed as a one-click action.

Vital Signs

All functions and objects are downwards compatible with the applications in the SAP GUI.

The Create function which was previously available in i.s.h.med (e.g. in the patient organizer) can be used for vital signs.

Parameterized Medical Documents (PMD)

Lab Values

The following actions are available:

The Create action is available for lab values. This action can be used to create a request to the lab.

· Create · Change

Medication Orders

· Release

The following actions are available:

· Create Version

· Create

· Cancel

· Change

The functions which were previously available in i.s.h.med (e.g. in the patient organizer) can be used for documents in the patient record.

· Cancel

Examinations The following actions are available: · Create · Change · Cancel Examinations can be ordered in i.s.h.med both with the clinical order component in the SAP GUI as well as with the service ordering function within Smart UI. The system displays the clinical orders in the Examinations component of the patient record.

The Change action uses the detail dialog which is available in the Medication component. The functions which were previously available in the Medication component are used for the other actions.

Progress Entries The following actions are available: · Create · Cancel

The following actions are available:

Within the patient record only the new application for entering progress entries can be used. Progress entries, which were created with the old application can only be displayed in the new patient record once migration has been executed.

· Create

Medical Services

· Change

The following actions are available:

· The functions which were previously available in i.s.h.med (e.g. in the patient organizer) can be used for diagnoses in the patient record.

· Create

Diagnoses

· Change · Release · Cancel

Data Sheet i.s.h.med basis Page 14 of 35

One of the following four service entry options can be determined in customizing for entering or processing medical services:

these are converted into the new progress entry format and can be displayed in the progress entries of the new patient record.

· Service Entry · Subsequent Service Entry · Medical Service Entry (you can specify a configuration here) · Service+Diagnosis Fast Entry (only available in the country version Austria)

Nursing Services The following actions are available: · Create · Change · Release · Cancel · The functions which were previously available in i.s.h.med (e.g. in the patient organizer) can be used for nursing services in the patient record.

Administrative Services The following actions are available: · Create · Change

Health Problem A health problem comprises all symptoms of a patient which require medical care. It specifies the reason for the contact with the healthcare institution. As a rule health problems are managed in special catalogs, e.g. WONCA, but can also follow freely selectable semantics in i.s.h.med. A health problem represents the parentheses around various content, regardless of its administrative assignment. The health problem is currently only significant in an outpatient scenario (prerequisite is SAP ACM – licensed product from SAP), predominantly where primary care is provided in so-called primary care centers. The health problem is supported in the following modules / components: · Clinical Process Builder (SAP Patient Management component – licensed product from SAP) · Patient organizer · Documentation work station in SAP Ambulatory Care Management for Healthcare (ACM – licensed product from SAP)

· Release · Cancel · The Maintain Services function (transaction NL10) from SAP Patient Management (licensed product from SAP) is still used for administrative services.

Chart The i.s.h.med Smart Chart (licensed), developed for Smart UI, is displayed in the new patient record.

Effects on Existing Data For inpatient progress notes, nursing notes and outpatient notes, migration must be executed, so that

Data Sheet i.s.h.med basis Page 15 of 35

The following content of the record can be grouped on a problem-specific basis: · Visits · Appointments · Medication orders · Clinical orders · Outpatient notes · Documents

It is possible to call information with a reference to one or more health problems in the patient organizer. Special display options are available for this. Furthermore, medical objects are assigned to a health problem in the patient organizer. For this purpose the system offers an overview of objects which are not yet assigned to a health problem.

A clinical order can also be entered as a preregistration with provisional data, the reference to a real patient is not necessary. Clinical orders can have a reference to a case, but this is not mandatory. If preregistrations exist for a patient at the time of admission, these can be assigned to the case. This assignment is made when the ordered services are confirmed, at the latest. Individual order items can also be actively detached from a case.

Clinical Order The clinical order is the tool for ordering examinations, treatments and surgeries as well as for planning inpatient admissions. The clinical order represents the recommended technology for ordering and replaces the historical functionality (service request) which, for reasons of downward compatibility remains available in the system, but is no longer described here. The clinical order refers to the information transfer and workflow design between the order initiator and the order fillers within an institution. A clinical order is used to organize diagnostics and therapy, in particular when several departments or the transition from the care unit to the outpatient clinic / service facility / surgery are involved. A clinical order (or an order item) is addressed to an organizational unit (outpatient clinic, service facility, surgery) or an employee. With its status concept, it enables the mapping of workflows and role distributions both for the order initiator (e.g. the care unit) as well as the order fillers (e.g. the radiology service facility). Several clinical orders can be created using collective entry. This enables a labor-saving procedure in case of a large number of similar orders, such as the ordering of daily routine examinations for all patients of an intensive care unit. The clinical order is not intended for the detailed organization of work within a care unit or outpatient operations. The optional i.s.h.med connectivity module (07601086) enables the inbound and outbound communication of clinical orders and therefore the connection of third party systems.

Data Sheet i.s.h.med basis Page 16 of 35

Definition of Order Types · An order type consists of clinical order components. This means that documentation in accordance with the purpose of the order type is possible. · Clinical order components are assigned either to the order header and apply to all order items contained within the order, or are assigned to the individual order item and enable the mapping of semantics which are predefined for a specific order situation (e.g. special content for a radiology order or a surgery). · An order type is addressed to one or more order fillers determined at the time of definition. · The use of an order type is assigned to specific order initiators (in the form of OUs) at the time of definition. · Order types can offer a range of orderable services, determined at the time of definition; alternatively the request for services which are possible with a specific order type depends on the service range of the addressed OU. · An order type (or in case of the grouping of several orders, an order item) follows a defined status profile. Generally, this is freely definable. · In the order components which are assigned to an order type, it is possible to define required entry fields, depending on the order status.

Clinical Order and Appointment Management (See also section under Appointment Management and Planning) · An order item can include an appointment template. This indicates a desired date or provides information on when the ordered action should take place. · This appointment template supports appointment planning at the ordered facility. · Depending on the planning authority (can the ordering facility allocate appointments in the ordered facility itself) the allocation of appointments for order items or individual services is possible directly from the order. · If the process begins with the allocation of an appointment (e.g. during telephone contact) the definite order can also be entered during the existing appointment (i.e. when the patient arrives at the service facility). · Services can also be ordered on a cyclical basis. Individual services are generated for each ordered service according to the cycle assigned. These can then be individually planned.

Process Acceleration and Comfort Functions · The data required for an order item can be preset in template management. · Several order items can be compiled in one order template as an order profile and simply called together.

Service ordering is based on the technical concept of the clinical order. The clinical order also remains available. The clinical order in the SAP GUI and service ordering can be used in parallel. Services which have been requested with service ordering can be processed in the clinical order. Clinical orders can also be called for processing from service ordering. Order templates can be used in service ordering. Order templates which have been defined for the clinical order or in SAP GUI, which contain at least one service and only one item, can be re-used. One or more services to be ordered can be created with service ordering. Service ordering is determined with the following parameters: · Order filler from the order filler group · One or more services from the service range of the order filler · Possible selection of another order filler and selection of one or more services In service ordering, requestable services from the service ranges of various order fillers can be selected and ordered in one step. The system bundles the services in one order, if they are of the same order type and are addressed to the same order filler. For services which are addressed to different order fillers, or were ordered with different order types, the system creates individual orders.

· Furthermore, predefined order templates can be used via the basis items in the versions of the documentation work station: in the i.s.h.med ward and i.s.h.med pathways modules.

Frequently used services can be selected from a personalized favorites list. Following selection of the desired services, further information can be entered in a detail view (for example a comment or the localization).

Service Ordering (Smart UI)

One-click actions are available in icon form for actions for processing orders, previous selection of an entry is not necessary for this. A click on an icon in the service row is all that is required to select a service.

Service ordering uses an easy-to-use user interface (Smart UI) which enables users to order services simply and quickly. The clinical order remains for complex cases.

Data Sheet i.s.h.med basis Page 17 of 35

An appointment template can also be created for a service ordering order. However, appointments cannot

currently be planned in service ordering. Appointment planning is possible at the service facility. Service orders from the new service ordering are managed in the system as individual orders with one order item each. A service is mandatory for service ordering. In service ordering there is currently no function for canceling orders. In order to be able to cancel a service ordering order, you can call the SAP GUI cancellation dialog for the order concerned from service ordering. Service ordering orders cannot be flagged as preregistrations.

Medical Service Management i.s.h.med is generally based on the same service master and corresponding basic data management as SAP Patient Management (licensed product from SAP). When i.s.h.med is activated, the service master is enhanced with additional attributes. Medical services are documented in the i.s.h.med transactions, generally with a reference to the service range. This defines which services can be performed at which organizational unit. To support the ordering process accordingly, services can be flagged as requestable and / or performable. Furthermore the service range at the time of ordering is also influenced by the order type definition and the hit list settings (see also Clinical Order).

Plan Services · Services are planned when an appointment is allocated for a service (or for an order item which comprises several services ordered from the same order filler). See also under Appointment Management and Planning.

step means the same individual services are generated according to the cycle attributes. · In this definition cycle represents a regular or irregular iteration regulation. · The individual services created within the generation step then represent the basis for an optional definite appointment planning step and can be documented or confirmed individually in this form.

Document Services · Performed services are documented either after they have been ordered or explicitly by the facility performing the service. The attributes relevant for the specific handling in the service billing or controlling area, such as the requestable departmental and nursing OU, are defined via parameters, depending on the process, or common proposal values are provided by the system. · The service documentation process follows a defined status profile, whereby the setting of each individual status (service performance, release, etc.) is, to a large extent, configurable. · At different times in the service planning and documentation process the documentation of the planned procedures (also multiple) can be ‘replaced’, i.e. refined or specified. At the time a service is performed, billing-technical replacement is offered, to create the actual billing services in a semi-automatic procedure. · Country-specific version: Depending on the country the system can automatically create procedures (e.g. DRG in Germany) or administrative services (e.g. LKF in Austria) at the time that a medical service is released.

· Cyclical services are services of the same service type.

· Depending on the user parameters set, services which are not a result of ordering are documented either via entry of (and possible searching for) service codes or the call of the service hit list.

· The definition or assignment of a cycle for a service and a manual or automated generation

· Services can be grouped into service groups for the following purposes:

· A cycle can be assigned to ordered services.

Data Sheet i.s.h.med basis Page 18 of 35

· Navigation support or grouping characteristic in the hit list · Simplified ordering · Documentation of a performable service group, to accelerate the documentation process and attach dependent documentation steps (material documentation, team documentation, servicerelated documents) to an entire group. · Mapping of semantic groups according to clientspecific definitions, e.g. regions. · By flagging in the service master the user can determine that an ordered service group must be replaced at the time of performance. The (optional) range of target services is presented. However, the service group can also be broken down into one or more other services, as long as these are assigned to the range of the performing organizational unit. · Services represent a possible reference level for: · Medical documents and medical records, whereby multiple references are possible. See also Medical Documentation, Parameterized Medical Documentation · Material consumption documentation · Team documentation - In i.s.h.med surgery (07601003) the ’anchor service’ is the reference point. · For the medical service documentation there is an optional alternative dialog application available, which enables a semantically preset and highly configurable documentation via corresponding customizing (see also base items). · This medical service entry is available in-place in the documentation work stations (see also i.s.h.med ward - 10415867 and i.s.h.med surgery - 07601003) as well as in the care unit and service facility views of the clinical work station. · The medical service entry offers the hit list, detailed information on services and the actual input area in table form in one dialog.

Data Sheet i.s.h.med basis Page 19 of 35

· Favorite lists are supported, these are defined via the base item. This means the specific semantic characteristic of the service entry dialog can be adapted specifically to certain work situations (see also i.s.h.med ward – 10415867). · The layout of the entry dialog as well as the function range can be configured. · Medical services must receive a reference to a movement (an outpatient visit, an inpatient admission, a surgery, etc.), at the latest at the time of performance. Depending on the settings made, the system automatically creates this reference and can also create a new visit, if no valid visit has been documented in the service-performing OU on the day concerned.

Appointment Management and Planning i.s.h.med enhances the appointment management available in SAP Patient Management (licensed product from SAP) with: · The reference between appointments and orders (specific order items, e.g. surgeries) and services. · Graphical user interfaces (planning grid and dayspecific, quota-based planning) · Various functions Planning with i.s.h.med is either day-specific (determination of the planned date only) or timespecific. i.s.h.med also shares the preregistration based on the clinical order with SAP Patient Management (licensed product from SAP). Appointment management in i.s.h.med is integrated into the processing functions and work stations in which preregistrations, orders and services are processed. Using appointment management the planning of outpatient or inpatient treatment processes is continuously possible:

· Entry of a preregistration for a treatment process under optional specification of only rudimentary patient data and then without the necessary case reference. · Preregistration of inpatient admission including pre-entry of important content for the automatic presetting of the administrative data on the patient · Management of waiting lists according to definable criteria with the possibility of specifying priorities and taking patient’s wishes into consideration · Planning of preoperative procedures, such as examinations at service facilities · Support of the admission process for preregistered patients · Creation of the case reference · The connection between an order item and an appointment can be made in both directions: Planning of an ordered procedure or subsequent documentation of an order for an appointment which was entered previously · Appointment planning is oriented towards (optional) appointment templates: Specification of a desired date and time within ordering, consideration of this content during the appointment search and planning at the service facility · The appointment template tool in clinical ordering also supports multi-appointments, via additional attributes and OU-specific settings. These can be used to determine time or content dependencies or sequences for several items of a clinical order. · The individual appointments resulting from a multi-appointment are saved as an appointment series. · Appointments in i.s.h.med can be created both stand-alone with a reference to one or more services or also for order items without services. · Appointments are always valid for the entire institution and generally have a reference to a

Data Sheet i.s.h.med basis Page 20 of 35

(provisional or actual) patient and a planning object (= calendar column at organizational unit, room or employee level) · Patient-related appointment series can be planned (such as a series of appointments at various OUs). · i.s.h.med provides an enhanced version of the MED Appointment Calendar from SAP Patient Management (licensed product from SAP) which can be called for the patients at all necessary places (e.g. for the display of planned services). · The MED Patient Calendar is technically a decoupled display variant of the patient organizer and is subject to its configuration functions. · An overview of the planned appointments is available in the form of appointment lists. These can be configured for each patient, attending physician (if entered in the visit appointment), each treatment or departmental OU.

Planning Grid The planning grid is a graphical tool optionally installed with the SAP GUI, which enables the modification of appointments. It is integrated into all planning functions, ordering, service facility and outpatient clinic organization and surgery scheduling. · Configuration functions · The planning grid is based on the OU structure of SAP Patient Management (licensed product from SAP) and the planning objects defined at room level or on an employee-related basis. · i.s.h.med shares the categorization of plannable slots with so-called scheduling types as well as the definition of the opening times of plannable facilities / employees with SAP Patient Management and the planning tools offered there. · i.s.h.med enhances the planning object definition offered by SAP Patient Management, with the addition of a deadline: This is the time up until which the orders to be planned must be received,

in order to be taken into account for the appointment planning of the following work day. · The display is determined in variants when the tool is configured. This also includes the decision concerning whether days without time slots (such as weekends, public holidays) should be displayed or not. · The variant which is used when the planning grid is initially presented depends on the user-specific settings as well as the context or process in which it is called. · Parameters can be used to control whether the dialog-supported appointment search, the planning grid or the SAP Patient Management planning tool should be used. The joint data and function base enables the parallel use of various planning tools (each with a different extent and focus). · Functions · Display of the time slot in variant form which controls which calendar strips (planning objects) should be offered simultaneously and whether this display should be day-specific or timespecific. A grouping option, e.g. of the rooms of an organizational unit (e.g. treatment rooms of an outpatient clinic or image-rendering devices of a modality type) is available using tab pages. · The planning grid supports a zoom-in for the incremental optimization of the display concerning the range of detailed information on one hand, and the overview display on the other. · The planning grid can be operated on a standalone basis, for example at the hub of a service facility for processing telephone appointment enquiries. · The planning grid can be called from a clinical order or an overview display of order items or services (e.g. Outpatient Clinic / Service Facility view type of the clinical work station) when one or more ordered services or order items are transferred.

Data Sheet i.s.h.med basis Page 21 of 35

· The objects transferred for appointment planning when the grid is called are displayed in a configurable work list. For example, the evening scheduling of appointments for the next day at service facilities is supported. · During appointment planning for a specific ordered procedure all other appointments allocated to the patient concerned are also displayed in the planning grid, to help the user to avoid content or time-related collisions. From this overview the user can navigate directly to any appointments which have already been planned, as long as this is presented in the active display variant. · The system can optionally also warn of timerelated collisions. The appointments of the patient are included in this warning, regardless of the OU in which they will take place. Day-specific appointments are classified as colliding with other appointments of the patient on the same day. · Clients can adapt the labeling of planning grid slots which are plannable and those which have already been planned using a BAdI. · The planning authority controls which planning OU may allocate which appointments at a specific plannable OU (a specific planning object). This ensures, for example, that a specific service facility generally plans its own ordered services, but still provides selected order placers with defined time periods on a self-service basis. · This planning authority can be supplemented or further restricted by authorized users at runtime. · Completed plans can be released (preferably during surgery planning) and are subject to versioning in case of subsequent enhancement or modification. Subsequent changes can only be made with special authorizations. Furthermore, it can be determined that the entry of a change reason is obligatory in case of subsequent changes.

· The planning grid offers comfortable options for storing day-related notes on planning objects (calendar columns), in order to inform the planning staff of any room and / or day-specific peculiarities (e.g. employee absences, congresses, etc.). · In the planning grid users can plan on a timespecific basis, whereby both the default time spans stored in the service master (for the service duration as well as for planning objectrelated preparation and follow-up times) as well as the stored scheduling types (as a proposal value when planning visit appointments without a service reference) are taken into account. · Users can also plan on a day-specific basis in the planning grid, in order to be able to map an on call appointment confirmation. · Within the planning grid appointments can be rescheduled or the duration changed using drag & drop. · The planning grid also offers the appointment search offered in other, non-graphical tools both in SAP Patient Management (licensed product from SAP) and i.s.h.med, and visualizes the time slot proposed by the appointment search either in color in the planning grid or presents the hits in a list for supplementing. In this way several appointments can therefore be planned (e.g. at different OUs) for one patient in one work step. The appointment search (see also service description SAP Patient Management – licensed product from SAP) supports the use of predefined search patterns, the specification of certain temporal dependencies between appointments and the consideration of patient preferences. · In i.s.h.med the system searches for appointments depending on a parameter, which is specifiable for each OU, either based on scheduling types, i.e. the labeling of the free slots in the calendar including their duration, or as a service-based appointment search. In the latter case, system settings are taken into account,

Data Sheet i.s.h.med basis Page 22 of 35

which assign specific scheduling types to defined services. This means that a targeted search for free slots with suitable content is possible, as well as the consideration of priorities. · The planning grid also visualizes group appointments and supports the filling of these. · The planning grid is subject to the general appointment management settings as far as the overbooking of appointments is concerned. · The planning grid supports the collective processing of appointments. · In order to comfortably be able to create repeat appointments, a previously booked patient appointment can be used as a template. · Refinement of planning: Appointments which were initially planned as day-specific (perhaps at a coordinating facility or an OU superordinate to a group of modalities or rooms) can subsequently be scheduled as time-specific (e.g. via drag & drop). In the same step it is also possible to specify the actual treatment room, physician or examination device (e.g. radiology). · In order to be able to quickly reschedule several appointments, for example if a resource is suddenly unavailable, the planning grid offers a collective processing function, with which appointment blocks can be changed, rescheduled or canceled. · When certain restricting parameters and formatting defaults are specified, the planning grid can also be printed out.

Quota-Based Planning If appointments, e.g. for surgeries, should not yet be planned as time-specific in the long-term, but are oriented towards defined available quotas, a separate tool is available. This is particularly suitable for planning admission appointments or surgeries and should be used for the resource type which is currently critical.

Optional: For planning admission appointments including approximate lengths of stay for the optimization of capacity in care units containing beds (see also in interdisciplinary units) the component i.s.h.med occupancy management (10415841) is available.

Configuration and Functionality · In order to be able to plan on a quota-related basis, service types are defined. These are technically stored as group services. · Categories can be oriented towards typically rough average durations of surgeries. · The actual medical services are assigned to these defined service types. · For each day the administrator defines the maximum number of services which can be planned for each category. · The user interface of the day-specific planning function enables the simultaneous visualization of admission quotas and, for example, surgery or treatment room quotas. · For faster navigation the day-specific planning tool displays an overview of days which have already been planned. · The state of a day’s booking, in relation to its quotabased time slots, is visualized in color.

Clinical Documentation The clinical documentation consists of: · Documents · Parameterized Medical Documentation (PMD) · Office documents (e.g. Microsoft Word) · Display – document categories for the visualization of XML data or PDF files · Progress entries – module-specific versions of continuous, mostly categorizable documentation. These versions are licensed with certain

Data Sheet i.s.h.med basis Page 23 of 35

i.s.h.med modules and are further described there. (Examples: Nursing progress notes, progress documentation, etc.) · Special documentation objects - This includes all content for which a specific documentation option exists in one of the modules supplied with i.s.h.med, in i.s.h.med basis of in enhanced SAP Patient Management objects (licensed product from SAP). Examples: Diagnoses, medical services, vital signs, allergies, content of nursing process documentation, etc.

Parameterized Medical Documentation The parameterized medical documentation (PMD) enables the structured documentation of patient-related information. It is used to create findings, for example at service facilities, to create discharge summaries and for transferring data from third party systems. Unlike in text documents (such as Microsoft Word, for example) the content of a PMD is saved in database tables. This enables the targeted formatting of different visualizations and printouts as well as the specific access to stored content for the purpose of summarizing (e.g. compiling the findings of a discharge summary) or evaluations.

Definition of PMD Types · Parameterized medical documents are based on document categories. The supplied sample documents can be copied and enhanced with the definition of document categories in i.s.h.med basic data maintenance. · A document category represents the parentheses around any number of documentation elements. Documentation elements are the granular component of a document category. A specific display appearance is assigned to each documentation element at the time of definition: the end result is a document category as a form. Existing form components are available for this.

· Documentation elements can be used individually or in groups in any number of document category definitions.

· The generation of the necessary database tables for a document category, as well as the process logic are, to a large extent, automated.

· As well as documentation elements in the form of input-ready form fields, there are also special elements available, which are used to integrate data from other application areas of i.s.h.med or from third party applications or which can be used to integrate special functions.

· Printing can be formatted with various technologies. As standard print forms are designed using SAP script (licensed product from SAP).

· External data modules (for example for integrating diagnoses, etc.) · Link elements (such as an html control for integrating intranet or internet resources) · Pushbuttons · Content of link elements and simple display fields is not stored as document content. · The structure of a document category can, via the versioning of its master data, be adapted to modified content requirements. The correct display of historical documents of the same category is guaranteed. · Process-relevant settings are determined at document category level, for example via the assignment of a document category to a document type. The latter determines the status profile which applies to a filled document (e.g. In Process à Dictated à Written à Corrected à Released). · The way the instances of a document of this document category behave during case archiving and case revision is regulated at document category level.

· A connection to Adobe printing is available, whereby transfer structures, including the naming of supplementary database content, can be semiautomatically provided in the document category design. A separate ADS (Adobe server) must be available. · When designing print forms with SAP script, an initial form is generated using the defined structures of a document category, the layout of which can be processed with standard SAP means. · Tools simplify the targeted productive use and distribution of document category definitions. It is possible to generate several parameterized medical documents (PMD) at once.

PMD and SAP Document Management PMD uses the SAP document management system (licensed product from SAP) and takes, for example, the status profile and archiving functionality from there.

Usage Scenarios · The (minimum) reference points which a document instance which uses this document category should have are determined when the document category is defined. · Patient (mandatory)

· The way the instances of a document of this document category behave during document dispatch is regulated at document category level.

· Case

· The definition process of a document category is supported in a separate work station. This is where the structure is defined, the screen layout is determined and special process logic is enhanced via user exits.

· Service(s)

Data Sheet i.s.h.med basis Page 24 of 35

· Movement(s)

· During the definition of a document category you can also define whether it is permissible to create more than one document of the same document category, at the level of one of the named optional reference points.

· Documents are therefore used in particular in the following scenarios:

· Often corresponding determination logic is available for the proposal values of other content.

· Discharge summaries (with a reference to an inpatient case)

Subdocuments

· Outpatient clinic reports (with a reference to an outpatient visit)

Several separate documents (of different categories) can be logically connected under one joint document number as subdocuments.

· Organ examination findings, such as radiology findings (with a reference to one or more services)

Security, Release and Versioning

Document Creation A document is often created from a specific, known context. One or more services in a service view in the clinical work station can be the starting point for the creation of a document or, for example, a task in a patient-related work station. Generally it is possible to create a document almost anywhere in the application. Depending on the currently available context information the user is prompted to enter or select data. · Selection of the document category · Allocation of a document number and, where applicable, a version number · Document date and time (in service-related documents this relates to the confirmation time of the performed service)

· A document runs through the pre-defined status logic of its assigned document type. At the end of each status profile there is a release status. This release status represents the applicational protection of the document against later changes. The content of a released document version remains stored in the database. A document is not released with a real digital signature. · If changes or enhancements are made to a document after it has been released, a new version of the document must be created. This is managed as the primary version to be displayed once the document has been released again. However, earlier versions can be accessed at any time. · Furthermore it is possible to track each save process of a document, regardless of versioning, in change documents. This is determined in the master data of the document type.

· Documenting OU

Special Indicators

· Brief text which describes the document content

· An instance of a PMD can have special indicators in the form of text or icons.

· Employee responsible · Reference points · Application and storage path (in Office documents and document references) The presetting of this document management data is based on proposal lists in Customizing. · Service-related document category assignments · OU-related document category assignments

Data Sheet i.s.h.med basis Page 25 of 35

· If a document has one or more special indicators, the one with the highest priority (defined in the master data) is displayed.

Editing Documents · The presetting of the fields of a document is logically determined at the time the document category is defined. This presetting is usually executed when the document is created or after field updates. The presetting can also be actively triggered when the document is filled.

· Interactive data transfer from other documents of the same patient.

Deleting Documents · In accordance with SAP standards, data which has been saved is not physically deleted, but excluded from display by the setting of a deletion indicator. · With corresponding authorization, deleted documents remain available for display. · In i.s.h.med there is a report for the physical removal of deleted documents from the database. · (See also: à Case Archiving)

Handling of Documents, Lists and Mass Processing Functions Documents can be displayed or edited using: · A version of the Documents view type of the clinical work station · The Prefindings Viewer link element in PMD · The patient organizer

is to directly inform the user of new clinical documents which are available either generally or specifically for him. The Documents view type of the clinical work station provides a corresponding determination logic for documents which is generally oriented towards the current departmental or nursing assignment of the patient. · In the overview list corresponding icons indicate whether the logged on user has already read the document concerned or whether another user has already read the document. · Here, the reading of a document means the conscious confirmation of a document which is technically mapped using the document’s status profile. · During the status conversion a log text can optionally be entered. · The specific logic of the findings inbox can be adapted to special requirements using the enhancement framework.

Dispatch Control The individual overviews each use their own special variant concept and have their own procedure for personalization or integration into the role concept. Parameterized documents can be displayed as follows: · Structured as in the entry dialog · As PDF · With an XML scheme (three are available) · With an XML scheme enhanced by the client Furthermore a preview of the printout is available which follows the formatting logic stored at the time of definition.

Findings Inbox This function represents the postal inbox of a care unit / outpatient clinic or a physician for internal documents, i.e. created in the same healthcare institution. Its goal

Data Sheet i.s.h.med basis Page 26 of 35

The dispatch control in document management determines which (external) recipients should receive a document and how. · Documents can be dispatched by post, fax, e-mail, business workplace, web service. Note: For the email and web service dispatch routes an i.s.h.med connectivity (07601086) license is necessary. · In dispatch control the document recipients are selected. · The configuration of dispatch control is connected to the document category. · The dispatch control has its own logging. · Country-specific version AT: A dispatch function (EDIVKA) to insurance providers is available.

Document Communication i.s.h.med as the clinical system with its record, the patient organizer and the various other views of clinical documents is positioned as a registry (directory) and, where applicable, as a repository (storage) of all clinical documents originating in a healthcare institution for a patient. i.s.h.med does not take on the role of an archive (see also Archive Connection). Document content can be imported to i.s.h.med (e.g. lab findings) or references to external documents managed (e.g. findings or image material in a 3rd party RIS). The following functionalities are supported: · Findings transfer via HCM or message communication infrastructure (MCI) · Transfer of document references: Synchronous document transfer (BAPI) or asynchronous transfer via batch input · Special case – lab documents: · i.s.h.med transfers lab findings in a standardized structured form, because lab findings are rarely individual results, but are more often called in trend / progress, i.e. in the form of a cumulative display. Furthermore it is important to specifically call certain individual parameters or parameter groups in specific treatment situations, or also be able to use for presetting (e.g. order forms for the radiology department). · When transferring lab findings, a lab order created in i.s.h.med can be referenced. · Lab data is saved by i.s.h.med in a document category supplied especially for this, which uses special logic for the data handling and display (print preview, cumulative findings, etc.).

Communication with External Systems Message Communication Infrastructure (MCI) The message communication infrastructure supports the implementation of communication processes with external systems in i.s.h.med. The message communication infrastructure provides a standard implementation model for this. The message communication infrastructure consists of the configurator, cockpit and monitor components. These components offer you functions for the configuration, formatting and tracking of incoming and outgoing message flows. Configurator – You can use the configurator to set up a communication process consisting of a start connector, transformer and end connector for a defined communication scenario. A range of standard connectors (e.g. file, RFC, HTTP, CWS, PMD connectors) and standard transformers are available for the configuration. Cockpit – You use the cockpit to receive an overview of the defined communication processes. The system displays how many messages it should process for a communication process, how many messages it has successfully processed and how many it was not possible to process. Monitor – You use the monitor to receive information on individual messages of a communication process. The system displays additional details, for example, the processing status, the start of processing and the end of processing of a message. The specific messages for importing / exporting i.s.h.med objects are provided in additional modules or can be configured in projects.

Archive Connection · For the outbound and inbound (= viewing) communication with archive systems i.s.h.med uses the standardized SAP technology Archive Link. · As a rule, the archiving of documents runs in the background for users. The connection to the archive

Data Sheet i.s.h.med basis Page 27 of 35

system Soarian Health Archive (SHA - subject to license) offers the option of prompting for a digital signature when a document is transferred to the archive system. Note: A special license (Add-On Archiving Connector Imp/Ex – 07601193) is required for the connection to SHA (licensed product).

· Multi-case diagnosis · Secondary diagnosis · Lock indicator (flagging of clinical diagnoses to prevent the administrative access to a diagnosis) · DRG information (country-specific, e.g. Germany) Additional diagnosis information

Diagnosis and Case Processing

· Diagnosis date / time

From an administrative point of view the basic medical documentation is essential and is provided by SAP Patient Management (licensed product from SAP). It is seamlessly integrated into all i.s.h.med clinical applications concerned.

· Diagnosing person

Generally, diagnoses are always documented for the case. A mandatory reference to specific movements of a case (e.g. outpatient visits to service facilities or surgeries) can be enforced by the system via customizing.

· Comment · Number of surgeries (number of surgeries which have been carried out due to a specific diagnosis with an inpatient stay) Several aids are available in SAP Patient Management (licensed product from SAP) and i.s.h.med for diagnosis coding:

Only a few selected functional details are listed here. A complete service description of the basic medical documentation is contained within the documentation on SAP Patient Management (licensed product from SAP).

· Diagnosis catalog

To support the documentation process both by medical staff as well as by any special documentalists or coding directors, a case can receive a case status, which also has a department-specific characteristic.

· Keyword catalog (multi-axial catalog)

Diagnoses can have attributes according to specific criteria, some of which are mandatory at specific times depending on (sometimes country-specific) customizing.

Additionally, a corresponding interface is available in SAP Patient Management (licensed product from SAP) for the connection of external coding systems or DRG groupers.

· Diagnosis type (referral diagnosis., treatment diagnosis) and diagnosis class (admission, surgery, discharge, cause of death, department main diagnosis, hospital main diagnosis). · Localization · Diagnostic certainty · Diagnostic supplement (see also clinical information such as Status After…)

Data Sheet i.s.h.med basis Page 28 of 35

· Hit list · Hierarchic catalog · OU diagnosis hit list

· External diagnosis coding

DRG and Other Billing Systems Country-specific characteristic: For processing diagnoses, procedures and certain other casedependent data SAP Patient Management (licensed product from SAP) provides a country-specific work station, which compiles the processing of the respective data, on a patient and case-related basis, in

a processing environment. Here, the call of an externally connecting DRG grouping software (DE) or online scoring (AT, LKF data) is also provided.

Clinical Case Processing Visits can be moved from one case to another using case revision. Most of the objects connected to this visit are automatically moved with the visit. This function is used when, for example, corrections to an object assignment result during an admission or when the wrong case was selected, for example, in a service facility. The various i.s.h.med objects (clinical orders, documents, radiology objects, medication orders and events) are taken into account in an accordingly plausible way.

Cancel i.s.h.med offers a standard cancellation dialog for its own objects as well as those which are jointly managed with SAP Patient Management (licensed product from SAP). This cancellation dialog helps the user to recognize dependencies between data scheduled for cancellation and other documentation objects of the same patient. The consistency of data objects which are dependent on each other is automatically guaranteed. If specific dependencies do not permit the cancellation of a certain object, the user is informed in the cancellation dialog.

Accident Number Country-specific characteristic AT: In the country version Austria SAP Patient Management (licensed product from SAP) and i.s.h.med offer the option of compounding outpatient and inpatient treatments with a so-called accident number. · An accident number indicates a specific treatment context and is actively created during the initial

Data Sheet i.s.h.med basis Page 29 of 35

patient contact for this treatment context within patient administration. · Via the assignment to a movement in SAP Patient Management (licensed product from SAP) objects in i.s.h.med receive an implicit connection with this treatment context. · The patient history and the prefindings aspect of the patient organizer (i.s.h.med radiology) enable special filtering or grouping of the record content.

Outpatient Clinic and Service Facilities Calling Patients · Following the administrative admission of a patient (SAP Patient Management – licensed product from SAP) i.s.h.med supports calls into the treatment room. · A patient who does not react can automatically be deferred. · The number of calls is logged and can be viewed in the clinical work station.

Outpatient Treatment · The quick creation of documentation, the service entry and requesting of further facilities in the planned treatment process is supported in the form of a simple patient-related work station. · The offered functions, including the respective semantics (e.g. which document categories are offered directly on pushbuttons) can be configured using customizing. · Note: Alternatively, for most of the functions provided here SAP Ambulatory Care Management for Healthcare (ACM – licensed product from SAP) (10178675) provides a patient-related work station based on the documentation work station.

Outpatient Clinic Folder (Part of SAP ACM – Licensed Product from SAP) · The outpatient clinic folder helps to clearly display individual unstructured information on outpatient visits in the form of outpatient notes. · When using i.s.h.med without ACM outpatient clinic folders and individual entries (notes) are created in the patient organizer. · An outpatient note has at least a patient reference. Case and movement references are optional and are configured in customizing.

Application Logging Application logging can be used to log all access to the patient record and specific actions regarding individual objects. If desired, depending on the configured definition, user-specific or patient-related logs are created, which can subsequently be evaluated. Application logging supports a healthcare institution in enhancing its authorization concept to satisfy privacy guidelines in national and regional law. It also enables a check of the effectivity of the configured authorization system and the selective checking of the adherence to organizational regulations.

· The date and time reference preset for an individual outpatient note is configured in customizing.

The following is connected to application logging:

· A print function is available for outpatient notes, with which one or more notes of an outpatient clinic folder can be printed.

· Documents

· Patient record

· Clinical orders

Treatment Sequence

· Medication orders (i.s.h.med medication)

In the outpatient environment i.s.h.med offers the option of determining treatment sequences.

· Medication events (i.s.h.med medication)

· A treatment sequence is the order of the datatechnically connected outpatient visits. · Treatment sequences can be planned in advance. · The steps of a treatment sequence can be called or supplemented in a separate treat screen. · The next planned step of a treatment sequence is called using a simple forward function. · The treatment sequence is used particularly during the organization of accident outpatient clinics and emergency admissions, to organize the necessary treatment steps across several facilities (the patient’s actual visit)

Ending Outpatient Treatment When a patient is deregistered at the end of an outpatient visit i.s.h.med can inform of the correct completion of the service documentation. Several variants are available in customizing for this.

Data Sheet i.s.h.med basis Page 30 of 35

Employee Responsible In many actions in i.s.h.med it is necessary to enter the employee responsible. This is a personal abbreviation which, from a master data point of view, corresponds to the business partner in SAP ERP (licensed product from SAP), which identifies the specific employee. Optionally it is also possible to assign such a responsible employee / business partner to an SAP user in the master data. The documentation of an employee responsible is not connected with the entry of a password or another check based on possession or knowledge, even if the entry is enforced by the system. The entry of an employee responsible serves processorganizational and documentational purposes and does not correspond to a digital signature.

Enhancement Framework

Functionality

i.s.h.med supplies adequate functionality for the typical standard processes of outpatient and inpatient activity, which can be used immediately following correspondding customizing within an implementation project.

· Generally, allergies are documented on a patientspecific basis.

Furthermore, i.s.h.med offers extensive possibilities for completely integrating and enhancing special cases or requests which exceed the boundaries of the supplied standard functionality. Two technologies are available for this: · Older parts of i.s.h.med offer so-called user exits. These programming interfaces, which are called at precisely defined times in a process, offer the option of implementing project-specific enhancements.

· Determine documentation status of allergy documentation: · Have enquiries been made? · Were these successfully completed? · The system differentiates between information which has not yet been queried and the fact that the patient does not know of any allergies at the time of the enquiry. · Documentation of individual allergies of the patient under specification of certain attributes:

· More modern technology with generally the same aim exists in an extensive library of BAdIs.

· Allergen

Allergy Documentation

· Assessment (documented allergies of the patient which are considered to be particularly critical, are highlighted in display)

In addition to the SAP Patient Management risk factors (licensed product from SAP) and as the first level in their replacement, i.s.h.med offers a documentation function especially for allergies in Release 6.05. This represents the first step on the path to the comprehensive documentation of categorized risks or hazard potential for the patient or those which the patient himself causes.

Basic Data · The allergen catalog for the allergy documentation is a special separate catalog category in i.s.h.med’s basic catalog maintenance. · In addition to the allergens, value lists must be stored in corresponding customizing tables for the attributing options listed below during documentation. · If the documentation of allergies is used for the connection of external checking systems in medication, the content of the allergen catalog (typically allergy groups) must be discussed with the supplier of the checking service.

Data Sheet i.s.h.med basis Page 31 of 35

· Allergy type

· Certainty (reliability of information) · Reactions and their severity (several reactions can be documented for each allergen) · The status of the allergy documentation can be displayed as a column in various patient-related views of the clinical work station. This then leads directly to the allergy documentation via a hotspot. · All allergy documentation can be integrated into the situations of the inpatient documentation work stations as a task. · The allergy documentation can be called directly if the patient search is integrated.

Examination and Laboratory Results The results of lab examinations have a special position in clinical operations. The visualization of the results of such examinations is rarely order-related and only partially expected in individual findings. i.s.h.med therefore offers several cumulative displays for lab

findings, which are integrated into the patient-related views of the clinical work station, as well as in the patient organizer and in the ward work station. · The cumulative findings of lab results provides, in its pivot-like display, an overview of the lab values of a patient or case, optionally also for multiple institutions.

Clinical Evaluations / Statistics i.s.h.med basis provides reports in the following categories: · Master data overviews · Services (evaluations using visits or treatments per day, transport list)

· It is also possible to display lab values for all the patients of a ward / care unit. · A restriction to only pathological values is supported. · Users can scroll through findings individually or in blocks. · Various filter functions are available (case, time period, specific lab parameters or parameter groups).

· There are various print formats available, including a collective printing function for each care unit / ward or for each institution, which can be printed as a background job, for example when new findings are received. · The cumulative findings can be provided for calling in several versions, such as when different lab information systems supply information to i.s.h.med (e.g. chemical lab, nuclear medicine lab). Alternatively, or in addition, to the tabular display of lab parameters, other graphical formatting is also available: · Active-X – component for use on Windows platforms: This enhances the above-described functionality with a trend display for a number of lab parameters and offers optimization options in the grid. · Web dynpro components for the formatting of lab results. This is available as part of the clinical overview in versions of the documentation work station (ward work station, surgery work station) and also stand-alone as an alternative to the other display options.

Data Sheet i.s.h.med basis Page 32 of 35

· Evaluations of clinical documentation (countryspecific characteristic: In Germany flat rates per case and procedure surcharges) More specific evaluation options are available in i.c.m.health (see corresponding data sheet).

Prerequisites for Implementation Modules

System

i.s.h.med SAP 6.0 EHP 6 basis is part of the i.s.h.med Basic Medical Record license package (10402193 or 10402294). Prerequisites for this package are:

· Licenses for i.s.h.med Named Users (10402192)

· Generally, i.s.h.med can be technically run on the hardware which is necessary for SAP Patient Management. We recommend the scaling of this concerning CPU performance, RAM, possible server clusters, etc. in accordance with the foreseeable system load (number of users, etc.) (see also SAP note number 1517664).

Integration

· The supported operating system platforms, database systems, etc. are the same as those for SAP ERP Release 6.0.

· License and installation of SAP Patient Management (IS-H) (10178662)

All i.s.h.med modules and departmental solutions are based on i.s.h.med basis. i.s.h.med is understood as a clinical information system in combination with SAP Patient Management (licensed product from SAP). In this integration there is generally no data or functional redundancy. The systems both jointly use the central datasets (such as patients, cases, services, diagnoses, etc. but also appointments, preregistrations, etc.). However, the integration also concerns the technical components such as the transport system, the online service portal and the upgrade and error correction processes. This integration immediately makes functionality from other ERP components available in i.s.h.med. The materials management (MM) content is accessed directly.

· The SAP GUI including the i.s.h.med-specific planning grid component is either used exclusively as the client application or, in addition, the Netweaver Business Client. · Adobe Document Services (ADS) are used for the form-based processing of business data. These run on a Java application server (see also i.s.h.med progress documentation data sheet).

Smart UI (see also SAP note number 1782982) The following recommendations apply for the use of Smart UI components: · SAP GUI for Windows 7.30 or higher

HANA

· SAP Netweaver 7.0 SAP EHP3 SPS 05 or higher

i.s.h.med can be used with HANA database technology from SAP. This technology can be run with the hardware which is usual for i.s.h.med.

· SAP Netweaver Business Client (NWBC) 4.0 for Desktop or higher

Implementing HANA requires an implementation project with SAP and other partners. Within this project it is necessary to procure licenses and configure applications. Furthermore the hardware in use is checked and adapted through optimization.

· Microsoft Silverlight Version 4 or higher (for the patient groups and Smart Chart components)

Data Sheet i.s.h.med basis Page 33 of 35

· Prerequisites for the use of WebDynpro technology

The following recommendations apply for a Smart UI infrastructure: · ABAP application server Hardware – Server: · CPU:

2x Xeon E5-2680 v2

· RAM:

512 GB RAM

· Model:

e.g. HP BL460c G8

· Additionally, if terminal servers are used (e.g. CITRIX) Hardware – Terminal server: · CPU:

2x E5-2680 v2 10-Core 2.8 GHz

· RAM:

64 GB RAM

· HDD:

2x 200GB SSD as RAID-1

· Model:

e.g. HP DL360p G8

· Work station – local NWBC installation or terminal server (e.g. Citrix XenDesktop 7.x) Hardware – Client: · CPU:

Core i5

· RAM:

8 GB RAM

· Graphic: Separate graphic card · Monitor: e.g. 22“ (TFT) with a resolution of 1920*1080 pixels (recommendation) e.g. 19” (TFT) with a resolution of 1280*1024 pixels (minimum) · IT network: At least 1 GBit/s network speed on client

Other Prerequisites ·

Once a year the client must provide voluntary information on license-relevant audits (number of users, number of patients treated each year). In the license contract Cerner expressly reserves the right to perform license audits.

Data Sheet i.s.h.med basis Page 34 of 35

· Services are required for productive use (some can be executed by the client).

The information in this document contains general technical descriptions of specifications and options as well as standard and

About Cerner

optional features which do not always have to be present in

We’re continuously building on our foundation of intelligent solutions for the health care industry. Our technologies connect people and systems and our wide range of services support the clinical, financial, and operational needs of organizations of every size.

individual cases. Thus all requested specifications and options are to be defined individually in the contract. Cerner reserves the right to modify the design, packaging, specifications and options described herein without prior notice. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and in several other countries. Documentation supplied to Cerner by third parties and included with this documentation is not warranted for accuracy or completeness. All personal and patient data displayed in Software Screenshots or

Contact

otherwise in this document are imaginary. Screenshots were created on Cerner owned systems for the purpose of presentation. Any technical data contained in this document may vary within defined tolerances. Original images always lose a certain amount of detail when reproduced. i.s.h.med is not intended to be used for monitoring, clinical diagnostic, and/or therapeutic purposes, or to replace clinical judgment or responsibilities. Healthcare professionals should always refer to the primary information source before making any clinical diagnostic plan or treatment.

Cerner Corporation / 2800 Rockcreek Pkwy / Kansas City, MO 64117 / USA This document contains Cerner confidential and/or proprietary information belonging to Cerner Corporation and/or its related affiliates which may not be reproduced or transmitted in any form or by any means without the express written consent of Cerner. All Cerner trademarks and logos are owned by Cerner, Corp. All other brand or product names are trademarks or registered marks of their respective owners. Data Sheet SW ishmed SAP 6.0 EHP 6 basis en.docx

Page 35 of 35

Released Date: 03/15

Cerner Health Services Deutschland GmbH Karl-Zucker-Straße 18 91052 Erlangen Germany www.cerner.com