Big Picture User Design Requirements for SRFC Patient Information System

Background

This document was generated primarily from interviews with Drs. Michelle Johnson and Sunny Smith (SRFC Attendings) and medical students Peter Bluvas and Ben Hulley in the Spring of 2007. It is a first-pass at specifying the functionality that end-users of the system want.

ENROLLMENT

•Includes contact information, demographics, past medical history (abbreviated PMH and includes previous diagnoses, hospitalizations), family history (FH), social history (SH), medications, allergies, health care maintenance (HCM)
•Information should be modifiable and deletable
•The system should remember the last “verification” date
•In some cases, the system does NOT need to remember the old values if changed (like FH or PMH)

CLINIC VISIT

•NOTE: The clinic visit interface should be as simple as possible! Data entry will be a bottleneck in our clinic workflow so we want to mnimize the time needed for this following a physical Patient encounter.
•Date of visit
•Primary care visit or specialty visit (cardiology, ophthalmology etc)
•Vital signs: blood pressure, heart rate, respiratory rate, temperature, weight
•“Point of service” (POS) refers to labs or procedures that are done at a visit. For example, a POS lab could be a urine pregnancy test or a test for strep throat. A POS procedure could be the draining of an abscess (called an I&D). These should be entered byThe information that needs to be captured is test/procedure name (i.e. pregnancy test or I&D), the relevant date, the value or result (if applicable) and the location performed (i.e. Downtown clinic)
•Referrals: There are many specialties and resources that we refer our patient to within our system (ie cardiology clinic) and outside our system (i.e. the MediCal? office). The system should ask if any referral were made and then, if yes, prompt the user to enter pertinent information. The basic information the system should track is the specialty, the reason for referral, date referred, status/outcome, and a free text note. Please note: In the short-term we plan to also use this feature to handle “external” referrals to Dental/Social/Legal/Acupuncture. We anticipate that the values for specialty and status/outcome will NOT be free text entry. Tracking the outcomes of referrals is valuable for reporting purposes and so we want “hard-coded” values that are easily queried and computed on.
•Diagnosis: Each visit any new diagnoses should be entered with information on the date the diagnoses started, the end date (if applicable) and the status (if applicable, like well controlled, poorly controlled, active, in remission). We are not certain if the system needs to record when a change in Status is made. (Anotherwards, if we change from controlled to poorly-controlled can the system forget that the status used to be controlled?) Diagnoses are presumed to last for multiple Clinic Visit events, and so the Disease list for a patient should be cumulative over all of their visits.In addition, diagnoses from previous visits/entries should pre-populate a We would like a list/table that would summarizes the patients’ acute and chronic medical issuesDiagnoses. We are not certain if we would like to have 2 types or flavors of Diagnoses: chronic and acute.
•HCM: These are services that are offered to ALL patients in an attempt to keep them healthy (like giving flu shots in the winter, mammograms for women over 40). The visit form should ask about any HCM items and rememberThe data that needs to be captured during a clinic visit for HCM items is the date of exam/service, the due date for the next exam/service, and possibly the result if applicable (i.e. abnormal mammogram). An advanced feature is for the system to embody “rules” about when Pt’s are overdue for a screening exam, and to alert the student/doctor when something is due. The guidelines for recommended HCM services/exams are published and widely available. There can be many complicating factors (like an individuals’ family history) and exceptions (like a man without a colon cannot be screened for colon cancer).
•Chronic disease maintenance: These are specific exams/studies that are performed at regular intervals on patients with specific chronic diseases (i.e. diabetes). The exams/studies that are recommended are disease-specific and are also published and available. For example, it is recommended that all patients with diabetes receive a foot exam every year. On the clinic visit form, there should be an opportunity for the student to enter any exams that were done that were a part of the chronic disease maintenance. Again, the data would be entered with a date, exam type (foot exam), and then due date for the next exam. (This is VERY similar to HCM. The important distinction between the two is that HCM applies to all patients including HEALTHY patients, and chronic disease maintenance applies to patients only with specific diagnosis)
•Red-Alert or Action items: Ideally, the system could alert the user if there are any outstanding or unresolved issues. These could be “red-alert” or action items. For example, if a patient was referred to cardiology clinic and the referral is pending, this could be an “action item” for the user to follow-up on. Similarly, if the patient is a woman over 40 and she hasn’t had her mammogram, the system could give a “red-alert” so that the user could address this.

LABS

•POS labs: see note in clinic visit
•Labs processed by QUEST: Once we have a unique patient identifier (ie a medical record number that is unique and specific to only one patient) we should be able to input labs directly from QUEST electronically. QUEST uses HL7.
•The information system should remember the date, type (i.e. glucose), value/result and the location (ie Quest or on site at the SRFCP)

PHARMACY

•Medical student/doctor enter an “order” for medication. This includes the requested or desired medication name, dose, sig (which means how the medication is taken, i.e. once in the morning before breakfast), indication for use and the number of pills dispensed. In some cases, the pharmacy will not be able to give the requested medication and will instead recommend a substitute medication. A medication will be labeled as “substitute” in this case.
•The pharmacy would have a list of patients that are waiting for the above orders to be filled. It would be a queue of patient names that they could click on to start working on.
•The pharmacy should be able to see a “patient summary” while reviewing the medication order. This “snapshot” would be a summary of medical problems/diagnoses and allergies to medications. The pharmacy should be able to see a medication list and access labs easily.
•Then there should be a way to make a label and finalize the dispensing of medication.
•Ideally we could be able to see and print a list of all the medications the patient is taking.
•Ideally we could use the list of medications to evaluate for possible drug interactions, side effects, and labs that need to be performed in order to safely administer the medication.
•In addition, the pharmacy team should consider a pharmacy inventory that would include medication name, dose and number of pills. Ideally, when a medication is dispensed, the number dispensed would be subtracted from the inventory and then we could know how much of a particular medication is available. Note: the inventory would have to be site specific according to the three sites.
•All of this should interact with and be relevant for the patient assistance medications also.

PATIENT ASSISTANCE

•Currently the patient assistance volunteers have a system using an excel spreadsheet that they find very convenient and useful. Basically, we could recreate the functionality of the excel spreadsheet and patient assistance inventory binder. The important information is the medication, dose, # available, reorder date, and status.

REGISTRY

•A chronic disease registry is a system to capture and track key patient information that assists health care providers manage patients with chronic diseases. Many common chronic diseases, like asthma and diabetes, utilize registries in order to provide high quality care. The features described here are read-only reporting tools that will extract information that has been captured by other modules of the system and display the information to the students/doctors in a way that facilitates better clinical decision-making. For example, rather than having to flip through a paper chart to ascertain the Pt’s previous lab values, these could be displayed in a table or graph by the system. The information relevant to the registry is disease specific and can change over time.
•The system should be able to generate lists of patients based on criteria. Ideally this interface would be flexible, allowing a patient subpopulation to be identified based on labs/diagnosis/demographics and allowing the ability to output various columns of information (ie. name/phone/labs/vitals). The end-user of this feature is a student/doctor trying to identify a subpopulation of patients that need to be coNtacted or followed-up with.
•The system should be able to generate reports on the POPULATION of patients with specific diseases. (For example, how many of the Free-Clinic patients with diabetes have had a foot exam in the last year.) These reports are static in that they always provide the same set of information. Primarily these are population statistics about patients that are used as a report card to indicate how well the clinic is doing at providing high quality care to its patients.
•The system should also be able to generate reports on INDIVIDUALS with specific diseases. (For example:, Has diabetic patient Jane Doe had a foot exam in the last year?). These reports will be viewed and/or printed and used by the student/doctor to initiate a clinical encounter with a Pt.

REFERRALS

•See section under clinic visit form

QWB

•Quality of well being: This is a questionnaire for patients that assesses overall well being. The patients are asked to complete the questionnaire at regular intervals when they are at clinic. Based on the responses, a score is generated. These scores are tracked over time in the hope that the care given at the SRFCP is stabilizing or improving the quality of well being of the patients.
•The information system should be able to remember the date that patient filled out the QWB, the score, and when the next QWB should be done.

DENTAL/SOCIAL WORK/LEGAL/ACCUPUNCTURE

•Eventually each of these disciplines at the Project would have their own tables linking to patient ID for their use.