Data Sheet SW Ishmed Basis

8/16/2019 Data Sheet SW Ishmed Basis

http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 1/35

i.s.h.medi.s.h.medi.s.h.med

basis(Basic Medical Record)

Data Sheet



Data Sheet i.s.h.med basis

Page 2 of 35

Table of Contents

Solution Defini tion .............................................. 4

Smart UI Initiative ..................................................... 4

Performance Features ........................................ 5

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

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

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

Base Items ................................................................... 6

Categories .................................................................... 6

Material Consumption ................................................... 6

Employees (Business Partners) .................................... 7

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

Medication Orders ...................................................... 14

Progress Entries......................................................... 14

Medical Services ........................................................ 14

Nursing Services ........................................................ 15

Administrative Services .............................................. 15

Chart ......................................................................... 15

Effects on Existing Data.............................................. 15

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

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

Definition of Order Types ............................................ 16

Clinical Order and Appointment Management.............. 17

Process Acceleration and Comfort Functions .............. 17

Service Ordering (Smart UI) .................................... 17

Medical Service Management ................................. 18

Plan Services ............................................................. 18

Document Services .................................................... 18

Appointment Management and Planning ................. 19

Planning Grid ............................................................. 20Quota-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 ........................................................... 25Security, Release and Versioning ............................... 25

Special Indicators ....................................................... 25

Editing Documents ..................................................... 25

Deleting Documents ................................................... 26

Handling of Documents, Lists andMass Processing Functions ........................................ 26

Findings Inbox............................................................ 26

Dispatch Control......................................................... 26

Document Communication.......................................... 27




Page 3 of 35

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 .................................................. 29Outpatient 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 ........................................... 31Basic Data .................................................................. 31

Functionality ............................................................... 31

Examination and Laboratory Results ...................... 31

Clinical Evaluations / Statistics ............................... 32

Prerequisi tes for Implementation .................... 33

Modules ................................................................. 33

Integration .............................................................. 33

HANA ......................................................................... 33

System ................................................................... 33

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

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




Page 4 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 mostimportant 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




Page 5 of 35

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

· Reduction of outlay for implementation and

training

Performance Features

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.

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),




Page 6 of 35

document categories and their structure and much

more.

Depending on the recommended implementation

scenarios, most of this basic data is connected to theSAP 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,

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 basicdata 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 service-

related 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




Page 7 of 35

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)

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.

· Depending on customizing, team documentation

offers employees, according to defined tasks andany 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).

· 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.

Implementation Support

Implementation support is used to transport

customizing data (e.g. order types for the clinical order)

and parameterized documents (PMD) in a systemlandscape.

The two most important components of this function

are offered in the ‘Customizing Transfer Manager’:

· Customizing - Export Wizard

· Customizing - Import Wizard

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.

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.




Page 8 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 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 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.

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.

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 asthe 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 horizontalscrolling.

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 displays content - depending

on the definition of the view - for all patients in an

overview and is therefore suitable for triggering

individual functions.

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 usingfunction keys.

The clinical work station can be enhanced with the help

of the enhancement framework with content to be

displayed and functions.




Page 9 of 35

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.

Administ rat ive and Clinical Object Types

(Content of Record)

· Clinical orders

· Requests

· Diagnoses

· Documents

· Services

· Appointments and movements

· Surgeries

· Procedures

· Medical records

· Country-specific version NL: DBC (Diagnose-

Behandeling-Combinaties)

· 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).

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)

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

· Health problem

· 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.

Screen Areas of the Record

· Range of aspects

· Navigation structure (tree or list)

· 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.




Page 10 of 35

Patient Organizer Functionality

· Call, access to the patient organizer

· The patient organizer can be called from various

views of the clinical work station for a specific

patient.

· 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.

· 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 organizer (not the patient viewer)

offers basic functions for processing the

displayed objects.

· New objects can be created, existing objects can

be changed and canceled.

· 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

clearly using filters or the display can be restricted

using these filters, to simplify work on specific groups

of patients.

Selection Dialog

The patient groups selection dialog enables the quick

and easy determination of patients. The following

selection criteria are available:

· Department

· Treatment / nursing organizational unit

· Current date

· Days back (for discharged patients)

Individual patient groups can be composed using the

following criteria:

· Department

· Treatment / nursing organizational unit

· 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.

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.




Page 11 of 35

· 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.:

· Surgery Tomorrow (a clinical order of the Surgery

type exists for tomorrow)

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

· Planned Discharge (a planned discharge exists)

The patients who satisfy the filter criteria are high-

lighted 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 suppressionof 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 graphical plan is the main component of the

Department Display and the Room Display. In the ListDisplay and the Card Display the system displays the

graphical plan next to the listed patients.

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.

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.

Patient Profi le (Smart UI)

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).

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.)

· Sex

· Age

· Birthdate

· 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.)




Page 12 of 35

· 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.)

· VIP indicator (icon)

· Patient Deceased (icon)

· 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.

· Length of Stay indicator (country version Austria: no

display)

· Department

· Room / bed

· Indicator for private patient

· Attending physician - if an attending physician has

been defined for the corresponding departmentalstay, he is displayed here.

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

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

·

Care unit· Case number

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).

The tasks for a patient are displayed in two lists:

· Tasks of all occupational groups

· Tasks for the user's occupational group

Currently the clinical order and service ordering are

connected to task management. Other tasks can be

displayed using BAdIs.

Applications

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




Page 13 of 35

· Edit Allergies

· Edit Diagnoses

· Create Document

· Edit Delivery Data

· Call Case Overview

· Create Case and Surgery

· Create Clinical Order

· Order Service

· Enter Service

· Subsequently Enter Service

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

license)

· Medication: Create Emergency Event (prerequisite:

i.s.h.med medication license)

· Medical Service Processing

· Outstanding Patient Items

· Create Surgery

· Edit Patient Master Data

· Display Patient Master Data

· 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.medprogress 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)

The applications component is configurable. Functions

can be hidden or grouped according to your own

criteria. Client-specific functions can also be integrated.

Patient Record (Smart UI)

The patient record is part of the patient profile. The

following elements characterize the operation of the

patient record (Smart UI):

· Configurable layout (property of the patient profile)

· One-Click-Action for frequently required functions

· Call of full screen detail screens

· Display of additional information in so-called pop-in

areas for specific objects

· 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)

· Case and time period selection

· Page navigation (property of the patient profile)

· i.s.h.med Smart Chart (licensed) is part of thepatient record

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.




Page 14 of 35

Actions which refer to an existing object (e.g. change,

cancel) can be executed as a one-click action.

All functions and objects are downwards compatible

with the applications in the SAP GUI.

Parameterized Medical Documents (PMD)

The following actions are available:

· Create

· Change

· Release

· Create Version

· Cancel

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.

Examinations


· 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.

Diagnoses


· Create

· Change

· 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.

Vital Signs

The Create function which was previously available in

i.s.h.med (e.g. in the patient organizer ) can be used for

vital signs.

Lab Values

The Create action is available for lab values. This

action can be used to create a request to the lab.

Medication Orders


· Create

· Change

· Cancel

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

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.

Medical Services


· Create

· Change

· Release

· Cancel




Page 15 of 35

One of the following four service entry options can be

determined in customizing for entering or processing

medical services:

· 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


· 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.

Administ rat ive ServicesThe following actions are available:

· Create

· Change

· 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

these are converted into the new progress entry format

and can be displayed in the progress entries of the new

patient record.

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)

The following content of the record can be grouped on

a problem-specific basis:

· Visits

· Appointments

· Medication orders

· Clinical orders

· Outpatient notes

· Documents




Page 16 of 35

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.

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 replacesthe 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 anintensive 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.

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.

Defini tion 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 statusprofile. 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.




Page 17 of 35

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.

· 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 wardand i.s.h.med pathways modules.

Service Ordering (Smart UI)

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.

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 determinedwith 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.

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 thelocalization).

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.

An appointment template can also be created for a

service ordering order. However, appointments cannot




Page 18 of 35

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 oneorder 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 sameorder filler). See also under Appointment

Management and Planning.

· A cycle can be assigned to ordered services.

· Cyclical services are services of the same

service type.

· The definition or assignment of a cycle for a

service and a manual or automated generation

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 depart-

mental 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.

· 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.

· Services can be grouped into service groups for the

following purposes:




Page 19 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, service-

related documents) to an entire group.

· Mapping of semantic groups according to client-

specific 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.

· 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 theday concerned.

Appoin tment 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 day-

specific, quota-based planning)

· Various functions

Planning with i.s.h.med is either day-specific

(determination of the planned date only) or time-

specific.

i.s.h.med also shares the preregistration based on the

clinical order with SAP Patient Management (licensedproduct 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:




Page 20 of 35

· 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

(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 plannablefacilities / 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,




Page 21 of 35

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 decisionconcerning 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 time-

specific. 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 stand-

alone basis, for example at the hub of a servicefacility 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.

· 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 time-

related 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.




Page 22 of 35

· 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 time-

specific basis, whereby both the default time

spans stored in the service master (for the

service duration as well as for planning object-

related 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 timeslot 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,

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 patientappointment 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 severalappointments, 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 PlanningIf 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.




Page 23 of 35

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 thesedefined 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 tooldisplays an overview of days which have already

been planned.

· The state of a day’s booking, in relation to its quota-

based 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

i.s.h.med modules and are further described

there. (Examples: Nursing progress notes,

progress documentation, etc.)

· Special documentation objects - This includes allcontent 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.

Defini tion 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 parenthesesaround 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.




Page 24 of 35

· Documentation elements can be used individually or

in groups in any number of document category

definitions.

· 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.

· 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.

·

The way the instances of a document of thisdocument category behave during document

dispatch is regulated at document category level.

· 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.

· The generation of the necessary database tables for

a document category, as well as the process logic

are, to a large extent, automated.

· Printing can be formatted with various technologies. As standard print forms are designed using SAP

script (licensed product from SAP).

· A connection to Adobe printing is available, whereby

transfer structures, including the naming of

supplementary database content, can be semi-

automatically 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)

· Case

· Movement(s)

· Service(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.




Page 25 of 35

· Documents are therefore used in particular in the

following scenarios:

· Discharge summaries (with a reference to an

inpatient case)

· Outpatient clinic reports (with a reference to an

outpatient visit)

· Organ examination findings, such as radiology

findings (with a reference to one or more

services)

Document Creation

A document is often created from a specific, known

context. One or more services in a service view in theclinical 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)

· Documenting OU

· Brief text which describes the document content

· 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

· Often corresponding determination logic is available

for the proposal values of other content.

Subdocuments

Several separate documents (of different categories)

can be logically connected under one joint document

number as subdocuments.

Security, Release and Versioning

· 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 saveprocess of a document, regardless of versioning, in

change documents. This is determined in the

master data of the document type.

Special Indicators

· An instance of a PMD can have special indicators in

the form of text or icons.

· 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.




Page 26 of 35

· 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

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

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 stationprovides 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 istechnically 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 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 e-

mail 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.




Page 27 of 35

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 rarelyindividual 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 documentcategory 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 supportsthe 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. f ile, 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 hassuccessfully 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.

Arch ive 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




Page 28 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).

Diagnosis and Case Processing

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 clinicalapplications concerned.

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.

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 fromSAP).

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.

Diagnoses can have attributes according to specific

criteria, some of which are mandatory at specific times

depending on (sometimes country-specific)

customizing.

· 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 …)

· 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 date / time

· Diagnosing person

· Comment

·

Number of surgeries (number of surgeries whichhave 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:

· Diagnosis catalog

· Hit list

·

Hierarchic catalog

· OU diagnosis hit list

· Keyword catalog (multi-axial catalog)

· External diagnosis coding

Additionally, a corresponding interface is available in

SAP Patient Management (licensed product from SAP)

for the connection of external coding systems or DRG

groupers.

DRG and Other Bil ling Systems

Country-specific characteristic: For processing

diagnoses, procedures and certain other case-

dependent 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




Page 29 of 35

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

patient contact for this treatment context within

patient administration.

· Via the assignment to a movement in SAP Patient

Management (licensed product from SAP) objects ini.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 Facilit ies

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.




Page 30 of 35

Outpatient Clinic Folder (Part of SAP ACM –

Licensed Product from SAP)

· The outpatient clinic folder helps to clearly display

individual unstructured information on outpatientvisits 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.

· The date and time reference preset for an individual

outpatient note is configured in customizing.

· A print function is available for outpatient notes, with

which one or more notes of an outpatient clinic

folder can be printed.

Treatment Sequence

In the outpatient environment i.s.h.med offers the

option of determining treatment sequences.

· A treatment sequence is the order of the data-

technically 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 (thepatient’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.

Appl ication 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 configureddefinition, 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 following is connected to application logging:

· Patient record

· Documents

· Clinical orders

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

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

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 process-

organizational and documentational purposes and

does not correspond to a digital signature.




Page 31 of 35

Enhancement Framework

i.s.h.med supplies adequate functionality for the typical

standard processes of outpatient and inpatient activity,

which can be used immediately following correspond-ding customizing within an implementation project.

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.

· More modern technology with generally the same

aim exists in an extensive library of BAdIs.

Allergy Documentation

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. Thisrepresents 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.

Functionality

· Generally, allergies are documented on a patient-

specific basis.

· 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 patientunder specification of certain attributes:

· Allergen

· Allergy type

· Assessment (documented allergies of the patient

which are considered to be particularly critical,

are highlighted in display)

· 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




Page 32 of 35

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 itspivot-like display, an overview of the lab values of a

patient or case, optionally also for multiple

institutions.

· 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 labparameters 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.

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)

· Evaluations of clinical documentation (country-

specific 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).




Page 33 of 35

Prerequisites for Implementation

Modules

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:

· License and installation of SAP Patient

Management (IS-H) (10178662)

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

Integration

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 alsoappointments, 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.

HANA

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.

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.

System

· 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).

· The supported operating system platforms,

database systems, etc. are the same as those for

SAP ERP Release 6.0.

· 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

· SAP Netweaver 7.0 SAP EHP3 SPS 05 or higher

· SAP Netweaver Business Client (NWBC) 4.0 for

Desktop or higher

· Prerequisites for the use of WebDynpro technology

· Microsoft Silverlight Version 4 or higher (for the

patient groups and Smart Chart components)




Page 34 of 35

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.

· Services are required for productive use (some can

be executed by the client).



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

About Cerner

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.

The information in this document contains general technical

descriptions of specifications and options as well as standard and

optional features which do not always have to be present in

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 trade-

marks 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

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.

Contact

Cerner Health Services

Deutschland GmbH

Karl-Zucker-Straße 18

91052 Erlangen

Germany

www.cerner.com