BMD en

Prometheus
Information system for stem cells donor registries

User documentation
STEINER
Version: 7.5.2010
All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or
mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the
written permission of the publisher.
Products that are referred to in this document may be either trademarks and/or registered trademarks of the
respective owners. The publisher and the author make no claim to these trademarks.
Prometheus
2010 Steiner, s.r.o.
3 Contents
3
Contents
Chapter I Introduction 8
................................................................................................................................... 9 1 History of Prometheus system
................................................................................................................................... 9 2 Basic concepts
................................................................................................................................... 10 3 Structure of Prometheus system
................................................................................................................................... 11 4 Work (production) and Testing Environments.
Chapter II Program Prometheus 14
................................................................................................................................... 14 1 Program start
................................................................................................................................... 14 2 User password change
................................................................................................................................... 15 3 Nomenclature update
................................................................................................................................... 15 4 Nomenclature HLA
................................................................................................................................... 16 5 Main program window
.......................................................................................................................................................... 17 Quick select buttons
.......................................................................................................................................................... 18 Panel selection buttons
.......................................................................................................................................................... 19 Work Panel Donor
.......................................................................................................................................................... 20 Work Panel Patient
.......................................................................................................................................................... 21 Work Panel Active Patients
.......................................................................................................................................................... 22 Hot keys
Chapter III Evidence of donors 23
................................................................................................................................... 23 1 Donor select
................................................................................................................................... 25 2 Donor data edit
.......................................................................................................................................................... 26 Form control
.......................................................................................................................................................... 27 Behavior of input fields
.......................................................................................................................................................... 29 Blood samples
................................................................................................................................... 31 3 Donor data change history
................................................................................................................................... 34 4 Donor stack
................................................................................................................................... 35 5 Donor reports
.......................................................................................................................................................... 36 Print report preview
................................................................................................................................... 36 6 Data import
.......................................................................................................................................................... 36 Basic data BPK import
.......................................................................................................................................................... 36 EMDIS data BPK import
................................................................................................................................... 37 7 Data export to BMDW
.......................................................................................................................................................... 40 Data Encryption
................................................................................................................................... 43 8 Data Export to NETCORD
.......................................................................................................................................................... 43 Exporting CBU data FI
................................................................................................................................... 45 9 Donor registration cards
.......................................................................................................................................................... 45 Creating Donor cards
................................................................................................................................... 47 10 Donor analysis
.......................................................................................................................................................... 48 Task definition
Prometheus 4
.......................................................................................................................................................... 48 Data preparation
.......................................................................................................................................................... 48 Column projection
.......................................................................................................................................................... 49 Donor selection
.......................................................................................................................................................... 50 Donor grouping
.......................................................................................................................................................... 51 Donor sorting
.......................................................................................................................................................... 51 Result viewing
.......................................................................................................................................................... 51 Print preparation
.......................................................................................................................................................... 52 Print
.......................................................................................................................................................... 52 Export to stack
.......................................................................................................................................................... 53 Data export to file
Chapter IV Evidence of patients 54
................................................................................................................................... 54 1 Patient select
................................................................................................................................... 54 2 Patient data edit
................................................................................................................................... 55 3 Attached Files
................................................................................................................................... 56 4 Patient data change history
................................................................................................................................... 56 5 Patient-donor relationships
................................................................................................................................... 58 6 Patient stack
................................................................................................................................... 58 7 Patient reports
................................................................................................................................... 59 8 Typing Report
................................................................................................................................... 62 9 Patient analysis
Chapter V Interfaces 62
................................................................................................................................... 63 1 Interfaces Work Panel - Imports
................................................................................................................................... 66 2 Interfaces Work Panel - Exports
Chapter VI Invoices 67
................................................................................................................................... 67 1 Invoice management FI
Chapter VII Storage and Product Management 72
................................................................................................................................... 73 1 Store structure
................................................................................................................................... 76 2 Positions in store
................................................................................................................................... 78 3 Store Product Management
Chapter VIII Donor search for patients 80
................................................................................................................................... 80 1 Patient selection
................................................................................................................................... 81 2 Search parameters
................................................................................................................................... 82 3 Search
................................................................................................................................... 82 4 Search result
................................................................................................................................... 84 5 HLA match grades of donor and patient
................................................................................................................................... 85 6 Repeated search
................................................................................................................................... 85 7 Search saving to database
................................................................................................................................... 85 8 Search report
5 Contents
5
Chapter IX Quality check 86
................................................................................................................................... 87 1 Donor database quality check
................................................................................................................................... 89 2 Patient database quality check
Chapter X Introduction to EMDIS system 89
................................................................................................................................... 90 1 Basic concepts
................................................................................................................................... 90 2 ECS
................................................................................................................................... 91 3 PGP
................................................................................................................................... 91 4 FML
................................................................................................................................... 91 5 Data messages types
................................................................................................................................... 92 6 Additional information about EMDIS
Chapter XI ESTER 92
................................................................................................................................... 94 1 Intervals
................................................................................................................................... 95 2 Data flow
................................................................................................................................... 95 3 EsterBmd
Chapter XII Characteristics of EMDIS messages 95
................................................................................................................................... 96 1 Physical and logical messages
................................................................................................................................... 97 2 DONOR_CB arriving message categories
................................................................................................................................... 98 3 Log. message characteristics
................................................................................................................................... 98 4 Log. message folders
................................................................................................................................... 99 5 Log. message status
................................................................................................................................... 99 6 New and old log. messages
................................................................................................................................... 99 7 Relations among log. messages
................................................................................................................................... 100 8 Arriving logical message creation
Chapter XIII EMDIS - work with program 101
................................................................................................................................... 102 1 EMDIS items of patient
................................................................................................................................... 103 2 EMDIS items of donor
................................................................................................................................... 104 3 Basic scheme of work with EMDIS
................................................................................................................................... 105 4 Internal requests and results
................................................................................................................................... 105 5 Browsing of log. messages
................................................................................................................................... 107 6 EMDIS patient tools
.......................................................................................................................................................... 110 Foreign patient tools EMDIS
.......................................................................................................................................................... 111 Patient status in registries
.......................................................................................................................................................... 111 Unification of work with all registries
.......................................................................................................................................................... 112 Watching of search results changes
................................................................................................................................... 112 7 Log. messages browsing
.......................................................................................................................................................... 113 General
.......................................................................................................................................................... 114 Physical messages
.......................................................................................................................................................... 116 Content
Prometheus 6
................................................................................................................................... 116 8 EMDIS search results
.......................................................................................................................................................... 116 Patient
.......................................................................................................................................................... 117 Summary of donors
.......................................................................................................................................................... 117 List of Donors
.......................................................................................................................................................... 120 Donor - Details
................................................................................................................................... 120 9 Report of search results
................................................................................................................................... 123 10 Addresses of EMDIS centers
................................................................................................................................... 124 11 EMDIS reports
.......................................................................................................................................................... 124 Reports of patient statuses
.......................................................................................................................................................... 125 Reports of EMDIS messages
................................................................................................................................... 125 12 Writing of unattached texts in EMDIS
Chapter XIV Communication in EMDIS 125
................................................................................................................................... 125 1 General rules
................................................................................................................................... 126 2 Patient statuses
................................................................................................................................... 127 3 Donor statuses
................................................................................................................................... 128 4 EMDIS messages
.......................................................................................................................................................... 128 Preliminary request
.......................................................................................................................................................... 128 Patient update
.......................................................................................................................................................... 129 Change patient state
.......................................................................................................................................................... 129 Alternative match list request
.......................................................................................................................................................... 130 Typing request
.......................................................................................................................................................... 131 Infectious Disease Marker (IDM) request
......................................................................................................................................................... 132 Sample request
.......................................................................................................................................................... 133 Donor reservation request
.......................................................................................................................................................... 133 Cancellation of request
.......................................................................................................................................................... 134 Workup request
.......................................................................................................................................................... 135 Message acknowledgement
.......................................................................................................................................................... 135 Text message
................................................................................................................................... 135 5 Repeated donors search
................................................................................................................................... 135 6 Request rejection
Chapter XV System administration 136
................................................................................................................................... 136 1 Installation
................................................................................................................................... 146 2 Initialization file
................................................................................................................................... 147 3 System parameters
................................................................................................................................... 148 4 Program Prometheus updating
................................................................................................................................... 148 5 Database DataBmd
................................................................................................................................... 149 6 Database archiving
................................................................................................................................... 149 7 Copy Tool
................................................................................................................................... 152 8 Users and groups of users administration
.......................................................................................................................................................... 152 Users administration
.......................................................................................................................................................... 153 Groups of users administration
................................................................................................................................... 154 9 Nomenclatures maintenance
................................................................................................................................... 155 10 Own nomenclatures of registry
7 Contents
7
................................................................................................................................... 156 11 General forms
.......................................................................................................................................................... 156 Control file
.......................................................................................................................................................... 157 Instructions of control file
.......................................................................................................................................................... 159 Instance of control file
.......................................................................................................................................................... 159 Change of control files
................................................................................................................................... 159 12 Creation of own reports
.......................................................................................................................................................... 160 Control file
.......................................................................................................................................................... 160 Instance of control file
.......................................................................................................................................................... 161 Change of control files
................................................................................................................................... 162 13 Establishing Emdis connections
.......................................................................................................................................................... 162 Setting PGP
.......................................................................................................................................................... 165 Setting Ester
.......................................................................................................................................................... 169 Setting Prometheus
................................................................................................................................... 174 14 User support
Chapter XVI Future developement of system 175
Chapter XVII What's new? 175
Chapter XVIII Manual revision 177
Prometheus 8
1 Introduction
Prometheus is an information system for registers of haematopoetic stem cells donors which was
developed by the company Steiner, Ltd. The Prometheus system is used in the Czech Stem Cells
Donor Registry in Prague (CS2 or CSCR), in the Slovak Bone Marrow Donor Registry (SK or
SKBMDR), in the Cyprus Bone Marrow Donor Registry (CY2 or CYBMDR), in the Bulgarian Bone
Marrow Donor Registry (BG) , in the ALF Registry (PL3 or BW), Finnish Red Cross Blood Service (FI)
and the Tobias Registry Sweden (SE).

Module ESTER (subsystem Prometheus) is furthermore used in several registers in Europe (Austria,
The Netherlands, Wales, Hungary), The United States (CRIR, Gift of life) and on Taiwan.
This manual serves as user documentation to the Prometheus system. It is designed for staff of a
haematopoetic stem cells donors registry who will work with this system.
This work was supported by financial help of the IRGHET foundation and Colette Raffoux.
The first part of manual describes the Prometheus system without working with the EMDIS system.
The second part is focused on the control of the EMDIS system. Prometheus can be used even
without the EMDIS system.
Chapter Program Prometheus describes basic features of the program Prometheus.
Chapter Evidence of donors describes working with a local database of donors.
Chapter Quality check describes the supervisory system of the Prometheus system.
Chapter Evidence of patients describes working with a local database of patients.
Chapter Donor search for patients describes working with a searching algorithm for the looking for
potentials donors for patients.
Chapter Introduction to EMDIS system describes basic rules EMDIS without reference to its
implementation.
Chapter ESTER provides basic information about this middleware which implements communication
rules EMDIS.
Chapter Characteristics of EMDIS messages describes the implementation of EMDIS messages to the
Prometheus system.
Chapter EMDIS - working with program describes end user's working with the program Prometheus.
Chapter Communication in EMDIS describes rules during a communication among registers in
EMDIS.
Chapter System administration provides information to a system administrator.
Introduction 9
1.1 History of Prometheus system
The company Steiner in cooperation withCzech Bone Marrow Donor Register or Czech H
aematopoetic Stem Cells donors Register (CS2, CSCB or CSCR) has been developing the informative
system PROMETHEUS since the year 1993. At the end of the nineties the system was converted to
Windows operating system. In 2001, we started an intensive development of software for a register
connection to EMDIS. This compelled to a great reorganization of the whole software and the
searching algorithm change. At the end of the year 2003 we connected CBMD to ZKRD through
EMDIS. In 2005 CBMD was as the first register in the world connected to NMDP through EMDIS.
Nowadays CSCR is connected through EMDIS to more than 13 foreign registers (ZKRD, NMDP,
EuropDonor, FGM, etc.).
In 2003, we also released the communication part of software for free use by the other registers. This
project is called ESTER. It is used in several registers in Europe (EuropDonor, Austria, Norway,
Wales, etc.), USA (Gift of Life, CRIR) and Asia (Taiwan). The company Steiner, Ltd. ensures a
development and a technical support of the software. Within EMDIS community Germans consider us
as senior EMDIS partners. We operate also as a test bundle for beginning EMDIS registers (e.g.
Taiwan, Wales, Hungary).
We are members of EMDIS IT committee and we made several successful proposals on changes in
EMDIS in past. The company Steiner organized a meeting of the registers involved vEMDIS (EMDIS
IT meeting) in Prague in March 2005.
In 2006, we were addressed by Slovak Bone Marrow Donor Registry (SRDKD) with a request of
provision of entire register software including a connection to EMDIS. On the basis of the new
cooperation we improved the software to be more universal.
In 2008, we started cooperation with the Cyprus Bone Marrow Donor Registry, Bulgarian Bone
Marrow Donor Registry and ALF Registry.
In 2009, we started cooperation with the South African Bone Marrow Donor Registry and the
Finnish Red Cross Blood Service.
1.2 Basic concepts
Donor we will understand under the term a haematopoetic stem cells donor. So the donor is either
marrow donor or cord blood unit.
Local donor a local donor of haematopoetic stem cells donors registry.
Foreign donor a donor of foreign haematopoetic stem cells donors registry (e.g. NMDP).
CBU Cord Blood unit.
BPK - Cord Blood Bank of the Czech Republic
MD - Marrow Donor.
Local patient a patient of local haematopoetic stem cells donors registry.
Foreign patient a patient of foreign haematopoetic stem cells donors registry (e.g. NMDP).
EMDIS European Marrow Donor Information System
BMDW Bone Marrow Donors Worldwide
See further: Basic concepts of the EMDIS system
Prometheus 10
1.3 Structure of Prometheus system
The PROMETHEUS system connected to EMDIS can be divided into 4 subsystems:
1. ESTER middleware (communication layer) for a connection to EMDIS which carries out special
tasks (sending and receiving e-mails, check and encryption of messages, etc.). Two communication
databases are part of that (EsterMail a EsterDb). For an end user this layer is invisible and quite
uninteresting. This layer is not dependent on concrete register's specific requests.
2. DataBmd the main register database. It contains donors, patients, EMDIS messages, search
results, etc.
3. ESTERBMD contains a communication program for a data transfer between ESTER and
DataBmd as well as a search program for EMDIS patients. This layer is dependent on concrete
registries specific requests.
4. Assistance programs and databases - there are regularly running applications on a
communication register server carrying out special tasks.
BmdQC is a program for quality check of database DataBmd.
BmdHLA is a program for nomenclature HLA updating from remote servers.
Database ValsBmd contains central register nomenclatures.
BmdWeb is a program for downloading new versions of the program Prometheus from the
company Steiner server .
Database DistSW contains installation packets of the program Prometheus.
BmdVelho is a program for the data exchange with Velho (used by the Finnish Red Cross
Blood Service).
BmdProgesa is a program for the data exchange with eProgesa (used by the Finnish Red
Cross Blood Service).
BmdSonet is a program for data exchange with Sonet, economic system (used by the Finnish
Red Cross Blood Service).
HLAcore is HLA library from ZKRD
BmdUpdate is a program that updates local computer.
5. program Prometheus application program for an end user. It contains tools for work with donors,
patients, searching, EMDIS, export to BMDW, etc. Basically this is the only thing an end user deals
with.
Introduction 11
Structure of Prometheus system
1.4 Work (production) and Testing Environments.
It is recommended that the user of the Prometheus system first tests the program or new version of
the program prior to using it in their production environment. After verifying that the program is in order
and the required alterations suite the user's need, then it can be introduced to the production
environment.
Production Environment:
Consists of the latest production version of Prometheus and the Production Database. The basic work
environment used by the registry during production. Each workstation that will be dedicated to Registry
work using the Prometheus system will have an installation of the Production version. The Database
will be located on the Database server that is agreed upon. Each user entitled to work with the
Prometheus system will have his or hers own user account, with individual user rights. The system
keeps a log of changes made by a user, it is thus imperative that the users refrain from sharing
accounts or passwords.
Test environment:
This will consist of the Testing version of the Prometheus system and the Test Database. The
installation of the Test version of Prometheus may be carried out on the workstations assigned for the
Prometheus 12
purpose of testing and validating new versions of the Prometheus system. The Production and Test
versions of Prometheus can be located together on the same workstation. The Test version of
Prometheus will access and work with the Test Database and only with this database. The Test
Database will be located on the Database server.
Prometheus Production and Test Environment schema.
Default Testing Database.
This data for the Default testing Database will be gained from the Production data. The Default testing
database will serve only the purpose of returning the Test Database to it's original condition. No
version of the Prometheus system will have access to it, thus the data contained cannot be altered by
any means other than recreating it from current Production data.
Test Database.
The Test version of the Prometheus system will be directly accessing this database. The Database
may be altered at will, and returned to it's original condition at any time the user wishes.
Special Data Copying tool Production to Default Testing.
Introduction 13
A special copy tool enables the comfortable copying of the relevant data from the Production database
to create the Default Testing Database. The system database however also contains data such as
System Parameters, which also contain information such as directory paths. This is why the tool is
designed in such a way as to keep these system parameters separate and independent. This could
also include data such as the data about User's and their accounts.
The system can be seen in the diagram below.
Default Test database creation schema.
Special Data Copying tool Default Testing to Test.
A special copy tool will create the database upon which the actual testing will be carried out, the Test
database. The tool returns the Test database to it's original condition, the condition prior to any
changes being done to it. It will delete the data in the Test Database and import unchanged data from
the Default Testing Database. As described in the diagram below.
Test database creation schema.
Prometheus 14
2 Program Prometheus
The program PROMETHEUS is the main tool in working with the PROMETHEUS system. It can be
installed on any number of workstations. It is a so-called client-server application, therefore data
changes done on one workstation are immediately visible on the other workstations.
2.1 Program start
Generally the program is launched by an icon (syringe) on a computer desktop. After launching the
program, an user is required to enter user identifier/ID and the password. An ID is a number assigned
by a system administrator.
Program Prometheus icon
Log in to the program
When the user, whose ID is 23 and the password is shoe, is logging in, he writes the text 23 followed
by a space and the text shoe. Together then 23 shoe (without quotation marks).
There are 5 attempts to enter the right password. When the fifths attempt in a row fails the user's
account will be locked. The user then has to ask an administrator for account unlocking, or password
change.
When the ID and the password are correct the program will start to initialize and then there will appear
a main program window.
Note: An user can log in to the system from any computer where the program PROMETHEUS is
installed.
2.2 User password change
An user can change their password for logging in to the PROMETHEUS program. This function is
called up by the command in menu Servis|Change password. The user is asked to enter a present
password, a new password and to confirm the new password.
Program Prometheus 15
User password change
After first logging in to the program the user is asked to change his password. We recommend doing
that.
See further: Program start
2.3 Nomenclature update
The Prometheus system uses many nomenclatures, e.g. post code, diagnoses, HLA, etc. Those
nomenclatures are saved on a server in a special nomenclature database (ValsBmd). The
nomenclature database is regularly updated, see system maintenance. Every computer locally
maintains his own copy of nomenclatures too. When a nomenclature on the server is changed it is
necessary to change local nomenclatures as well. Accordingly the program Prometheus checks after
it's start whether it is working with the up-to-date nomenclatures and if not, it updates them
automatically.
Update of local nomenclatures
2.4 Nomenclature HLA
The nomenclature HLA is a table of HLA codes (e.g. A*01AB), their meaning and qualities. It contains
serological as well as DNA codes. Some functions work with the nomenclature HLA. These are e.g.
Prometheus 16
donor data control, donor searching, data export to BMDW, etc.
Nowadays, the nomenclature has approximately 500 thousand items, that is quite a lot. So it makes
working with the nomenclature more time-consuming, which may slow down some functions of the
program (e.g. donor searching).
PROMETHEUS has two independent systems for the management of HLA nomenclature, but only one
of these systems can be used. This can be set in the inicialization file.
1. Own system, based on BMDW lookup tables (http://www.bmdw.org)
Program PROMETHEUS optimizes access to this nomenclature in a way that the whole nomenclature
HLA is loaded to an internal computer memory after launching the program. This loading is absolutely
automatic, it takes about one minute and the program informs about it through a dialog window. It is
possible to start working with the program as soon as this is loaded.
When an user terminates the program the nomenclature HLA is deleted form the computer memory
and it is necessary to load it again during the restart of the program.
Loading of the nomenclature HLA
2. ZKRD's HLAcore system, based on WMDA files (
http://www.anthonynolan.org.uk/research/hlainformaticsgroup/wmda.htm)
PROMETHEUS does not load the whole HLA dictionary after startup, but cooperates with external a
system, called HLAcore. If this system is running, you can see a small icon on the taskbar. HLAcore
system is currently recommended as HLA nomenclature system for Prometheus.
HLAcore is running (smiling face)
2.5 Main program window
The main window is an initial guidepost for running functions of the program. A window's look and the
arrangement of its items are similar to other applications from Company Steiner, Ltd.
The main window with patient folder opened
2.5.1 Quick select buttons
There are quick select buttons below the menu: Select donor, Select patient, New donor, New
patient, EMDISnew, EMDISreq, EMDISold a Exit.
Select Donor the selection of a donor. Same function as menu Donor|Select. The next button with
an arrow allows a quick choice of any of the last selected donors.
Select Patient the selection of a patient. Same function as menu Patient|Select. The next button
with an arrow allows a quick choice of any recently selected patients.
New donor - the creation of new donor.
New Donor drop down selection - The arrow on the right hand side of the button. With expanded
selections: New Local Adult Donor, New Local Cord Blood Unit and New foreign/Other Donor
New patient - the creation of new patient.
New Patient drop down selection - The arrow on the right hand side of the button. With expanded
selections: New Local Patient and New foreign/Other Patient.
User Box - This shows the user that is currently logged into the system, below his name is the user
Prometheus 18
group he belongs to.
Exit termination of application. Same function as menu File|Exit.
2.5.2 Panel selection buttons
On the main program window on the left are buttons for selecting different panels or windows
dedicated to different tasks.
Task select buttons
Donor Button - To view or to work with Donors.
Patient Button - To view or to work with Patients.
Active Patients Button - To view a table of patients with an Active EMDIS status
Local Search - To work with local searches.
EMDIS new - To view or work with New EMDIS messages
EMDIS old - To view or work with Old EMDIS messages.
Interfaces - To view or to work with your interface applications.
Invoices - To view or work with your invoice applications.
Note: All panel selection buttons are shown here. But a user will have visible only that which is
according to his or hers user rights.
Kapra jsem cilene lovil malokdy. Nejlepsi vysledky byli z boatu na kapry ktere se slunili a byli videt. Jinak spis to byl
nahodny ulovek, kde cilova ryba bylo neco jineho. Obcas prekvapi co je kapr ochotnej sezrat, jako docela velkej
streamer, nebo silene barevnej blob. Nekdy vezme suchou. Chytal jsem cilene i Amury na sucho. Ale tohle je opravdu
jen kdyz se sejdou mimoradny podminky.
2.5.3 Work Panel Donor
A desktop is situated below the quick select buttons. There we can have one donor folder (his record
in the database), a patient folder or old and new Emdis messages . On the left there is column which
allows the user to switch between the Donor folder, the Patient folder, New Emdis messages, Old
Emdis messages etc.
After opening a donor folder we can see a panel with basic information about the donor on the
desktop. The panel also includes contextual buttons Edit and Reports. At the bottom of the panel we
find the Quality Control Warnings table.
Furthermore the donor record shows imported data, this is below the line under the donors general
data. These data are as they were imported via an import interface. It is in no way possible to alter this
data. The example used below is from the Finnish registry, showing the data imported from the Finnish
Registries lab system, Velho.
Note: Note, Interface imports are not used by all registries.
The panel with basic information about the donor
The tool bar of buttons:
Edit - this button allows you to Edit the data of the currently selected donor.
Reports - this button allows you to access the Donor Reports application.
Prometheus 20
- This button closes the folder of the Patient that is currently open.
2.5.4 Work Panel Patient
A desktop is situated below the quick select buttons. There we can have one donor folder (his record
in a database). On the left there is column which allows the user to switch between the Donor folder,
the Patient folder, New Emdis messages, Old Emdis messages etc..
After opening a patient folder we can see a panel with basic information about the patient on the
desktop. The panel also includes contextual buttons Edit, EMDIS Status, Emdis Update, EMDIS
Search Results, EMDIS Requests, EMDIS Result, Fax Req., Local Search, Rep. and "X". The
patients data consists of three tabs, Patient Record, EMDIS Messages and Attached Files. The
Patient Record tab shows the basic information of the patient, the table on the top right shows the
current status of the patient at each and every registry. The EMDIS Message tab allows you to see all
Emdis messages concerned with the selected patient. The Attached Files tab holds a table containing
all files attached to the particular patient.
The panel with basic information about the patient
The tool bar of buttons:
Edit - This button allows you to enter and edit the Patient's Data.
EMDIS Status - this button allows you to change the patient's Emdis status, globally, or a selected
HUBs using the little arrow to the right of it.
EMDIS Update - this button allows you to send a Patient Update, either globally, or a selected HUBs
using the little arrow to the right of it.
EMDIS Search Results - this button allows you to navigate between the Emdis Search Results
regarding the currently open patient.
EMDIS Request - this button allows you to send Emdis Requests.
EMDIS Result - this button allows you to send Results to requests.
Fax Req. - this button allows you to generate Fax Requests. (function not yet fully operational)
Local Search - this button opens the internal Donor Search tool.
Rep. - This button opens the Patient Reports application.
- This button closes the folder of the Patient that is currently open.
Below the Status table:
- this button allows you to change the Emdis
status of the currently selected patient.
Indicators EMDIS Status show indices of the patient status in other EMDIS registers. If for example at
least one HUB with a patient in an active status exists then the indicator ACT is highlighted red.
2.5.5 Work Panel Active Patients
A table is situated below the quick select buttons. This table contains a list of patients that have an
Active EMDIS status. On the left there is column which allows the user to switch between the Donor
folder, the Patient folder, New Emdis messages, Old Emdis messages etc.
The table allows the user to view the complete list of Active local patients. The Patient needs to have
an Active status in at least one other EMDIS registry to appear in the table. All EMDIS hubs to which
the user is connected also appear on the table, thus the patient's status in every hub can be
conveniently viewed. Double clicking on a row containing a patient will result in the patient's record to
be opened and the program will switch to the Patient Work Panel.
An example of what a table could look like can be seen below.
Prometheus 22
Active Patients Work Panel.
Columns may be displayed or hidden by clicking on and marking or un-marking the available
columns. The Patient ID column shows the patients ID. The Pat center shows the medical facility the
Patient is registered at. CZ, AT, AU, BG etc. columns denote the patient's EMDIS status at the given
HUB.
2.5.6 Hot keys
Some frequently used functions can be called up by hot keys. The hot keys are mentioned next to
appropriate functions in the menu.
Hot key Function Hot key Function
F3 Donor select F5 Patient select
F2 Donor close F4 Patient close
Ctrl-D Donor edit (Edit 1) Ctrl-P Patient edit (Edit 1)
Ctrl-N New donor Ctrl-M New patient
Alt-Q Program shutdown Ctrl-S Search for patient selected
Alt-X Option confirm Esc Option abort
The table of most frequently used shortcuts of the program PROMETHEUS
Evidence of donors 23
3 Evidence of donors
Menu Donor
The program functions for the work with donors are in the Donor menu. Firstly we select a donor's
folder by the command Select (F3), then we carry out some work and afterwards we close the folder
by the command Close (F2).
The currently opened folder is automatically closed at shutdown of the program, as well as when
opening a folder of another donor.
Through the use of the command New (Ctrl-N) we establish a new donor. We can delete a donor from
the database by the command Delete.
Warning: The deleting of a donor is irreversible, so always delete donors with consideration.
By the History command you are shown the donor data change history.
3.1 Donor select
We select a donor via the dialog window Donor select. Into the field Donor identification field we can
enter one of the options mentioned in the right bottom part of the window (Possibilities).
Prometheus 24
Donor select
Example
Let's have a donor whose ID is CZ1234D, name John Smith, personal number 501122/123, his
second identifier is CZE-PRG-8764, and one of his Sample ID's is 123456. This donor can be
selected by following options:
CZ1234D - donor ID
1234 - donor number
Smith John - surname and name of donor
Smith - surname of donor
Nov - beginning of donor's surname
123456= - One of the donor's Sample ID's (the "=" sign at the end is necessary)
501122123r - donor personal number (the r sign at the end is necessary)
501122r - beginning of donor personal number (the sign r)
12345+ - First characters of Sample ID (the sign + at the end)
etc.
On the contrary, this donor cannot be selected by following options:
John Smith - the surname has to be first, then the name
501122123 - when using the personal number it is necessary to add the sign r
3.2 Donor data edit
The main activity with a donor is browsing and editing his data. This we perform by command Edit
(Ctrl-D). The form can be customized, different registries can have different data entry forms.
Donor data browsing and editing
When you submit changes, the system performs many checks of the donor's data. If it finds some
problems, they are displayed in Errors and Warnings window. You must at least correct the Errors.
Prometheus 26
Errors and warnings
3.2.1 Form control
The form for donor data edit has the same control as all other forms in the program PROMETHEUS.

After pushing the button OK tests of entred data correctness will be done, then the made changes will
be saved to a database and the form will terminate. The command can be called up also by the
shortcut Alt-X.

After pushing the button Cancel the form entry will be interrupted and made changes will be lost. The
command can be called up also by the buttont Esc.

In principle, the form contains more pages. The panel in the right down corner informs about a number
of currently displayed page (1 in the picture) and about total pages (10 in the picture). Through left
arrow (or the shortcut Page Down) we can pass on previous page. Similarly right arrow (or Page Up)
displays the next page.
Bookmarks panel on the bottom part of the window allows to switch pages quickly. An underlined
legend sign defines an appropriate shortcut. For example we can call up the fourth page (4 Adr) by
the shortcut Alt-4.
We can do the switch among editing form's items by a mouse click or by a keyboard. The pass on next
item is called up by pressing buttons Enter, down arrow or Tab. On the previous then by pressing up
arrow or Shift-Tab.
There is a status panel on the bottom part of the window that provides a contextual help to just active
form's item.
The small arrow beside a form item indicates that we choose a value from some given choice of
values. The list of possible values can be called up by a click on arrow or by the button F3. The value
can be changed also by buttons + or space (next value) and (previous value).
Three dots beside a form item indicate that we choose a value from some nomenclature. We call up
the nomenclature by a click on the button with the three dots or by the button F3.
3.2.2 Behavior of input fields
Date field
Date format: dd.mm.yyyy, e.g. 26.01.2009
Press d for todays date
Type 17 to select day in actual month, e.g. January 17, 2009 (if current month is January and year
is 2009)
Type "17 6" to select day and month in actual year, e.g. June 17, 2009 (if current year is 2009)
Type 6 12 7 to select December 6, 2007
Prometheus 28
Press + for previous date
Press - for next date
Press Ctrl - for previous month
Press Ctrl + for next month
F3 for selection by calendar
Selection from static code list
Press Space for next value
F3 for selection by list, Esc to leave selection list
Press number as shortcut of selection

Item with static code list
Selection from code list
Selection from dynamic code list
Type code of the selection
F3 for selection by list, type first characters of code to filter the list, Backspace to clear filter, Enter to
confirm selection, Esc to leave selection list

Item with dynamic code list
Select registry from code list
3.2.3 Blood samples
Blood Samples.
Any donor may have one or more blood samples linked to himself.
The blood sample entry consists of various important information:
Sample ID, which is unique and cannot appear anywhere more than once. The Sample ID is entered
and chosen by the user. When selecting a donor, one may use the known Sample ID, or the first
characters of the Sample ID.
Number, this is an internal number generated by Prometheus.
DNA Sample ID, given and entered by the user
Date of collection, the date the sample was collected, entered by the user
Date received, the date the sample was received, entered by the user.
Prometheus 30
Freezer tray, a recording of where the sample is stored, entered by the user.
Comment, a field free for the user's use in case a comment is needed.
Recording a Blood Sample (As required by the Cyprus Bone Marrow Donor Registry)
Open the Donor data edit form and go to the "Samples" page, as can be seen below
Clicking on "New" or using F4, will open the Sample entry and editing window, as seen below.
The Sample ID is a required field and must be entered. The program will warn you if the field has not
been entered.
The Sample ID is unique and cannot be entered more than once. The program will warn you incase
the entered Sample ID already exists.
Management of Samples.
The user may manage the samples using the following buttons and short cut keys:
Edit or F4, used to edit the highlighted Sample entry
New or F3, used to record new Sample entries
Delete or F6, used to delete the highlighted Sample entry.
3.3 Donor data change history
The history of donor data change is called up by the menu command Donor | History. Firstly, a
donor or a patient has to be selected by the command Select Donor. If a history for the donor exists,
the table with his data will appear, otherwise a blank table will be opened.
Prometheus 32
Donor data change history
History window description
In the title bar we can see an identifier of donor or patient, according to start option.
In the column User is the user name of the user who did the appropriate operation.
The operation is in the column Operation. We distinguish 3 types of operations:
1. Insert insert a record
2. Update arrangement of an existing record
3. Delete delete a record
In the column On Time, the time when the operation took place is written.
Field Name, we can find the inserted, changed or deleted values name here.
Old Value contains the original value which the system had contained before processing the
operation.
New Value contains a new value the operation result.
Navigation
There is a navigation panel on the bottom-left, right above the data result.
Navigation arrows allow movement in the table (left to right):
1. First record
2. Previous record
3. Next record
4. Last record
5. Filter
Filter and sorting
It is possible to work with results in the History in several ways:
The first and the simplest method is clicking on the column name and the whole table is sorted
according to this column. So if we click on the column User, the table will be sorted in accordance
with the user who did the operation in alphabetic order from the lowest to the highest. After clicking
again the sequence will reverse.
Another way is the choice of appropriate column values and to those values lines limit. By moving
the cursor on a column name the small arrow on the right part will highlight. After clicking on the
arrow a small list of values will appear. By checking appropriate values the choice limit to those
values. The filter can be reset to original state by choosing the value All. Finally, selecting Custom
displays a dialog for an own filter definition supporting logical operators AND and OR.
The last type is Filter builder - dialog that permits a definition of complicated filters for a general
table. So it influences all columns. It is possible to load saved filter templates or you can save
created filter as a template for next use.
Termination
The button Close closes the window of History.
Prometheus 34
3.4 Donor stack
You can open the donor stack through the use of menu command Donor|Donorstack.
Donor stack
This is a user tool serving for the determination of a certain group set of donors. The donor stack
allows working with more donors together. You can utilize this for example in Donor reports. The
content of a donor stack (set of donors) is saved in a database - it means that the content will stay
saved even after termination and restart of the program. Nevertheless, the donor stack doesn't serve
for permanent information storage (e.g. permanent grouping of donors with certain quality). Each user
works with just his own donor stack.
In fact, each user has at his disposal three sets (stacks) of donors, those are marked by numbers 1, 2
and 3. Data can be stored in all three stacks at once but only one stack is always actively used. By
using the buttons Active stack you set which stack you want to be active. The table shows a content
of the active stack. The button Add adds a donor to the stack. The button Remove removes a
selected donor from the active stack. The donor is then deleted from the stack, but his data remains
normal in the evidence of donors. Remove all is the button for deleting all donors from the active stack
.
Warning: Through the donor stack you choose a set of donors you want to further work with as a
whole. Therefore it doesn't matter in which order donors are in the stack. Donors are ranged in the
stack by a donor number.
3.5 Donor reports
PROMETHEUS allows a print out of various reports of one or more donors. The menu of possible print
reports can be called up by the menu command Donor|Reports. Each report is described by its name
(Name) and brief description (Description). When you select the report more detailed information will
appear on the bottom part of the screen. The report generation is started by pressing Select.
There are several types of donor reports:
Selected donor reports - displays donor data whose folder is just opened on the desktop. These
reports are usually labeled (selected donor).
Donor reports in stack - displays all donor data in a donor stack. These reports are usually labeled
(stack).
Special reports - displays data of donors selected on the basis of special criteria. These reports are
usually labeled "(special)"
Donor reports choice
See further: creation of own reports
Prometheus 36
3.5.1 Print report preview
After the generation of a report, it's preview is displayed. You can work with it through the button bar
placed in the upper part of the window. The button F4 prints the report. The button F5 calls up a dialog
window for printer setting. With magnification buttons, magnifier and 1:1, you change the report
preview size.
Tools for work with print report
Print report saving menu
With the button you invoke an export menu of the report. You can convert the report into PDF
format or as a binary file. Through the command Mail you can send the report by e-mail.
By the button you end your work with the report. The button calls up a help to print report
preview.
3.6 Data import
Data import serves for a mass donor data overwriting from a external file. The program Prometheus
supports these imports:
Basic data BPK import
EMDIS Data BPK import
3.6.1 Basic data BPK import
This function is not available yet. The data BPK exchange will be solved more complexly after an
agreement with BPK.
3.6.2 EMDIS data BPK import
Through this function you can do a bulk data BPK import that is used in EMDIS (see EMDIS donor
items). After choosing the command you have to select the file with imported data. This file has to
have the format dBase IV which you create by using the program Corel Paradox or Microsoft Excel for
example.
File structure for EMDIS data import (viewed in the program Paradox)
Example of file content for EMDIS data import (viewed in the program Paradox)
3.7 Data export to BMDW
Each register regularly sends its actual donor data to BMDW. This is carried out once a month always
to certain date. BMDW then creates a new donor database which contains actual donor data from the
whole world.
You can find actual information about the terms of donor data delivery on website www.bmdw.org
Registry Information section Deadlines for data delivery subsection.
PROMETHEUS allows the creation of donor data files for export to the BMDW edition. This process is
called up by the command Donor BMDW Edition, as seen in the picture below.
Prometheus 38

Choosing BMDW Edition from the Donor menu
BMDW requires that the donors MD (marrow donor) and CB (cord blood unit) have to be exported
each in a separated file. After selecting the command you have to fill in two following data fields:
Registry ID - select the register identifier in BMDW.
Donor type - select the type of donors who you want to export. As seen below.
Data fields in BMDW edition parameters
Click "OK". You will most likely now receive a warning as seen below. If you want to overwrite the old
BMDW file then click "Yes".
BMDW overwrite warning
The process will now start. The creation of the data file can take even several tens of minutes
according to the size of final data file. The text file named UPD-code.20 (where code is a register
identification inBMDW) is the result of an export. For example for the register CS the text file would
have the name UPD-CS.20. The text file contains a donor table. The list of columns is dependent
on the fact whether we exported cord blood or marrow donor donor types. A file syntax matches
the specification BMDW File Format 2.0.
The final file is saved usually in the folder C:\Steiner\Bmd\Edition, but it can be elsewhere depending
on your System settings. The program at the end informs you where the file was created.
Location of exported file BMDW.
After the export, the list of "warnings" and "errors" found during the export is displayed. If the data file
contains serious mistakes (according to the document BMDW File Format 2.0) BMDW will refuse
donors with serious errors. You can print the list found by the program PROMETHEUS then correct the
mistakes and export the data again.
It is possible to filter, to sort and to group to a tree the table of warnings and errors. By the button
Export data you can export the table e.g. to Excel and you can print it through the button Print
preview.
Prometheus 40
List of warnings and mistakes after the export to BMDW
Before sending you have to encrypt the data file and sign it by PGP. You will use the public PGP
BMDW key. The final file is UPD-code.20.pgp, e.g. UPDCS.20.pgp. Send this file as an e-mail
enclosure to BMDW.
We recommend that sent files are copied to some accessory folder and so keep an archive of data
files sent.
See manual data encryption under the next chapter Data Encryption.
3.7.1 Data Encryption
With regards to the problems BMDW is having with reading our automatically encrypted BMDW Data
files, it has been decided that we do so manually until further notice.
Manual BMDW Data Encryption.
Locate the created BMDW data file (e.g. UPD-CS.20) at C:\Steiner\Bmd\Edition\ See also data
generation in Data export to BMDW
It is recommended that you copy and save the BMDW data file (e.g. UPD-CS.20) into a sub directory.
For instance a subdirectory named according to the relevant month the BMDW data file is being sent
to BMDW. C:\Steiner\Bmd\Edition\January for example, and proceed with the encryption from there.
Right click on the generated BMDW data file (e.g. UPD-CS.20) , open the "PGP" menu option a click
on "Encrypt" as can be seen below.
Select the users you require to be able to decrypt the file from the top list, this would be your own
registry and BMDW. You can double click on the user or do drag and drop of the user into the
recipient list, as can be seen in the picture below.
Prometheus 42
You should now have the selection as in the picture below. The example is taken from SK registry,
use your own relevant settings.
The end result is an encrypted copy of BMDW data file (e.g. UPD-CS.20) in the same folder as the
original. You my now send this encrypted file to BMDW at bmdwdata@europdonor.nl
3.8 Data Export to NETCORD
Registries that wish to have their Cord Blood Units a part of the NETCORD database may export this
data and submit it to NETCORD.
For this Prometheus may be set in a suitable manner to conform to the registry's method of data
submission.
3.8.1 Exporting CBU data FI
The method adopted by the Finnish Red Cross Blood Service is described in this section.
The application prepares the data to be exported. Thereafter the registry staff will export the data using
the Lotus application.
Preparing the data for export:
1. In the "Registry" menu select the "Export" option. As can be seen below.
Prometheus 44
Drop down menu - "Registry"
2. In the export options window that opens, select the "NETCORD - Active CBU's to NETCORD"
option. As may be seen below.
Export type selection window
3. The application will prepare the data to be exported in the database, this will take a few moments
depending on the size of the database.
4. After the data is prepared a new window containing all the excluded CBU's, those not qualifying to
be exported to NETCORD.
3.9 Donor registration cards
Prometheus caters for the making of personal Donor registration cards for donors. It automatically
creates a print file with the donor's information taken from the database.
3.9.1 Creating Donor cards
The program automatically uses the donor's information from the database when creating the donor
card print file.
The following information is printed:
Donor ID
Name and Surname
Address, Postal code and country.
Which donors will be in the file is dictated by the choice of Donor numbers. The user decides from
which donor to begin with and which will be the last. (e.g. donor 150 to donor 250, the file shall contain
all donors from and including 150 to 250)
Using the function
Open the "Registry" menu and choose "Export".
Select the Donor cards function and click on "select", as seen in the picture below.
Prometheus 46
Enter from which donor to begin with, which to end with, the name of the file and where the file
should be saved, as seen below.
You choose any suitable file name. You may either write down or show the path.
The time taken for the file to be generated varies according to the amount of donors in the list. Many
donors may take quite a while.
3.10 Donor analysis
The software tool Donor analysis (below just Donor analysis) allows working with the whole donor
database and their substantial data. It presents the data to an user through one big table. Table lines
correspond to particular donors and columns correspond to donor attributes (e.g. antigens).
The purpose of the donor analysis is composed of various statistical enquiries, database consistency
checks, searching for unsystematic errors in data, etc.
Donor analysis use in progress in the following steps:
1. Task definition
2. Data preparation (donor table)
3. Column projection (selection of suitable donor attributes)
4. Donor selection (displayed donors limiting)
5. Donor grouping
6. Donor sorting
7. Result viewing
8. Print preparation
Prometheus 48
9. Print or export to stack or data export to file
3.10.1 Task definition
Firstly we have to think out what we want to do with the donor analysis i.e. to define the task.
Task examples
A) We want to know an actual list of local CB donors in a database who have the status Available.
B) We want to find the age distribution of local MD donors who have the status Available.
C)We want a statement of all temporarily unavailable donors.
D)We want a statement of all donors who don't have a birth date mentioned.
3.10.2 Data preparation
The donor analysis is started from menu Donor|Donor analysis
After confirmation of Donor analysis start (Do you want to start ?) the program will start loading the
donor data from a server to a computer memory. For security reasons there is no temporary file
created on a drive at the same time, therefore it's necessary to have a sufficient memory in the
computer from which the command is started to admit the whole donor database. The table creation
can take several minutes. At the end of the process a resulting window Analytic tool for donors will
appear.
Donor analysis
3.10.3 Column projection
At the beginning implicit columns will appear on the screen (Donor ID, Sex, Birthyear, etc.). Probably
these columns won't suit us to solve our task and we will want to change them.
Click on the small button in left upper corner. The list of all available columns will display. The
columns shown in the table are checked in the list. By the change in checking columns you can
choose just those which you need to solve your task.
Tip: You can change a column width displayed in the table.
Tip: By dragging a column heading you can also change their order in the table.
3.10.4 Donor selection
An objective is to choose the logical condition which each donor in the table has to fulfil e.g. to solve
task A) there have to be the condition
(Don. Status = Available) AND (Don. type = CB)
Prometheus 50
Donor analysis - chosen filter condition
Both columns have to be present in the table (see Column projection). At activating the condition we
proceed in this manner: we move a cursor on the small button near the column heading Don.
status. We click on the button and it will display the list of all values of Don. status column which are
present in the table. We choose the value Available. Now the table is reduced to only appropriate
donors, the small arrow near the column heading Don. status changed a color to blue and the actual
filter condition appeared in the bottom part of the screen. Similarly we set the column Don. type on the
value CB. Herewith we have solved task A).
The whole actual filter condition is displayed in the bottom part of the window in the grey bar. We can
activate/deactivate this condition through the checking box in the left part of the grey bar. By "X" button
utterly left on the grey task bar we can delete the whole filter condition.
The button Filter Rows in the right part of a navigation bar is dedicated to advanced users. Through
the button we can create even very complicated filter conditions. After pressing it the tree structure of a
filter condition will be displayed. We can define interval conditions (e.g. donor's age 20 to 30 years),
use more operators (AND, OR, NOT), etc. You can save the whole filter condition on a drive (file .flt)
and load the donor analysis again in future.
3.10.5 Donor grouping
Donor analysis: table grouping to tree according to donor type (Don. type) and donor status (Don. status)
Sometimes we need to group donors by some attribute (column). For example in solving the task B)
we want to group donors according to the column Birthyear. The upper grey bar with the notice "Drag a
column header here to group by that column" serves for grouping. The notice really describes how it
works. Drag the column Birthyear heading to the upper grey bar. Drop it there. The whole table will
transform to a group of donors according to their year of birth. You can unroll particular groups by the
buttons +.
We can group according to even more attributes. If we want for example further division of each donor
group of particular year of birth by sex we will drag the heading of the column Sex to the upper grey
bar (to column Birthyear). Now we have columns grouped at two levels - primarily according to the
year of birth and then according to the sex.
We cancel the column grouping by dragging of grouped column heading back to the table.
3.10.6 Donor sorting
We can sort donors according to one or more columns. We carry out that by clicking on the column
heading according to which we want to sort. The grey arrow will display near the column title and it will
indicate an unsorting. Clicking again on the heading will reverse the donor sorting.
If we have donors grouped by some attributes we can sort them by all columns according to which we
group (e.g. firstly according to the year of birth then according to the sex).
3.10.7 Result viewing
The final data can be viewed for example through the navigation buttons in the left down part of the
window. The buttons provide moving by record (arrow up, arrow down), by pages (PageUp,
PageDown) or skipping at the beginning and the end of the table (Ctrl-Home, Ctrl-End). We can select
a record by the button with an asterisk to make possible a quick return on it by the button with an
asterisk and an arrow.
3.10.8 Print preparation
If the view of data on the screen does not suffice us and we need to print them, it is necessary to
modify the table to be suitable for a print. Its a rule that what you can see on the screen you will see
approximately on a printed paper. Its not convenient to print a great amount of columns because they
wont get into the paper width.
If some column values dont get into the column width it is convenient to enlarge the column. This is
done by moving the cursor on the column heading border and by mouse dragging the column is
enlarged.
By the button Print preview you display print preview.
Prometheus 52
3.10.9 Print
By the button Print preview we display the table print report which we can successively print.
Donor analysis print preview
The print preview with several other tools is displayed. You can further modify the final view by these
tools. Total number of pages is mentioned on the left down.
Warning: A great amount of displayed donors leads to a great amount of printed paper (e.g. hundreds
of papers).
3.10.10 Export to stack
We can save a ready list of donors to a donor stack and then we can further work with it.
Through the button Clear stack we delete a content of the actual donor stack. By the button Selected
to stack we add the selected donor (selected line of the table) to the active donor stack. You can also
select and add more donors all at once. You select donors by left mouse button with the button Ctrl
pressed (for selecting particular donors) or Shift (for selecting continuous selection of donors).
By the button All to stack you add all donors displayed in the table to the active donor stack.
Warning: The donor stack is assigned to keep several tens or hundreds of donors at maximum. We
dont recommend inserting too many donors to the stack..
3.10.11 Data export to file
Format selection for data export
By the button Export data you can export the donor analysis result to an external file on a drive. You
have several export formats to choose from, the most common is an export to Excel file.
Prometheus 54
4 Evidence of patients
Menu Patient
The evidence of patients is very similar to the evidence of donors.
The program functions for a work with patients are available in menu Patient. We work with the patient
in this way firstly we select his folder by the command Select (F5) then we perform some actions
and finally we close his folder by he command Close (F4).
At termination of he program the currently open folder will be closed automatically. At opening a folder
of another patient the actual folder will be closed as well.
Through the command New (Ctrl-M) we establish a new local patient and through the command New
foreign patient we establish a new patient from a foreign register which is not connected to EMDIS.
By the command Delete we delete a patient from the database.
Warning: The deleting of a patient is irreversible, so always delete donors with a consideration.
By the command History you display the patient data change history.
4.1 Patient select
We select a patient similarly as in donor select. In the field Patient identification we can fill in one of the
options mentioned in the right bottom part of the window (Possibilities).
4.2 Patient data edit
The main activity with a patient is browsing and editing his data. This we can perform by one of the
commands Edit. The commands Edit all have the same function (patient data edit), they differ only in
the edit button layout (donor data attributes) on the form. The most common is the command Edit 1
(Ctrl-P). The form control for a patient data purification is the same as form control for donor data
purification.
Evidence of patients 55
4.3 Attached Files
It is possible to attach external files to a patient, such as text documents or scans of fax messages etc.
A table of attached files is found in "Attached Files" tab in the Patient work panel, as can be seen
below.
Attached files tab in the Patient work panel
Table description:
File name column - The name of the file, as it was imported.
Description - A short text description of the file.
Patient - The patient's ID
Donor - ID of donor relevant to the attached document.
Date edit - Date and time of last change.
Edited by - Name of the user that made the last change.
File management:
Open file button - serves to open the highlighted file in the attached files table.
New file button - serves to attach a file to the patient record. Prometheus will require the
user to show the path to the file.
Describe file button - serves to enter a text description of the file highlighted in the
attached files table.
Update file button - serves to replace the highlighted file in the attached files table with a
new or updated version of the document. Prometheus will require the user to show the path to the file.
Prometheus 56
Delete file - serves to delete the highlighted file in the attached files table.
Save file - serves to save a copy of the highlighted file in the attached files table
anywhere on the PC used. Prometheus will require the user to show the path for the file.
Note:
When attaching a new file, Prometheus will prompt you to enter a donor, this donor will then be visible
in the table in the "Donor" column. If the document has no relevant donor, the select "cancel" and the
document shall be attached with out a specified donor.
4.4 Patient data change history
The history of donor data change is called up by the menu command Patient | History. The history
window is the same as the window in the evidence of donors and you can find its description in the
Donor data change history chapter.
4.5 Patient-donor relationships
Function Donor relationships shows family relationships between patient and donors. You must
select a patient before showing relationships of the patients. Relationships are shown in a table, each
row represents one relationship.
Patient - Donor relatioships
Records can be filtered, you can use the navigation bar.
The New Button creates a new relationship. First, you must select a donor through the Donor select
form, then a relationship entry form shows up.
We distinguish two types of relationships:
Base Relationships
Extended Relationships
Their possible values are:
Base Relation Extended Relation
Parent Unknown
Mather
Father
GrandParent Unknown
Maternal
Paternal
Children Unknown
Daughter
Son
Sibling Unknown
Sister
Brother
Related Unknown
Aunt
Uncle
Cousin Unknown
Female-Cousin
Male-Cousin
Friend Unknown
Girlfriend
Boyfriend
Prometheus 58
The Entry form has a check for the correctness of values. If a selected combination is not possible, a
warning message shows up and Extended relation will change to a correct value.
The Edit button allows the editing of existing relationships.
The Remove button removes existing relationships.
4.6 Patient stack
The patient stack has a similar function as the donor stack and it's control is the same.The patient
stack can be in addition used for a multiple donor search for patients.
Patient stack
4.7 Patient reports
The PROMETHEUS program allows a print out of various reports of one or more patients. The menu
of possible print reports can be called up by the menu command Patient|Reports. Each report is
described by its name (Name) and brief description (Description). When you select the report, more
detailed information will appear on the bottom part of the screen. The report generation is started by
pressing Select.
There are several types of patient reports:
Selected patient reports - displays patient data whose folder is just opened on the desktop. These
reports are usually labeled (selected patient).
Patient reports in stack - displays all donor data in a patient stack. These reports are usually
labeled (stack)".
Special reports - displays data of patients selected on the basis of special criteria. These reports
are usually labeled "(special)"
Patient report selection
After selecting a report and pressing the button Select the print report preview will displayed.
See further: creation of own reports
4.8 Typing Report
This tool is used for the creation of a typing report to be printed.
Description:
The patient (local or foreign) concerned is chosen from the database
The specific donors who's HLA data you wish to send are chosen from the database
Prometheus 60
The program then generates a printable report with the required data.
Using the Typing Report function:
The function is found in the Patient|Reports menu as the SABMR Typing Report.
A three page window will open. The first page requires you to choose the patient. Either your own
local patient, or a foreign patient that is in your database. There are two separate buttons "Local
Patient" and "Foreign Patient". As can be seen in the picture below.
After pressing a button, a patient is selected in the standard manner.
The second page has several fields which you may fill in, as seen in the picture below.
You can open the selection on the "To:" field and choose a known institute from the database, or you
may enter any other institute manually.
"Our Ref" and "Your Ref" may be filled in automatically depending on what patient we are dealing
with. You may overwrite the text manually.
The rest of the fields may be used with free text only limited by the amount of space.
The third page allows you to choose the relevant donors for your report. The page can be seen
below.
Prometheus 62
By pressing the "Add donor" button, you may select a donor in the standard way. By pressing the
"Remove donor" button you may remove a highlighted donor from the list.
When you are done, you may press ok. The result is a printable form with the relevant data, you print
it or save it on your PC (as a pdf file for example) at a selected destination.
4.9 Patient analysis
The patient analysis has an analogous sense as the donor analysis and we work with it in the same
way.
5 Interfaces
Prometheus may can be customized to work with different types of interfaces or means of Data
transfer.
Interfaces 63
Prometheus with the Interfaces work panel opened.
5.1 Interfaces Work Panel - Imports
This section describes import function, the examples shown in this section are of the Velho, eProgesa
and Sonet Interfaces, used by the Finnish Red Cross Blood Service.
Prometheus 64
Interfaces Panel - Imports tab.
This panel serves to view imports that have taken place. But it can also serve to manually execute
imports.
The panel shows two tables. Import Tasks and Import Task Records.
Navigation in the Import Tasks and Import Task Records tables.
You may highlight any Import Task in the Import Tasks table by clicking on it. The Import Task
Records table then shows each record contained in the respective Import Task. The contents of the
Import Task Records are explained bellow. The data in the record concerns either a Patient or Donor,
who's ID is visible in the Import Task Records table. By double clicking on any of the records, the
Patient's or Donor's record will be opened, that is if there is such a patient or donor in the system.
Description of the tables:
Import Tasks: Each individual import task is shown here. An Import task may contain several records
that are to be imported into the Prometheus system
ID - each and every executed import is given a import ID by Prometheus.
Type - the Interface from which the import is taking place.
Exported on - the date the data was exported from it's source
Added on - the date the task was added to the list of tasks
Added by - the user that executed the task
OK - the number of records that were imported without difficulties.
Denied - the number of erroneous records, irrespective if the task has been executed or not.
Pending - the number of records that have not yet been imported. The task has not yet been
Interfaces 65
executed or the record is erroneous.
Total - the total number of records contained by the task
File name - the exact name of the file the task has been read from.
Format - the format version of the import file.
Import Task Records: The records with their details located in the "Import task" highlighted in the
"Import Tasks" table. Each record of the task is shown on an independent row in the table.
Import ID - the ID of the import task the record belongs to
Row ID - the Implicit Row Identifier of the record in the Database. The value serves to assist the
System Administrator to locate the record directly in the Database.
Status - the status of the record. Pending, Imported or Denied.
Donor ID - the ID of the Donor in Prometheus
Patient ID - the ID of the Patient in Prometheus
Imported on - the Date an Time the record was imported
Imported by - the user that executed the importation of the record
Error - a description of the error, if an error exists.
Data - the actual data of the record as physically stands in the import file.
Automatic Import Function.
The interface and it's import functions take place in the background, unnoticed by the user. The
process or, assistance program, is executed automatically via Ester Timer at pre set intervals.
BmdVelho is a program for the data exchange with Velho
BmdProgesa is a program for the data exchange with eProgesa
Manual Import Operation.
Imports can be executed manually via the Interface panel.
1. An Import Task can be added using the button. Thereafter show the path to the
import file you wish to add.
2. Highlight the Import Task in the Import Tasks table and click on the button. The
Import Task is then executed and all new valid records will be imported into Prometheus.
3. An Import task may be canceled. Highlight the Task you wish to cancel and click on the
Prometheus 66
button. You will be asked to confirm your decision of cancelling the selected
import task.
4. An Import Task may be removed. Highlight the Task you wish to delete and click on the
button. Note: You can not delete an Import Task that has already been
executed.
5.2 Interfaces Work Panel - Exports
The Exports tab in the Interfaces work panel allow the user to view Exports that have been executed.
The tab contain a table of executed export tasks. Below is an example of exports, to Sonet in this
case, used by the Finnish Red Cross Blood Service.
Interfaces Work Panel - Exports tab.
The tab has only one functional button, the Refresh button, used to update the screen.
Description of export tasks table:
Export ID - The ID number of the executed export task.
Type - The type of interface in question.
File Format - The format, or version of the file format.
File Name - The name of the file.
Total - The number of items in the task.
Exported by - Who is responsible for the export.
Interfaces 67
Export Date - The date the export was executed
Status - Status of the export..
Error messages - A description/reason of the error that occurred during the execution of the error.
6 Invoices
This function serves to generate data files for Invoices to be created by the registries economic
software systems. Input for the invoice data (invoice items) may be generated by the user, but
Prometheus may use triggers such as events (e.g. patient registration) that occur in the system as an
impulse for data generation.
It is important to set Invoice items to the automatic triggers.
6.1 Invoice management FI
The purpose of this application is for the Prometheus system to export invoice data or invoice items to
the Sonet system used by the Finnish Red Cross Blood Service (FRC).
Below can be seen the Invoice Work Panel. It contains a table of invoices that each contain their
respective items.
Invoices work panel - Invoices tab
Prometheus 68
Overview:
The table consists of Invoices each with their unique Invoice ID. Each invoice contains it's respective
invoice items.
The table:
Status - the status of the invoice item, New, Completed, Exported or Canceled.
Customer - customer with customer ID code.
Patient ID - the respective patient's ID.
Patient Name - the respective patient's name.
Donor ID - the respective donor's name.
Department - the department responsible for the invoice.
Delivery date - delivery date.
Product number - The product ID code.
Units - the number of unit's of the one type of product.
Unit Price - the price for one unit of product.
Price - the price for the amount of unit's in the invoice item.
Creating Invoices:
The creation of invoices is carried out in two ways. Manually by the user, or by the Prometheus system
on the basis of preset triggers.
An important note is that every invoice has a unique ID, one invoice may contain more invoice item.
The user only adds "new invoice items", either to an existing invoice with existing unique invoice ID, or
onto a new invoice. See note bellow in step 3.
Manual operation:
1. Add a new invoice item by clicking on the button
2. Prometheus will require you to select the patient for whom the invoice is valid for. Select the patient
in the standard "Select patient" window as seen below
Invoices 69
Select Patient window - for new invoice item
3. A Invoice Edit window seen bellow will open. Fill in the relevant data. Some fields contain drop down
lists of possible item.
Edit Invoice Item window
Note: the default setting for the "Invoice ID" field is "Create new invoice", if left as is, the invoice item
will be put onto a new invoice. It may however be edited (see Editing invoice items) later. Using the
drop down option shown below, the user may select to which open invoice the item will be added to.
Prometheus 70
Drop down menu of open invoices - Invoice ID on the Edit Invoice Item window
Editing Invoice Items:
The user may edit an individual invoice item on open invoices (such that haven't been exported yet) by
highlighting the Invoice item required and clicking on the button. The Edit Invoice Item
window (similar window as when creating a new item) will open and allow the user to execute changes
to the item. Items on exported invoices and canceled invoice items cannot be edited.
Note: Donor and Patient ID's on the invoice item cannot be changed.
Cancelling Invoices Items:
The user may cancel individual invoice items on open invoices (such that haven't been exported yet)
by highlighting the Invoice item required and clicking on the button. The Invoice Item will
remain visible for reference, but it will be crossed out. Items on exported invoices cannot be canceled
Deleting invoice Items:
The user may delete individual invoice items on open invoices (such that haven't been exported yet) by
highlighting the Invoice item required and clicking on the button. The Invoice Item will be
permanently deleted. Items on exported invoices cannot be canceled
Exporting:
Invoices can be exported in two ways. Manually by the user, or automatically at regular time intervals
by the system via the BmdSonet application.
Note: Only Invoices that have all there items in the "Completed" or "Canceled" status (i.e. no item can
be in the "New" status) can be manually exported or will be exported by BmdSonet.
Complete invoices by highlighting the invoice header or any of it's items and click the
button. This will confirm the validity of the invoice and all it's items, the invoice
will be then exported when the export is run, either automatically or manually. An Invoice is
confirmed either.
Invoices 71
Note: Canceled Items will not be confirmed, their status cannot be changed to "Complete".
Run manual export by clicking on the button. The execution of an export is
confirmed by a notification window with the status of the export.
Refresh the table by clicking on the button.
View the trigger of the highlighted Invoice Item by clicking on the button. The trigger
is what caused the Item to be added to the Invoices.
Customers:
The list of all customers known by the system can be viewed on the "Customers" tab. These are
imported via the Interface function. An example may be seen bellow.
Services:
The table with a list of all services known by the system can be viewed on the "Services" tab. These
are imported via the Interface function. An example may be seen bellow.
Prometheus 72
7 Storage and Product Management
The Store application serves to keep a detailed record of stored samples and products. It can also
function as a tool for locating samples and products or even locating free storage space. It is
interlinked to the Donor records and samples or products may be conveniently viewed directly from the
Donor record in the Donor work panel.
The user himself defines the structure the store is organized in. The user can furthermore allocate
what type of products or samples maybe be stored where, this may be useful when using the
automatic function for locating free storage space or position.
The user may also may add remarks or notes to each individual position. The user may also lock a
position. A product from the locked position cannot be moved from that position, neither can a product
be allocated to a locked position. A locked position may be unlocked, but only by the user that
originally locked the given position.
Products may be moved from a position to a different position, and this is done similarly to the widely
used and known "cut and paste" function.
Storage and Product Management 73
The main Store window.
The Window consists of a set of functional buttons, and two sub windows, Structure of store and
Positions in store.
The Store work panel can be accessed selecting the "Store" option in the "Registry" menu of the main
program window or using the "Sample" tab in the Donor's Record user panel explained here.
7.1 Store structure
The visual presentation of the Store's structure is much the same as a directory tree, with directories at
the same level, subdirectories and the final subdirectory or level with the individual storage positions.
An example of a tree bellow.
Prometheus 74
Structure of storage
In the example above, you may see the top levels "My Store". Each level may have it's own sub-levels,
and each sub-level may further have other sub-levels of it's own. The structure of these levels is
defined by the user. The lowest level is the "position" level which can not contain other levels, but it
does contain it's own user defined positions. These are the "Box" positions in the example above.
Creating a new Top Level:
1. Click on the button.
2. An edit window for the new Top Level will open. Give the Level a name.
3. You may also enter a remark in the description text box. Click the "green tick" to finish.
Creating a new Sub-Level:
1. High light the Level where you want the new Sub-Level to be situated by clicking on it. Now click on
the .
2. An edit window for the New Sub-Level button will open. Give the Sub-Level a name.
Note: You may create Sub-Levels of Sub-Levels, but always remember to have the level where you
want the new sub-level highlighted.
Creating a new Positions Level
1. High light the Level where you want the new Positions Level to be situated by clicking on it. Now
click on the .
2. An Edit window for the new Positions Level as seen bellow will open. Give the Positions Level a
Name
Positions Level edit window.
3. Define the number of Rows and columns, you may also give them names.
4. You may define what type of product is this Positions Level reserved for using the drop down
selection at "Positions are intended for"
Editing a Level, Sub-Level or Positions Level:
Prometheus 76
1. Highlight the level you wish to edit by clicking on it. Click on the
2. An edit window for the level will open, you may edit the fields you require.
3. Click the "green tick" to finish.
Deleting a Level, Sub-Level or Positions Level:
Highlight the level you wish to delete by clicking on it. Click on the
Note: You may only delete a Level if it is void of any other levels, sub-levels or position levels.
7.2 Positions in store
The arrangement of the Positions level is defined by the user. An example of a Positions Level with 5
columns and 6 rows can be seen below.
Positions in store
Adding a product via the Store work panel:
1. Highlight the position where you want the product to be situated by clicking on it. Click the
button.
2. A window requiring the products or samples ID will open. Enter the Product ID.
3. Click the "green tick" to fix the product to the chosen position.
Note: You may only enter and existing product or sample ID sing this method
Removing a product:
1. Highlight the product you wish to remove by clicking on it. Click the button.
2. A window for confirming your action will open. Click "Yes" if you wish to proceed or click "No" if you
wish to cancel the action.
Note: You can not remove a product from a locked position.
Moving a product:
1. Highlight the product you wish to move by clicking on it. Click the button.
2. Highlight the position where you want the product to be moved to by clicking on it. Click the
button
Note: You may also move the product to a different Position Level. You can not move a product in a
locked position.
Locking and adding a note to a position:
1. Select a position you wish to lock or add a note to by highlighting it. Click the button
2. A lock/note position window will open.
If you wish to lock the position, tick the "Lock position" box.
If you wish to add a note, write the text in the text field provided.
3. Click on the "green tick" when done.
Note 1: A little "note" icon will appear in the position that contains a note. A little "lock" icon will appear
in the position that is locked. An example can be seen in position Row 1, Column 1 of the Position in
store picture above.
Note 2: Only the user that locked a position can unlock that position.
Searching for a Product:
Prometheus 78
You may locate the position of a product by clicking the button. Enter the product ID in the
window that opens. The Program will take you to the position the product is located at.
Searching for a free position:
You may locate the first free position by clicking on the button. The program will take you
the first free position available.
Note: You may search for the first free position that is designated for a specific product type using the
drop down list by clicking the little arrow of the aforementioned "search free position" button.
7.3 Store Product Management
The products or samples in store can be managed in the Donor record user panel, by viewing the
"Samples" tab, as can be seen in the picture below.
The "Samples" Tab consists of:
New Sample button - For creating entering new products or samples.
Edit Sample button - For editing the data about a product or sample.
Sample in store button - To place the product or sample into the "Store", or to view it's position in the
"Store".
Delete Sample button - To delete the highlighted product or sample.
Table of samples - This shows all the products or samples of the Donor.
Table of Samples columns:
Sample - The Product or Sample number. An internal number created for and by Prometheus.
Sample ID - The ID of the sample.
Type - The sample type
Freezed on - The Date the Product or Sample was frozen.
Store position - The position where the product or sample is stored in.
Deleted on - The date the product was deleted on.
Comment - A free text comment to the product or sample.
Adding a New Donors Product or Sample:
1. Click the "New Sample" Button.
2. Fill in the information in the edit window that opens, as can be seen below
Editing the Data of a Product or Sample:
1. Click the "Edit Sample" button.
2. Edit the Data.
Putting the Product or Sample into the "Store":
Prometheus 80
1. Click the "Sample in store" button.
2. The "Store" work panel will open. Paste the Product or Sample as described here. You may use the
"Search free position option"
Note: If you click the "Sample in store" button on a highlighted sample that is already in the "Store",
the "Store" user panel will open and you will be shown the product or sample's position.
Deleting a Product or Sample:
Highlight the product or sample you wish to delete and click the "Delete Sample" button.
Note: You can not delete a Product or Sample that is in the "Store", you will have to remove it from
there first.
8 Donor search for patients
One of the main program functions is the searching for potential haematopoetic stem cell donors for
patients with a haemopoiesis disorder. The commands for donor search are available from the main
program window in the Search menu.
The Search Tool has several features which correspond to the work order for executing searches:
New Search - When you wish to run a new search
Patients - To select a patient. Or you may use the little buttons above the Patients table.
Search Options - To set the search parameters. They can be seen in the Search Options table.
Search results - To view and manage the results. The Search Results tabel which appears after a
search has been executed.
8.1 Patient selection
Using the we select patients for whom we want to do a search. Mostly we want to
search for a donor for only one patient but the PROMETHEUS program allows multiple donor
searches for several patients at once.
Note: The button holds several options in a drop down menu.
You may use the Patient management buttons above the Patients table:
Donor search for patients 81
The list of selected patients for a search is in the table. We add an additional patient with the Add
button. We remove patients from the table with the Del button. The button View displays the patient's
record. Through Up and Down we can change the order of patients in the table.
If we want to work with the prepared list later we can save it into the patient stack. This is carried out
by the Patient list to stack option under the Patients button mentioned above.
On the contrary, with the Patients in Stack option under the Patients button mentioned above, we
load the list of patients from the patient stack.
Patient table
8.2 Search parameters
On the Search Option window the search parameters are shown: maximum donor number, maximum
admissible levels of HLA mismatch patient-donor, maximum admissible age of donor, the date of
request, the date of search, commentary, etc. We can change the parameters. It is important to realize
that the search result has to always be interpreted in context with the set search parameters. If
parameters too strict were set, then there could be not even one donor in the search result. On the
contrary, at setting too benevolent parameters we would be buried in a number of donors with
mismatches at the serological level.
Search Tool - Search Options
Prometheus 82
8.3 Search
We start the search itself with the Run search button. The search can take several minutes, the time
is directly proportional to the number of patients for whom we search and the number of donors in a
database. An indicator shows you the search progress.
Process of donor search for patients
8.4 Search result
After completing a search the table with found donors will be displayed. A control is similar to Donor
analysis.
Realize that in searching for more patients there are suddenly donors in the table who were found for
different patients. When some donor suits more patients he will appear several times in the table The
patient for whom the donor was found is mentioned in the column PatientID. In the column DonorID
there is an identifier of the donor followed by the Sex and the Type of donor. In the Match grade
column, the match grade of the donor is stated with one patient (the one with an identifier in the
column Patient ID). Finally the donor's HLA is stated.
The HLA of the patient which corresponds to the selected donor in the table (the active line) is stated
in the right upper part of the screen.
As stated above, we work with the table similarly as with the tool Donor analysis. That means that we
can arbitrarily enlarge the columns, change their order, but also add new columns and delete the
contemporary ones (see Column projection). The list of unviewed columns can be called up by the
small button in the left upper corner of the table. The complete list of the columns that we can use
in the table is here:
Patient ID the identifier of the patient
Donor ID the identifier of the donor
Type donor type (MD = marrow donor, CB = cord blood).
Sex F=female, M=male
Year of Birth the year of birth (has sense for MD donors).
Match grade HLA match grade of the donor and the patient
Status donor status
A1, A2 intelligent columns for HLA-A donor locus. If the donor has a typology at the DNA level the
DNA data will appear here (allele or the code NMDP expressing the allele group). If not the serology
will appear. The data in those two columns are sorted to correspond to the patient data. When the
donor has a patient mismatch in this HLA locus the value displayed is highlighted in color. An allele
mismatch is highlighted deep blue a serological mismatch is highlighted light blue.
B1, B2 - intelligent columns for HLA-B donor locus.
C1, C2 - intelligent columns for HLA-C donor locus.
DR1, DR2 - intelligent columns for HLA-DR/DRB1 donor locus.
DQ1, DQ2 - intelligent columns for HLA-DQ/DQB1 donor locus.
Search Result Table
Similarly as in the donor analysis we can filter the table according to various conditions here. The
search result limit to only one donor can be one of the convenient filters when searching for more
patients at once. Other useful filters are for e.g. selecting only the donors of the MD type, viewing only
certain match grades of the donor and the patient, reaching an exact HLA-A locus match in allelic
group, etc.
The table can be also grouped by particular column and sorted by one or more attributes.
Prometheus 84
8.5 HLA match grades of donor and patient
If possible the program counts the match grade of the donor and the patient at the DNA level. If the
donor DNA information is missing the patient DNA information is transformed into serology and then it
is compared to the donor. Theoretically it could happen that we would have neither the patient DNA
data at disposal. In that case the donor and the patient will be compared only at the serological level.
Total HLA match grade of the donor and the patient is counted according to HLA- A, B a DRB1 loci,
and HLA-C and HLA-DQB1 loci are excluded. The following view explains particular HLA match
grades that can occur by comparing one donor to one patient:
6/6 Allele Matched
- The donor is tested at I. class as well as II. class (A, B, DRB1).
- A full allele match at HLA- A, B and DRB1.
6/6 Potential (Allele) Matched
- Potential allelic match at HLA- A, B and DRB1.
6/6 Antigen Match (Allele Mismatch)
- A full match at serological level at HLA- A, B and DR
- A mismatch at DNA level
5/6 Antigen Match
- One mismatch at serological level at HLA- A, B or DR.
4/6 Antigen Match
- Two mismatches at serological level at HLA- A, B and DR.
- This match grade has mostly sense just for a donor CB (cord blood).
4/4 AB Antigen Match
- The donor is tested at I. class (HLA- A, B).
- A full or potential match at serological level at A, B.
3/4 AB Antigen Match
- The donor is tested at I. class (HLA- A, B).
- One mismatch at serological level at A or B.
Unknown match grade / Too many MM
- The level of match of the donor and the patient is not possible to count or the number of mismatches
is too high.
8.6 Repeated search
It can happen that you are not satisfied with the search result. A wrong set of search parameters
causing an insufficient or too high number of donors is probably the reason. However, you can change
the search options even after the search and start the search again. The contemporary search results
will be deleted and replaced by the new ones. By repeating this operation you can tune the search
options to be most satisfactory for a concrete case.
8.7 Search saving to database
As soon as you consider the process of setting parameters and searching as complete, you can save
the search result into the database. That is carried out by pressing the button. The search
parameters will be saved into the database as well as the main patient data, the main donor data and
the match levels. A new search identifier (search ID) is assigned to this unit according to which you
will be able to return to the search without the necessity of starting the search process again.
As soon as you save the search in the database you cannot change it because it serves only for
documentary purposes. That means that you can't change the search parameters, the list of patients
or start the search again. If you want to search again you have to set up a new search.
Realize as well, that after saving the search data of some found donor, and his data thereafter
changes (for example the donor is tested further at II. class), these changes will not be shown in the
recorded results in the database - the donor will have still only I. class HLA there. If you do a new
search, the donor will already of course have the current and correct data.
8.8 Search report
You can basically perform two types of Search reports.
1. Report with all results:
Executed with the button.
2. Custom report with selected results:
With the Report Maker, you can create a custom report of the search results by selecting chosen
donors from the Search Results table.
Prometheus 86
Report maker table and tools
Insert Donor Button - Inserts the Donor highlighted in the Search Results table.
Remove Donor - Removes the highlighted donor from the Report Maker
Clear List removes all Donors from the Report Maker.
The button then executes the custom report.
9 Quality check
The Prometheus system helps users to control the data quality in the database DataBmd. The tool for
the quality check is the program BmdQC which is run on a communication server (see Structure of
Prometheus system). The Program BmdQC analyzes data according to settings in the database and
looks for inconsistencies. Then it saves these findings in the database into a special table.
An user is warned at when starting the program, that there are some inconsistencies. In the bottom
part of the Donor Desktop window there is an informative panel Quality Control Warning where the
list of all found problems is displayed.
Quality Control Warning
Each problem has these attributes:
Problem description - usually contains an entity identifier of which the problem concerns (e.g.
Quality check 87
donor identifier) and the problem explanation.
Priority - the problem priority. It can be Urgent (urgent problem), High (important problem
influencing donor selection for patients for example), Normal (medium importance) and Low (less
important problem).
From - date from which the problem exists. So it's no the date the problem was found, this could be
an earlier date.
Status - the problem status. It can be Open (opened problem), Solved (solved problem), Postponed
(postponed problem) or Reraised (reopened problem).
Responsible - the user who is probably responsible for the problem. For example if the error is in
some donor's HLA typing, the one who revised the donor data last time is responsible. When no one
is responsible for the problem (e.g. a donor reservation expiration) then the System is stated as
Responsible.
The system contains these checks:
Donor database quality check
Patient database quality check
If you fix the problem, press button, this updates the list of warnings.
9.1 Donor database quality check
The system contains the following checks:
Donor status, reason for donor status and time interval for donor status check
STATUS BEGIN DATE END DATE STATUS REASON
? [4]
AV Opt Opt (in future [3]) Opt
TU Req [6] (in past [8]) Req [7] (in future [1],
after begin date [5])
Req [10]
RS Req [6] (in past [8]) Req [7] (in future [2],
after begin date [5])
Opt
DE Req [6] (in past [8]) Den [9] Req [10]
Table of donor status check with check number stating
[1] Erroneous donor status (TU). Status end date is in the past.
[2] Erroneous donor status (RS). Status end date is in the past.
[3] Status end date is in the past.
[4] Invalid donor status.
[5] Status end date before status begin date.
[6] Status begin date is missing.
[7] Status end date is missing.
Prometheus 88
[8] Status begin date in the future.
[9] Status end date of donor status DE should be empty.
[10] Status reason is missing.
Donor basic data check
REGISTRYID is not empty [11]
DONORTYPE is 1 (CB) or 2 (MD) [12]
SEX is 0 (M) or 1 (F) [13]
STATUS (AV, TU, RS) and DONORTYPE=MD => BIRTHDATE is not NULL [14]
STATUS (AV, TU, RS) => BIRTHDATE is not in future [15]
STATUS (AV, TU, RS) and DONORTYPE=MD => (age is < 56 years) [16]
STATUS (AV, TU, RS) and DONORTYPE=MD => NAME is not empty [17]
STATUS (AV, TU, RS) and DONORTYPE=MD => NAME is not empty
[11] Registry ID is missing.
[12] Unknown donor type.
[13] Unknown sex.
[14] Unknown birthdate.
[15] Birthdate is in the future.
[16] Donor is too old (more than XX years).
[17] Donor's name is missing.
HLA donor check
HLA-A - values according to actual HLA dictionary [18]
HLA-B - values according to actual HLA dictionary [19]
HLA-C - values according to actual HLA dictionary [20]
HLA-DR - values according to actual HLA dictionary [21]
HLA-DQ - values according to actual HLA dictionary [22]
DNA-A - values according to actual HLA dictionary [23]
DNA-B - values according to actual HLA dictionary [24]
DNA-C - values according to actual HLA dictionary [25]
DNA-DRB1 - values according to actual HLA dictionary [26]
DNA-DQB1 - values according to actual HLA dictionary [27]
[18] Wrong serology code at HLA-A.
[19] Wrong serology code at HLA-B.
[20] Wrong serology code at HLA-C.
[21] Wrong serology code at HLA-DR.
[22] Wrong serology code at HLA-DQ.
[23] Wrong allele code at DNA-A.
[24] Wrong allele code at DNA-B.
[25] Wrong allele code at DNA-C.
[26] Wrong allele code at DNA-DRB1.
[27] Wrong allele code at DNA-DQB1.
Quality check 89
Cord Blood donor check
[28] Too old date of birth of CBU.
[29] Sex is missing (CBU).
Other Checks and Automatic Operations:
[30] ZIP code is missing.
[31] Resrv. Patient ID is missing.
[32] Reserv. patient ID unknown.
Maximum age of AV, TU and RS donors:
[33] ... then automatically change status to DE (too old).
Maximum age of AV and TU donors:
[34] ... then automatically change status to TU (too old).
9.2 Patient database quality check
There are no checks available yet.
10 Introduction to EMDIS system
EMDIS (European Marrow Donor Information System) is a communication system for the quick data
exchange among bone marrow donor registers, transplantation centers, donor centers, etc. The first
work on the system started in 1992, but it has become a trend in this branch not until recent times.
That's by virtue of its main advantages: quickness, reliability, security and computer support of all
communication between donor and patient centers.
EMDIS is conceived in such a way that singular registers have servers permanently connected to the
internet or are connected regularly. In contrast to BMDW where data exchange and search procedures
are not only between national registers and the central database but also among each other.
Prometheus 90
Comparison of BMDW and EMDIS models
Obviously the BMDW server will be integrated into the EMDIS system in the future (see IT staff report
on the EBMT conference Prague 2005). That means that a search request could be proceeded only to
it.
10.1 Basic concepts
HUB an active bundle in the EMDIS network, example a donor register or transplantation center, etc.
Each HUB has an assgined identifier. For example CSCR (CS2) has the identifier CZ.
ECS Emdis Communication System, the rules for reliable messages transfer in EMDIS.
PGP Pretty Good Privacy, the encryption system used in the EMDIS system.
FML Flexible Message Language, the language in which the EMDIS messages are coded as text.
Perhaps it will be replaced by XML language in the future.
Message a message is what we intuitively imagine under the term. Each message must have a
sender and a receiver.
10.2 ECS
Classic e-mails were chosen as a means of communication in EMDIS. Each register has at least one
e-mail address to which the e-mails from other registries come. That brings certain advantages, for
example the acceptance of an already standard network medium, but also complications with the
unreliability of e-mail delivery, the possibility of doubling e-mails on their way, the mix up in the order of
e-mails, etc.
Currently the EMDIS Communication System (ECS) protocol version 2.0 is used for the message
exchange in the EMDIS system. It concerns mechanisms which should use particular bundles so that
e-mails are delivered on time and in the right order.
With the help of ECS it is possible:
1) To have a guarantee that massages sent from HUB A to HUB B will be all delivered and in the same
order as they were sent.
2) To settle that the HUB will automatically ask for resending of the message which was not delivered
although it should have been.
These message types sent by e-mails are distinguished:
1) Data message, the e-mail subject is EMDIS:<HUB>:<SeqNum> where <HUB> is a HUB identifier
and <SeqNum> is the ordinal number of the message.
2) Meta message, the e-mail subject is EMDIS:<HUB>, where <HUB> is again an identifier of the
HUB that sent the massage. There are three types of Meta massages:
a) Ready informs that the HUB is active. There is the line msg_type=READY on the first line of
the letter body.
b) MsgAck informs which is the highest message number the sender of the meta messages has
already received from the receiver. There is the line msg_type=MSGACK" on the first line of the
letter body. On the second line there is seq_num=<SeqNum> where <SeqNum> is the highest
number of received message.
Introduction to EMDIS system 91
c) ReSend the resending request for some message. There is the line msg_type=RESEND on
the first line of the letter body. On the second line there is seq_num=<SeqNum> where
<SeqNum> is the number of requested message.
Note: In the next text the term message will stand for a data message.
10.3 PGP
PGP is a well-known encryption system used also in the EMDIS system. It serves for the encryption
and a decryption of FML messages to assure the transfer security over the internet. Only the one to
whom the message was destined to can decrypt it. PGP also gives us the certainty that the received
message was not deliberately modified on its way and that it was not forged by a third person (so
called PGP signature).
10.4 FML
The data of particular messages are written down in the e-mail body by the special language
developed for that purpose, called Flexible Message Language (FML).
Sentences in this language are legible for computers as well as people. The record order of particular
messages elements does not matter. FML is also not a line oriented language.
It makes no sense to describe the syntax of the language here, it is quite uninteresting for the end
user. Just for an illustration we can show the sentence samples in this language here.
DONOR_CB
/FIELDS HUB_SND, HUB_RCV, P_ID, D_ID, D_BIRTH_DATE, D_SEX, D_TYPE
, MATCH_GRADE, D_ABO, D_ETHN, D_CMV, D_CMV_DATE, D_TOXO, D_EBV, D_A1
, D_A2, D_B1, D_B2, D_C1, D_C2, D_DNA_A1, D_DNA_A2, D_DNA_B1, D_DNA_B2
, D_DNA_C1, D_DNA_C2, D_DR1, D_DR2, D_DQ1, D_DQ2, D_DRW1, D_DRW2
, D_DRB11, D_DRB12, D_DRB31, D_DRB32, D_DRB41, D_DRB42, D_DRB51
, D_DRB52, D_DQA11, D_DQA12, D_DQB11, D_DQB12, D_DPA11, D_DPA12
, D_DPB11, D_DPB12, D_STATUS, D_STAT_REASON, D_NONAVA_DATE, CB_VOL
, CB_NC, CB_34PC, CB_MONO_NC, CB_CFU, CB_REDUCTION
:
"DE", "FR", "FRLY96009/96", "DEAKB.......12911", 19671221, "F", "D",
, "OP", , , , , , 3, 30, 35, , 4, , , , , , , , 15, 13, , , , , 1301
, 1502, , , , , , , , , , , , , , , "AV", , , , , , , , ;
FML text sample (german donor pro french patient)
This is a massage of the DONOR_CB (donor or cord blood) type. The items which it may and must
contain are derived from the message type. /FIELDS introduces the item list, and after the colon the
message data themselves begin. One FML text can contain hundreds of different message types. If
two consecutive messages have the same type and the item listing the listing is stated only once.
10.5 Data messages types
Message title Description
PAT_UPD New patient registration
PAT_STAT Patient status change
PAT_ALTPH Patient alternative phenotype registration (IS NOT USED ANY MORE)
DONOR_CB List item of convenient donors for patient (one donor or cord blood)
PHEN_LIST List item of convenient phenotypes for patient (one phenotype).
Prometheus 92
MATCH_SUM Summary of search result for patient.
TYP_REQ Request of further donor type testing.
TYP_RES Result of further donor type testing
SMP_REQ Request of sending of donor blood sample.
SMP_ARR Supposed date of delivery of donor blood sample.
SMP_RES Sample test result.
IDM_REQ Request of sending of infectious illness sample.
IDM_RES Result of request of sending of infectious illness sample.
RSV_REQ Request of donor reservation for transplantation purpose.
RSV_RES Result of reservation.
REQ_CAN Request cancel.
WOR_REQ Request of starting work on transplantation.
MARR_STAT State of work with donor.
NEW_ADD Register data update.
MSG_DEN Request rejection.
WARNING Warning message.
TXT_MSG Text message.
DON_UPD Donor downloading. (not used)
SEA_RES Search result. (not used)
NO_RES No result. Service cannot be settled.
MSG_ACK Received messaged confirmation.
RES_REM Unsettled request remind.
ALM_REQ Donor alternative phenotype reservation.
ALM_RES Same as DONOR_CB, but it is used as answer to ALM_REQ
CBR_REQ Request of supplemental information about Cord blood unit
Message types in EMDIS
10.6 Additional information about EMDIS
Additional information about FML and the EMDIS system can be found:
At www.zkrd.de - the site of the German register and on the site of the EMDIS system
In the document FML Message Flow Diagrams (message-flow.pdf)
In the document Flexible Message Language (fml.pdf)
In the document The Semantics of FML-messages (emdis-semantics.pdf)
In the document FML Data Dictionary (data-dictionary.pdf)
11 ESTER
ESTER (ECS Message Transfer Between EMDIS Registries) is an original Czech software provided to
bone marrow donor registers connected to the EMDIS system. It is a middleware (communication
ESTER 93
layer) which carries out it's special tasks. The ESTER system is invisible to the end user working with
PROMETHEUS.
Thanks to the ESTER system the user (an end user or a register software programmer) is shielded
from unpleasant activities such as encryption, work with e-mails, FML, etc. In spite of the fact he
should have a basic idea of what is going on in the background.
The ESTER system contains these databases:
EmdisMail the database for e-mail communication abroad.
EmdisDb the database for saving of FML messages and particular EMDIS system messages.
The ESTER system contains these programs:
Ester Timer The only program running permanently and starting other programs.
EsterECS Receives/Sends e-mails, rules ECS.
EsterPGP Encryption and decryption of emails by PGP.
EsterFML FML language, creation and reading of FML texts.
EsterMon Watching the system, creation of daily reports.
Scheme of data flow between ESTER and EsterBmd systems
The ESTER system closely cooperate with the EsterBmd system which supplements programs:
EsterBMD Message assignment to donors and patients, data exchange between DataBMD and
EMDIS databases, logic of the EMDIS system.
EsterSrc (BmdSrc) Search for foreign patients.
Each particular ESTER and EsterBmd program fulfils a specific task. So if we for example send the
message abroad these programs will process it in this order: EsterBMD, EsterFML, EsterPGP,
EsterECS.
On the contrary the received message is processed by these programs in this order: EsterECS,
EsterPGP, EsterFML, EsterBMD. And if it is a donor search request then EsterSRC too.
Prometheus 94
Ester Timer
Minimized Ester Timer
11.1 Intervals
Programs EsterFML, EsterPGP, EsterECS, EsterBMD and EsterSrc are run independently of each
other in periodic time intervals (usually 30 minutes or 1 hour) through the program Ester Timer. So
the message will pass through the system after a few hours at latest.
For example, the sent message should get to a foreign receiver in two hours. The program EsterBMD
is closest a user works with. It regularly picks the messages prepared to be sent and it delivers the
new ones. So if you create a message to send by mistake it is convenient to cancel it in time until the
program EsterBMD processes it.
ESTER 95
11.2 Data flow
Scheme of data flow in ESTER system
11.3 EsterBmd
This subsystem (software module) creates a link between the ESTER subsystem and the main
database DataBmd. It contains the search engine for EMDIS patients (EsterSrc or BmdSrc). The
engine is started every hour and it deals with requirements of the donor search from abroad. The
EsterBmd system processes daily a great amount of preliminary requests and carries out a repeated
search for a huge number of foreign patients e.g. in CSCR (CS2) there are currently (March 2008)
more than 3200 registered active patients from the whole world for whom the repeated search is done
every night. As soon as a new convenient donor for some patient appears in the register the system
automatically sends a search result update.
Thanks to this subsystem, the staff needn't manually (by fax) deal with the requirements of preliminary
searches from abroad, all is done automatically.
A regular search can proceed for local active patients also. If an user inserts a new donor convenient
for some local active patient in the database, the system will alert him. So there is no need of manual
starting of the search in a local donor database for the purpose of a new search result.
12 Characteristics of EMDIS messages
The connection of a register to EMDIS can be implemented in several ways. EMDIS only sets the
communication rules. It is separately up to each registry how these rules will be applied. This chapter
Prometheus 96
describes the specific implementation of EMDIS in the PROMETHEUS system.
12.1 Physical and logical messages
Physical message it concerns EMDIS system data message. For example:
Message of the type TYP_REQ is a physical message (typing request),
Message of the type DONOR_CB is a physical message (one donor in a search result), etc.
Logical message the logical messages concern us rather more than physical messages i.e. the way
the user comprehends them. A logical message is a group of physical messages. An user always
works with logical messages. However, the physical messages are sent abroad for example.
Search result is a logical message which can contain tens of physical messages of the type
DONOR_CB but also others (PHEN_LIST, MATCH_SUM)
Typing request is a logical message which contains only one physical messages of the type
TYP_REQ.
Logical message categories physical messages are of different types, concerning logical
messages we are talking about categories.
Logical message
category
log.
messag
e role
HUB which created
the message
Physical message
types which it can
contain
Number of
phys.
messages
Patient registr./upd.
Preliminary request
Patient update
Alternative phenot.
Change patient status

request
request
request
request
request
Patient
Patient
Patient
Patient
Patient
PAT_UPD
PAT_UPD
PAT_UPD
PAT_ALTPH
PAT_STAT
1
1
1
1
1
Search result result Donor DONOR_CB,
PHEN_LIST,
MATCH_SUM
1 to hundreds
Donor status RS
Search result upd.
Search result upd.(!)
Key donor update
result
result
result
result
Donor
Donor
Donor
Donor
DONOR_CB
DONOR_CB
DONOR_CB
DONOR_CB
1
1 to tens
1 to tens
1
Resend donor list
Resend phenot. list
Resend search result
request
request
request
Patient
Patient
Patient
PAT_STAT
PAT_STAT
PAT_STAT
1
1
1
Typing request
Result of typing
request
result
Patient
Donor
TYP_REQ
TYP_RES
1
1
Sample request
Sample arrival date
Sample testing result
request
result
Note 1
Patient
Donor
Patient
SMP_REQ
SMP_ARR
SMP_RES
1
1
1
IDM request
Result of IDM req
request
result
Patient
Donor
IDM_REQ
IDM_RES
1
1
Characteristics of EMDIS messages 97
Donor reserv. request
Donor reserv. result
request
result
Patient
Donor
RSV_REQ
RSV_RES
1
1
Workup request
Donor workup status
request
Note 2
Patient
Donor, Patient
WOR_REQ
MARR_STAT
1
1
Cancel of a request
Donor status change
Message denial
No result
request
result
result
result
Patient
Donor
Donor, Patient
Donor
REQ_CAN
DONOR_CB
MSG_DEN
NO_RES
1
1
1
1
Warning message
Text message
Address to broadcast
Message acknowledgem.
Donor, Patient
Donor, Patient
Donor, Patient
Donor, Patient
WARNING
TXT_MSG
NEW_ADD
MSG_ACK
1
1
1
1
EMDIS logical message categories in subsystem PROMETHEUS
Note 1: Sample testing result is the only answer which the patient side creates. Even though it is a
result it belongs to patient sent messages - thus among requests.
Note 2: Donor workup status result is almost always sent by the patient side. The only exception is the
status after a transplantation when the patient side can use the message for a transplantation result
notification.
12.2 DONOR_CB arriving message categories
The arriving DONOR_CB physical message is assigned to the logical message category according
to these criteria:
1. If the donor status is RS (reserved for our patient)
=> the resulting category is "Donor status RS"
2. If the donor status is TU (temporarily unavailable), OP (reserved for other patient) or DE (donor is
deleted) and we had sent the request before
=> the resulting category is "Donor status change" (negative answer to our request)
3. Concerning the patient with who we have already worked (i.e. some our request has been created
before)
=> the resulting category is "Key donor update"
4. Concerning the answer to our Preliminary request or Patient update
=> the resulting category is "Search result"
5. Concerning the group of donors containing the donor who is Available and his HLA match grade is
6/6 Allele Matched, 6/6 Potential (Allele) Matched or 6/6 Antigen Match (Allele Mismatch)
=> the resulting category is "Search result upd.(!)" (i.e. important search result update)
6. Other cases
=> the resulting category is "Search result upd." (less important search result update)
This sorting helps the user effectively manage the processing of search result updates from foreign
registries.
Prometheus 98
See further:
Donor status
Watching of search results changes
12.3 Log. message characteristics
Each logical message has these basic characteristics:
HUB to which register the message belongs i.e. it is the receiver for sent log. messages, it is the
sender for received messages.
Folder to which folder the message belongs. (See Logical message folders)
Category log. message category. (See Physical and logical messages)
New/Old if the message is new or old (See New and old log. messages)
Status in which status the message is actually situated (See Log. message status)
Date message date. For sent message that's the date of message creation and for received
messages the date of receiving.
Other, supplementary characteristics:
Message number unique number of logical message in the system.
Count of fyz. msg. number of physical messages which the logical messages contains.
Date of first fyz. msg. - the date of the first physical message.
Date of last fyz. msg. - the date of the last physical message.
Internal patient number an internal number of the patient with whom the message is associated
with. If the message is not associated to any patient, the value will be 0.
Internal donor number an internal number of the donor with whom the message is associated
with. If the massage is not associated to any donor, the value will be 0.
Inserted to database on the date of record creation in the database. User number determines the
number of the user which created the message. If the message was received or it wasn't created by
any user but by the PROMETHEUS system, then the User number = 0.
Date of last change the date of last message edit e.g. New to Old transfer.
User number determines the number of the user who edited the message.
12.4 Log. message folders
The logical messages are grouped to five folders in the program.
Local patients-requests the requests for local patients (e.g. Typing request). It is always
concerned with log. messages sent abroad.
Local patients-answers the answers to requests for local patients (e.g. Typing result). It is always
concerned with log. messages received from abroad.
EMDIS patients-requests - the requests for foreign patients (e.g. Typing request). It is always
concerned with log. messages received from abroad.
EMDIS patients-answers - the answers to requests for foreign patients (e.g. Typing result). It is
always concerned with log. messages sent abroad.
Other messages the messages which cannot be assigned to a local or foreign patient. New
addresses can be the example. It is concerned with log. messages sent to abroad or received from
abroad.
Internal requests - the requests for local patients and local donors. These messages are not sent
to EMDIS, they are only handled internally.
Internal results - the results for local patients and local donors. These messages are not sent to
EMDIS, they are only handled internally.
12.5 Log. message status
Status or the state of log. message can be one of these values:
Prepared to send log. message prepared to be sent, it is not sent yet i.e. processed by the
ESTER system.
Sent sent log. message.
Received received log. message.
Prep.to send,canc. log. message that was prepared to send but was canceled before sending by
the user.
Sent,cancelled sent log. message which was canceled after sending by the user.
Received,cancelled received log. message later canceled by the sender.
Received,not proc. received search request for which the ESTER system hasn't done a search
yet. That's a temporary state that will change to Received after doing the search.
Received,denied received log. message which was by for some formal reason denied, e.g.
breaking the EMDIS rules.
12.6 New and old log. messages
Each logical message can be:
New every recently received or every recently sent message.
Old every message which was marked as already processed by the user.
A conversion of log. messages from old to new is unusual and there will be a warning message
displayed asking whether you are sure about it.
12.7 Relations among log. messages
Each log. message can be created as the answer to some other message (especially some request).
The request is then called Request and the answer Result.
Example 1: The log. message Typing result is received for the concrete couple donor-patient as the
answer to previously sent log. message Typing request.
Example 2: Two log. messages Typing request should be created step by step on the basis of the
received log. message Search result
Prometheus 100
Instance of the relation among log. messages.
The creation of an answer (e.g Typing request) is sometimes even expected in some log. messages.
If the answer does not exist yet, then the messages are labeled as Requests without result.
It is necessary to realize the fact that the having an answer to a log. message does not depend on it if
the log. message is new or old (see New and old log. messages). The user can label the message as
old, without a creating a answer. It is a special behaviour, but the reasons for it can exist. It can also
happen that the user creates an answer to the request, but he does not move it into the old messages.
Also, for this behaviour we can see the reasons.
Request with the
required answer
answer does not exist answer exists
new message Newly received request from
abroad or newly sent request
User created the answer but
he left the message among
the new ones
old message User moved the message among
the old ones although the answer
does not exist to it. As it is a
special behaviour, the warning is
displayed to the user
Request is completely done
i.e. it was answered and
saved among the old
messages.
Messages with required answer
Some log. messages expect that only one answer will be created (e.g. one Typing result will be
created for Typing request). If the user tries to create another answer, a warning will be displayed,
asking the user about his sureness in the action.
If the answer to the request is labeled as invalid (i.e. rejected by the recipient or canceled by the
sender) then the request will appear again among the messages which do not have any answer (
Requests without result).
12.8 Arriving logical message creation
As we know physical messages are sent through the Internet however we work with logical messages.
We remind that the logical message are a group of physical messages in the general case. When are
the logical messages created then?
The outgoing logical messages are created the moment they are made - there is no problem because
the user creates only logical messages and he does not worry about physical ones.
With arriving messages it is just a little different. The program EsterBmd take care of aggregating the
physical messages into logical ones.
In most cases it is clear how to create a logical message, because it contains only one physical
message (see Physical and logical messages). The logical message is automatically created from
these received physical messages. The only example of a possible problem is the arrival of the logical
message Search result. This can contain tens of the physical messages. It could happen that these
messages will be delivered at various times. Nobody can know if all physical messages which belong
to the new logical message have been already delivered or if we should wait for the creation of a
logical message. This situation is solved by the program in the following way: The logical message
Search result contains the physical messages of the type DONOR_CB and PHEN_LIST which have
the same sender, belong to the same patient and their date of the receiving is in a sufficiently short
time interval.
13 EMDIS - work with program
This part describes the work of the end user with EMDIS in the program PROMETHEUS.
Communication scheme
The heavy green lines of the communication scheme will be considered by us as EMDIS.
There are several controls in connection with EMDIS in the main window. Their description can be
found in the chapter Main program window.
Thereinafter in this chapter:
EMDIS items of the patient
Prometheus 102
EMDIS items of the donor
Basic scheme of work with EMDIS
Browsing of the log. messages
Patient tools EMDIS
Browsing of the log. message
EMDIS search results
Report of the search results
Addresses of the EMDIS centers
EMDIS reports
Unification of work with all registers
Writing of unattached texts in EMDIS
See also:
Introduction to the system EMDIS
ESTER
Characteristics of EMDIS messages
Communication in EMDIS
13.1 EMDIS items of patient
The data of the local patient, which are sent in the messages to EMDIS, are read from the database
DataBmd. So it is possible to send only that which is filed in the database (e.g. the antigens, the name,
the date of birthday, the blood group, etc.)
Some items of the patient serve especially for the EMDIS purposes. They are:
Patient EMDIS diagnosis (DG EMDIS) the patient diagnosis according to the EMDIS
nomenclature.
Patient date of diagnosis - the date of the diagnosis determination
Disease phase - an optional item
Weight the weight of the patient in kg, an optional item
Patient CMV status - an optional item
Ethnic the ethnicity of the patient, an optional item
Grafting physician ID the identifier of the doctor of the EMDIS center, an optional item
You can find further information about the data of the patients, which are sent to the system EMDIS, in
the documentation EMDIS.
EMDIS - work with program 103
13.2 EMDIS items of donor
The data of the donor, which are sent in the messages to EMDIS, are read from the database
DataBmd. So it is possible to send only that which is filed in the database (e.g. the antigens, the name,
the date of birthday, the blood group, etc.)
Some items of the donor were newly introduced in the connection with the system EMDIS. They are:
Ethnic the ethnicity of the donor, an optional item
Donor CMV status - an optional item
Date of CMV test - an optional item
Toxoplasmosis - an optional item
EBV status - an optional item
Donor collection type
Number of PBSC
Number of MARROW
Number of pregnancies - the number of pregnancies of the female donor, an optional item
Number of blood transfusions - the number of blood transfusions, an optional item
Donor height - the height of the donor, an optional item
Donor weight - the weight of the donor, an optional item
The following items are extra available for cord blood:
Collected net volume of CBU
Volume of frozen CBU
Collected net number of nucleated cells
Number of nucleated cells in frozen CBU
Collected number of CD34+ cells
Number of CD34+ cells in frozen CBU
Collected number of mononucleated cells
CFU preserved
Method of volume reduction
CBU CT typing date
CBU DNA available
Maternal serum available for CBU
Quantity of maternal serum for CBU
You can find further information about the data of the patients, which are sent to the system EMDIS, in
Prometheus 104
the documentation EMDIS
13.3 Basic scheme of work with EMDIS
The button EMDISnew of the upper bar in the main window of the program PROMETHEUS serves for
the display of the new messages.
See the new and old log. messages
See Browsing of the log. messages
The button EMDISold of the upper bar in the main window of the program PROMETHEUS serves for
the display of the old messages. Then the program calls on you to enter the filter conditions to the
messages which you want to display. You can limit e.g. the date range (Date from a Date to), so the
time interval of the creation of the log. messages which you are interested in. If you fill up also the HUB
selection, you can limit the displayed messages only to one HUB.
See the new and old log. messages
Filter of (old) EMDIS messages. The user wants to display all old Typing request and Sample request in the year 2005
which were sent to and received from Germany.
The button EMDISreq of the upper bar in the main window of the program PROMETHEUS or menu
Comm|EMDISRequestswithoutresult serve for the display of the requests without answers. The
window for the entering of the filter conditions will appear again before the display of the messages.
See Relations among the log. messages
All log. messages are either in EMDISnew or in EMDISold. The tool EMDISreq serves especially
for the checking and it displays the selected log. messages from EMDISnew and EMDISold.
The menu command Patient|EMDIS serves for the work with the concrete local patient. If any patient
is not chosen, the program calls on you to select the patient at first.
See Patient tools EMDIS
The menu command Comm|EMDISForeignpatient serves for the work with the concrete foreign
patient. Then the program calls on you to select the foreign patient at first.
See Patient tools EMDIS
13.4 Internal requests and results
Program PROMETHEUS allows to create EMDIS requests not only to foreign registries, but also to
your own registry (recipient of the request is your registry). These requests are called "EMDIS internal
requests". They are not sent to EMDIS, you just handle them internally.
System allows to create these internal EMDIS messages:
Preliminary request
Patient update
Search result
Search result upd.
Typing request
Result of typing
Sample request
Sample arrival date
Sample testing result
IDM request
Result of IDM req
No result
Donor status change
System does not allow to create these internal EMDIS messages:
Alternative phenot. - special search strategy in local database is done by internal search tool
Donor reserv. request - reservation of local donor for local patient is done in evidence of donors
Donor reserv. result - reservation of local donor for local patient is done in evidence of donors
Workup request - not supported
Donor workup status - not supported
Address to broadcast - not supported
System of internal requests and results follows common rules of EMDIS messages, i.e. system will
warn you if you want to move a Typing request to old messages, but there is no corresponding Result
of typing.
13.5 Browsing of log. messages
This chapter describes the window of the application for the browsing of the log. messages. It is
possible to call up it for the browsing of:
New log. messages EMDISnew
Prometheus 106
Old log. messages EMDISold (with the filter from... to, HUB, etc.)
Request without the answers EMDISreq (with the filter from... to, HUB, etc.)
Browsing of the new EMDIS messages
The form control:
There is a tree of the folders of the messages on the left side of the screen. The selected folder of
the messages is highlighted in yellow and its content (the table of the messages) is displayed on the
right side of the window. If you choose e.g. EMDIS patients-answers, you will see all of such
messages in the table on the right.
The list of the sub-folders of the folder can be unrolled by the clicking on the symbol +.
The number in brackets near the folder of the messages is the number of the messages in the
folder.
If you click above the tree of the folders by the right mouse button, you will call up the context menu
where you can find the commands of the unrolling or the rolling of the whole tree.
The navigation buttons in the lower part of the table for the mouse cursor shift in the table of the
messages.
You can display it by the clicking on the message
You can find the basic information about the patient in the left part of the window who relates just to
the selected message
If the box OK (in the table of the messages) is checked, it means that the log. message is old. If it is
not checked, it is new. If you check the box OK and you close the form by the button "Green tick",
the new log. message will be the old one.
It is necessary to press ALT-X or the button "Green tick" for the saving of the changes you have done.
Other escape of the window will not save the changes.
Column headings of the table behave intelligent:
If you click on them by the mouse, you can sort them by ascending or descending order.
If the table is already sorted by any column, you can hold SHIFT and click on the heading of other
column. You will reach the finer sort according to other criterion (the column sorting according to
more columns at once)
You can filter the displayed values in this column by the click on the arrow in the column heading.
You can edit the column width.
You can change the displayed order of the columns by the "drag & drop" of the column heading
between two other column headings.
You can aggregate the messages by the "drag & drop" of the column heading into the grey box
(above the columns headings) according to this column. You can "take out" more column headings
at once and create a tree of messages.
You can combine the particular processes of work with the column headings (the filtration, the
sorting, the aggregating)
The button Patient Tools will display patient tools EMDIS of the just selected log. message.
The button Search results will display the just selected search result in the generated form.
The button View message will display the just selected log. message.
The button Print message will display the report of the just selected log. message.
Note: The button Patient tools will display the window where you can manipulate with the messages
(to create the new ones, to change the status, to create the answers, etc.). The content of your original
window for the browsing of the messages will not be changed. It is necessary for the updating to close
this window and to call up again the command of its opening.
13.6 EMDIS patient tools
This chapter describes the window of the application for the work with the concrete patient, both the
local one and the foreign one.
In the Patient work panel you use the EMDIS tools.
Prometheus 108
EMDIS patient tools, the bookmark States (table on the right).
There is the example of the window EMDIS tools in the picture where the local patient is displayed.
The bookmark States are selected. There is a list of the foreign registries (HUBs) and the the patient
status in these registers in the middle, and the date results were received on the right.
The button EMDIS Search Results calls up the window for the analysis of the received search results
for this patient.
It is possible to create a new messages (a requests, a result, the updating of the patient, etc.) by
opening the EMDIS messages tab (see EMDIS messages).
EMDIS patient messages tools, the bookmarked Messages
This picture shows how the window looks like of the EMDIS patient and the bookmarked Messages
are displayed. There are the structured log. messages on it which is connected with the displayed
patient. The control is similar to the one of the window of the browsing of the log. messages (see
Browsing of the log. messages). It is then possible to for e.g. sort out and aggregate or filter the table
according to the particular columns. Show message will display the selected message (see Browsing
of the log. messages), Report will create a report of the message.
By the help of the tree in the left side of the window you can display only the messages you are
interested in (e.g. Local Patient-results).
Prometheus 110
13.6.1 Foreign patient tools EMDIS
The Patient Work Panel, with a Foreign Patient.
The window Foreign Work Panel looks similar to the one for the local patient. In contrast to it, there is
no possibility to create requests or to change the status, the table of the statuses in the particular
registers is missing as well. On the contrary some items are new:
Registry the HUB the patient is registered in.
Status the patient status in the PROMETHEUS system.
Search Result the last updating of the patient data.
Active searches the information about the searching for the patient in the active status, see
Repeated donors searching. First is the date where it was searched for the patient for the first time
in the database DataBmd. Last is the date of the last search. Count is the number of searches.
Matching preferences - the preferences for the donors searching which are defined by the foreign
register. Max. donors is the limitation of the maximum numbers of the donors in the particular
categories in the search results. Preferences is the chain of the seek preferences. More see the
documentation EMDIS.
13.6.2 Patient status in registries
Patient status in the EMDIS registers
The patient can have various status in the EMDIS registers. Nevertheless the program leads the user
to have the same status in all registers. If the patient status is the same in all partner EMDIS registers,
it is impossible to choose only one register and to change its status. In that case all registers are
always selected and the patient status is changed in all registers at once. Then we can speak about
the patient status in EMDIS rather than EMDIS patient status in the register. Note please that the local
register is also the part of the table. EMDIS behaves then as one virtual register that is its original
idea, see Unification of work with all registers.
If you want to change only the status in the selected registers, click on the check box beside the marks
of the registers and then click double on the table of the registers. The form for the change of the
patient status will be displayed and it is possible to change the status in all selected registers at once
by the help of it.
13.6.3 Unification of work with all registries
The Prometheus system is designed to make the work with more registers (HUB) at once easier. The
user can change the patient status not only in the foreign HUB but also in home HUB. Home hub
represents actually the local database of the donors (DataBmd) however the program offers to the
user such a view which resets the differences between the local database of the donors and the other
registers.
Home HUB has these specifications on the contrary of the other HUB:
The immediate donors searching for the patient will appear at the change of the patient status to
PRE (preliminary).
The program presents to the user though that the messages are being sent (e.g. preliminary
request) but in fact no messages are being sent.
If you send request to your HUB, it is handled as internal request.
Prometheus 112
The main advantage of this access is the comfortable comparison of the search results. The user can
work with the donors of all registers at once that called for the donors searching, including the home
one and he can create the reports containing the donors of the various registers. If we set the patient
status in home HUB to ACT (active) and a new donor, who is suitable for the patient, will appear in the
database DataBmd , the message with the new search result will be delivered to the user.
If we want to change the patient status in all HUB (including home HUB) we can do it easily in that way
that we change the status in HUB "ALL". The change will be displayed then in all HUB. Tho work with
HUB "ALL" has this limitation:
It is impossible to change the status in HUB "ALL" if the patient statuses in the other HUB are
different. In this situation it is necessary to unite the patient statuses in various HUB to the same
status at first and then only you can work with HUB "ALL".
It is impossible to send the requests (e.g. typing request) or other messages to HUB "ALL".
13.6.4 Watching of search results changes
You can set not only the status but also the attribute Watch in each register. Its value influences the
information rate of the user about the changes of the result document of the donors from the particular
register. The system can be easily overloaded by the information at the informing about each change
of the search result and you must manually check a large amount of the new messages which usually
contain insignificant changes of the search result. On the contrary if you are not informed at all, you
can miss the important change. Choose some compromise by the setting of the watching of the
changes for each register where the particular patient is active.
Setting of the attribute Watch
The meaning of the particular values of the attribute Watch is following:
None - the system automatically checks the new outgoing messages Preliminary request and
Patient update and the received new messages Search result, Search result upd. and Search result
upd (!). The other messages (e.g. Key donor update) are not concerned with this setting.
Standard - the system automatically checks the new outgoing messages Preliminary request and
Patient update and the received new messages Search result upd. The other messages (e.g.
Search result) are not concerned with this setting.
All - the user is informed about everything and he must check himself all new messages.
13.7 Log. messages browsing
This chapter describes the window for the browsing of one log. message. It is possible to call it up by
the button View message or by clicking on the line in the table of the messages.
The window has three bookmarks:
General
Physical messages
Content
There are the tools for the work with the displayed log. message in the lower part of the window:
Print message the new report of the log. message will be displayed
Update donor it has sense only by the received message Sample testing result. It makes possible
the updating of local donor according to the message information
New result If the log. message Request is displayed, it makes possible to create a new answer to
this request. It is a context number and it means that e.g. if the log. message Typing request is
displayed, the button serves for the creation of a new Typing result.
Donor status change It serves for the creation of a negative answer for the displayed request
(see Communication in EMDIS).
Deny request It serves for the rejection of the displayed request (see Communication in EMDIS).
Cancel request It serves for the cancellation of a request (viz Cancellation of a request).
New Text msg. It serves for the creation of a new text message which is connected with the same
couple patient-donor as the displayed message is (see Text message).
New warning - It serves for the creation of a new warning which is connected with the same couple
patient-donor as the displayed message is
13.7.1 General
This bookmark contains the information about the log. message as a whole (see Characteristics of the
log. message).
Prometheus 114
Browsing of the log. message, the bookmark General
The basic information (Main information) is Status, HUB, Folder, Category, New/Old and Date. The
additional information (Additional information) is Message number (a unique number of the log.
message), Count of physical messages (a number of the physical messages of the log. message),
Date of the first physical message, Date of the last physical message, Internal patient number (a
internal patient number in the PROMETHEUS system), Internal donor number (an internal donor
number in the PROMETHEUS system).
The further information is Inserted to database on (a date of the message saving to the database)
and the user number who created the message. Date of last change (a date of the last change in the
database) and the user number who did the change.
The boxes Message is answer of request and Message is request with answers inform about the
relations of the displayed log. message to other log. messages. The displayed log. message could be
created as the answer to some request. In that case it is possible to display this request directly by the
button View Request. If some answers were created on the basis of the displayed log. message, it is
possible to choose one of them (or more) and to display it by the button View answer.
13.7.2 Physical messages
It serves for the display of the list of the physical messages included with the logical message (see
Physical and logical messages). You can display the content of the physical message for the just
active physical message of this list (the courser is on it). You can find it on the bookmark Content.
List of the physical EMDIS messages in the logical message
Prometheus 116
13.7.3 Content
Display of the content of the physical EMDIS message
The button Save to file serves for the saving of the message listing to the text file. You can copy this
listing to the Windows clipboard by the button Copy to clipboard.
13.8 EMDIS search results
This chapter describes the application window for the analysis of the search results of EMDIS. It is
possible to call it up by the button Search Results from the window for Browsing of the log. messages
or by the button EMDIS Search Results from the window Patient tools EMDIS.
This tool serves for the work with the search results for the concrete patient. It has four bookmarks:
Patient
Summary of Donors
List of Donors
Donor Details
13.8.1 Patient
It contains the basic information about the patient, e.g. the personal identification number, the name
and surname, the HLA typing. This information is displayed analogous to the main window of the
program.
13.8.2 Summary of donors
Summary of EMDIS search results (Summary of Donors)
This bookmark displays the summary of the lists of the donors for the patient. Each line represents
one list of the donors, let us say the logical message. The meaning of the particular columns is
following:
Status It serves as a tool for the recognizing of it if the list has been already processed by the user
or not. I.e. if the log. message is new or old.
HUB The register which carried out the searching and created the list of the donor.
Date It is a date of the creation of the list for outgoing messages and a date of the receiving for the
received messages.
The columns with the particular match grade of the donors and the patient succeed where the
number of the list donors is shown in the particular match grade.
The button Report of donors serves for the display of the donors report in the selected list (the active
line of the table).
13.8.3 List of Donors
This bookmark makes possible to work with the list of all potential EMDIS donors for the patient. It
displays all donors from all lists of the donors in the synoptic table. Each line of this table represents
one donor or rather - one updating of the donor data of the EMDIS register.
Prometheus 118
List of the potential EMDIS donors for the patient
The meaning of the main columns of the table is following:
Message It indicates if the donor belongs to the list of the donors which is newly received (New), if
it was processed by the user (Old). See also New and old log. messages
Donor update It can take these values: New (a new donor), Upd (= Update, the updating of the
donor) or Dupl (=Duplicate, the updating of the donor which does not bring any change of the data).
Validity - It indicates if this line represents the last known data of the donor or if there are obsolete
(historic) data which were updated later. It can take these values: Latest (last known data) or
Obsolete (obsolete data). Each donor displayed in the table has always just one line with the value
Latest and he can have several lines with the value Obsolete. The filter is automatically set to "
Validity = Latest" at the opening of the table which means that there are displayed only the records
of the donors with the latest known data in the table.
Updated - It is the date of the sending of the data of the donor for the foreign patient and it is the
date of the latest change of the data of the patient for the local patient.
HUB - The register of the donor (HUB which carried out the searching and created the list of donors
where the donor belongs).
ID - the identifier of the donor in the EMDIS system. Two first letters are a shortcut of the register.
Status - the donor status
Type - the type of the donor (MD = marrow donor, CB = cord blood).
Sex sex (F=female, M=male)
Year of Birth the year of the birth of the donor (has sense for MD donors).
Match grade match grade of the donor and the patient
A.1, A.2 the intelligent columns for HLA-A locus of the donor. If the donor has the typing at the
level DNA, the DNA date will appear (allele or the code NMDP which expresses the group of the
alleles). If he has not, the serology typing will appear. The data of these two columns are arranged in
such a way to satisfy the data of the patient. If you click on the NMDP code expressing the groups of
the alleles (e.g. A*02BEJX), the list of the alleles included in this code will appear in the status bar
under the table. If the donor has a mismatch witch the patient on this locus, the displayed value is
color highlighted both in the table of donors and in the HLA panel of the patient (on the right up)
B.1, B.2 - the intelligent columns for HLA-B locus of the donor.
C.1, C.2 - the intelligent columns for HLA-C locus of the donor
DRB1.1, DRB1.2 - the intelligent columns for HLA--DR/DRB1 locus of the donor
DQB1.1, DQB1.2 - the intelligent columns for HLA--DQ/DQB1 locus of the donor
If you press the button , the window for the choice of the table columns will be displayed. There are
tens of other columns (the blood group, CB values, etc.) by which you can widen the table. It is enough
to check the column and this will appear immediately in the table of the donor. You can hide this
column by the unchecking. You can find the meaning of all items which you can add to the table in the
EMDIS documentation.
The column headers of the table behave intelligent:
If you click on them by the mouse, you can sort the data in the table ascendingly or descendingly.
If the table is already sorted by any column, you can hold SHIFT and click on the heading of other
column. You will reach the finer sort according to other criterion (the column sorting according to
more columns at once)
You can filter the displayed values in this column by the click on the arrow in the column heading.
You can edit the column width.
You can change the displayed order of the columns by the "drag & drop" of the column heading
between two other column headings.
You can aggregate the messages by the "drag & drop" of the column heading into the grey box
(above the columns headings) according to this column. You can "take out" more column headings
at once and create a tree of messages.
You can combine the particular processes of work with the column heading (the filtration, the sorting,
the aggregating)
In addition to the sorting of the particular columns you can also sort the table according to the more
complex predefined sorting criteria. If you click on the button Sort by date and HUB, the table will be
primarily sorted by the date of the receiving of the information about the donor, then by HUB and
Match grade. In upper part of the table the new received donors will appear. But if you are more
interested in the best donors of all lists than in the date of the receiving, please use the button Sort by
Match Grade. The table will be sorted by Match grade, HUB and the date of the receiving. We do
recommend the user to prefer the predefined sorting criteria to own sorting by the particular columns.
Tip: If you cancel the filter "Validity=Latest" and on the contrary you set the filter of the ID column to
only one ID donor, the data history of this donor will appear for you. You can work with it then, e.g. to
sort it.
Tip: If you choose Custom at the setting of the filter in the header of the column, the possibilities of
the finer setting of the filter of this column will appear for you. You can also set the filter of the column
A1 to the value "0,2%" by which you will obtain the donor with the second allelic group on the locus
HLA-A.
Prometheus 120
Typing request this button will display the form after the sending of the request Typing request
for the selected donor
Sample request this button will display the form after the sending of the request Sample
request for the selected donor
Report of donors the donors report will be displayed. The parameters of the report are already
filled according to it which complex criterion was used for the sorting of the table. If Report maker (see
below) is on, the report will be created according to it.
Report maker this tool makes possible to create any report of the donors from the table. The
table will be displayed which you can insert the selected donors from the original table of all donors by
the buttons Insert selected donor to. You can mark more donors by the mouse if you hold the
pressed CTRL (single donors) or SHIFT (coherent whole of the donors). You can delete again the
selected donor in the table Report maker by the button Delete donor. If you want to change the order
of the selected donors, catch the left edge of the selected donor in the table Report maker and move
it to a different place (up or down). This created report will be displayed by the button Report of
donors. The reports creation mode will be canceled by the button Hide report maker.
13.8.4 Donor - Details
It displays the detailed data about the selected donor in the bookmark List of Donors. It is concerned
with the whole content of the message DONOR_CB. The button Save to file makes possible to save
the text into the text file. The button Copy to clipboard will copy the content of the message to
Windows clipboard.
13.9 Report of search results
Before the display of the report, the window EMDIS Search Result Options will be displayed where
you can set the parameters of the report, i.e. you can e.g. limit the display of the match grade. The
report will be displayed by the button OK.
Parameters of the report of the supply list of EMDIS donors
The EMDIS report of the donors of the program Prometheus has similar display as the report of the
donors used by ZKRD has.
Prometheus 122
EMDIS report of the search results
There is a header including the patient name, his identifier, the sex, the date of birth, the blood group
and the diagnosis on each page of the report. The phenotype of the patient follows. Then the header of
the table of the potential donors (the date of birth, CMV, HLA loci, the donor status, the sex, etc.) is
stated. There are the particular patients in the table who are aggregated according to match grade with
the patient.
Note: For the display of the phenotype of the donor or the patient : If the typing was carried out at the
level DNA, the DNA date will appear (allele or the code NMDP which expresses the group of the
alleles). If it was not, the serology typing will appear.
There are the highlighted mismatches between the phenotype of the donor and of the patient on the
report. It is applied for HLA loci A/A*, B/B* and DR/DRB1. The mismatch Allele mismatch is
highlighted bold, the mismatch Split/Broad mismatch is highlighted bold and underlined.
The end information can appear at the end of the report. It depends on the parameters of the reports
which the user chose before the display of the report. There is the summary of the match grade levels
between the donors and the patient and the number of the donors in these levels in the section
SUMMARY. There is the list of the shortcuts of the EMDIS registers (HUB) displayed in the report and
their explanation in the section REGISTRIES. The shortcuts appear at the beginning of the identifier of
the donors and they are highlighted bold. There is the list of the NMDP codes, which express the
group of the alleles and they are displayed on the report, in the section MULTIPLE ALLELE CODES.
The codes are ordered and aggregated by the particular HLA loci.
13.10 Addresses of EMDIS centers
The address of some institution must be stated in some messages (e.g. who pays the transplantation
for, where to deliver the sample, etc.). All addresses are filed by the HUB directory of EMDIS centers
not to send these addresses in each message. We reference then only to the identifier of the center
(institution) of this directory in the messages.
The statement of the EMDIS centers will be displayed by the help of menu
Comm|EMDISAddressesofcenters.
Addresses of EMDIS centers
The table of the displayed centers has five columns. Institution ID is just the identifier by the help of
which everybody references to an institution. The first two letters of the identifier must be consistent
with the identification of the register in EMDIS, e.g. CZ. column Country is a code of the country
according to the norm ISO-3166 2. The column Institution type can be EMDIS Hub, Donor centre,
Transplant centre, Harvesting centre, Typing laboratory nebo Financial institution. City is a city where
the company seats. Person is a contact person.
You will create a new center by the button New. The form for the filling up the data of the center will be
displayed.
You can edit the data of the selected center by the button Edit. You should do it only at the local
centers.
You can send the information about the selected center to some HUB by the button Send.
You can delete the selected center by the button Delete. This step should be done choicely by you.
Prometheus 124
The information about the foreign centers is automatically updated by the help of the Address to
broadcast messages. So if you change the data of the local center, you should send this message to
all EMDIS partners for whom it is relevant (the button Send). On the contrary the information about the
center is automatically updated by the received message from abroad.
There is the list of the addresses (Address anouncements) on the left part of the window, by which
the information about the center was sent (for the local centers) or received (for the foreign centers).
You can display the selected message of the list by the button Show message and then e.g. press or
just go through it.
13.11 EMDIS reports
The EMDIS reports are called up by the menu command EMDIS | Reports.
Selection of the EMDIS report
Two types of the reports are available: :
Reports of the patient statuses
Reports of the EMDIS messages
13.11.1 Reports of patient statuses
It is about the reports which display the summaries of the EMDIS patients according to the patient
status:
Local patients in EMDIS the local patients in the other EMDIS registers.
Foreign EMDIS patients the foreign EMDIS patients filed in the local database
Local patients in local DB the local patients filed in the local database.
After the choosing of the command the window will be displayed where you can choose the foreign
HUB for the report and the groups of the patients (according to their status). The report will be
displayed on the basis of the chosen criteria.
13.11.2 Reports of EMDIS messages
It is about the reports which display the summaries of the EMDIS messages:
EMDIS Messages - the common report of the EMDIS messages.
EMDIS Requests without result the undone requests (without the answer) in given period.
After the choosing of the command, the filter of the EMDIS messages will appear and by the help of it
the user can specify the displayed messages.
The table will be displayed on the report where each message represents one line. The HUB, the date,
the category, the status of message, ID and the name of patient are displayed in these messages.
13.12 Writing of unattached texts in EMDIS
Some forms contain the editing boxes where it is possible to write an unattached text (e.g. Remark,
etc.). These texts must not contain the Czech and the Slovak diacritics, only the signs ASCII. If you
write somewhere the letter with the Czech diacritics, the program will change it to the letter without the
diacritics (e.g. "r" is changed to "r").
This rule applies also for the filling up of the addresses of the EMDIS center.
14 Communication in EMDIS
This chapter describes the rules from EMDIS documentation and it explains them in connection with
the behaviour of and the checking of the programs of the PROMETHEUS system.
In the case of obscurities, please have a look at the actual version of the official EMDIS documentation
(see Further information about EMDIS).
14.1 General rules
The FML Data Dictionary document (data-dictionary.pdf)
The term donor means marrow donor or cord blood unit
Do not use the Czech and the Slovak diacritic marks for the writing of unattached texts, the notices
and the explanations.
The maximum amount of the material in one Sample request or in Pre-collection sample request is
100 ml.
If the number of required samples (number of tubes) is not filled, the default value is equal to 1.
The FML Message Flow Diagrams document (message-flow.pdf)
Prometheus 126
The system always sends abroad all information which is available. It means it is prohibited to hide
some data which belong to the message.
The The Semantics of FML-messages document (emdis-semantics.pdf)
Each message always contains the sender and the recipient.
Some messages can have further obligatory data. If it is so, the program does not allow to send the
message if all data are not filled.
Each request is uniquely determined by the donor identifier, the patient identifier, the category of the
request and the day of the request (request date). The user is not allowed to create the duplicate
requests by the system. If it was necessity, it is necessary to cancel the previously created request
and then you can create a new one.
The received request from abroad will be rejected if it is duplicate.
Each request (request) must be answered by just one of the following messages:
1. the corresponding answer (result), e.g. TYP_RES
2. the change of the patient status which informs about it that the donor is unavailable and why it is
so (DONOR_CB)
3. the rejection of the request (MSG_DEN)
4. no result the request can not be carried out (NO_RES)
It is eventually possible to create besides the warning (WARNING).
14.2 Patient statuses
The patient status in the foreign register can be:
PRE (Preliminary Search) The patient status is PRE if the Preliminary request was received - that
means the first report about the patient.
ACT (Patient Active) There is repeated donors searching for the patient in this status. It is also
the only status when the request creation is possible for the patient.
SUS (Patient Activity Suspended) There is no repeated donors searching for the patient. All
previously sent requests are normally processed. The request creation is impossible.
STP (Patient Stopped) All activities for the patient are stopped. The old requests are canceled.
Admissible changes of the patient status
Communication in EMDIS 127
Old status New status Note
ACT ACT It is purposeful only as the request for the resending of the search
results (reasons NPH, NML or RCM).
PRE ACT If the change is sent another day than Preliminary request, the
answer is the new search result. If there are some preferences
for the searching in previous message Preliminary request or
Patient update, they will be used.
STP ACT The answer is the new Search result.
SUS ACT The answer is the new Search result.
ACT PRE The request for the change of the status is rejected.
PRE PRE The answer is the new Search result.
STP PRE The request for the change of the status is rejected.
SUS PRE The request for the change of the status is rejected.
ACT STP
All activities for the patient are stopped and the requests are
automatically canceled.
PRE STP The request for the change of the status is rejected.
STP STP It is purposeful only as the request for the resending of the search
(reasons NPH, NML or RCM).
SUS STP All activities are stopped for the patient and the requests are
automatically canceled (canceled).
ACT SUS
All activities for the patient are stopped. There is no repeated
donors searching for the patient. The previously sent requests
are not canceled, the patient HUB must explicitly cancel them.
PRE SUS The request for the change of status is rejected.
STP SUS The request for the change of status is rejected.
SUS SUS All activities for the patient are stopped and the requests
automatically canceled.
Changes of the patient status
14.3 Donor statuses
The donor status in the EMDIS system can take these values:
AV (Available) The donor is available for the transplantation aims.
TU (Temporarily unavailable) The donor is temporarily unavailable. The reason why and the date
when he is unavailable from must be mentioned.
RS (Reserved) The donor is reserved for our patient.
OP (Other patient) The donor is reserved for other patient.
DE (Deleted) The donor is deleted from the register. The reason must be mentioned.
Prometheus 128
14.4 EMDIS messages
The term HUB of patient is used for explanations of the messages rules, as the register (HUB) which
generally asks for something for its patient. On the contrary the term HUB of donor means the register
(HUB) which is generally asked for something because of its donor.
It is necessary to realize during the reading of this chapter that your register can be in role of
HUB of patient as well as HUB of donor.
14.4.1 Preliminary request
Preliminary request
After sending the message Preliminary request, the patient status is set to Preliminary search (PRE)
in the register of donor and as an answer the search results are sent. Any further activities are not
possible till the patient status is not changed to Active (ACT). The only possibility how to change the
patient status is through the message Change patient state.
The first message Preliminary request (PAT_UPD) serves at the same time as the registration of the
patient in the register of donor.
If there are some mistakes in the message Preliminary request (e.g. bad HLA codes), the HUB of
donor can answer by the message Message denial or Warning.
14.4.2 Patient update
Patient update
If any information about the patient is changed (antigens, diagnosis, etc.), it is pertinent to inform about
it the HUB of donor where the patient is filed. In the case that the antigens or the search criteria are
changed, the HUB of donor will send new search results.
If there are some mistakes in the message Preliminary request (e.g. bad HLA codes), the HUB of
donor can answer by the message Message denial or Warning.
14.4.3 Change patient state
It is used for the change of the patient status in the HUB of donor. If the patient status is changed to
ACT, the remote HUB performs repeated donors searching. The status ACT is also the only one when
it is possible to send the request.
If the patient status is SUS or STP and we change the status again to ACT, it is necessary to send
also Patient update. It is therefore that the HUB of donor could already delete the patient data from its
system.
We can also use Change patient status message to request new search result without changing
patient status. In such case, both old and new patient status is PRE of ACT, but Reason for change of
status is:
NPH - Send new phenotype list
NML - Send new match list
RCM - Send new phenotype list and new match list (complete match list)
HUB of donor response with corresponding Search result.
If there are some mistakes in the message Change patient status (e.g. incorrect change of the
patient status), the HUB of donor can answer by the message Message denial or Warning.
14.4.4 Alternative match list request
Request an alternative match list for a patient
This message can be considered as an extension to the Preliminary request. The result is Alternative
match list result - a set of ALM_RES messages with fully matched donors with regards to the
Prometheus 130
alternative phenotype - therefore providing a simple mechanism to obtain mismatched donors for the
patient. It also provides cord blood units with up to two major antigen mismatches (as usual) with
regards to the phenotype given.
The alternative phenotype does not go into the repeat search process. The patient must be known at
the remote system (Preliminary request must precede the first Alternative match list request
message).
Its a common practice to look in BMDW whether mismatched donors are available for a certain
patient. If the search was successful those donors can be requested from the hub found. With the
Alternative match list request these donors are automatically added to EMDIS.
Multiple Alternative match list requests should all provide a different phenotype from that provided
by the last Alternative match list request message. Otherwise they can be rejected.
The patients matching preferences must not be respected for the donors returned i.e. Alternative
match list request yields the default search results.
14.4.5 Typing request
Typing request
The reply to Typing request can be:
Typing result (the result of typing, the positive reply to the request)
Donor status change (the donor is unavailable, the negative reply)
Message denied (the rejection of the request, the negative reply) with the reasons.
Service can not be done (the request received, but the negative reply) the request can not be
done.
The message Typing result contains the same request date and reference code which were also
stated in the request.
It is possible that several messages Typing request will be received for one couple donor-patient in
one day from register of patient. In that case it must have different request to the further typing. If the
request to a test is redundant, the message is automatically rejected. It is prohibited to accumulate
these requests and to reply to them by one message Typing result. Each correct Typing request
must have one answer.
The program Prometheus does not allow to create two messages Typing request for the couple
donor-patient in one day to eliminate the needless mistakes. If there is e.g. user mistake and if the
requests of already sent request need to be completed, it is necessary to cancel the old request and
then to create a new one.

14.4.6 Infectious Disease Marker (IDM) request
Infectious Disease Marker request
The results of the IDM test are given back in the message IDM result. If the results can not be
delivered, the answer is Donor status change (the donor is unavailable, the negative answer) or
Message denied (the rejection of the request, the negative answer) with the reasons or Service can
not be done (the request received but the negative answer) - the request can not be done.
It is possible that several messages IDM request will be received for one couple donor-patient in one
day from register of patient. In this case, they must have different requests of IDM. If the request to a
marker is redundant, the message is automatically rejected. It is prohibited to accumulate these
requests and to reply to them by one message IDM result. Each correct IDM request must have one
answer.
The program Prometheus does not allow to create two messages IDM request for the couple
donor-patient in one day to eliminate the needless mistakes. If there is e.g. user mistake and if the
requests of already sent request need to be completed, it is necessary to cancel the old request (see
Cancellation of a request) and then to create a new one.
Prometheus 132
14.4.6.1 Sample request
Sample request
The values Earliest and latest date of sample reception, which mean the time interval when the sample
can be delivered, are important in the message Sample request. If the first date is missing, the date
of the message receiving in the HUB of donor will be automatically completed by the system. If the
second date is missing, the receiving of the sample can continue whenever after the first date.
The user should not send the second Sample request for the couple of patient-donor. But it is not
prohibited by the program Prometheus.
After contacting of the donor, the information about the supposed Sample arrival date (the positive
reply) will be sent by the HUB of donor. Some registers send also Infectious Desease Marker result.
If the sample can not be delivered, the answer is Donor status change (the donor is unavailable, the
negative answer) or Message denied (the rejection of the request, the negative answer) with the
reasons or Service can not be done (the request received but the negative answer) - the request can
not be done.
After delivering of the sample to the register of patient, the message Sample result, which informs
about the results of the sample test (e.g. IDM), should be send back.
14.4.7 Donor reservation request
Donor reservation request
The answer to Donor reservation request is Donor reservation result which contains the item
Result of donor reservation. The item says whether the reservation was successful or not. If the
reservation was not successful, it is necessary to send one more message - Donor status change
which explains the reasons. Other reasons of the unsuccessful reservation are solved by the help of
Message denied (the rejection of the request, the negative answer) with the reasons.
The HUB of donor must check if the reservations are not too long or "never-ending".
14.4.8 Cancellation of request
Cancellation of a request
The message Cancel of request cancels the previously sent request. It contains the description of
the message, which is to be canceled, and the reasons.
If the patient status was changed to SUS in the register of donor, the requests are not canceled and
the HUB of patient is to think of the cancellation of them by the help of the messages Cancel of
request.
If the patient status was changed to STP in the register of donor, all requests are automatically
canceled and the HUB of patient need not send the messages Cancel of request.
Prometheus 134
14.4.9 Workup request
Workup request
The message Workup request is used for both bone marrow and cord blood unit.
The values Date sample collection, range start and range end in the message Workup request mean
the time interval when the sample can be delivered. If the first date is missing, the date of the message
receiving in the HUB of donor will be automatically completed by the system. If the second date is
missing, the receiving of the sample can continue whenever after the first date.
The field COND_DAYS (Number of days before the agreed upon transplantation date, when the
conditioning of the patient will start) gives the number of days required for the conditioning regimen
envisaged. The donor and the transplant centre must consider this number of days when calculating
the date of marrow collection.
If the type of anticoagulant to be used for the marrow is not specified in the WOR_REQ message,
heparin should be used (according to the guidelines of the WMDA).
One message Donor workup status or more ones, which inform the HUB of patient about the
happening of the donor, can be sent as an answer to Workup request. Date of the confirmation of the
workup request should be filled in the first one of the messages.
If the request can not be done, the answer is Donor status change (the donor is unavailable, the
negative answer) or Message denied (the rejection of the request, the negative answer) with the
reasons or Service can not be done (the request received but the negative answer) - the request can
not be done.
After finishing of the transplantation, the whole process is finished by the HUB of patient when the
message Donor workup status with the information about the date of transplantation to the HUB of
donor is sent. The warning message Request has already result. Are you sure you want to create
another one? is displayed by the program in that case. The request really has the answers - done by
the HUB of donor. In that case it is purposeful to press the button Yes and to fill up the form where you
inform the HUB of donor about the date of transplantation.
14.4.10 Message acknowledgement
The quick explicit confirmation of the request receiving by the remittance HUB has been possible to
demand since 2005. It is often common that a request was sent by the HUB of patient but it has not
been replied for weeks or even months. The questions can appear if the request has been delivered.
Therefore Message acknowledgement can be chosen at filling up the form of some messages. The
remittance register should send back Message acknowledgement immediately after receiving of the
request.
Unfortunately Message acknowledgement does not mean the taking note of the received message
by the remittance register. It means only the receiving and the saving of the message in the system.
This sureness should be done by other mechanisms (see ECS). Therefore we do believe that the
mechanism of the Message acknowledgement is not so useful.
14.4.11 Text message
The text message contains the identifier of the patient and of the donor. It is suitable e.g. as the
commentary on an action for the couple patient-donor.
The standard emails should be used in the common communication among the people.
14.5 Repeated donors search
The regular donors searching is done in the register of donor for all patients of the register of patient
in the active status. How often it is done, it depends on the setting of each register. The interval is 24
hours in the system EsterBMD. This interval is monitored individually for each patient.
The new result of the searching is sent only in that case that:
the new donor appeared in the register of donor who has better match grade than another donor
who was sent by the last search result
the antigens or other information about some donor, who was sent in the last search result, are
changed. It means e.g. DR selection, the change of the donor status, the completion of the blood
group, etc. The change of the donor status can mean also deleting of the donor from the register.
Further information about the EsterBMD system, see the separate chapter EsterBmd.
14.6 Request rejection
If the request from abroad has any formal imperfection (infringes the rules EMDIS), it is automatically
rejected by the system ESTER or EsterBMD. The denied message is not deleted, it will appear among
the new messages in the folder EMDIS patients-requests and its status is Received, denied. It is
impossible to reply to this message. The Message denied will appear among the new messages in
the folder EMDIS patienst-results where the user can find the reason of the rejection.
The denied request is not done and the HUB of patient must send it again.
Alike if some Warning on the basis of the received message from abroad is sent by the ESTER
system, this message will appear among the new messages in the folder EMDIS patients answers.
Prometheus 136
15 System administration
15.1 Installation
This chapter briefly describes the process of installing the Prometheus system. The installation should
always be carried out by the administrator not by the end user.
The Prometheus system does not need installation BDE nor the installation of the Paradox system.
The system is designed for the computer networks without a DCHP server. Each computer should
have a fixed IP address and a suitable computer name.
The communication server must have internet access, especially the possibility of sending emails
through a SMTP server, downloading files with the help of FTP and HHTP protocols and connecting to
POP3 server.
The database server communicates with the other computers on the 3050 (Firebird)
The process of the installation of the database server:
Preparation:
Create folders "Steiner", "Service" and "Install" in this structure: c:\Steiner\Service\Install\. This will
serve to store all relevant installation packages.
1. Install Firebird server.
Begin by downloading the Firebird installation package by following the link:
www.steinersw.eu/david/bmd/Install/Firebird-2.1.1.17910-0_Win32.exe with your internet
browser. Choose to save the file onto your PC at your previously created "Install" folder at
c:\Steiner\Service\Install\
Run the Firebird-2.1.1.17910-0_Win32.exe program.
Go through the installation steps and use the installation location offered by the set up program,
unless you require otherwise. Stop at the Select Components window as seen in the picture below.
System administration 137
Mark Server components - Super Server binary and Developer and admin tools components, as in
the picture above.
Open the roll down option and select "Full installation of Server and development tools" option as
seen in the picture below and click next.
Then keep clicking next, leaving all default options until the installation is complete.
2. Install IBExpert (For the servers on the platform Windows directly on the server, for Linux servers on
client PC).
Download the IBExpert installation package by following the link:
www.steinersw.eu/david/bmd/Install/setup_personal.exe with your internet browser. Choose to
save the file onto your PC at your previously created "Install" folder at c:\Steiner\Service\Install\
Run the setup_personal.exe program. Leave all the default settings and options as they are. The
program will however alert you on several occasions that some options are only available on the
customer version, just keep clicking "OK" and finish the setup.
Create a desktop shortcut Icon of IBExpert.
Start IBExpert and set the Multiple document interface.
Under" Tools" open the User Manager. Use the Manager to add the users: DATABMD, LOGINBMD
and DISTSW, as seen below.
Prometheus 138
user pasword SYSDBA
Create a shortcut icon of IbExpert on the desktop
Start IBExpert, and set Multiple document interface
Tools User manager, to add an user DATABMD, LOGINBMD and DISTSW, change the user
password SYSDBA
3. Create DataBMD, DistSW, ValsBMD and HLAcoreDB databases.
4. Register the DataBMD, DistSW, ValsBMD and HLAcoreDB databases
Do not save the passwords
5. Fill the ValsBMD database with data.
6. Fill the DataBMD database with data.
7. Create the database aliases to the databases (restart Firebird).
The process of installation the communication server:
Preparation:
1. Install the Firebird client library.
Open the roll down option and select "Minimum client install - no server, no tools" option as seen in
the picture below and click next.
2. Install IbExpert.
3. Install PGP
Import the public key of the company Steiner.
4. Copy the address structure to the server (folder C:\Steiner\BmdServer)
5. Create system variable HLAPATH=C:\Steiner\HLAcore\Data, restart computer.
6. Set the initialization files (BmdHLA.ini, BmdQC.ini, BmdWeb.ini)
7. Create the shortcut icons on the desktop (BmdWeb, BmdHLA, BmdQC, IbExpert).
Prometheus 140
8. Download the new version of Prometheus packages to DistSW database using the BmdWeb
program.
9. Install and to configure ESTER, see documentation ESTER
10. Install ActivePerl, restart computer and install Perl PPM packages DBI and InterBase. Adjust Perl
scripts (database aliases).
The process of installing an additional system client:
Preparation:
1. Install the Firebird client library.
Open the roll down option and select "Minimum client install - no server, no tools" option as seen in
the picture below and click next.
2. Download the Prometheus program package.
Download the Prometheus program package by editing the following link
www.steinersw.eu/david/bmd/Install/SteinerXX.zip, replacing XX with your registry's Emdis ID
code and typing it into internet browser. (e.g. www.steinersw.eu/david/bmd/Install/SteinerZA.zip for
South Africa)
Registry codes:
CY - Cypress
CZ - Czech Republic
WB -Poland ALF
SK - Slovak Republic
ZA - South Africa
NOTE: It is important you adhere to the registry ID codes as each Prometheus program package
contain unique settings relevant to your registry.
Choose to save the file onto your PC at your previously created "Install" folder at
Unzip the SteinerCY.zip package and copy the two files it contains, Bmd and HLAcore, into your
"Steiner" folder at c:\Steiner
3. Create a new system variable HLAPATH.
Right click your "Computer" or "This Computer" Icon, either on your desktop or "Start" menu. Click
on "Properties" on the menu.
A computer properties window should open up. Follow the next instructions according to which
Windows Platform you have on your PC. Access to these properties is slightly different in Windows
Vista than to Windows XP.
Vista user:
The window below should now be open
Prometheus 142
Click on the "Advanced system settings" option in the panel on the left. Vista will ask your
permission to continue.
The "system properties " should now open, as seen in the picture bellow. Choose the "Advanced"
folder and click on the "Environment Variables" button at the bottom of the window.
The "Environment Variables" window should now be open. Click on the "New" button under "System
Variables" as seen in the picture below.
A "New System Variable" window should now be open. Type "HLAPATH" as the Variable Name and
type "c:\Steiner\HLAcore\Data" as the Variable Value. As in the picture below.
Prometheus 144

Click OK and leave the Computer settings confirming the changes as you go along the way.
Windows XP user:
The System Properties window should now be open, as seen in the picture bellow.
Open the "Advanced" folder and click on the "Environment Variables" button at the bottom of the
window.
The "Environment Variable" window should now be open. Click on the "New" button under "System
Variables" as seen in the picture below.
A "New System Variable" window should now be open. Type "HLAPATH" as the Variable Name and
type "c:\Steiner\HLAcore\Data" as the Variable Value. As seen in the picture below.
Click OK and leave the Computer settings confirming the changes as you go along the way.
4. Create the Prometheus desktop Icon.
Open the "BmdExe" folder at c:\Steiner\Bmd\BmdExe\ using your browser. Create a shortcut of the
"Bmd exe" file (right click on "Bmd exe" - click on "Create Shortcut") and place it onto your desktop.
Rename the shortcut Icon as "Prometheus".
5. Create the Documentation Desktop Icon.
Open the "BmdDoc" folder at c:\Steiner\Bmd\BmdDoc\ using your browser. Create a shortcut of
the "BmdEn pdf" file (right click on "BmdEn pdf" - click on "Create Shortcut") and place it onto your
desktop.
Rename the shortcut Icon as "Prometheus manual"
6. Start Prometheus via the desktop Icon you have created.
Prometheus 146
Depending on the windows system and it's settings, it might be necessary to restart your PC.
7. Updating Prometheus
Open the "BmdUpdate" folder at c:\Steiner\Bmd\BmdUpdate\ using your browser. Start the "
StartUpdate.bat" program. The program will update Prometheus, Vista users are likely to be asked
for permission. The process may take several minutes. A successful running of the program will
show no error messages in the bottom half of the programs window, if you get any error messages,
contact the Prometheus admin.
Incase of a successful update, create a shortcut of the "StartUpdate.bat" program from the folder
at c:\Steiner\Bmd\Params\ and place it in the Windows startup folder. This can be done by 'drag
and drop' with your mouse. Drag the shortcut of "StartUpdate.bat" and hover over the Windows
"Start" button on the left bottom corner of your screen. The button will unfold into a menu, hover over
the the "All Programs" button ("Programs" in Windows XP). When the "All Programs" menu unfolds,
hover over the "Startup" button and drop the shortcut amongst the "Startup" programs. Make sure it
is there successfully. "StartUpdate.bat" will now run every time your PC is switched on, updating
Prometheus.
15.2 Initialization file
The initialization file of the program Prometheus is Bmd.ini and you can find it mostly in the folder C:
\Steiner\Bmd\Params. It contains e.g. the path to the databases, the place of the nomenclature, etc. At
the system installation it is necessary to edit this file manually and to set minimally a path to the
databases DataBmd.
The next system changes are allowed to be made by the menu command Servis | Initialization file.
The change of the initialization file of the program Prometheus
15.3 System parameters
You can set the system parameters in menu Servis | System parameters.
You can set these parameters:
Delete interval of program log - Number of days of saving the user login history to the program
Prometheus
Data audit [yes/no] - the starting and shutdown of evidence of the history of the data changes
User name, password, path and character set to the database ValsBmd
Automatic updating of the nomenclatures ValsBmd [yes/no] - nomenclatures downloading from
database ValsBmd to the workstations.
User name, password, path and character set to the database DistSW
Use DistSW [yes/no] - if the DistSW database should be used or not, i.e. if workstations will be
automatically updated.
Local EMDIS hub ID - Register identifier in EMDIS
Local country ID - ISO code of the country, where the register occurs. From this variable program
knows which ZIP codes and diagnoses to use.
Registry ID 1 - The first BMDW code of the register
Registry ID 2 - The second BMDW code of the register (if the data cord blood is also in the
database)
Minimum length of the user password (the number of signs)
Birth date and sex by pers. number [yes/no] - if birth date and sex can be derived from personal
number (Czech rep. and Slovakia only)
DonNew FOR file - name of the entry form definition file for new donors (e.g. "DonEditCY")
DonEdit FOR file - name of the entry form definition file for donor updates (e.g. "DonEditCY")
PatNew FOR file - name of the entry form definition file for new patients (e.g. "PatEditCY")
PatEdit FOR file - name of the entry form definition file for patient updates (e.g. "PatEditCY")
VPE CharSet - virtual print engine character set.
Default values at creating a new donor - sex, type of donor, donor status, ID register, donor
center, agreement, ethnicity, country
Default values at creating a new foreign donor - sex, type of donor, donor status, ID register,
donor center, agreement, ethnicity, country
Prometheus 148
Default values at creating a new patient - sex, patient status, ID register, transplantation center,
ethnicity, country
Default values at creating a new foreign patient - sex, patient status, ID register, transplantation
center, ethnicity, country
Default maximum numbers of donors at creating a new searching
Default parameters of search engine
Calculation parameters of probability of donor-patient match - experimental
Maximum donor age - the number of the years, it will be shown at the quality check
BMDW export - parameters
Invoices - set Item number to triggers: Activation fee item, Foreign service item, Stem cell donation
item, CB unit item, Transplantation fee item and Invoice fee item.
15.4 Program Prometheus updating
The new versions of the program are downloaded from FTP server of the company Steiner by the help
of th program BmdWeb, which is installed on the communication server.
The program controls if there is a new version of the program on the server. If it is so, it will download
it, it will verify the validity of PGP sign and it will insert the installation packet in the database DistSW.
The program Prometheus checks at starting if there is a new version of the program in the database
DistSW. If it is so, the new actualization will be offered by itself to the user. If the user chooses an
actualization, the program shutdown will continue and the actualization process will be started which
will install a new version of the program Prometheus. After its finishing the user can start the program
Prometheus again, now already the new version.
The program Prometheus will be updated also after starting or restarting the computer.
15.5 Database DataBmd
The DataBMD database is the main and the most important database of the register. It contains these
groups of the tables:
Donors the records of donors. More than 100 attributes are allowed to be saved to each donor.
Patients the records about the patients.
Search the records about the searching of the potential donors for the selected patients.
EMDIS donors the records about the foreign donors (EMDIS).
EMDIS patients - the records about the foreign patients (EMDIS).
EMDIS news EMDIS, the search results of the donors for EMDIS patients and EMDIS center
folder.
NetCord
Database values the nomenclatures of the database items (insurance companies, diagnoses,
etc.).
BMDW edition the files of the donors, sent to BMDW.
Stacks the stacks of the donors and patients.
Data audit the audit of the data changes.
System tables the system tables of the users, the groups of users, the access rights, audit, the
system parameters, etc.
Events - the events of the donors and the patients.
15.6 Database archiving
The database must be archived regularly, it is recommended once a day.
Automatic archiving in CSCR
The database register is saved on the database server.
The database engine is Firebird
The process, which carries out the database backup, starts on the communication server every night
at 3:00. This process finishes approximately at 4:30.
Backup contains the full database.
The arisen archive is encrypted by the help of the public PGP key of the register.
PGP file is saved in the communication processor in the folder c:\Archive\DataBmd\Pgp. The new
PGP file (e.g. DataBmd20070725.fbk.pgp) arises in this folder every day.
15.7 Copy Tool
This tool serves to to create copies of the Database. This can be used to create Default databases and
Test databases, all according to the way the user has set up his Production and test environment.
Set up:
It is best to have the "Copy Tool.exe" file located together with it's configuration file. The Program
should be run via a short cut link which also points the path to the configuration file.
Copy Tool Operation:
The main window of the Copy Tool may be seen bellow.
Prometheus 150
Copy Tool main window
Main window features:
Config button - Opens the configuration window.
Create Default DB button - Creates a Default DB from the Production DB
Create Test DB button - Creates a Test DB from the Default DB
Close button - Closes the program.
Report Window - The events taken place appear in the main space of the Copy Tool window.
The Configuration Window can be seen bellow. The Configuration window directly controls the data on
the Configuration file.
Copy Tool Configurations window
1. Server host The name of the database server or local host. If left empty, localhost is used as
default
2. User name DB username.
3. Password DB user's password.
4. Server port the port for acces to the DB.
5. Protocol Network protocol type.
6. Source Database Path to production DB.
7. Default Test Database Path to default test DB.
8. Test Database Path to test DB.
9. Log dir path to where logs are stored.
10.DB Params Path to the DB parameter file.
11.DBX Client lib Name of the client library of the DB server.
12.DB Character set Name of the character set of the DB server.
Note:
"Test Database" - the path to the test database, source is always the DB shown in "Default Test
Database"
"Default Test Database" - The path to the default test database, source is always the DB shown in
"Source Database"
Prometheus 152
15.8 Users and groups of users administration
The tool for the users and the groups of users administration is called up by the menu command
Servis | System users and groups.
Users and the groups of users administration
The window with the table of users in the left part and the table of groups of users in the right part will
be displayed.
15.8.1 Users administration
You can create a new user by the button New. You can change the characteristics of the existing user
by the button Edit.
Each user has these characteristics:
He has the unique user number (automatically created)
The name of user, which is displayed in the program later.
The database user, always set to the value databmd.
He belongs in just one group of the users.
He has the set validity of the password.
He has the set validity of the user account.
The time of the last user login is filed.
The time of the last password change of user is filed by the system.
The number of the unsuccessful login attempts (bad password) is filed by the system.
The user has also the rights to the particular functions of the program. An access to each function
can be set up individually (Allowed) or according to the rights of the group (by Group).
The user has his own setting of the program.
Change of user's data
You can delete the user from the system by the button Delete.
Warning: We do not recommend you to reset the user from the system because several system
connections will be broken thereby. If you want to block an access of the user, it is better to limit a time
interval of the validity of the user account.
You can delete the user password by the button Reset password. The password will be set to its
initial value. E.g. the user number 2 will have the password "2 2" (two space two).
See also: Program start
You can unblock the account of the user by the button Unblock who entered bad password more than
five times successive and his account was blocked.
15.8.2 Groups of users administration
You can create a new group of users by the button New. You can change the selected group of users
by the button Edit.
The group of users has following qualities:
The number of the group of users (automatically created)
The name of the group of users which is displayed in the program later.
Access rights
Prometheus 154
Access rights of the group of users
15.9 Nomenclatures maintenance
The Prometheus system contains several types of nomenclatures:
1. Nomenclature of HLA items
BMDW lookup tables, NMDP codes
These nomenclatures are updated from the servers www.bmdw.org and http://bioinformatics.nmdp.
org by the help of the program BmdHLA
The data are saved in the database ValsBMD where they are distributed to the local computers after
starting the program Prometheus from
2. Nomenclatures ValsBMD, supplied by Steiner company:
The national nomenclature of diagnoses, postcode, HLA (serology, list of HLA loci), the
nomenclature of the countries, BMDW registers, EMDIS registers, etc.
The updating of these nomenclatures is provided by Steiner company
The data are saved in the database ValsBMD where they are distributed to the local computers after
starting the program Prometheus from
3. Nomenclatures in the program Prometheus:
The blood groups, the patient status, the donor status, the reason of elimination, etc.
The updating of these nomenclatures is provided by Steiner company
The data are saved directly in the program Prometheus.
4. Own nomenclatures of the register
Own list of diagnoses, insurance companies, the connected EMDIS registers
The updating of these nomenclatures is provided by the system administrator
The data are saved in the database DataBMD
It is possible to edit the nomenclatures by the help of menu Servis | Database values
See also: Own nomenclatures of the register
15.10 Own nomenclatures of registry
It is possible to edit the nomenclatures by the help of menu Servis | Database values
Own list of the diagnoses
The national code, the description and the equivalent code in EMDIS are filled at every diagnosis.
Insurance companies
The code and the description are filled at every insurance companies.
The attached EMDIS registers
The sequence number, the code, the description and Watch are filled at every register.
The sequence number 0 is stipulated for the empty value. The sequence number 1 is stipulated for
virtual register ALL.
Watch represents the default value of the setting of the changes of the search results monitoring for
the particular patient:
Value 0 means None
Value 1 means Standard
Value 2 means All
Prometheus 156
Nomenclature of EMDIS registers
15.11 General forms
Different users can have different requirements on the design of the data-entry forms. Therefore the
program Prometheus uses so-called general forms which make possible to adjust the data-entry
forms to the requirements of the particular user. This chapter is defined especially for the
administrator, the end user can omit it.
The general form has these characteristics:
It is generated dynamically every time it is to be displayed.
Its design is defined by the control file which is saved locally on the hard disk of the workstation.
It can be various for each workstation.
15.11.1 Control file
There is a summary of the general forms of the program PROMETHEUS in the following table and
their control files.
Function Menu command Control file
The creation of a new donor Donor New donor DonNew.for
Display/Change of the donor data Donor Edit donor 1 DonEdit1.for
Donor Edit donor 2 DonEdit2.for
Donor Edit donor 3 DonEdit3.for
Display/Change of the donor NetCord data Donor - NetCord DonEdit4.for
The creation of a new patient Patient New patient PatNew.for
Display/Change of the patient data Patient Edit patient 1 PatEdit1.for
Patient Edit patient 2 PatEdit2.for
Patient Edit patient 3 PatEdit3.for
general forms of the program PROMETHEUS
See also:
Instructions of the control file
Instance of the control file
Change of the control file
15.11.2 Instructions of control file
The control file of the general form is an ordinary text file. There are instructions in the separated lines
(see the table) which are processed at the dynamic creation of the common file by the program
PROMETHEUS. The first line of the file is ignored.
Instruction
s
Description
ITEM Item of the form for the data entry. It can be an edit box, a combo box, etc. It mostly
corresponds to some attribute of the date structure of the database.
PAGE Separation of the particular pages (bookmarks) of the form.
TEXT Unattached text
TABS Definition of the page titles (bookmarks) of the form
/E File end. Any text can succeed to this instruction and it will be ignored at the processing
of the file.
Instructions of the control file of the dynamic form
The full syntax of the instruction ITEM is following:
ITEM xxx yyy www hhh 000 000 Item_ID the_text_in_front_of_the_item
where
xxx is x ordinate of the item on the page of the form (in pixels).
yyy is y ordinate of the item on the page of the form (in pixels).
www is an item width.
hhh is an item depth.
Prometheus 158
Item_ID is an item identifier or an item connection to data. This identifier can have maximally 15
signs.
the_text_in_front_of_the_item is the explanatory text note which is displayed in front of the item. This
note must begin on the 46th sign of the line.
The full syntax of the instruction PAGE is following:
PAGE
The full syntax of the instruction TEXT is following:
TEXT xxx yyy mod text
where
xxx is x ordinate of the item on the page of the form (in pixels).
yyy is y ordinate of the item on the page of the form (in pixels).
mod is the style of the text (see the table).
text is an unattached text
mod Sample of the text
001
002
003
004
005
006
007
008
Here is the sample of the text.
Style of the text of instruction TEXT
The full syntax of the instruction TABS is following:
TABS text
or
TABS &x text
where
x is an unattached letter or digit (e.g. 1). Then the page will be available by the keyboard shortcut Alt-x
(e.g. Alt-1).
text is an unattached text of the title of the page.
15.11.3 Instance of control file
There is the instance of the control file of the form for the donor correction in the picture. The first line
contains a commentary and it is ignored at processing of the file. The general form contains two pages
(bookmarks). The first one has the title "Basic information" and it is available by the keyboard shortcut
ALT-1. There are three items on it. E.g. the second item is connected with the donor name (Name), it
will be placed on the coordinates (150, 50) and its text note is "Surname and name". The second page
"Further information" will have the keyboard shortcut ALT-2.
Donor edit <rev. 13.10.2006>
ITEM 150 020 000 000 000 000 RegistryID Registry ID
ITEM 150 050 000 000 000 000 Name Surname and name
ITEM 150 080 000 000 000 000 Title Title
PAGE
ITEM 150 110 000 000 000 000 BirthName Maiden name
ITEM 150 140 000 000 000 000 PersNumber Personal identification number
ITEM 150 170 000 000 000 000 BirthDate Date of birthday
ITEM 350 170 000 000 000 000 Sex Sex
TEXT 020 210 002 Comment
ITEM 020 230 000 000 000 000 Comment
TABS &1 Basic information
TABS &2 Further information
/E
Instance of the control file of the general form
15.11.4 Change of control files
The default control files of the general forms are supplied with each version of the program
PROMETHEUS by the Steiner company. These files are placed in the folder C:\Steiner\Bmd\ExeBmd.
The complete list of the items for use in the general form is included. The dynamic form generation
can be slowed down by the larger number of the items (about 100). If you want to change any control
file (e.g. DonEdit1.for), do the following:
Copy the control file from the folder C:\Steiner\Bmd\ExeBmd to the folder
C:\Steiner\Bmd\Customization
Edit this file copy.
The control files are searched at first in the folder C:\Steiner\Bmd\Customization by the program, if the
searching is not successful, it is searched in the folder C:\Steiner\Bmd\ExeBmd.
Warning: Do never change the control files in the folder C:\Steiner\Bmd\ExeBmd, but only their copies
in the folder C:\Steiner\Bmd\Customization.
15.12 Creation of own reports
The system users can have different claims on the design of the reports. Therefore the program
PROMETHEUS uses the common and very sophisticated generator of the reports which makes
possible to adjust the reports to the claims of the concrete user.
The report has these characteristics:
It is always dynamically generated when it should be displayed.
Its design is defined by the control file which is local saved on the hard disk of the work station.
The control file can be different for each work station.
Prometheus 160
The report header generally contains the register emblem, its name and address. It is possible to edit
these data by the help of the menu command Servis | Address of the Registry. The emblem must be in
the BMP format with the size about 59 x 76 pixels.
The report footer generally contains the page number, the date of the report creation and the
information about the actual version of the program Prometheus.
15.12.1 Control file
The control file of the report is the text file, where the program is written down in Pascal language, by
the help of it the report is dynamically created. These files have an extension *.rep and their name is
created according to the following scheme:
File prefix Description File example
DonRep Donors reports DonRep001.rep
PatRep Patients reports PatRep001.rep
EmdRep EMDIS reports EmdRep012.rep
MsgRep Report of the EMDIS message MsgRep001.rep
SrcRep Report of the search results SrcRep020.rep
15.12.2 Instance of control file
This is the instance of the control file of the report of the donors in the stack.
//HLA + Status + Name (stack)
//This report works with the donor stack.
//It prints donors with their name, donor type, status, CMV and HLA
uses
'TbmdVPEPlugInScriptElemBase', 'TbmdPlugInScriptElemDonor';
var
DonIndex: Integer;
procedure PrintHeader;
begin
bmdPrintRegistryHeader(1);
SetArialFont(15);
SetTextBoldOff;
Print(nLeftMargin,nTop-120,'List of Donors');
SetArialFont(10);
Print(nLeftMargin,nTop+75,'Report DON010');
bmdSetYPos(350);
bmdPrintLine1;
SetCourierFont(10);
SetTextBoldOn;
bmdPrint('Donor ID');
bmdPrintX(nLeftMargin+530,'DonStat');
bmdPrintLn('');
bmdPrint('Donor name');
bmdPrintX(nLeftMargin+530,'CMV');
bmdSetYPos(350);
bmdPrintAntigenHeader;
bmdPrintLine1;
end;
procedure AddNewPage;
begin
NewPage;
PrintHeader;
end;
begin
bmdLoadDonorStackData(bmdActiveDonorStackNum);
PrintHeader;
for DonIndex := 1 to RecordTableNumRecords do begin
if (bmdFreeLinesCount < 2) then AddNewPage;
bmdSelectDonor(DonIndex);
bmdStorePos;
bmdPrint(bmdGetDonRecIt('DONEMDISID'));
if (bmdGetDonRecIt('DONTYPE')='CB') then bmdPrint(' ('+bmdGetDonRecIt('DONORID2')+')');
bmdPrintX(nLeftMargin+530,bmdGetDonRecIt('DONEMDISSTATE'));
bmdPrintLn('');
if (bmdGetDonRecIt('DONTYPE') = 'CB') then begin
SetTextBoldOn;
bmdPrint('Cord Blood');
SetTextBoldOff;
end else
bmdPrint(bmdGetDonRecIt('NAME'));
bmdPrintX(nLeftMargin+530,bmdGetDonRecIt('CMV')+' '+bmdGetDonRecIt('CMVDATE'));
bmdRestorePos;
bmdVPEPrintDonorPhenotype;
bmdIncYPos(10);
bmdPrintLine1;
end;
if (bmdFreeLinesCount < 2) then AddNewPage;
bmdPrintLn('');
SetTextBoldOn;
bmdPrint('Number of donors: '+deItoA(RecordTableNumRecords));
bmdPrintFooter;
VPEPreview;
end.
15.12.3 Change of control files
The default control files of the reports are supplied with each version of the program PROMETHEUS
by the Steiner company. These files are placed in the folder C:\Steiner\Bmd\ExeBmd. If you want to
change some control file (e.g. DonRep001.rep), do the following:
Copy the control file from the folder C:\Steiner\Bmd\ExeBmd to the folder
C:\Steiner\Bmd\Customization
Edit this file copy.
The control files are searched at first in the folder C:\Steiner\Bmd\Customization by the program, if the
searching is not successful, it is searched in the folder C:\Steiner\Bmd\ExeBmd.
Warning: Do never change the control files in the folder C:\Steiner\Bmd\ExeBmd, but only their copies
in the folder C:\Steiner\Bmd\Customization.
Prometheus 162
15.13 Establishing Emdis connections
Following a mutual agreement amongst Emdis registries to connect with each other, you may proceed
with the technical aspects of establishing a new connection.
The process can be divided into three main steps, namely in the settings of the PGP, Ester and
Prometheus programs.
Note: All steps are to be typically carried out on the communications server
What is needed:
The public PGP key of the other registry. Available at www.emdis.net
A contact for the administrator of the other registry. It can also be found at www.emdis.net
The valid email address for data exchange. Can be provided by the administrator of the other
registry.
15.13.1 Setting PGP
Sensitive data that is exchanged amongst registries is encrypted, thus the data can not be easily
abused by unauthorized persons. The data thus can be practically read only by the sender and
receiver, the Hub that is sending the message and the Hub receiving the message. Special virtual keys
are used by the program responsible for the encryption of your data. Your communications server will
be most likely equipped with PGP, the program used for encryption. PGP contains or stores your own
unique key, but it also contains imported public keys of the Hubs that you are communicating with.
Thus a message sent from your Hub to another will be encrypted using your own key and that of the
other Hub. Thus the other hub shall be able to decrypt your message and also recognize that the
message is from your Hub and that the data is safe to process.
Downloading public keys:
One of the first steps when establishing a connection with another Hub is acquiring their public key.
Public keys can be downloaded at www.emdis.net in the "PGP keys" section under "Participants".
Right click on the link next to the required registry on the web page and select "Save target as.....", the
file should be saved as a asc file, eg. emdisnvl.asc.
It is recommended that you store all your keys at one place.
Adding the new registry public key onto your key ring:
1. Import the public PGP key you have downloaded for the other registry onto your key ring.
Right click on the PGP (the little pad lock) icon, among the icons in the system tray on the right side
of your task bar.
Select "PGPkeys", as seen in the picture below.
2. A PGP keys window should now be open as seen in the picture below. Now click on the folder icon
of the tool bar "Import keys from a file", or select "Import" from the "Keys" menu.
3. Show the path to the relevant key you have downloaded and import it onto your key ring.
Where to find the key properties
This is useful for when you will be setting Ester, where you need to set the correct ID of the key of the
new Hub.
1. Open the "PGP keys" window described above, highlight the relevant key in the table and choose
"Properties" via the "Keys" menu as in the example below.
Prometheus 164
2. A window with the key's properties should now be open, as seen in the example below.
The ID of the key in the example above has been highlighted. It is recommended that you copy/
paste the ID when you need to use it, when setting this field in Ester for example.
15.13.2 Setting Ester
Ester is the program responsible for the sending, receiving and sorting of messages communicated
among Hubs. It is therefore imperative that you set the correct identification details of the new Hub,
Email address for communication and to set the identification of the PGP key of the new Hub so that
the program knows which key to use.
Should your registry be using a different software program for communication, please refer to it's
relevant manual.
Adding the new Registry into Ester:
Open the program Ester Admin, the Icon, , should be on your desktop. The Ester Admin
window should open, as seen below.
Select "HUBs" from the "Options" menu. A window with all existing hubs should open, as can be
seen below.
Prometheus 166
Click on the "New Hub" button. A window for adding new hubs should now be open, as can be seen
below.
Fill in the following fields, it is recommended that you use copy/paste wherever possible :
1. "Hub ID", with the ID of the new hub.
2. "Name", with the name of the new hub
3. "Email", with the correct email address for data exchange of the new hub.
4. "Pgp key ID", with the correct PGP Key ID. The ID can be found in the PGP program, using the
"Show key or certificate properties" button on the tool bar when you have the "PGP keys" window
open. Mark the relevant key of the new registry you have imported, and click on the "Show key or
certificate properties" button. The first field is the key's ID, best use copy/paste to put this value into
Ester Admin. You may now close all PGP windows when done.
5. Mark "Decrypt and Check Signature" under "PGP - Messages from remote Hub".
6. Mark "Encrypt and Sign Messages" under "PGP -Messages to remote Hub".
The result should look similar to the example below, but with the correct and relevant information.
You may now enter confirm the new hub with the green "tick' or ok button.
Establishing the connection:
You are now ready to communicate. You may now inform your counterpart from the other/new
registry that you are prepared.
Once you both confirm that you are ready to switch communication on, you may change the status
of the hub.
1. Select "HUBs" from the "Options" menu. A window with all existing hubs should open, as can be
seen below.
Prometheus 168
2. Highlight the relevant hub and press the "Edit HUB" Button.
3. Edit the "Status" field and change it to "Normal state", as can be seen below.
Confirm with the green "tick" sign.
Confirming the connection has succeeded:
In Ester Admin open "Emails" under the "Tables" menu, as seen below.
A window with all incoming and outgoing emails should be open. Under "Processed received
messages" open the folder of the relevant hub. The right side of the window contains a list of
received emails. The bottom right section contains the contents of the email of the highlighted
message in the table above it. You should receive emails from the registry, the "HUBseqNum"
should be "0" and the content of the message should be as in the Example below.
If you receive these messages, then the connection is successful. Get confirmation from your
counterpart at the new Hub that all is well on their side as well.
If so, you may proceed with the next step of adding the new hub into Prometheus.
15.13.3 Setting Prometheus
At this stage you should have established physical communication with the new registry. Now all that
remains is adding and setting the details of the new Hub in the Prometheus program itself. But beware
that once you have set the Hub into the active state in Prometheus but have not established a
Prometheus 170
successful connection with the new Hub, Prometheus will nevertheless regard the Hub as active, and it
shall generate Emdis messages the usual way. Thus the messages will not be physically sent to the
new Hub and you will risk the loss of these messages.
The procedure can be split into two main steps, firstly adding and editing the values of the new Hub,
and secondly the sending of information regarding Institutions, such as transplant centers, relevant to
your registry. The information contains the codes and addresses of the institutions, information
imperative in several forms of Emdis messages (described in the Emdis documentation, available at
www.emdis.net) and it is important the new Hub has registered these institutions. It is also important to
send the information as soon as a successful connection has been established and the new Hub has
been added into Prometheus.
Adding the new Hub into Prometheus:
Run Prometheus. Select "EMDIS HUBs" under "Database values" in the "Service" menu as can be
seen below.
A list of all your Emdis Hubs should now be open, as can be seen below.
Use the "+" button on the tool bar at the bottom of the window, as can bee seen below.
A new empty row should have been created as can be seen below.
Fill in the new row with the relevant values.
1. ID, must be a vacant (not used) number.
2. Code, should be the relevant code of the new Hub.
3. Description, usually the name of the Hub or registry.
4. Watch, set the value to "1"
An example of entering a new Hub below.
Prometheus 172
Confirm entering the new Hub using the green "tick" button in the tool bar, as can be seen below.
Confirm the whole procedure using the main green "tick" sign on the right bottom side of the window.
Hint: The ID numbers also dictate in which order the hubs will be presented to the user in Prometheus
itself. You may freely edit the numbers of the existing hubs should you wish to keep them in
alphabetical order. Remember to always use a vacant number, you may for instance increase the
values by a 100 and then one by one place them in the right order. After changing each row, confirm it
with the green "tick" sign on the tool bar.
Sending Institutions and addresses of your registry:
When communication is up and running, you may proceed to send all your Institutions and their
addresses relevant to your Registry to the new Hub.
Choose "Addresses of centers" from the "Emdis" menu, as can be see below.
A table with all your known Emdis centers should now be open, as can be seen below. It contains a
table of all your known Centers, and to the right under "Address anouncements" is a record of when
and to which hub has the highlighted Center been sent to before.
It is recommended that you filter the "Country" column. Move your cursor over "Country" and
should appear, mark your country.
Choose a Center you wish to send to the new hub by highlighting it. And press the "Send" button.
An Address to broadcast window should appear, as can be seen below.
Prometheus 174
Choose the relevant Hub you are sending the Center to in the "Send to HUB" field. Click OK, and
then confirm the "Are you sure to send the message" window which appears, if you are sure of
course. Repeat the process with every Center in the list that needs to be sent. The "Address
Anouncements" section will tell you if you have sent the center to the relevant Hub or not. The
system will send the information via Ester in the form of NEW_ADD messages (described in the
Emdis documentation, available at www.emdis.net). Have your counter part at the other Hub confirm
having received your Centers/Institutions and their addresses.
The new Hub should also send their relevant institution data, make sure this is done successfully.
The failing to do so, may result in message denials.
15.14 User support
User support of the PROMETHEUS system:
Email: emdisadm@steiner.cz
ICQ: 94-597-865
Skype: steinerda
Mobile phone: +420-604487664
Contact persons: David Steiner [david@steiner.cz], Karel Peyerl [peyerl@steiner.cz], Kamil Skala [
skala@steiner.cz], Ariel Steiner [steiner@steiner.cz]
Future developement of system 175
16 Future developement of system
The plans for the future development of the system are following:
Electronic Data Interchange with the donor center (e.g. CSCR-BPK)
Integration with the KBK system
Integration with the Orpheus system (HLA laboratory)
Theory of probabilities at the selection of the donor on the basis of the haplotype frequencies
17 What's new?
What's new section.
This section will be updated with every new version of this manual which will be published. It should
serve to introduce the user to new functions and utilities added to the Prometheus program.
7.05.2010
Interfaces:
Inclusion of exports tab.
Invoices:
Application for creating Invoice data export files
Copy tool:
Copy Tool. For default test database and test database administration.
System parameter settings for automatic triggers.
Attach files to patient records:
The possibility to attach files directly onto the patient's record.
Active Patients Work Panel:
A work panel where the user may view all patient with an "Active" status at any EMDIS HUB
NETCORD Export:
The export function for submitting your CBU data to NETCORD.
Technical changes (version: 2.1.0.131):
Prometheus 176
o Uses HLA Nomenclature Version 3
o File attachments to Patient record
o Possibility to cancel imports.
o Invoices
o Active patients work panel
o HLA Nomenclature version added to system parameters
o Additions to Donrep001:
- DateTimeAdd.
- mobile phone number.
- also CMV status
- day of donation, type of donation
- date when the last typings have been done
- date when first typings have been done
- social security number
- comments, health note, illness note, medication note
- internal, external comments
16.01.2010
Interfaces:
New Prometheus function. Interfaces for the importation of data from other systems.
Storage and Product information system:
A new application for the management of Products and Samples in Store.
Work (production) and Testing Environments:
The setup of test and production environments.
23.11.2009
New Design:
Prometheus has been innovated. The main program window has been redesigned, with intention of
being more intuitive and user friendly to use.
17.08.2009.
Emdis connections:
What's new? 177
A guide to establishing new Emdis connections to other registries.
Typing reports:
A tool for generating and printing typing reports.
22.06.2009.
Blood samples:
The tool for recording Blood samples has been extended to cater for saving multiple samples. You
may now also open a donor using his/her sample number.
Donor cards:
A tool which will automatically generate a printing file for the creation of donor registration cards.
18 Manual revision
2010-01-16
Alterations to the manual corresponding to changes in design (Karel Peyerl)
Interfaces - Exports (Karel Peyerl)
Copy Tool (Karel Peyerl)
File attachment. (Karel Peyerl)
Invoices (Karel Peyerl)
NETCORD export (Karel Peyerl)
Active Patients Work Panel (Karel Peyerl)
2010-01-16
Alterations to the manual corresponding to the new design (Karel Peyerl)
Interfaces (Karel Peyerl)
Storage and Product information system (Karel Peyerl)
Work (production) and Testing Environments. (Karel Peyerl)
2009-11-23
Alterations to the manual corresponding to the new design (Karel Peyerl)
2009-08-17
Emdis connections (Karel Peyerl)
Typing Reports (Karel Peyerl)
2009-06-22
Prometheus 178
What's new? section (Karel Peyerl)
Blood samples (Karel Peyerl)
Donor Registration cards (Karel Peyerl)
2009-04-17
Expansion of the Installation section (Karel Peyerl)
Addition of Data Encryption (Karel Peyerl)
Grammatical Corrections (Karel Peyerl)
User support contacts, update (David Steiner)
2009-01-18
Manual corrections (David Steiner)
2009-01-11
Patient-donor relationships (Kamil Skla)
Alternative match list request (David Steiner)
Internal requests and results (David Steiner)
2008-12-26
System installation (David Steiner)
2008-06-13
English version (Eva vehlov, Libue Kupkov)
2008-04-28
Manual check (Libue Kupkov)
2008-04-15
System administration (David Steiner)
2008-04-11
Quality check (David Steiner)
Changes history (Kamil Skla)
2008-03-24
EMDIS Watch (David Steiner)
Consolidation of the documentations of the BMD system and EMDIS system and transfer to the
system Help & Manual
Change the system name to Prometheus
2007-10-14
Quality check (David Steiner).
2006-11-08
Manual revision 179
Document created (David Steiner).
2006-04-26
Document format according to IP3 and software changes of the BMD system (David Steiner)
EMDIS documentation widened to the documentation of the whole BMD system.
2005-07-14
Donors analysis (David Steiner)
2005-06-05
Document format according to IP1, IP2 and software changes of the BMD system (David Steiner).
2004-03-03
Document created (David Steiner).

BMD en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMD en

Uploaded by

Copyright:

Available Formats

Prometheus

Information system for stem cells donor registries

You might also like