Medical history questionnaire digitization turns each answer on a paper health history into a stored value: conditions, surgeries, medications, allergies, family history and social history. Yes and no questions keep three states, yes, no and unanswered. Medication and allergy lists become rows. Narrative answers stay as free text, linked to the page, for a clinician to read.
Medical history questionnaire sections to structure
Medical history questionnaire sections to structure usually follow the paper form's own order: past conditions, past surgeries and hospital stays, current medications, allergies, family history and social history. Each section has a different shape, so each needs its own kind of field rather than one long list of answers.
The health history part of an intake packet is the set of pages where patients describe their past care and current health. What those pages typically ask is laid out in the guide to what the health history part of an intake form covers. This post is about storing the answers once they are read.
A useful first step is to sort every question on the form into one of four shapes:
- Yes or no questions. "Have you ever had high blood pressure?" Each becomes one field with three possible values.
- Lists. "List your current medications." Each item becomes a row with several fields of its own.
- Short facts. "Year of last tetanus shot." Each becomes one typed field, such as a year or a number.
- Narratives. "Describe any other health concerns." Each stays as text.
Short facts need a type, and the type should allow for how patients actually answer. A field typed as a four-digit year will reject "2015?" or "not sure," yet both are real answers. Store the text as written in one field and a cleaned value in another only when the text is clear. A blank cleaned value next to "not sure" tells the reader more than a forced guess.
Social history deserves its own look because its answers are often ranges or habits rather than facts. Tobacco, alcohol, exercise and occupation questions come back as "a pack a week," "weekends," "some" or a checked box beside a printed range. Where the form prints ranges, store the range the patient chose. Where the patient wrote words, keep the words.
Sections often mix shapes. A surgery section may ask "Have you had any surgeries?" as a yes or no question and then give lines to list them. Store both. The yes or no answer tells you the patient responded to the question. The list tells you what they wrote. A patient who checks yes and writes nothing has given a different answer from one who leaves both blank.
A data model sketch for one questionnaire
The sketch below shows how one fictional patient's history pages might be stored. The patient, the answers and the field names are examples only, and the structure is one reasonable choice, not a standard.
questionnaire:
form_code: "HX-EN-v2" # example form version
patient: "Example patient: Rowan Ellery (fictional)"
conditions:
- question: "High blood pressure"
answer: yes
- question: "Diabetes"
answer: no
- question: "Asthma"
answer: unanswered # both boxes left blank
- question: "Thyroid disease"
answer: unclear # sent to a reviewer
surgeries:
any_surgeries: yes
items:
- text: "appendix out"
year_written: "2009"
- text: "knee scope"
year_written: "about 5 yrs ago" # kept as written
medications:
- name_written: "lisinopril"
strength_written: "10 mg"
frequency_written: "1 a day"
- name_written: "vitamin D"
strength_written: "" # left blank by patient
frequency_written: "daily"
allergies:
no_known_allergies_box: unchecked
items:
- substance_written: "penicillin"
reaction_written: "rash"
family_history:
- relative: "mother"
condition_written: "breast cancer"
social_history:
tobacco: no
alcohol_written: "socially"
other_concerns_text: "trouble sleeping since spring"
Every value keeps the patient's own wording. Nothing has been turned into a code. Each field would also carry a link to its spot on the scanned page, so a reader can check the original in one step.
How should yes and no history questions be stored?
Yes and no history questions should be stored with at least three values: yes, no and unanswered. Collapsing a blank into "no" records an answer the patient did not give. A fourth value, unclear, is worth keeping for marks a reviewer could not decide, so they can be asked again.
Paper history forms often print a row of conditions with a yes box and a no box for each. Patients fill these unevenly. Some check every box carefully. Some check only the yes boxes and leave the rest blank. Some skip a whole column when they reach the bottom of the page. Each pattern means something different, and a two-value field erases the difference.
The four values and what each means:
- Yes: the yes box is marked and the no box is empty.
- No: the no box is marked and the yes box is empty.
- Unanswered: both boxes are empty.
- Unclear: both boxes are marked, or a mark could not be read. A person decides or asks the patient.
Forms with only a single box per condition, "check any that apply," are harder. An empty box there could mean no, or it could mean the patient skipped the row. The stored value should say "not checked" rather than "no," so nobody reads more certainty into it than the form collected.
The same three-state logic applies to consent boxes on the same packet, where the cost of guessing is higher. The guide to reading consent checkboxes and signatures on intake forms explains how ambiguous boxes get handled.
Mark the patient's choice in the record, not a summary of it. A field that says "yes" next to "High blood pressure" records what the patient reported. It does not say that the patient has the condition. That distinction matters to the clinician who reads it later.
Medication and allergy lists on history questionnaires
Medication and allergy lists on history questionnaires are handwritten free-text lists, and they are the hardest part of the history to digitize. Each line can hold a drug name, a strength, a frequency and sometimes a reason, written in any order. Store each line as a row, keep each part as written, and send unclear lines to a person.
Medication lists bring several reading problems at once. Drug names are long, unfamiliar to general spelling checks, and often abbreviated. Patients write brand names, generic names and nicknames. Strengths mix numbers and units, and a handwritten "0.5 mg" can lose its decimal point. Frequencies come in many forms: "twice a day," "BID," "2x," "morning and night."
A row per medication works better than one long text field. Useful parts for each row are:
- Name as written. The exact text the patient wrote.
- Strength as written. Number and unit together, such as "10 mg".
- Frequency as written. The patient's own words.
- Line confidence. How sure the software is of the whole line.
- Page link. Where the line sits on the scan.
Keeping each part "as written" is the safe choice for intake. Matching a handwritten name to a standard drug vocabulary is a later step that needs care and review, and it belongs to the clinical records work covered in the clinical records category.
Allergy lists follow the same pattern with fewer parts: the substance and, where the patient wrote one, the reaction. One extra field matters a great deal here. Many forms have a "No known allergies" box. Its value must be stored separately from the list. A checked box with an empty list means the patient reported no allergies. An unchecked box with an empty list means the patient did not answer.
Watch for lists that run off the lines. Patients with many medications write in the margins, on the back, or on a separate sheet stapled behind. A digitization step that reads only the printed lines will miss them. Any page that has writing outside the expected fields is worth a reviewer's look.
Who checks a digitized medical history questionnaire?
A digitized medical history questionnaire is checked in two different ways by two different people. A reviewer checks that each extracted value matches what the patient wrote. A clinician then reads the answers and decides what they mean for care. Software reads the marks and the words. It does not interpret them.
The first check is about transcription. Did the software read "lisinopril" correctly? Is that a yes box or a no box? Did it catch the allergy written in the margin? This check can be done by trained staff who compare each uncertain field against the page. On Schema Care, a history field read below the customer's confidence threshold is held for this check with the answer highlighted on the scan, and the reviewer's correction is recorded with their name and the time. The review workflow on the Schema Care homepage walks through it.
The second check is clinical. A patient who checked yes for heart disease, listed a blood thinner and wrote "stent 2019" under surgeries has told a story a clinician needs to read as a whole. Deciding what that story means, whether it is complete, and what to ask next is a clinical judgment. It is not part of digitization, and software should not attempt it.
Keeping the two checks separate protects both. Transcription reviewers are not asked to make medical decisions. Clinicians are not asked to hunt through scans for misread boxes. And the record shows clearly what the patient said, what the software read, who corrected it, and who reviewed it clinically.
A practical sign that the line is being crossed is a step that turns answers into conclusions. A workflow that flags "patient is diabetic" from a checked box has moved from recording to interpreting. The safer wording is "patient reported diabetes: yes."
History questionnaire answers that should stay free text
History questionnaire answers that should stay free text are the ones where forcing a code would change or lose what the patient meant. Vague dates, family stories, symptoms in the patient's own words and "other" answers all belong here. Store them as text with a link to the page, and let a clinician read them.
There is a strong pull to turn every answer into a code, because coded data is easy to search and count. On a patient-reported history, that pull does harm when the answer was never precise in the first place.
Answers to leave as text include:
- Vague dates. "A few years ago" or "when I was a kid" should not become a specific year.
- Uncertain conditions. "Doctor said something about my heart" is not a diagnosis and should not be coded as one.
- Family history stories. "Dad's side, lots of heart trouble" holds information a clinician can use but no single relative or condition to code.
- Other and comments boxes. These catch whatever the form did not ask, by definition.
- Symptoms in the patient's words. "Tired all the time" carries meaning that a code for fatigue may not.
- Social history details. "Socially" for alcohol, or "quit a while back" for smoking, are answers, not measurements.
Free text still needs care. It should be read by OCR so it is searchable, checked by a reviewer if the reading is poor, and kept beside the image so the original can always be seen.
When a history form has many narrative answers that the practice wishes were structured, the fix is on the form, not in the data. Replacing an open question with a list of checkboxes collects structured answers at the source. Whether to do that on paper or move the history to a digital form is the subject of paper vs digital intake forms. For older history forms sitting in a backlog, the guide to patient intake form digitization covers which ones are worth extracting at all.