The purpose of this document is to outline the requirements for a patient record information system/model for the Arkansas Children's Hospital NICU. Since the same pediatric residents and neonatology attending staff cover the critical- intensive- and special-care nurseries at University Hospital, it would be desirable to install the same system at that location as well. At present, the code name for this project/system is Prism.
Motivations. The most immediate motivation is the desire to reduce the effort relieve the tedium involved in generating the required documentation of patient care.
Usage Patterns. To provide insight into how Prism is to be used in the clinical setting, I begin with the section entitled Usage Patterns. This section describes our clinical activities and how these activities might be expected to evolve with the introduction of a computer-based patient record system. The essential principle here is that the patient record should be generated as an integral part of the clinical activities, not as a clerical activity performed after the fact.
Data Structures. By definition, a patient record is a data set. In the section entitled Data Structures I try to demonstrate the second essential principle, that the patient record data set is highly structured. This is not to imply that there is only one possible logical structure. Indeed, the proper logical structure of the patient record is elusive and often obscured by the physical structure of traditional (paper-based) medical records. Above all else, however, the patient record is a "record of healthcare," where "record" implies (1) concurrent collection of information and (2) persistence of that information, and where "healthcare" implies (1) assessment of collected information and (2) decision-making based on this assessment. Thus the logical structure of the patient record data set is generally problem-oriented or goal-oriented.
Presentation/Interface. Although the data set is highly structured and relatively fixed, the views of this data set will be quite varied and must be adaptable. In the section Presentations and Interfaces, I outline a few possible user (clinician) interfaces and other types of presentations of the data. The essential characteristics are ease of use and flexibility. Also in this section is a description of helpful interfaces to the hospital information systems.
Neonatology Team Rounds each day is the focal point of patient care in the NICU and special care nurseries. This is the period of time when new information is exchanged and the management plan is updated for each patient. Unfortunately the attending neonatologist expends a substantial amount of effort in generating a progress note during rounds. We have tried dictating brief notes between each patient, filling out templates and a variety of other mechanisms over the years, none of which have been entirely satisfactory. The current practice is (generally) to prepare a kind of "progress note worksheet" from a template at the beginning of each day. This worksheet has a number of blank areas or fields that are filled out before or during rounds. Once it has been filled out it becomes the "progress note" for that day. Parts of this progress note are then copied mechanically or manually to form the worksheet for the next day.
Most (or all) of the information contained in the attending progress note is already contained in a similar note created by the pediatric resident or neonatal nurse practitioner. The reason for this duplication is that with manually generated notes, it is difficult to prove direct involvement by the attending physician without a full note dictated or handwritten by the attending. With computer-generated notes, however, we would envision a way of annotating the portions of patient care that receive direct input from the attending during rounds, and thus a single note would suffice.
Given (1) that the focus of patient care is team rounds and (2) that the patient record should be generated as part of the patient care process, using Prism will become a crucial part of making team rounds. It is anticipated that the team (especially the attending neonatologist) will review the current information on each patient as displayed on the laptop screen and update the patient care plan from the user (provider) interface. This means that the provider interface will need to be intuitive and easy to navigate, as well as sophisticated. The screen will need to be large enough to display substantial information at one time and be easily readible.
In preparation for rounds each day, considerable information must be collected, calculated and organized by the NNP or resident. Prism should help make this activity as efficient as possibled as well as assure accuracy of the data that is obtained. Again this calls for a provider interface that is both sophisticated and easy to use.
It is anticipated that previously archived data will be downloaded to a laptop computer each morning. This information will be updated prior to rounds as the NNP or resident goes to each patient bedside and goes over the flow sheet and examines the patient. Calculations based on new patient weight should be automatic. Laboratory and other results should be downloaded from Meditech.
If time allows, orders for the updated management plan are written in the patient's chart during rounds, but more often they are written after rounds. The resident or NNP typically note the changes needed in their progress note during rounds, and they go back to the bedside after rounds to write the orders. Tentative hyperalimentation fluid orders may have been generated before rounds, and if a change is made on rounds these have to be regenerated with the new values. Much of the afternoon is then typically spent preparing the progress note template for the following day. Also during the afternoon, procedure notes for line placement and so on are documented manually, often on a separate sheet of progress note paper.
We do not anticipate Prism printing most orders in the near future, but printing admitting orders (customized for each patient) by the system would be helpful. In addition, a prioritized task list (or to do list) would make sure that the daily orders are written in a timely fashion. Likewise, procedure notes could become part of the progress note generated at the end of the day.
A small (but not insignificant) part of each day is spent by the attending neonatologist marking a billing sheet for each patient. We want to make sure that the billing is accurate and timely, and what better time to perform this task than during rounds? Moreover, a billing clear spends an significant amount of time preparing the billing sheets each week. This time could be elimiated completely. (In fact, the billing information could probably be sent to CUMG/MCPG online.)
At the time of patient discharge, a discharge summary is drafted by the NNP or resident. Even for a short hospital stay, this takes a significant amount of time, and for a long stay the time required can be overwhelming. Moreover, an interim summary (off-service note) is generated monthly at the change of service by the pediatric residents on their patients. This, too, takes considerable time and makes getting ready for the end of the month extremely tedious. Prism should reduce this effort to a minimum as all the pertinent data is already present in structured format. It should be added that discharge summaries are currently dictated and transcribed. This could be eliminated as well.
The structure of healthcare information is fine-grained and rich. By "fine-grained" I mean information that consists of an enormous number of data elements (variables, fields, slots, attributes). And by "rich" I mean: (a) that the data types for simple elements are quite varied, and (b) that simple data types may be combined in many different ways to form many different compound data types.
Healthcare is traditionally directed toward the detection, identification and management of health problems, hence the so-called problem-oriented approach to patient records. Being at risk for a given health problem may constitute a problem to be managed as well, so that management of health risks is part of the problem-oriented approach. Broadening this concept somewhat, health problems are often identified relative to health goals. If, for example, appropriate weight gain is one health goal, inadequate weight gain may be identified as the health problem "failure to thrive" or "feeding intolerance" and so on. In some situations, however, the health goal may be more easily expressed than the inverse health problem, and thus the patient record is more goal-oriented.
Many healthcare providers find it helpful to organize a patient's health goals and health problems according to body systems. In this case, it is not uncommon to include pseudo-systems such as "infectious disease" or "nutrition" even though these examples might be placed under the immune and gastrointestinal systems respectively. In any case, a system-oriented patient record is possibly a more comprehensive way to organize problem- or goal-oriented records.
patient record
| . |
patient identity (up)
|
1 We will also require some type of alias
index, as many newborn infant undergo a name change
within the first few days or weeks of life. 2 Or "given" name to include first and middle names with suffix. 3 In the case of mixed race, the patient's race is determined by the race of the mother. 4 In name conflicts, the date of birth is often used to establish the correct identity. (Some theoreticians have advocated using a hash function of the exact time and GPS coordinates of birth as a universal identifier.) 5 In the case of twins or other multiple birth, the birth order is a crucial component of identity. |
There are two purposes for accurate patient identification. One is to assure that the information is recorded for the proper patient, and the other is to make sure each patient has only one record.
unique patient identifier (up)
|
1 It is anticipated that Prism will eventually be used at both ACH and UAMS. It may also be desirable to store medical record numbers from referring facilities. |
intake assessment (up)
|
1 The review of systems is nearly irrelevant in newborn patient, but this may be a good place to 'systematically' collect certain types routine information. In older children, the traditional ROS is of more importance, although still not as crucial as for adults. |
birth history (~HPI) (up)
|
* duplicate from patient
identity 1 The gestational age and birthweight are also important parameters for derived values elsewhere. |
Comment: The birth history is of special importance in pediatrics and of unique importance in neonatology, where it essentially becomes equivalent to the "history of present illness" (HPI) in an older patient.
maternal history (~PMH of patient) (up)
|
1. |
obstetric history (up)
|
1 number of pregnancies including this
pregnancy 2 prior to the delivery of this patient |
physical examination (up)
|
1 The behavioral state/exam needs to be fleshed out. Examples of choices include: alert, spontaneously active, active with stimulation, irritable, sedated, lethargic. |
Comment: This is my first pass at structuring the physical exam data, based largely on our typical approach to the admitting PE. In retrospect, the data itself could be structured more logically (systematically), but allow for a variety of different presentations (clinician/user interfaces) depending on the situation. For example, the clavicles logically belong to the skeletal system, but they are typically examined along with the respiratory system when we examin the chest. For the newborn, we will also need to put together the data set necessary for gestational age assessment.
limited physical exam (up)
|
. |
HEENT exam (up)
|
1 In the newborn, the TM's are not generally examined, and position and recoil of the ears are assessed only on intake (admission). |
neck and chest exam (up)
|
. |
cardiovascular exam (up)
|
1 need help from CV in characterization of
heart sounds and murmurs 2 Pulses: temporal, carotid, axillary, brachial, radial, femoral, tibial, dorsalis pedis, posterior tibialis. |
abdominal exam (up)
|
. |
genitourinary exam (up)
|
. |
skeletal exam (up)
|
. |
Comment: I did not take the time to structure the entire skeletal exam, but this will include such specifics as the presence of absence of hip click and congential defects such as polydactally or club feet. The list is long.
neurological exam (up)
|
. |
dermatologic exam (up)
|
. |
Comment: I'm not sure where to put congenital ichthyosis.
location (up)
|
. |
These options for location are fairly specific for the skin exam. Perhaps a more generallized schema would suffice for describing the location of any given finding.
Dubowitz Score (up)
|
See J. Pediatr 1970, 77:1. |
Comment: The items listed above are from the original Dubowitz Scoring system for estimating gestational age. We will probably use a modified version called the Dubowitz/Ballard Exam.
family history (up)
|
. |
Comment: These are aspects of the family history that seem most pertinent to the neonatal patient. We should work with Genetics to come up with a more general family history structure. Incidentally, the family history and the social history are examples of static data structures (information that does not typically change over a hospital course) but which is frequently edited as new information is obtained.
|
. |
Comment: This information is typically obtained by our social workers or staff nurses as well as NNP's and residents (and attendings).
current status (up)
|
1intake and output for previous day. 2current fluid administration rate(s) and feeding schedule. |
Healthcare occurs in the present, in the "here and now" wedged between the past and the future. Patient care involves collecting information about the present state of the patient, which in turn is a result of the past. It requires evaluating the meaning of that (past and present) information and making decisions about what to do in the future. Then it entails watching for some period of time and reassessing the outcome of those decisions, and so on in a cyclic process.
The record should obviously include facts (observations and findings) about the patient's present state (which likely includes facts from the past). The record must also include some representation of how the provider interprets those facts and the decisions made as a result of that interpretation. There must be a record of events (therapeutic or observational) that occur in the interim, and the cycle starts again.
current age (up)
|
1 A derived value, but may be stored as
well. First 72 hours of life, usually expressed in
hours, and in days thereafter until 30 to 60 days.
After that: days, weeks and days or months and
days. 2 The PCA is derived from the chronologic age and the gestational age at birth. It is usually expressed in weeks or weeks and days. 3 The AA is PCA minus 40 weeks. |
Chronologic age is a central aspect of health factors and risks throughout the entire lifetime of all patients. Postconceptual or adjusted age is important in infancy for prematurely born patients.
growth parameters (up)
|
1 Current weight in kg (easy conversion to
lb and oz for parents might be convenient). For times
when an accurate weight cannot be determined,
"estimated weight" or "working weight" might be a
useful parameter. If the patient is significantly
edematous, we may wish to have an estimated "dry
weight" as well. 2 increase or decrease in grams since yesterday or increase or decrease in gm/kg/day in the past n days. 3 or other assessment of weight for length. The pondoral index is (weight/length3) * 100 |
Growth is a crucial aspect of the health status throughout all of pediatrics, but especially in the newborn period.
interim history (up)
|
. |
The interim history is often a narrative summary of the events since the last progress note. It frequently includes a statement about new problems identified and a statement about frequency and severity of apnea, bradycardia or desaturation events, a comment about feedings and so on. It may or may not be possible to give it more structure, but in any case there would seem to be a need for a free text narrative. On the other hand, nearly all of the information included in this section could be distributed in the other data structures.
temperature support (up)
|
. |
respiratory support (up)
|
. |
intake and output (up)
|
. |
fluids and nutrition (up)
|
. |
indwelling lines and tubes (up)
|
. |
laboratory values (up)
| chemistry | hematology | other |
|---|---|---|
SODIUM POTASSIUM CHLORIDE CARBON DIOXIDE GLUCOSE CALCIUM BUN PHOSPHORUS ALBUMIN ALK PHOS CREATININE TRIGLYCERIDE IONIZED CALCIUM MAGNESIUM TOTAL BILI DIRECT BILI FREE T4 TSHdrug levels GENTAMYCIN VANCOMYCIN THEOPHYLLINE PHENOBARBITAL |
WBC CORRECTED WBC RBC HGB HCT MCV MCH MCHC DIFF METHOD MONOS(%) LYMPHS(%) POLYS(%) BANDS(%) EOS(%) BASOS(%) VARIANT LYMPHS NRBC PLATELET SPUN HEMATOCRIT RETICS(%)absolute neutrophil count (derived value) |
blood gases
pH PCO2 PO2 HCO3 BASE EXCESSblood bank ABO & Rh INDIRECT COOMBSfluid hematology WBC CSF RBC CSF POLYS CSF BANDS CSF LYMPHS CSF MONOS CSFmicrobiology |
x-ray findings (up)
|
. |
Comment: We need to discuss how radiologic findings can be given more structure. Currently I plan to use free text fields.
other objective findings (up)
|
. |
health problem (up)
|
. |
The health problem may be the most important data structure in the entire patient record (especially if the record is to be considered "problem-oriented"). It is not entirely clear that lists of findings and lists of medications should be distributed among the various health problems of the patient. In the first place a given medication, for example, might be associated with more than one problem. Secondly, it is frequently helpful to view all the "findings" together, or to view the entire medication list in one place. On the other hand, it is a good discipline to make sure that every test or treatment is associated with at least one identified health risk or problem.
Another complicating factor in the problem-oriented record is that conceptually problems can often be nested. A high-level problem might be "respiratory distress" with subproblems of "hypoxemia" and "hypercarbia" or diagnoses such as "pneumonia".
medication (up)
|
1 generic name. 2 the interval can be derived from frequency and vice versa. 3 indexed dosage derived from patient weight daily. |
Comment: Commonly used medications in neonatology can be found at Neonatology on the Web or NICU Web.
discharge plan (up)
|
. |
Comment: I am not quite sure how to structure the discharge plan. The essential principle, however, is that planning for discharge begins soon after admission and is updated continuously.
drug level (up)
|
. |
hyperalimentation fluid order (up)
|
* duplicate from growth 1 fixed decimal value (0.1) 2 derived = rate * 24 3 derived = volume / weight 4 % = grams per 100 ml (1 kg = 1 L) -- range = 0 to 25 (12.5 if peripheral) 5 derived = indexed volume * % * 0.01 * 0.6944 (reciprocal of 24 * 60 / 1000) 6 derived = indexed volume * % * 0.01 * 3.4 (glucose is 3.4 kcal/gm) 7 range = 0.5 to 3.0 (or 3.5) in increments of 0.5 gm/kg/day 8 derived = amino acids * 4.05 (protein is 4.05 kcal/gm) 9 range = 0.5 to 3.0 in increments of 0.5 gm/kg/day 10 derived = lipids * 10.0 (fat is 10 kcal/gm) 11 derived = glucose + protein + lipid calories 12 derived = (glucose + lipid calories) / (amino acids / 6.25) 13 derived (used to find optimal proportions) 14 derived (used to prevent precipitation) 15 medications can also be added to the HAF order:
|
Comment: This data structure is taken from the FeN Planner that has been in use in the NICU for over five years. The FeN Planner has an enteral feeding component that is not included here, and it does several kinds of error checking (specifically negative volume and CaP precipitation alerts). It also calculates the HAF worksheet suitable for use by pharmacy.
A subset of this structure could be used for regular fluid orders and possible even for medication drips such as pressors.
record of changes (up)
|
This is the part of the patient record structure that is the least clear to me right now. The current status is updated continuously, and much of the historical information will be maintaind there, at least in summary form. But many of the details cannot be held in the current status, and a record of changes in status/plan must be maintained. A kind of snapshot of the current status would suffice, but this would also be quite inefficient because the proportion of the state that changes at any given time is quite small. |
provider record
|
. |
Comment: I have only started working on a possible structure of the provider record. The patient record is the central aspect of Prism, but each provider will surely want to keep track of patient's they have cared for, types of health problems they have managed and procedures that they have done.
Although the logical (structural) core of Prism shall allow for evolutionary change and incremental growth, this core will be more stable than the presentation layers (clinician/user interface). Hence, the presentations layers shall be designed: (1) to be highly flexible and adaptable, and (2) to be modifiable independent of the core model.
The success of Prism will depend to a large extent on how the healthcare provider is expected to interface with the system. The interface must be easy (intuitive) for a new user (the new pediatric residents on a rotation, for example) to learn, but sophisticated enough to meet the demands of complex clinical situations. For a few tasks it will be acceptable for Prism to require slightly more time than current paper-based methods, but for most tasks, Prism should allow the provider to do the same amount of work in less (occasionally much less) time.
The user interface shall present a clear distinction between activities that focus attention on a given patient and those that are related to daily workflow and the oversight of a group of patients. I believe this is best accomplished through two separate frames (browser or application windows), one for each of these modes: the provider and patient frames.
the provider frame
|
. |
Comment: The provider frame is essentially how the provider organizes his or her patient lists and workflow. There are several different ways that the provide may want to view the patient list, including a graphical representation. I would anticipate eventually including an extensive knowledge base here as well.
the patient frame
|
. |
Comment: If any single aspect of Prism will determine its success, it is probably the patient frame. It will be essential to make navigation quick and intuitive, and information input as effortless as possible. Most users will already be familiar with the Web browser, so this interface might be ideal. It would also allow the inclusion of HTML help screens and knowledge basees. On the other hand, the browser frame (window) has a generic menu and toolbar, and we might be better served by having a custom frame/window with its own menu, toolbar and so on. If we do end up taking the browser approach, a clear navigation frame will be essential.
daily progress note
The documentation of patient care in the NICU (in the form of daily progress notes) remains a constant source of frustration for numerous reasons, including less than desirable quality and marked inefficiency in producing such documentation. Thus the generation of paper-based progress notes is a primary motivation in creating Prism.
Several possibilities come to mind for how such notes should be created and printed. First, we might use a COM link to MS Office and let Word or Excel print the document. Second, we might generate output to be sent directly to Windows (or other OS :-). Third, we might generate the document as an XML or HTML file that could be printed as well as saved online.
We may also want to allow several different styles for the progress notes. For example, the traditional style includes sections for Interim History and subjective findings, Objective Findings (lab results, PE, etc), Assessment (problem list), and Plan. An alternative style would be to have findings, assessment and plan divided up according to problems in the problem list.
procedure note
Structured procedure notes could be printed separately or as a component of the daily progress note.
admitting H & P
Typically there are two admitting history and physical notes created for the chart. In a computer-generated H & P, both the attending neonatologist and the resident or NNP could easily document their seperate involvement in a single note.
transfer or off-service summary
discharge summary
What a time saver!
hyperalimentation order form
daily sign-out sheet
billing sheets
nursing-unit patient/provider list
download laboratory results
As we discussed a couple of weeks ago, being able to download lab result directly from Meditech would not only save time, it would insure accuracy.
download other results
download patient demographics
upload discharge summary
Why should discharge summaries be dictated and transcribed if they can be generated from the structure record?
upload admission H & P
upload progress notes
Meditech is not probably not ready to accept this volume of infromation currently. (??) And the preferred way of reading the notes is most surely not through PCI.
order entry
Down the road, we could improve accuracy, reduce errors, and save time by having Prism input orders directly into Meditech's nursing (or physician) order entry system.
When we are thinking about implementing this system at UAMS, an interface to "echart" could be a life-saver. Currently UAMS has not put echart into the NICU because of the complexity of the order set. No one believes that the physicians could (or would even try to) keep up with the load using the current interface. If Prism could provide the interface, however, it might work better than for any other unit in the hospital.