project data model

Data Model

for Ophthalmology

Documentation

Published by the Project Management Division at ifa systems AG/

Cologne, Germany

ifa systems AG ifa united i-tech Inc. ifa systems iberia S.L. Augustinusstr. 11 b 1850 SE 17th St. Ste. 107 Cami de Can Manuel 24 50226 Frechen, Germany Ft. Lauderdale, FL 33316, USA 07120 Son Espanyol - Espana phone: +800-43222557 phone: +1-888-4432367 phone: +34-971-438555 www.ifasystems.de www.ifa4emr.com www.ifasystems.es

Table of Contents

1. Concepts on structured medical documentation.................................................................................. 4

1.1 Computer Science in Ophthalmology ............................................................................................ 4

1.2 Individualizing and Standardizing .................................................................................................. 4

1.3 The 3 levels of medical Service procedures .................................................................................. 6

2 Data Entry Structure .............................................................................................................................. 6

2.1 Patient Context .............................................................................................................................. 7

2.2 Risk Factors .................................................................................................................................... 7

2.3 Ophthalmic Numerical Findings .................................................................................................... 7

2.4 Refraction data .............................................................................................................................. 7

2.5 Observation Classes....................................................................................................................... 8

2.6.1 Ophthalmic Surgery ................................................................................................................... 9

2.6.2 Orthoptics ................................................................................................................................ 10

2.7 Diagnoses for Refractions ............................................................................................................ 10

2.8 Ophthalmic and Global diagnoses ............................................................................................... 10

2.9 Treatment Plan ............................................................................................................................ 10

2.10 Service Codes............................................................................................................................... 11

2.11 Medications ................................................................................................................................. 11

2.12 Medical Surgery ........................................................................................................................... 11

2.13 Glasses/CL Prescriptions .............................................................................................................. 11

2.14 SNOMED Mapping Observation Classes ..................................................................................... 12

2.15 SNOMED Diagnosis Mapping ...................................................................................................... 12

2.16 SNOMED Medications (Database) ............................................................................................... 12

2.17 Free Text Documentation ............................................................................................................ 12

3. Data OUTPUT Structures ..................................................................................................................... 13

3.1 Complete Patient Record ............................................................................................................ 13

3.2 Filtered Patient Data ................................................................................................................... 13

3.3 Chart with Numerical Findings .................................................................................................... 14

3.4 Graphic Findings .......................................................................................................................... 14

3.5 Structured Reports ...................................................................................................................... 14

3.6 Administration reports, forms and Billing ................................................................................... 15

3.6.1 Administration reports ............................................................................................................ 15

3.6.3 Billing ....................................................................................................................................... 15

3.7 Statistics and Analysis.................................................................................................................. 16


3.8 Export Interfaces ......................................................................................................................... 16

3.9 SNOMED (Structured Reports) .................................................................................................... 16

4. Organization of Introducing Ophthalmic Documentation .............................................................. 18

4.1 Data Input and Output Areas ...................................................................................................... 18

4.1.1 Data Input Areas ...................................................................................................................... 18

4.1.2 Data Output Areas ................................................................................................................... 20

4.2 Checklist for generating and presetting the system ................................................................... 22

4.3 System Analysis for Data Interfaces ............................................................................................ 24

5. Summary ............................................................................................................................................. 26


Data Model for Ophthalmology

Documentation (ifa systems AG)

1. Concepts on structured medical documentation

By the use of computers, a milestone in history has been reached - to have the ability to document with

standardized terminology and structured data. Scientific development and quality can be increased

rapidly if valid and digitally processed data is available. The era of text reports in the medical field is over

and instead observations are being systemized and made communicable.

1.1 Computer Science in Ophthalmology

Ophthalmology was predestined for a complex data model for documenting medical and demographic

patient data for the computerized patient record. Within 20 years (from 1987 to 2006) a multi-

dimensional data model for documentation in eye clinics and practices was developed by the ifa systems

Group. The system was supported by the official EU project (OPHTEL – Telematics in Ophthalmology) and

the international IEE-Project (Integrated Eyecare Environments).

With the data model it is possible to systematically document more than 98% of all patient cases in

ophthalmology as well as in global medical observations. For this, there are approximately 40

terminology databases that are linked to one another for individualized as well as standardized

terminology. Doctors can link their own individualized vocabulary (coded) with a standardized

terminology dictionary (e.g. diagnosis codes (custom) with ICD terms).

Additionally, the data model offers very flexible and variable documentation because descriptive terms

as well as classifying terms are available in different databases. This makes the data model compatible

with the ICD classifying system and the descriptive SNOMED nomenclature.

1.2 Individualizing and Standardizing

A data model is only acceptable when a doctor can keep using the methods he/she has learned for

documentation. The digital data structure has to be flexible in a way that it can be adapted to the

doctor’s methods and not the other way around.

In ophthalmology, there are different models for examination and treatment procedures as it is the case

with medical documentation. Some ophthalmologists work systematically based on the area of the eye

(organ oriented e.g. cornea, retina, lens etc.). Others work based on the examination steps and

document accordingly (diagnosis, slit lamp, refraction, etc.).


These examination and treatment procedures are represented by so-called observation classes

(observation classes in SNOMED) which can be defined by users within the ifa program. The user can use

pre-existing terminology databases and –for a specialized field – can expand upon these and

differentiate.

The elements in observation classes are made up of 5 digit codes (abbreviations) each with a long text

description. Additionally, the codes can be modified, localized and ranked (SNOMED modifiers). For

example, a code for an embedded corneal foreign body might be COFBE. With the additional fields the

entry can be further qualified with e.g. OD for right eye, 3O for 3 o’clock localization and FR for rusty

iron. Another clinic (or practice) may use different abbreviations for the same observations.

Standardization comes through at a later point of time with the so-called mapping database.

The mapping functions can be understood clearly in an example with diagnosis. Ophthalmologist can

map (link) their own abbreviations with corresponding ICD Codes. A further advantage of this data model

is the fact that customized abbreviations can be linked to more than one diagnosis standardized term.

For example DR01 can be used for Diabetic Retinopathy, Retinopathy is the basic disease and diabetes is

the modifier. In a SNOMED report it is also possible for colleagues from different fields of medicine to

interpret the standardized report.

By linking customized terminology with standardized terminology a worldwide communication system is

created. This makes it possible for doctors in Italy to document in their own language, the system

summarizes the codes into a report and a colleague in the USA receives the report in English.


1.3 The 3 levels of medical Service procedures

The procedures for patient examinations and treatments can be organized into 3 levels. At the beginning

level there are assorted observations, tests and patient interviews (findings survey). In the second level,

medical evaluation or classification takes place (diagnosis). From here the third level is derived e.g.

doctors orders, prescriptions, surgery or other therapy.

Level 1 Observation and Examination Results

- Reason for visit

- History

- Findings

- Test results, etc.

Level 2 Medical Classification

- Diagnosis

- Suspect diagnosis

- Rule out diagnosis

Level 3 Doctor’s Treatment Doctor’s Treatment

- Prescriptions (glasses , medicine, etc.)

- Surgery

- Treatment plan

- General therapy

The data model for ophthalmic documentation (ifa program) makes it possible to link 3 levels. Repeat

processes can be transferred to the data model where findings are linked with the diagnosis and these

are then linked to suggested doctor’s orders.

In all 30 observation classes up to 5 suggested diagnoses can be linked to one findings code. Diagnoses

can then be mapped with service codes (e.g. billing codes) and suggested medications.

Linking different levels of typical service procedures in the clinic can simplify data input on the one hand

and can function as a sort of a guideline on the other hand.

Presettings for the data model are made in the ”User“ and ”Abbrev.“ area of the program.

2 Data Entry Structure Ophthalmic documentation in the ifa program offers approx. 200 different types of data (with different field structures) for the fields of conservative ophthalmology as well as ophthalmic surgery and orthoptics/strabismus. Within the OP documentation it is possible to generate additional customized types of data.


2.1 Patient Context

In order to optimize data input, age and sex are automatically generated from the demographic data

(date of birth and salutation). Since race can be relevant to certain eye diseases an additional data field

within the demographic part of the system is available for that use.

Other social patient factors are stored within the 30 findings classes and not in the demographic area of

the program so that these factors are available if needed for reports.

2.2 Risk Factors

In order to emphasize the importance of medical risk factors this data can be entered into a separate

area. Medical risk factors are defined as allergies, blood pressure, handicaps, etc. This area of the

program was designed so that assistants (non-physicians) can enter this data in the pretesting phase of

the examination. The 30 findings classes are generally used for differential and more discreet types of

risks since this data is entered by doctors.

The medical risk factors in this data category are constantly displayed at the top of the screen of the

patient’s medical record. This data can also be exchanged with monitoring programs in order to establish

an ”Early Warning System“ (watch dog) in the clinic.

2.3 Ophthalmic Numerical Findings

In ophthalmology important findings and results from tests made with instruments can be produced

which makes data interfaces available. These data records are compatible with standard output from

examining instruments. The following areas are available:

Intraocular Pressure (IOP) -> Connection to NCT

Visual acuity -> Connection to phoropter

Keratometer data -> AR/keratometer systems

Other numerical test results e.g. perimetry and biometer data are entered and stored in separate

software applications. More and more software modules are becoming available from the instruments

manufacturers. These applications are linked to the patient history via interfaces.

2.4 Refraction data

Two different types of data records are offered for refraction data:

objective refraction -> Connection to autorefractor

subjective refraction -> Connection to autophoropter

Results from refraction data are used to generate suggested prescriptions for glasses and contact lenses.


2.5 Observation Classes

The observation classes are extremely important for structured ophthalmic documentation. 30 different

observation classes can be custom defined by the user. An unlimited number of codes (abbreviations) is

available for each observation class.

For example, observation classes can be defined for the following areas:

General history

Family history

Medical risks

Corneal findings

Fundus findings

etc.

Standard presettings in the 30 observation classes cover from 6,000 to 10,000 abbreviation codes. The

basis code consists of a 5 digit abbreviation (that can be digitally stored) and a description that can be 40

characters long. The descriptions are linked with the presetting table to the stored abbreviation.

Example: GLAOA Glaucoma open angle

Within data entries observation classes (findings abbreviations) can be qualified with further

abbreviations called modifiers. These specific modifiers contain data on: whether the observation was

made on the left, right or both eyes, the localization of the finding, the severity of the finding. For each

finding 3 additional fields exist for entering these modifiers.

When designing the observation codes, two different concepts can be used. The observation code can be

entered very generally and the specifications will be entered into the modifier fields. Theoretically it

would be sufficient to differentiate between only two different types of glaucoma and any further

specifications could be made in the 3 modifier fields. The other option consists of using the findings

codes to differentiate distinctively between diseases and then only use the modifier fields for special

localization modification (or special cases). The advantage of the last concept is that by differentiating

the findings codes distinctively the findings can then be used for specific statistical analysis. The

modifiers are included in all data output functions i.e. text reports, letters, etc. but in quantitative

statistics only the observation codes (findings) of each class can be evaluated. The suggestions for

presettings are usually so distinctive that they can be used by other specialized eye clinics.

Currently, standardized terminology for ophthalmology is being written on an international level. A

committee from the AAO (American Academy of Ophthalmology) is currently developing proposed

terminology, based on the so-called SNOMED standard (SNOMED = Systemized Nomenclature for

Medicine).


SNOMED is a descriptive documentation language that differentiates between model levels and

observation classes. The data model in the ifa program is completely compatible with the SNOMED

concept. As soon as the reworked ophthalmic SNOMED nomenclature is finished it will be possible to link

custom finding abbreviations (observation codes) with SNOMED codes with the so-called mapping

program.

In the data model it is also possible to link certain findings with proposed diagnoses. For example, the

finding ”visual field loss“ could be linked with several glaucoma diagnoses. If these links have been set,

when entering this finding, the linked diagnosis will be recommended to select from. The user can simply

click on the appropriate diagnosis or enter a different or new diagnosis into the medical record. These

links on different levels help to simplify data input and more than that help to establish the use of certain

documentation guidelines.

The abbreviations and the corresponding descriptions of observation classes are displayed in the

computerized patient history, printed out in reports or displayed in interfaces.

2.6 Special-Documentation

Ophthalmic documentation can cover all areas of ophthalmology because of the flexibility in the

program’s design (see 30 observation classes). Additionally, the CPR software offers special data models

for 2 extra areas in ophthalmology:

Ophthalmic surgery

Orthoptics

Both of these documentation areas are integrated in a way that they are directly linked with one

another. In practice, this means that all general findings and diagnoses are also available for the OP

documentation and patient orthoptics records.

2.6.1 Ophthalmic Surgery

Additional data records are supplied for documenting surgical cases. Types of OP’s (e.g. phaco) can be

preset to include all of the standard steps for that OP. Complete documents i.e. OP reports are linked

with these OP types. Changes can be added with customized information to accommodate any

deviations in the procedures for that surgery (e.g. complications).

A data record generator (designer) exists in the OP program. This designer can be used to generate

customized special data records that are not already included in the program. Data records for lens

specifications already exist in the OP program.


2.6.2 Orthoptics

A complete additional data model is available for the area of orthoptics. Included in this model are data

records for e.g. binocular vision, stereopsis, motility testing with 9 or 49 positions, etc. This numerical

data is supplemented by observation codes from the 30 observation classes. If a special department for

orthoptics/strabismus exists in the clinic then it is recommended to define and preset one of the

observation classes just for that area.

2.7 Diagnoses for Refractions

Based on refraction values that have been entered, refraction diagnoses e.g. myopia will be

automatically proposed by the program. The system evaluates the refraction data and can even propose

combined diagnoses e.g. myopia and astigmatism. A single refraction diagnosis code can include up to 4

different diagnoses.

Refraction diagnoses are part of general diagnoses. They are made up of a 5 digit abbreviations, a 40

character description and a general classification for normal, permanent and quarterly diagnoses (see

below).

2.8 Ophthalmic and Global diagnoses

A separate database is available for diagnoses, independent of observation classes. Just like the

refraction diagnoses, global diagnoses are also 5 digit abbreviations, 40 character descriptions and

classified by normal, permanent and quarterly diagnoses.

A permanent diagnosis is automatically reentered into the patient’s medical record at every visit.

Permanent diagnoses are always visible in the header at the top of the patient’s medical record.

The user classifies which diagnoses are considered normal, permanent, etc. Examples of permanent

diagnoses might be pseudophakia, glaucoma, etc. Normal diagnoses are any acute illnesses, injuries, etc.

The descriptions for diagnosis codes may include the corresponding ICD codes. It is also possible to link

the ICD’s to the diagnosis with the mapping database.

2.9 Treatment Plan

A specific patient treatment plan can be derived and generated from service codes. In the treatment

plan, all examinations and measures taken are displayed graphically on a time axis. Call up the treatment

plan and get a quick overview of all examinations already carried out and all measures planned for the


future. These measures can then be linked to the departmental “Appointment Scheduler” in the

program.

2.10 Service Codes

A database is available for all medical services (e.g. procedures, examinations, tests, etc.). The service

code field has 5 digits (for alphanumerical codes). The codes can be linked to a service legend. It is also

possible to store descriptive tests for the service code descriptions. This database can be used for

insurance codes.

2.11 Medications

A separate database just for ophthalmic medications is also available. A code is available for all

medications and combinations of medications that are on the market (including different package sizes).

The database stores the name, the package sizes and all other relevant data.

It is also possible to link internal medication databases (typical prescribed meds for that clinic) to an

external industry database, often available on CD.

The distinct central pharmaceutical number is used as the identification code for mapping with

corresponding data records (in Germany).

2.12 Medical Surgery

Codes for OP’s can be placed in different databases depending on the specific statistical needs. OP codes

are included as part of the general documentation within the 30 observation classes. This way, a special

class for OP history with the corresponding OP codes is often dedicated within the history part of the

program (e.g. ICPM codes).

Furthermore, codes like ICPM can be used to supplement or replace the service codes. This is practical if

statistics for service codes are needed.

The third possibility for ICPM codes is in the specialized OP documentation. The ICPM codes are part of

the data exchange for AODT (outpatient operations data transfer from the German insurance

companies).

2.13 Glasses/CL Prescriptions

Based on data input for refractions the program automatically proposes prescriptions for glasses/contact

lenses. For the actual prescription additional data (e.g. type of glasses, etc.) needs to be added. The data

in the data record “Glasses Prescriptions” is the basis for printing out prescriptions for glasses or contact

lenses.


2.14 SNOMED Mapping Observation Classes

The introduction of the SNOMED codes in international ophthalmology represents a new additional

database for terminology. The codes from the 30 observation classes can be combined with SNOMED

codes. These links already exist for the area of diagnosis.

2.15 SNOMED Diagnosis Mapping

Standardized terminology is often not flexible enough for daily documentation in the computerized

patient record. For this reason, the data model provides the ability to link custom terminology with

standardized terminology (mapped).

The individualized diagnosis codes can be combined with ICD codes, which are part of the SNOMED

nomenclature. ICD 9 and ICD 10 databases are also available. These are classified based on WHO (World

Health Organization), in a 5 digit system, and further classified with 6 digits. The 6 digit code is based on

the ICD catalog published by the American Academy of Ophthalmology (see also book on ICD coding in

ophthalmology, published by Biermann Publishing in cooperation with ifa).

Mapping local diagnosis with standardized codes makes it possible to combine custom abbreviations to

several diagnoses. Then, for example, the abbreviation DR for diabetic retinopathy is linked to the ICD

code for diabetes as the basic disease, and to the code for diabetic retinopathy for the ophthalmic

disease.

The ICD database makes it easy to link both codes. An intelligent search algorithm screens and compares

the long descriptions in both databases.

In Germany, a linked database combination of local terminology with the ICD terminology already exists.

2.16 SNOMED Medications (Database)

Medications can also be linked with external standards. In Germany links exist between medication

abbreviations and the so-called Central pharmaceutical numbers.

2.17 Free Text Documentation

In addition to the structured input that has been described up until now, the data model also offers the

ability to enter free text into all areas of the program. The free text entries should be kept to a minimum

though, in order to allow for a systematic analysis of the digitally stored patient data. The custom

terminology should be so distinct, especially in the 30 observation classes, that more than 98% of the

observations can be systematically stored. The individualized free text should only be used in special

cases.


The individual free text can be entered into the remarks line to all observation classes where codes are

attached (F4 function).

Another free text function exists in the program for entering multiple lines of free text. These too, can be

combined with the data model.

A third possibility exists by entering information into the so-called “Infobox”. The “Infobox” should be

seen as sort of a reminder note that is only usually used on a temporary basis – e.g. special notes about

patients.

The fourth possibility is the creation of text reports. Two different text systems exist:

ifa Write

MS Word for ifa

Documents can be created with both systems that can be included as part of the patient record.

3. Data OUTPUT Structures

Complex output structures also exist to the differential input areas within the CPR software. The stored

patient data in the CPR can be evaluated and exported in all possible forms e.g. text reports, forms,

digital data reports as well as billing and statistics.

3.1 Complete Patient Record

The complete patient record is a compilation of all stored data for that patient. This is displayed in the

screen and contains all numerical results from all 30 observation classes, diagnoses, medications, free

text, etc. This complete patient record can also be printed out.

The complete patient record (as well as all other displays of data) can be custom defined by the user and

thus modified (see “User”).

3.2 Filtered Patient Data

The program offers a variety of possibilities for filtering patient data for compromised analysis and

interpretation.

As an example for this, the so-called “patient record short” can be used. This record can be custom

defined by the user. It may be used to include all data only from the last visit.

A so-called “Layout Medical Record Screen” can be created for each working area within the program

(e.g. observation classes, diagnosis input, etc.). This “Layout Medical Record Screen” displays any "other"


data that is relevant for that working area or area of documentation. The user can use the information

system for entering data from already existing patients.

For clinical documentation it is also sensible and essential to document the "normal" findings. Since this

substantially increases the amount of data entered for each patient, it can overload the “quick

overviews”. For this reason, a function has been developed to highlight only the “important” findings.

This makes it easier to quickly evaluate the extracted data. The program can be set up in a way that only

“important” findings will be displayed thus producing a quicker overview.

Another method of filtering data exists of course in generating reports. All codes are imported into the

reports that are necessary to create an overview.

3.3 Chart with Numerical Findings

The data model provides graphic charts for visualizing observations and findings for tonometry and visual

acuities.

The tonometry trend chart is especially important. Pressures for the left and right eye are displayed

separately on a time axis. Additionally, an average of past IOP values can be displayed as a graph.

Graphic displays can have a positive influence on patient education and are often used in clinics to

optimize patient compliance (e.g. glaucoma patients).

3.4 Graphic Findings

Regardless of the type of data model, the ifa program makes it possible to display findings as graphics.

Symbols can be inserted or drawn onto templates (e.g. fundus picture, picture of the eye). These

symbols are stored in a database together with their corresponding descriptions i.e. findings (e.g. horse

shoe tear, cotton wool spots, etc.).

Photo documentation for ophthalmic data is also available (see separate pamphlet on storing images and

image documentation).

3.5 Structured Reports

Several alternatives within the program are available for text output e.g.:

MS Word for ifa

Report Generator within OP Documentation


Form letters can be generated to be used for all patients where patient data is replaced from each

patient. Graphic charts, findings graphics and patient images can also be inserted into the documents.

Reports generated in “Word for ifa” can be sent automatically as attachments to emails.

With Word a complex word processor such as MS Word was combined with the patient data from the ifa

system to "MS Word for ifa". Prerequisite is the corresponding Word license. All of the patient data

records can also be inserted into these documents. Form documents can be created for doctor's reports,

OP reports or extensive individualized expert's reports.

A report generator within OP documentation is also available for quick text output. It generates the

preset OP steps in a form document.

3.6 Administration reports, forms and Billing

The system contains extensive possibilities for administration functions (e.g. clinic administration) which

differentiates between patient relative and time relative reports.

3.6.1 Administration reports

In administration reports there are direct and indirect ways of generating statistics. For the direct way,

functions like the so-called Explanation Statistics for Coding (explanation of why codes were used, etc.)

are available. The results are overviews of patient data with the corresponding diagnoses. On the one

hand these documents the quantity of the services rendered, on the other hand the efficiency of the

services (seen from an economic point of view).

For an indirect way of generating statistics, data can be exported into a standard database (e.g. MS

Access) and evaluated in that program with the appropriate tools.

3.6.2 Forms

All stored patient data can be used to create standard forms with a special “forms generator” – i.e.

prescriptions, glasses prescriptions, patient release reports and internal patient oriented documentation.

Additional forms are available within the OP documentation.

Users can generate forms or alter existing forms on their own if they have been trained on the forms

generator. (See guide to Forms Generator)

3.6.3 Billing

Based on procedures and services codes the system can be used for writing and administering insurance

bills and private patient bills.


In Germany and Austria, the ifa system holds a license from the union of national insurance carriers for

writing quarterly insurance bills based on ADT standards (exchange data protocol).

The program can also be used for private billing functions. Single or consolidated bills can be written.

Extensive service statistics are available for the area of patient billing.

3.7 Statistics and Analysis

The system also offers direct and indirect evaluation methods for the area of statistics and analysis.

Direct statistics can be calculated straight from the system on documented diagnosis and medications

prescriptions. Diagnoses are classified based on patient groups and age and the desired time periods can

be selected (month, quarter, year, etc.).

Patient profiles can also be created. Statistics based on new and existing patients and single and

combination diagnoses can be made (see also Recall).

If the diagnosis codes are mapped with ICD classifications, a distinct ICD statistic can then be made.

The direct evaluations can be supplemented by indirect evaluations with an external database. An export

interface exists that can export patient data, based on time periods, into an external database e.g.

Access. The Access standard tools can be used to produce statistics in lists, charts, etc.

The indirect data evaluation makes it possible to filter data or to extract certain data for research which

is not possible with the real data for forensic reasons.

3.8 Export Interfaces

Extensive export interfaces are available within the ifa system. Data can be exchanged with local

evaluation programs or with external administration systems. Although standard tools exist for export

interfaces, each interface has to be programmed individually. For this, the IT Dept. will supply a system

analysis with examples of data records. The data protocol can either be individualized or follow the HL7

standard. The ifa systems group is a member of the HL7 Organizational Committee.

The different possibilities for export interfaces are described in detail in the OPHTEL EU project (see

“Status Report and Interface description“ WP11/Integration).

3.9 SNOMED (Structured Reports)

Currently, efforts are being made to introduce the SNOMED structure (standardized terminology) on an

international level. ifa is currently working together with CAT, a workgroup from the American Academy


of Ophthalmology, on a special issue of the existing codes for ophthalmology. Standard reports, called

Structured Reports (SR) have been worked out within this cooperation.

3.10 DICOM Documents

The DICOM standards were initially developed in the field of radiology and are used as the standard for

all other areas of medicine. A DICOM document (DICOM = Digital Imaging and Documentation in

Medicine) is made up of 3 areas:

Technical header

Image information

Medical data document (SNOMED)

The technical header in a DICOM document depends on the instrument that is used (e.g. camera or

diagnostic laser). In addition to the image data stored in a specific format, the document will be linked

with information from the CPR software based on the SNOMED standards. The ifa systems Group is a

member of the international DICOM committee and responsible (with others) for ophthalmology.


4. Organization of Introducing Ophthalmic Documentation

The complexity of the data model requires consistency in preparation for the computer documentation.

The data flow within the eye clinic/eye department needs to be analyzed ahead of time. The existing

type of manual data input and output will then be changed with the corresponding presettings.

4.1 Data Input and Output Areas

4.1.1 Data Input Areas

The data to be entered in ophthalmology comes from very different areas and data sources. Data

categories can be classified as follows:

General patient data

Secondary history (not medical)

Pretests

General examinations

Diagnosis statements

OP area

Specialized areas (orthoptics, strabismus, etc.)

Administration and billing

Data input can generally be separated into the 4 following areas:

Data export from administration systems (demographic patient data)

Data collection from non-physician (secondary history, pretests, etc.)

Data collection from physicians (primary history, findings, etc.)

Data export from digital diagnostic and examination instruments (autorefractor, perimeter, etc.)

An overview of the areas for data collection, the sources and the corresponding areas of responsibility

helps to support professional use of the computerized data model (see next page).


Overview Data Input Eye Clinic/Eye Department

Collection of Data No. Area of

responsibility

Dept.

General patient data

- Basic data (address, etc.)

- Admin. Data (internal pat. no. etc.)

- Reason for visit

- Referring doctor

- Billing code

Secondary History

- Risk factors

- Chief complaints

-

-

Pretesting

- Objective Refraction

- Lensmeter

- Vision

- Subjective Refraction

- Perimetry

-

-

General Examination

- History

- Chief complaint

- General finding

- Ophthalmic findings

- Special examinations results

-

-

Diagnosis statements

OP area (separate entries)

Special area (orthoptics, CL etc.)

Administration and billing data


4.1.2 Data Output Areas

Similar to data input areas, data output areas can also be classified into different areas:

Monitor screens

Form printouts

Invoices

General reports and doctor’s reports

Statistics

Data interfaces to external systems

Furthermore it is important to differentiate between different data recipients and their communication

forms:

Administration department (billing and statistics)

Colleagues (referrals, other treating physicians, etc.)

Patients (private billing, patient education fliers, etc.)

Team (training, internal studies, etc.)

With data output it is important to note the goals of the project (see Compendium for Introducing the

Computerized Patient Record in an Eye Clinic). By using computerized data processing, information is

consolidated substantially when compared with traditional hand written records. It is important to

establish which additional areas for data output would be desired to attain even more efficiency when

introducing the CPR.

On the following pages you will find an overview of possible data output areas as checklists.


Overview of Data Output Areas in Eye Clinic/Eye Department

Data Output No. Area of

Responsibility

Dept.

Monitor Screens

- Patient history (complete)

- Patient overview

- Layout of Medical Screen

-

Forms

- Patient registration overview

- Exam form

- Prescription for meds

- Changes in glasses prescrip.

-

Billing

- Internal services documentation

- Insurance billing

- Private billing

- Billing statistics

-

Reports and Doctor’s Reports

- Release reports

- OP reports

- General doctor’s letters

- Standard examinations

- Special examination results

Statistics

- Diagnoses

- Services

- Patient profile

Data Interfaces

- Data import

- Data export


4.2 Checklist for generating and presetting the system

The CPR system enables the user to customize presettings and adapt the program to fit the existing

practice routines (data flow chart). Various working areas are available for this e.g. “User” and “System”.

The following are some of the areas that will be preset:

Screen design

Database documentation (abbrevation system)

Mapping function (links internal and external)

OP Documentation and other specialized areas

Graphic surfaces (Smart Screen)

System generation and presettings are carried out in the preparation phase together with the systems

partner. Suggested presettings are given to the user to be used as a basis for modifying and customizing

their own.

Smart Screen (templates and buttons for quick data input) demands a separate special training session.

Customized templates can only be created after all areas of the system have been preset and the

routines for data input are concrete and on paper.

On the following page you will find an additional checklist for support on these topics.


Additional Checklist for Presetting the System in the Eye Clinic/Department

Generated Screen No. Area of

Responsibility

Dept.

- Menu per workstation

- Routine definition per workstation

- Medical Screen Layout per workstation

- Patient history

- Patient file short

- Positive findings/negative findings

Database Documentation

- Diagnosis codes

- Observation classes (30)

- Service codes

- Medications

- Other abbreviations

-

Mapping Functions (Links)

- Observations/ Findings – Diagnosis

- Diagnosis codes

- Diagnosis medications

- Diagnosis ICD codes

- Functions billing codes

-

OP Documentation

- OP classes and types

- OP standards steps

- OP services (ICPM)

- OP reports

-

User Surface SMART SCREEN

- Menu templates

- Entry templates

- Functions templates

(see separate description)


4.3 System Analysis for Data Interfaces

Establishing data exchange between the CPR system and other systems in the clinic is done in a separate

system analysis. Included are the requirements from the IT Dept. The system analysis contains the

following areas:

Description of target system (functions, operating system, etc.)

Technical protocol descriptions (transmission, protocols, etc.)

Data description (data form and type of transmission)

Mapping overview (if one category is to be transmitted into another category)

Examples of desired data transmission

Organizational information (Areas of responsibility, time schedule, etc.)

Different interface and data export programs exist (see OPHTEL deliverable Status of Integration). In any

case, it is necessary to program and adapt each system individually, since the systems are

heterogeneous. This is calculated based on time needed within the project. The system analysis should

be available approx. 4 weeks before the test installation. Further changes will be made on the basis of

supplements to the system analysis. On the following page, there is an outline for a proposal for a

system analysis.


System Analysis for Export and Import Interfaces for CPR System (ifa)

Table of Contents:

1. Description of target system - Admin. system

- General documentation system

- System platform

2. Technical description of

transmission

- Physical transmission (e.g. file, serial,

TCP/IP, FTP)

- Logical transmission

- Protocol (e.g. HL7, etc.)

3. Description of data for transmission - ID

- Diagnosis

- CPT codes, etc.

4. Mapping overview (if data from

observation class has been

transmitted)

5. Examples of desired data

transmissions

- Standard examples

- Record with all possible patient data to be

transferred

- Examples as printouts and on data medium

6. Organization information - Responsibility in the IT Dept.

- Time schedule

- Confirmation for changes and budget

Remarks to conditions: The system analysis is a part of the project contract. Any changes in requirements

after the system’s analysis are additions to the contract and will be invoiced accordingly. Missing

information or false information is carried by the project client.


5. Summary

The data model for ophthalmic documentation in the ifa system has been developed based on modern

requirements from medical information sciences. Specialized medical ophthalmic documentation has

already been realized for more than 30 million patients.

The system is completely compatible to existing international standards and standards that are currently

being developed (i.e. SNOMED and DICOM). Existing classification systems such as ICD and ICPM are

already included.

Data export from more than 200 examination and diagnosis instruments into the patient medical record

have already been developed for the field of ophthalmology. Approximately 20 new instruments and

data interfaces are programmed each year.

The success of introducing a computerized patient record depends on how well the custom adaptation

of the data model for that clinic’s or department’s specific requirements have been fulfilled. The systems

partner (ifa team) gives support by training and acting as a consultant in organizational queries.

Exchange of experience from existing users and information exchange on a regular basis is sensible and

necessary. This exchange is supported by the system partner with user meetings and information

exchange and communication via internet).


Definition of Observation Classes

Version: Example 1

No. Code

2-digit

Class Description

(up to) 20 digits

Responsibility Area

01 A1 History– Allergies

02 A2 History – Family

03 A3 Risks– Allergies

04 A4 Risks– Medications

05 A5 Risks– Ophthalmology

06 RF Risks

07 RV Reason for visit

08 GL Glasses

09 OR Objective Refraction

10 VI Vision

11 CC Chief Complaint

12 OM Orthoptic/Muscle

13 PU Pupil

14 LL Lids/Lacrimal

15 CJ Conjunctiva

16 CO Cornea

17 AC Anterior Chamber

18 IC Iris/Ciliary Body

19 LE Lens

20 GK Vitreous

21 AH Choroid

22 NH Retina

23 OP Optic Nerve.

24 PE Perimetry

25 FA Fluo-Angiography

26 OP Surgery

27 US Ultrasound

28 TP Treatment Plan

29 N.N.

30 N.N.



Version: Example 2

No. Code

2-digit

Class Description

(up to) 20 digits

Internal:

Responsible area

01 RS Review of Systems

02 PH Past Medical Hx

03 PS Past Surgical Hx

04 PO Past Ocular Hx

05 EM Eye Medications

06 MD General Medications

07 AL Allergy Hx

08 FH Family General Hx

09 FO Family Ocular Hx

10 SH Social Hx

11 CC Chief Complaint

12 HP Hx of Present Illness

13 PU Pupils

14 EE External Exam

15 MO Motility

16 LI Lids

17 CJ Conjunctiva

18 CO Cornea

19 IR Iris


21 GO Gonioscopy

22 LE Lens

23 VI Vitreous

24 RE Retina

25 ON Optic Nerve

26 VE Vessels

27 MA Macula

28 AT Additional Tests

29

30


Version: Example 3


No. Code

2-digit

Class Description

(up to) 20 digits

Internal:

Responsible area

01 Y1 Symptom 1

02 Q1 Quality 1

03 L1 Location 1

04 S1 Severity 1

05 D1 Duration 1

06 T1 Timing 1

07 C1 Context 1

08 A1 Associated 1

09 Y2 Other Symptoms

10 Q2 Quality 2

11 L2 Location 2

12 S2 Severity 2

13 D2 Duration 2

14 T2 Timing 2

15 PA Pachometer

16 EC Endothelium Count

17 Y3 Symptom 3

18 Q3 Quality 3

19 L3 Location 3

20 S3 Severity 3

21 D3 Duration 3

22 T3 Timing 3

23 C3 Context 3

24 A3 Associated 3

25 SE Specialty Exams

26 PO Past Ocular Hx

27 CH Contact Lens Hx

28 EM Eye Medications

29 PR Ocular Procedures

No. Code

2-digit

Class Description

(up to) 20 digits

Internal:

Responsible area

30 AL Allergies

31 PH Past Medical Hx


32 MD Systemic Medications

33 FH Family Medical Hx

34 SH Social Hx

35 GE Gen.\ Mental Status

36 CN Constitutional

37 PS Psychological

38 EN Ear, Nose and Throat

39 HB Cardiovascular

40 LR Lungs & Respiratory

41 GA Gastrointestinal

42 MU Muskuloskeletal

43 GN Genitourinary

44 SB Skin and Breast

45 NE Neurological

46 ED Endocrine

47 IS Immunological

48 BL Hem./Lymphatic

49 LV Low Vision

50 PU Pupils

51 DL Pupils Dilation

52 VF Visual Fields

53 MO Motility

54 AD Adnexae

55 EL AD/Eyelids

56 LG AD/Lacrimal Glands

57 LD AD/Lacrimal Drainage

58 PN AD/Preauricular Node

59 FA Facial

60 CB Conjunctiva

61 CP Conj./Palpebral

No. Code

2-digit

Class Description

(up to) 20 digits

Internal:

Responsible area

62 CO Cornea

63 EP Cornea/Epithelium

64 EO Cornea/Endothelium


65 ST Cornea/Stroma

66 CS CL Soft

67 CR CL RGP

68 IR Iris


70 FC Fulfilment Center

71 L Letters

72 GO Gonioscopy

73 LY Lens

74 LA Lens/Ant. Capsule

75 LC Lens/Cortex

76 LN Lens/Nucleus

77 LP Lens/Post. Capsule

78 VI Vitreous

79 OA Optic Nerve

80 CD ON CD Ratio

81 ON ON Nerve Fiber Layer

82 RT Retina

83 MA Macula

84 VE Vessels

85 PP Periphery

86 TP Treatment Plan

87 TM Treatment Meds

88 TS Treatment Procedures

89 TC Treatment CL

90 TL Treatment LV

91 SO Soft CL Order

92 RO RGP Order

93 TT Test/Labs Ordered

94 AT Additional Tests

95 TI Test Interpretation

96 TF FU/To Do/RTC

97 OP CPT Codes

98 RM Relationship Mgmt

99 SG Sign Off

project data model

Documents

ifa systems iberia

ifa systems ag cologne

medical surgery

ophthalmic surgery

ophthalmology documentation

data model

refraction data

data entry structure