data sheet sw ishmed basis
TRANSCRIPT
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 2/35
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 3/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 4/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 5/35
Data Sheet i.s.h.med basis
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),
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 6/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 7/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 8/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 9/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 10/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 11/35
Data Sheet i.s.h.med basis
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.)
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 12/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 13/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 14/35
Data Sheet i.s.h.med basis
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
The following actions are available:
· Create
· Change
· Cancel
Examinations can be ordered in i.s.h.med both with the
clinical order component in the SAP GUI as well as
with the service ordering function within Smart UI. The
system displays the clinical orders in the Examinations
component of the patient record.
Diagnoses
The following actions are available:
· 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
The following actions are available:
· 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
The following actions are available:
· Create
· Change
· Release
· Cancel
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 15/35
Data Sheet i.s.h.med basis
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
The following actions are available:
· Create
· Change
· Release
· Cancel
· The functions which were previously available in
i.s.h.med (e.g. in the patient organizer ) can be used
for nursing services in the patient record.
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 16/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 17/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 18/35
Data Sheet i.s.h.med basis
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:
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 19/35
Data Sheet i.s.h.med basis
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:
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 20/35
Data Sheet i.s.h.med basis
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,
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 21/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 22/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 23/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 24/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 25/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 26/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 27/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 28/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 29/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 30/35
Data Sheet i.s.h.med basis
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.
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 31/35
Data Sheet i.s.h.med basis
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
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 32/35
Data Sheet i.s.h.med basis
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).
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 33/35
Data Sheet i.s.h.med basis
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)
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 34/35
Data Sheet i.s.h.med basis
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).
8/16/2019 Data Sheet SW Ishmed Basis
http://slidepdf.com/reader/full/data-sheet-sw-ishmed-basis 35/35
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