ProjectProposal-RayhanLal
From CS160 User Interfaces Fa06
Contents |
Target User Group and Problem Description
I have volunteered at public hospitals for several years and have been involved in introducing database management systems to track certain patient information. The reliance on paper charts and difficulty in searching these records or accumulating the data from several records is a very real problem. Imagine you are a resident working a 14-hour shift and you get to a patient who needs an anti-inflammatory. You give the patient prednisone, a glucocorticoid. You discover that the patient may have been a diabetic, which can lead to a serious case of hyperglycemia and possible ketoacidosis. You saw many patients that day and don’t quite remember all their names. Rather than check every chart, one can just cross-check diabetes and prednisone for the patients who came in today and if nothing comes up everything is all right. Otherwise, the patient can be called and treated appropriately for the condition. This system is useful for anyone who deals with medical records from clinicians to managers to researchers. Valuable time, energy and perhaps even lives can be saved when records like this can be dynamically searched in a database.
Related Work
When the tablet PC hit the market, it was envisioned that this system might deliver a viable e-charting system. However, physicians who I have worked with find the system bulky and the feel of stylus on tablet awkward. Additionally, providing a tablet for so many individuals would be costly (minimum $700/unit) and replacements or upgrades become quite impractical. By contrast, the Anoto system is an order of magnitude less expensive (for the same number of units). There are two solutions I have encountered that utilize Anoto: NISChart [1] and Satori Labs FusionForm [2]. NISChart seems to have disappeared from the spotlight and I have not seen many new developments. FusionForm Desktop is very close to what I first envisioned. The only issue I have is that it seems expensive and does not provide an ERM (electronic records management) solution. My implementation would integrate a database system, allowing hospitals with no prior electronic record to use the product immediately. Based on preference, old data can be entered manually or new charts can just be created on-demand. Additionally, the whole package would be open-source allowing any hospital to use and modify the code as long as they had the Anoto pen. (It might also be possible to capture physiological data from particular equipment, adding it directly to a record).
Problem Context and Forces
The process starts with the paper; forms are designed on a computer. Using a form explorer tool, rectangular areas are designated for entry of particular data types. A name field would, for example, be designated as an area for character strings. Checkboxes would simply be Boolean areas where any mark would indicate true. With further development, certain areas could contain limited vocabularies (e.g. medications). The hospital already recruits printing companies to deliver their paper charts. There should be no problem adding on the dot pattern. Each form would either have a unique dot pattern or an area to enter which form one is dealing with.
The pen system is ideal because a paper-copy is maintained and only slightly more work is necessary to synchronize this information to the electronic system. Additionally, the pen affords a few modes of output including vibration and status lights. Vibration could signify a patient is recognized by the system and if a streaming system is available this can cause a terminal in the exam room to display the patient’s record. Additionally, stray marks into other fields can be deduced by timestamps and continuity from the main text written in a field. Because each pen has a unique ID, one is immediately aware of which doctor added to a chart and when.
Using an open-source database management system, such as PostgreSQL, would allow unparalleled data management and manipulation. The user-interface will be very important for this part of the system, since we would not expect a general practitioner to be able to write SQL queries. Thus, we must prepare certain common queries in advance. These would include sorting on various fields and performing important calculations. For example, individuals studying epidemiology might like to see what the most common diagnosis was in the last few weeks.
Solution Sketch
The general steps should require a minimum of additional user-interaction while affording the richest possible feature set. Essentially, when someone goes to sign-in, a unique key will be entered into the department’s database. This includes name and medical record number. Any patients registered in this manner are on an active list. Red flags will go up if by the end of a given period this patient is not seen (they might leave AMA – Against Medical Advice). The patient gets off the list when a doctor writes on the patient’s chart and synchronizes this information with the system. We will use an open-source handwriting recognition package to recognize any character or numerical fields on the chart. Because this will simply be a module, it can be replaced by newer, more accurate and perhaps trainable engines. Upon docking, a prompt will display recognized fields and allow for corrections before final commitment to the database. The promise of improved recognition might even encourage doctors to write more legibly.
