Patient demographics form the core of the data for any medical institution. They allow for the identification of a patient and his categorization into categories for the purpose of statistical analysis. In my work I have found that there are more or less 5 different ways of interpreting the term “demographics.”
- Date of birth, gender (Ref: Google Health)
- Birth year, gender, country, postal code, ethnicity, blood type (Ref: Microsoft HealthVault: Personal Demographic Information, Basic Demographic Information)
- (A or B) + Contact information (Name, Phone, Address)
- C + Emergency contact information, family doctor, insurance provider data
- (C or D) + Allergies, major diagnoses, major medical history
When developing a clinical application, ease of integration into existing business processes is paramount. The features implemented by the application are going to dictate how well the application gets received and how it can help or hurt productivity. In this post, I look at how the business processes for patient registration can be best supported by software.
First a look at the process:
From this URN diagram we see that the patient comes in, clerk collects data (sometimes partially), patient gets treated, data intake form is completed if incomplete, quality assurance checks the form to make sure it is really complete, checks to see if it is a duplicate patient and if not everything the chart is stored. The reason for why the intake form is sometimes only partially completed is down to many factors. The most understandable of which is that patients can arrive at hospitals unconscious and are therefore unable to communicate their particulars to the healthcare providers. Other reasons come down to unknown information (such as medications or even something like a postal code) although the patient is conscious or human error.