CHOS-WG Scenario: Patient
identification
Version 0.3, 25 May 2009, Etienne Saliez,
- Introduction:
- Generic scenario dealing with the opening of a patient record,
the very first step is here to retrieve the right patient record.
- Description:
- Retrieving a patient record:
- Search procedure:
- Introduction:
- Since it not known if a record already exist for the
patient,
the first step is always to try to retrieve an archived record.
- In large medical centers of large cities, personal
recognition is no more possible. Be careful, identification imply
responsibilities which may be potentially even more critical
than confidentiality issues.
- Search on a record number:
- If available, a unique record number is in principle the
best solution:
- A number or code pointing exclusively to one unique
patient record.
- A number makes sense in the context of an "Information
Space", which must always be known in an
unambiguous way, e.g. inside a given department of a given hospital,
inside a given hospital, inside the national system of a given country.
- In some systems a patient could have more than one
identifications. As far as pointing to a unique patient several
aliases may exist and could be useful.
- Remark: depending of the cultural environment, some
countries allow or do not allow the use of their national ID number for
medical purposes.
- Moreover in order to reduce the risk of typing error it
is recommended to require to type some redundant check information, as
a check digit and/or initials of first and last name (which oblige
people to read not only the number but also the names).
- If available reading an electronic card.
- However the user is still responsible to check that the
presented card indeed belong to the patient, particularly in case of
children and elderly patients. In countries where some people do
not have any insurance, a card could have been borrowed.
- Search on descriptors:
- Usual descriptors:
- Last name, first name, date of birth, sex.
- The problem is here that none of these descriptors is
unique. The association of these descriptors reduce the risk of
error to a very low level, which in practice is usually accepted
although never perfectly
safe.
- What in case of incomplete information?
- The hight probability level cannot be met, and it
should not be allowed to search in the database. However in order
to avoid to disturb the work, a unique patient ID nr may be created,
but not merged to any preexisting record in the data base.
- In practice a question of policy and a responsibility
of the medical director. Some lazy medical centers retrieve
patient only on a first and a last name. This should be strongly
discouraged and forbidden by the software.
- Candidates retrieved from the database, with a few
additional information:
- If 0 candidate, the patient does not exist in the
database and a new record should be created.
- If 1 or more candidates, look carefully at a few
additional information, as e.g. address, date of latest
contact, etc...
- It is sometimes possible that none of the candidates
would really correspond to the patient arriving at the reception.
Two patient having the same descriptor is never absolutely excluded.
In case of doubt 2 errors are possible:
- To create a second record for the same patient. The
safest attitude because the lack of integration is just a little
annoying and not worse than the old paper based administration.
- To have 2 patients sharing the same
record.
A dangerous risk because information of one patient could be applied
to the other one. For example the blood group of one given to the other.
- Corrections:
- After careful control, it should become possible to
solve problems of temporary record and occasional error, but merge
and unmerge of patient records are here out of the scope of the current
basic
version. A job reserved to a few responsible persons.
- Coming from a choice in a proposed list of patients:
- A short list of patients is proposed. For
example a list of patients having an appointment, or being on the
working list of a lab, etc...
- A click on an entry in such a list, will open the record.
- Validation:
- Anyhow an echo of the full identification of the patient plus
few additional information (address, ..),is presented and
the user is responsible to accept the proposal of the computer.
- If necessary a new patient record is created.
- Administrative information:
- Although not strictly a part of the identification, a set of
administrative information is usually required, as:
- Address, telephone, ...
- Mandate for the Care Team, and who is the main referent
doctor according to the choice of the patient.
- Health insurance information:
- Optionally if the patient agree some family links as
partner, parent, children (NB: remember that the system works primarily
on birth names).
- ...
- Maintenance:
- As long as some information is missing, questions will
appear. Of course when a new record is created, but even later if
not yet available.
- Adaptations can be made at any time if necessary.
Moreover maybe after a predefined delay, a reminder asking to confirm
that the information is still valid.
- Identification document:
- The patient should be recommended to carry a medical
identification document.
- If no such document is available nor some kind of official
Social Security card, a card should be given to the patient.
A
simple approach is to print a label and to set it on a small card with
the address of the organization. The patient number is unique
inside the organization, i.e. the "information space".
This label could contain a few more practical information, as full
names, address, insurance, referent doctor, ...
- Result:
- So far we have a valid patient identification from an
administrative point of view, but not yet the next steps as:
- To check the authorization to access the medical content of
the record : Access-Control.html .
- To activate to medical software components.
- Required resources:
- A user session must be open.
- PatientID Class
- ...