Table of Contents

<texit info> author=Bent Bisballe Nyeng (deva@aasimon.org) title=The Pentominos Patient Registration System </texit>

The Pentominos Patient Registration System

The patient registration system handles the pairing of a patient, an operator and an apparatus at a given location at a given time interval.
This is necessary in order to correctly store the produced data in a way that makes it possible to retrieve it at a later point in time, for further analysis.
The system consists of five basic units:

  1. A system A is used by a nurse that binds the patient with an UID, for the day.
  2. The Pidio1) client that retrieves UID from an external reader, and sends it to the Pidiod server, together with its location ID.
  3. The Pidiod2) server that:
    • Handles the maps between UID to patient ID.
    • Handles the maps between location ID to UID.
  4. The Feed3) data retrieval client that makes the actual apparatus communication.
  5. The Artefact data server.

Systems overview diagram. Arrows indicate data transmission/sharing.

The system works in the following steps:

What is already there

Currently we have a running implementation of all systems but A (hence the non-name). The current implementation of Pidio utilizes a simple numerical keyboard and a magnetic strip reader, for danish health insurance card.
To improve simplicity on the system, no identification is currently made of the operator (this is at the time being not mission critical data, but must be added at a later point due to documentation procedures) The numerical keyboard and a magnetic strip reader Documentation of all communication protocols between the systems exists but are not yet written in a formal way. These documents will be produced A.S.A.P.

What needs to be made

We suggest that a new Pidio implementation is created based on the RFID technology, reusing the rest of the patient registration system.
In order to make it more 'sexy' it is essential that the reader itself is given a sturdy look-and-feel design.
The application A must be designed as a GUI application (and named properly) and implemented at least as a working prototype.

1)
PatientID Input Output
2)
PatientID Input Output Daemon
3)
Feed Extravagates External Devices