Project PANACEA
<![CDATA[
EUREKA FUNDED PROGRAMME
PROJECT DESCRIPTION
PANACEA Consortium
August 1994
AGENDA
SECTION 1 PROJECT INTRODUCTION
SECTION 2 COMMUNICATING THE ELECTRONIC PATIENT RECORD
SECTION 3 PATIENT DATA CARDS - ROLE AND STATUS
Role of the PDC
Current Status
User Requirements
Smartcard Technology
What is a universal interface?
SECTION 4 PANACEA PDC INFRASTRUCTURE
Data Structures
Security
Interface to healthcare applications
SECTION 5 PROJECT DELIVERABLES
Document Summary
This document describes the background to Project PANACEA and the
planned deliverables. The content is designed to be used within the
Project Initiation Document (PID) and as a detailed project
description for external and internal communications.
Version 1.0
9 July 1994
SECTION 1 PROJECT INTRODUCTION
A patient held electronic medical record that is both dynamic and
evolutionary, accessible wherever care is provided, has been projected
as part of future healthcare services in most western countries,
including the UK. For almost ten years, there have been a succession
of trials of such a record based on portable electronic devices, such
as smartcards or memory cards, which whilst highlighting both
potential benefits and pitfalls has not yet led to any wide scale
usage.
The PANACEA project is not another such trial, but focuses on removing
one of the major barriers to the successful use of a patient held
medical record. Its principal delivery is an open software
infrastructure that can integrate into individual health services
information system strategies providing a seamless view of the
electronic patient record, no matter where the data is held.
Project PANACEA will develop this software infrastructure and then
test its acceptability both from a technical and clinical (user) view
in two locations: Exeter, Devon and Lisbon, Portugal.
This will involve the integration of the software infrastructure with
a number of existing and planned healthcare applications. Part of the
piloting process will involve the use of mobile computer systems
within a community healthcare environment.
The advances this project will bring include:
Universal/open format for communicating the complete medical
record between incompatible application systems based on Read 3
clinical coding structure
Use of mobile computers in a remote clinical application
Greater synchronisation of medical information between
different computing systems and services
Providing a solution to the problems of patient record access
within community care
The expected success of the project is based on the experience of the
PANACEA consortium that combines healthcare, academic, industry,
consultancy and government backing.
The prime partner is the University of Exeter that has pioneered many
developments in the areas of primary care and electronic records, in
addition to providing local management for one of the most successful
pilots of patient held records in Europe - The Care Card.
Bull Information Systems, and its sister company Bull CP8, have led
the development of smartcard technology for over a decade, and has
extensive experience in designing and advancing the introduction of
patient held records, and in the integration of healthcare
applications.
Exeter and District Community Health Service NHS Trust who will trial
the software infrastructure within their mental health services,
backed by their application systems suppliers.
Abies Medical Information Systems who have extensive experience in
developing clinical based applications and integration with patient
held records.
F7 Consultoria em Systema of Portugal who provide consultancy services
to the Portuguese health service, and who will both provide
application products and services to the Lisbon trial of the
infrastructure.
The project is based on several man years of international design on
the requirements of a portable electronic patient held record and
software infrastructure, and on the experienced gained from several of
the major international implementations of the technology throughout
Europe.
As a EUREKA funded project, the UK implementation is supported by the
Department of Trade and Industry.
SECTION 2 COMMUNICATING THE ELECTRONIC PATIENT RECORD
In today's health service, medical information concerning the patient
is scattered and uncoordinated between information systems used by the
different parts of the service.
Hospital systems (e.g. Patient Management, Ward Systems etc.) hold
details on the patient that relate to specific inpatient or outpatient
care. The Laboratory system holds details of test results, various
Community agency systems hold details specific to their focus, some
pharmacy systems hold details on medication dispensed and General
Practitioner systems typically hold comprehensive detailed summaries
pertaining to their direct knowledge of patient conditions, diagnosis
and treatment programmes.
The problem is that even in the most computerised environment, the
electronic patient record is dispersed and uncoordinated over a wide
range of incompatible systems such that no one clinician has access to
all the pertinent parts of the record. Often data is incomplete or
worst, out-of date. This leads to uncoordinated requests for
information, and care based on partial data.
To communicate medical data between two or more healthcare
professionals, several communication methods are used: Post,
telephone, electronic mail and facsimile. However, except for the
telephone, all other communication methods are not synchronised with
the movement of the patient. When a patient is referred to a
hospital, or discharged from hospital, the information that is
communicated between secondary and primary care is based on known data
a point in time. It does not take into account any treatment or
diagnosis that may take place between the communicating of the
information and the next time the patient comes in contact with the
carer receiving the communication.
In England, the NHS plan to install a nation wide network that will
allow all information systems to communicate with each other using
national and international standard messages. This will certainly
enhance the current environment. Unless, however, all information
systems are enhanced so that they can interrogate each other's
databases, or all the existing systems in use are replaced with
equivalent systems that are both compatible and capable of sharing
information across the network in real-time, then the information gap
will continue. This is because of the potentially unpredictable
movement of the patient. Acute hospitals are starting to move in this
direction through the centrally co-ordinated HISS programmes. But to
expand this programme to include all aspects of primary care and the
many community agencies is today thought to be too big a challenge.
The patient held record represents the key to both synchronisation of
data and catering for patient movement. It does not replace a
national network, but complements it.
Each time that a patient receives care, the card is used to update the
local healthcare professional's information with data collected since
the last contact, and act as a communication media for new information
associated with this treatment/diagnosis/ investigation. The
professional does not need to predict who will next require access to
the new information, but by adding it to the portable record, can be
assured that it will be available at the point of patient contact.
Current communication of discharge reports, laboratory test results
and radiology reports between hospitals and GPs will still be required
to provide the relevant healthcare professional with information in
advance of the next patient contact. The card simply fills the
information gap.
SECTION 3 PATIENT DATA CARDS - ROLE AND STATUS
3.1 Role of the Patient Data Card
The patient held record or, as it is most commonly known, the Patient
Data Card (PDC) has three roles:
To provide an effective identification of the patient. When
the card is submitted to an information system it provides patient
identification details that will allow the system to correctly match
the patient with its local data.
To synchronise data between incompatible and dispersed
information databases.
To provide mobile information systems, such as hand held
computers, with access to the patient record. i.e. for domiciliary
visits.
It can contain the full range of patient data including:
Identification and other demographic information
Medication details (+ prescription and dispensing details)
Emergency details
Diagnosis and treatment summaries
Test results and potentially images
3.2 Current status of PDCs
As was indicated earlier, since 1985 when the first PDC implementation
took place in the French town of Blois with Carte Santé, there have
been many trials but no national implementation.
Pilot implementations have typically been based on either:
a dedicated application that reads and displays the data
to/from the card
a front end application that read the card and then passed it
to a healthcare application
integration of the card with a single application.
Whilst each trial showed that the smartcard or memory card technology was:
capable of holding the data required
robust enough to be carried by the patient, and
that there were benefits or potential benefits in the use of
the technology
The implementation method chosen limited the potential for rolling out
on a wider scale. The obvious draw back in each of the above
implementation methods being:
If a dedicated application that simply managed the card as a
separate database, it would not be either financially or operationally
viable to have an additional system at each point of care just to
handle the PDC. Such an environment would add to the clinician's
workload without providing any long term answer.
If a front end application, then the cost of having additional
hardware and software combined with the integration with existing
systems would make the solution on a large scale financially a non
starter.
If PDC support only came with a dedicated clinical application
then this would need to be installed at each point of care - again, it
would not make financial sense.
It can easily be seen that the only practical solution to the use of
PDCs would be if any existing application could easily, and at a low
cost, access the card as though it was another local database. Much
as in the same way most healthcare applications can support some level
of data communications.
In the UK there are still a number of small trials either starting up,
as in Aberdeen in Scotland, or continuing as in the Care Card, but no
plans for any wide scale or national use. As the cost of integration
with existing systems is prohibiting individual health authorities
taking local initiatives, PDCs will probably not progress any further.
The only way that the PDC will start to be used is if a software
infrastructure is put in place, where existing systems can be easily
and at a low cost, adapted to integrate the portable record, where all
the inhibitors are addressed so allowing for local implementations
that can naturally progress to a national or regional scheme.
This is the heart of project PANACEA. The software infrastructure
being EuroCare.
3.3 User Requirements
In understanding what are the barriers that have held back the
introduction of PDCs, it is first important to recognise what is
required for a successful implementation. The criteria for success:
(1) Patients must carry them
Unless the patient carries the card with them at all times, then it
will provide only part information. If this becomes a common
situation, then the value of the PDC will be considerably reduced.
(2) Professionals must use them
If the professional does not ask for the card at the start of each
consultation, then once again only part information will be contained
on the portable record.
(3) No conflict with National Government Initiatives
Any Patient Data Card system introduced must not be in conflict with
the national strategies and initiatives, for example, in the UK with
the Community Information System for Providers (CISP) programme. If
it did, then it would be difficult for individual hospital units and
other healthcare agencies to justify the required budgets for
implementation.
(4) Must be a cost benefit
There has to be a tangible cost benefit before such as system could be
introduced.
Looking at each of these four criteria for success in more detail:
- Patients must carry them
Experiences from existing PDC systems throughout Europe show that
Patients will carry the card if they perceive a benefit. High card
carrying rates were identified where the patients felt that the card
was actually contributing to a better service from healthcare
providers. This belief most often occurred when the patients' could
visibly see the card being used, and where there had been a programme
of patient education.
Simply stated, patients carried the cards when they believed that the
healthcare professional that they come in contact with actually
requires the card as part of the process of care.
- Professionals must use them
Experience has shown that professionals ask for and use PDCs when they
perceive a benefit.
Whilst it is easier to introduce a patient data card where there is
only limited existing information systems in place, except for care
away from the normal healthcare base, without such an infrastructure
there is little purpose for the portable record in shared care. A key
factor for success is, therefore, that the use of the card must not
create any additional processes for the professional. So, for those
General Practitioners, for example, that have implemented information
systems that are patient/person focused, the PDC must be directly
accessed by the existing system, appearing almost completely
transparent to the user. The two separate patient records must appear
as one to the user.
- No conflict with National Government Initiatives
The PDC needs to integrate with the existing systems and IT strategy.
Within the English NHS, this means integration with the various
central initiatives, whilst supporting the standards that are being
introduced under the IM&T Strategy. It must also take into account
the key ethical and data protection issues.
Costs in developing a truly universal PDC software interface that can
interact with many different healthcare systems have previously been
underestimated. Because of this there has been a gap between the
potential PDC off-the-shelf applications and user requirements.
- Cost Benefits
The most difficult criteria for success with PDCs are that they must
be seen to be providing cost benefits. Most trails and initial
implementations have shown potential cost savings in areas such as
reduced administrative tasks, medication prescribed and
investigations, however, the size of trail with limited patient
coverage has meant that the findings could not be easily translated
into tangible cost savings.
Where the patient data cards are used by specific patient groups that
require either concentrated or prolonged periods of care such as in
child health, metal health, diabetic care or care of the elderly, it
is easier to identify the cost benefits.
3.4 International Requirements
In addition to the requirements described above for a successful
implementation, there are a number of necessary additional facilities
identified if a PDC infrastructure was to be country independent.
Language independent
The data held on the PDC should be language independent, so
that when a patient travels between locations where the main
communicating language changes it should be possible for the data to
be transferred to the local application in that language.
Supports national security/data protection/legal requirements
Each country has differences in what medical information can
be accessed and by whom. The infrastructure must allow for local
rules/regulations to be applied in a way that when the patient travels
to a different country the then local rules/regulations would apply.
Coding system independent
Not all countries utilise the same coding/classification
standards. The data held on the card must be coding system
independent so that when it is read by any one application the data is
transferred from (and to) the card utilising in a form acceptable to
the local system.
Technology supplier independent
The infrastructure must be independent of technology and
supplier, i.e. Open, if it to be acceptable to any agency that wishes
to utilise it.
3.5 Smartcard Technology
The technology requirements for a patient data card can be summarised as:
Durable, as it will be treated similarly to any other piece of
plastic card;
Large enough memory capacity to hold a patient medical and
administrative data
Is secure from unauthorised access to the medical data
Quality look and feel
The smartcard, or Integrated Circuit Card (ICCard), and to a lesser
degree, the Memory Card can satisfy these needs.
An IC Card is a single piece of silicon to ISO standards for bank
cards in terms of size and flex. Into the plastic is embedded a
single chip microcomputer, as the diagram shows below.
With the advanced in IC Card technology, there should be no
restrictions on what data can be recorded on the card. If efficiently
recorded, today's cards can hold up to 50 A4 pages of information.
And as most medical data held on the smartcard is typically coded
(e.g. utilising the Read Clinical Classification codes in the UK),
today's technology is capable of holding an average patient's history
for up to 10 years.
Although the plan is for the EuroCare software infrastructure to
support other card technologies, the initial development will
concentrate on the IC Card.
The self programmable one chip microcomputer (SPOM) embedded into the
ISO standard plastic card is comprised of a Read Only Memory (ROM)
that contains the IC Cards operating system, a RAM which is used as
working memory, an EPROM or EEPROM memory that contains the medical
record and an 8 bit central processing unit.
The core of the card is made from white PVC which is then covered on
both sides by a thin film of transparent PVC. This allows the support
of all the physical aspects of the international standards and
embossing of the card.
The IC Card represents an ideal medium for storing patient related
information because of its inherent security architecture and design.
Maximum security is provided through the physical and logical
specifications of the chip and the manufacturing process.
Inviolability and fraudulent copying are guarded against by the use of
FAMOS technology with buried layers of non erasable memories able to
withstand magnetic and electro-magnetic fields, X-rays or ultra violet
rays.
The operating system that is etched into the Read Only Memory during
the chip manufacturing process determines the IC Card's capabilities
and security controls. The only external access to the micro chip is
via the central processor unit and hence the operating system.
The secure operating system controls all access to the memories
including the patient data, as wells as managing the structure of that
data and all external behaviour. The operating system supported is
based on ISO recommendations and supports a hierarchical filing system
which is ideally suited for the PDC application. Each level has its
own security controls based on a sophisticated access control and
authentication system. IC Card Data Files
To read or write to the cards data files, the card first checks that
the request has come from an authorised individual by the submission
of security keys. These keys also determine what data the requester
has the right to access. If there is any attempt to "hack" the card
it will automatically lock itself from further access and require to
be unlocked by an authorised body, typically with a PDC the patient's
GP. In the diagram above, one data file contains the medical record,
divided into a number of sub files that contain groups of information.
The "other data" is clinical based information that would only be
accessible by clinicians.
If there is an attempt to penetrate the cards memory through any
physical attack the card will immobilise its security files, and
depending on the type of attack, may become permanently inaccessible.
In addition the protection from external environments, the microchip
is contained within a well of resin that allows the plastic card to be
bent and twisted in line with ISO standards without any damage. It is
therefore well suited to being carried and stored in the same way as
other plastic cards.
3.6 What is a universal interface?
The software infrastructure at the heart of project PANACEA is a
universal interface, known as EuroCare, designed in a number of
discrete layers. Acting as the translator between the card and the
application, it is designed to be linked into existing healthcare
information systems whilst accessing any PDC which could be based on
one or more technologies (IC Card, Memory Card, ISTN etc). It is
designed in such a way that it can reside on any host utilising any
operating system, the only limitations being the requirement to first
have the interface ported to the particular host environment, and the
external connection of an intelligent card reader using an RS232
interface.
SECTION 4 PANACEA PDC INFRASTRUCTURE
This section describes the EuroCare interface, the security
architecture, data structures, the application interface and how it
will typically be linked to healthcare applications.
The main functions of EuroCare interface are:
Takes data from application and writes to card in common
compacted form
Reads data from card decompacts, and passes to application
Manages access rights and general security
Translates data from card into free text or other coding
Translates data from application into common codes
Manages physical and logical card interfaces
4.1 EuroCare architecture
The EuroCare interface is divided into four main sections, the
Application Interface, the Card Driver, the Translation Layer and the
Card Interface Layer.
Application Interface
This interfaces with the existing healthcare application by
providing a series of commands which can be called to carry out
specific patient data card and host functions. Validation is carried
out on the command requests and data received before the command is
executed by calling the relevant functions supplied by the Card
Driver.
Translation Layer
This will be, in effect, a library of functions which can
optionally translate the data and clinical codes on the card into
other application specific codes.
Card Driver
The Card Driver will contain those functions which call the
Card Interface Layer. These functions may not always be those which
the application is aware of, as one command issued by the application
could equate to several actual functions. Once the function(s) to be
carried out is determined, the command(s) and data are sent to the
Card Interface Layer. All communications with the Card Interface Layer
are managed within the Card Driver.
Card Interface Layer
This resides on the intelligent IC Card readers, interfacing
directly with the cards. An objective of implementing as much code
onto the Intelligent IC card reader as possible is that the more code
which can be stored on the Intelligent IC card readers, so making it
easier to port the system to different host operating systems. The
Card Interface Layer contains the security controls, compaction and
decompaction of data, record management and physical interface with
the IC Card (or other card technology).
A more detailed description of the functions of the layers of
the interface is included within the following subsections.
4.2 Data Structures
The data storage has been designed for multilingual support, therefore
all of the data on the card which can be stored using recognised
coding systems uses them including ISO standards for data definitions.
A brief description of the data which is stored on the cards is given
below.
i) General Information about the patient.
ii) A subset of the patient's medical record including all historic
data which would be relevant to any future treatment.
iii) Medication and Emergency information. This will allow the card
to be used during or for the dispensing of drugs. A doctor would write
the prescription to the card, the patient would give take their card
to a pharmacy who would use the card to dispense the medication.
After the medication is dispensed information is written to the card
to show this.
The data structures used within the patient data card, and in
communicating with the healthcare application, have been designed to
be very flexible in order to allow the system to store further
information which may be required in the future, for example
costing/contract related details.
As far as the application developer is concerned, there are four data
files with different levels of security and each is stored in one of
the four WZs (Working Zones). The contents of these different files
are :-
WZ 1 - Administrative
Identification of the patient
Registration details
Notes
Special Records
Extension Records
WZ 2 - Emergency data and medication
Notes
Special records
Extension records
WZ 3 - Other data (main clinical record, test results, observations etc)
Notes
Special records
Extension records
WZ 4 - Tables
Site table
Author table
Deletion table
Record Table
The tables defined above in WZ 4 are used within the PDC to minimise
space taken and to provide a form of audit trail. It is necessary to
identify against each data item written to the card who was the author
of the information (normally a healthcare professional), from which
site and from which system the data was transferred. On the card,
therefore, this information is stored in tables and indexed to the
individual data items. The deletion table identified data items that
have been designated as deleted and no longer valid. The record table
allows data items to be linked together in the form of relationships
such as a Care Plan.
An author table entry is unique for an individual and each individual
should usually only have a single entry in the table. However,
occasionally a health professional may have more than one identifier
on account of different posts in different locations, for example a GP
who also attends his/her local community hospital.
A site table is unique for each separate application database (e.g. a
PAS). Two application databases should be defined as separate if they
are not updated by each other in real time. In this context if a
change made after reading a card or making a manual entry on one
application is not immediately resolved with the other application,
they are separate. Usually each computer will have a different
identifier unless the card based functions act directly on a common
file server or network. Where departments keep separate databases on
the same multipurpose computer, the application itself will need a
separate identifier. This way the issue of synchronisation of data
can be fully addressed.
The data formats used in the card are not seen by any external
application and are used to provide the maximum flexibility with
efficiency of storage. The data structures passed between the
Interface and the healthcare application represent the external view
of the card and it is therefore these that are described below. The
data structure used by EuroCare have been designed to be flexible
enough to interface to any general healthcare application.
There are four types of data structures used in the interface -
Primitive, Major, Extension and Special.
The primitive data structures are component parts of the major and
extension data structure and therefore will not be passed across the
interface as records in their own right. Examples of these include,
identity of author, date, patient name, post code in an address, and
dosage on a medication request.
The major data structures are the five main record typess which exist
in EuroCare. Every time an update is made to the patient's card, it
will consist of at least one of these records.
IDENTIFICATION
REGISTISTRATION
NOTE EVENT*
PRESCRIPTION EVENT
EXTRA (general)
*Examples of a Note Event record include: general clinical record,
medication details, sensitivities, administrative associated with
medical history, family history details, past history details,
possible diagnosis, confirmed diagnosis, planned activity, carried out
activity.
At the time that the identification record is written to the patient
card (i.e. on issue), there is some additional data which must also be
written. The first site and author table entries must be written as
these entries define who issued the card and where it was issued.
Additionally, the site country and site region fields of the first
entry in the site table define the validity of any Extra records which
are specific to Country or region.
This record can never be deleted. Any required change to this record
would require a new card to be issued.
There may be any number of NoteEvent records within the EuroCare
ADF. These records may be in WZ 1, 2 or 3 according to the required
level of access protection.
Other records may be associated with the NoteEvent record either by
physical location or by reference to the record handle of the
NoteEvent (i.e. its WZ number and record number). By this means it is
possible to string a number of records together as an episode of care
or care plan.
The NoteEvent record can be explicitly deleted and is never implicitly
deleted (by a later NoteEvent). Changes cannot be made except by
deleting the record and creating a new record which includes the
changes details. Any extension records associated with the NoteEvent
record are deleted (by the interface) when it is deleted.
The Extra record forms a header identifying additional records which
do not form extensions to the preceding NoteEvent record. Any number
of extra records may exist in WZs 1, 2 and 3.
The Extra record is followed by a number of general extensions which
contain the data specified by the Extra record. There is no validation
of the ordering of this data, so this allows extensions to be defined
without impacting the interface software.
Applications which do not recognise the Extra record will ignore its
data content after a read rather than reporting any errors. The
interface should refuse to pass through any Extra records on a write
which are national, regional or local unless the issuing nation,
region or local application of the card (as found in the first site
record of the site table) matches that of the current application (as
found in the Extra record) at the appropriate level.
The extension data structures are used to provide a high degree of
flexibility in what is written to the patients card. These records are
'appended' to one of the major records to enhance its meaning or to
provide any extra information which the application feels is
appropriate. Any number of extension records could be 'appended' to a
major record. However, extension records only have a meaning in the
context of the major record to which they are attached and therefore
these records cannot be written to or read from the card on their
own. When a major record is passed across the interface, all it's
extension records will automatically follow it and likewise, when a
major record is written to the card, any associated extension records
must be written immediately afterwards.
Examples of extension records are:
MEDICAL AUTHORITY
INTEGER
DOSAGE
FREE TEXT
NUMERIC DATA
FINANCIAL DATA
AUTHOR SITE DETAILS
EXTENDED NAME
EXTENDED ADDRESS
DATE
TIME
The special data structure is the end session record. This record is
written automatically by the EuroCare Interface to the card in any
data zones which have been changed when the Close card command is
carried out. It therefore can never be written by the application but
can be returned with all the other records after a read command.
The nature of the data structures chosen means that it is not possible
to know how many records or what type of records, will be returned by
the EuroCare Interface after the execution of a "Read card"
command. Therefore a dynamic list is used to pass records back from
the Interface which can hold a variable number of records of diverse
types.
4.3 Security
Access rights for health professionals will be controlled by issuing
them with keycards (IC Cards). These keycards are set up with
different levels of security for the different types of health
professional so that the working zones (WZs) which a health
professional can access can be restricted. In order for a health
professional to access a patient's card they must use their keycard in
conjunction with a password. This ensures that keycards which are lost
or stolen cannot be used by anyone else. All cards become 'blocked' or
unusable after the entry of a pre-defined number of wrong
passwords. This situation can only be reversed by someone with the
necessary authority.
All the security features listed above are provided by the EUROCARE
INTERFACE. As far as possible these are implemented using the cards
built in security mechanism, where this is not sufficient the security
will be handled by the software which is burnt into the Intelligent IC
card readers ROM.
There are several aspects to the security of the EuroCare interface :
i) Preventing access by unauthorised personnel to the information
stored on the card.
ii) Restricting the access of authorised personnel to only those
records which they have authority to access.
iii) Ensuring that all records have an associated Author and site
reference, so that it is possible to track who wrote which information
to the card.
iv) Restricting the issue of patient cards.
v) Restricting the issue of keycards (held by the Healthcare
Professional).
vi) Ensuring that the issue and use of keycards and patient
cards allows for different versions of keycards. For example, a
version 1 keycard will not be able to access version 2 patient
cards. This will provide an added level of security.
During the first access to the system for the day the health
professional must place their card into a card reader. The
application will then prompt them to enter their password. Once this
has been done patient cards can be read and written to within the
constraints of the security level of the health professional's card.
In many countries it is important to allow the patients to view their
own medical records easily. This is both to meet the Data Protection
Act and to help the acceptance of the system.
To allow for this all the data on the card can be read by its owner on
entering their card's PIN. It is envisaged that the application
developers will provide a separate system to do this, i.e. it would
not normally be a function of the health professional's system.
4.4 Interface to healthcare applications
The application Interface receives requests from the application. The
processing here will include data validation and determining which
lower level function calls are required.
Commands will be implemented as a set of procedure calls which are
accessible to developers using any language which allows the calling
of external procedures in linked C library format.
Other applications (which cannot link to C libraries) will pass
commands via a pipe or files. This would work by using an application
which will accept the commands and data through a pipe or file, then
calling the EuroCare interface commands in the normal way with the
data. This would be the responsibility of the calling application and
is not a part of the EuroCare Interface.
Commands include:
Check for card presence
Open Card
Check Patient card
(Patient) View card
Key card
Enter PIN
Issue new Patient Card
Read card
Add record
Delete record
Close card
Example of effect of Open Card command..
Interface will...
Check if card is a patient card, unblock card if blocked (PIN),
Read identification record, card version number, issue number and update
number
Checks that version number matches interface version,
patient card authenticates keycard and visa versa, returns identity
record to application.
SECTION 5 PROJECT DELIVERABLES
The main project deliverables will be:
i) EuroCare interface
ii) Interface integrated with a number of healthcare applications
iii) A mobile workstation with direct access to patient record (via PDC)
iv) Reports on the success of the trial.
Project PANACEA Overview
Version 1.0
]]>
Comments to Dr Robin Hopkins at
<100340.2104@compuserve.com>