WO2000065485A2

WO2000065485A2 - System, method and apparatus for encoding medical information with exemplary codes

Info

Publication number: WO2000065485A2
Application number: PCT/US2000/011571
Authority: WO
Inventors: William Ernest Rutherford; Jennifer Bennett; Daniel Popp
Original assignee: Physicians Information Exchange, Inc.
Priority date: 1999-04-27
Filing date: 2000-04-27
Publication date: 2000-11-02
Also published as: CA2371401A1; WO2000065485A3; AU4976800A; IL146156A0; EP1204936A2

Abstract

A system, method and apparatus for encoding medical information about a patient that can serve as a basis for supporting applications ranging from a medical records system to a data warehouse containing medical history information. The encoded information pertains to an individual patient, their medical history, conditions, treatment and other related information.

Description

SYSTEM, METHOD AND APPARATUS FOR ENCODING MEDICAL INFORMATION WITH EXEMPLARY CODES

BACKGROUND OF THE PRESENT INVENTION

Field of the Invention

The present invention relates to a medical record and healthcare information coding scheme and method, particularly to a system for providing physicians the ability to record data in a natural language format and extract finely granular information about treatments, conditions and outcomes .

Description of the Related Art

Electronic medical records systems have been in existence for over twenty years . Databases containing medical and healthcare information have been around for a similar time period, and claims-based data warehouses have been in use for over a decade. Given this, there has not yet been an implementation of a system that allows the physician to collect clinical healthcare information at the source, place it in a common repository (a clinical data warehouse) , and query meaningful results from it.

As a physician and former university hospital research associate, one of the applicants, Dr. Ernest Rutherford, realized that physicians need instantaneous access to complete and accurate medical records and healthcare information. They also need to be able to utilize sophisticated queries regarding efficacy of treatment, changes in patient condition over time, comparisons across data sets, and the discovery of relations between practices, treatments and outcomes. The existing database applications typically allow for the extraction of patient records based on a keyword, but do not provide for any type of automated analysis or comparisons.

Conventional healthcare information coding schemes are a method for collecting related information and have been in existence for over a century. There has been quite a lot of work done in recent years, including work performed in the fields of medical informatics, artificial intelligence and knowledge representation. The most pertinent work is in the area of medical informatics and includes coding schemes, such as ICD-9 (International Classification of Diseases, Ninth Revision circa 1950 to 1993) , CPT (Current Procedural Terminology circa 1966) , SNOMED (Systemized Nomenclature of Human and Veterinary Medicine circa 1970) , and UMLS (Unified Medical Language System circa 1986) .

ICD (International Classification of Diseases) codes were designed by the World Health Organization to facilitate the statistical listing of morbidity and mortality. The ninth revision of these codes (ICD-9) were published in 1977 and were subsequently modified by the United States National Center for Health Statistics to include limited clinical information. The ICD-9 CM codes are now required by Medicare on each ^λ Part-B' claim submitted by physicians . The structure of the coding scheme contains a number that can indicate a disease process or phrase describing a disease process . Without exception, the descriptive phrase cannot be changed in any way, so the when a coded number related to a phrase is selected, it is an all or none situation. It is possible to make the code slightly more finely granular by adding modifiers, but there is a limit to the degree of specificity that may be achieved. For example, a patient presents to a physician complaining of urinary frequency over the past three days, abdominal pain in the supra pubic region, and occasional blood in the urine. ICD-9 is limited to three codes: 599.7 Hematuria, 788.41 Urinary Frequency, and 789.07 Abdominal pain, generalized. There is no mechanism to record the very basic clinical information of how long the condition has existed, how often the hematuria occurs, or even the location of the abdominal pain.

CPT (Current Procedural Terminology) codes were developed in 1966 by the American Medical Association as a listing of descriptive terms and identifying codes for services and procedures performed by physicians. CPT codes are widely used for billing of physician services under governmental and private health insurance programs . These codes do not, however, allow a sufficient description of the procedure to signify the complexity or difficulty of the procedure. They do not document the procedural process nor do they permit precise linking of procedures with diagnoses, co-morbid states or other * finely granular' clinical information.

SNOMED has been in use since the late 1970s and was designed for pathological classification. The latest version, SNOMED RT (Reference Terminology) is organized in a multi-axial and hierarchical manner. The different axes allow for the coding of various aspects of a situation such as the disease, functions, body parts or regions, occupations, and drugs. The hierarchical organization of the terms and the use of modifiers allows for varying degrees of detail to be encoded at the same time, i.e., from a specific disease description be able to identify more general conditions such as the disease category, the affected body system, and possibly the disease cause. The missing piece in SNOMED RT and all the other coding schemes is that there is no way to apply context to the information being coded and there is no specific way to store the information in a database such that it can be queried and analyzed in a sophisticated manner.

In 1986, the National Library of Medicine began developing the Unified Medical Language System (UMLS) . This system is still under development. It is designed to help health professionals and researchers retrieve and integrate electronic information from a variety of disparate systems. This system, however, is very complex and is intended for use by system developers. There is, therefore, a clear need for an improved system and methodology for encoding medical information. SUMMARY OF THE INVENTION

The present invention is a system, methodology and apparatus for encoding medical information about a patient that can serve as a basis for supporting applications ranging from a medical records system to a data warehouse containing medical history information. The encoded information pertains to an individual patient, their medical history, conditions, treatment and other related information. A more complete appreciation of the present invention and the scope thereof can be obtained from the accompanying drawings which are briefly summarized below, the following detailed description of the presently- preferred embodiments of the invention, and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the method and apparatus of the present invention may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein: FIGURE 1 illustrates an exemplary configuration of database interconnections for correlating a variety of distributed medical data about a particular patient;

FIGURE 2 illustrates an exemplary interface whereby a user may access information from databases, such as the configuration shown in FIGURE 1, to determine and hierarchically relate segments with a variety of attributes pursuant to the teachings of the present invention; FIGURE 3 illustrates a table or database containing functionality therein for converting and cross- referencing a variety of conventional coding schemes into the preferred coding scheme of the present invention;

FIGURE 4 illustrates a preferred configuration of segment values pursuant to the teachings of the present invention;

FIGURE 5 represents an exemplary list of associations between segment names and abbreviated codes therefor pursuant to a preferred embodiment of the present invention;

FIGURE 6 illustrates exemplary steps utilized in designing a code form pursuant to the principles of the present invention; FIGURE 7 illustrates an exemplary interface for accessing and modifying controls pursuant to the present invention;

FIGURE 8 illustrates a further exemplary interface for accessing and modifying attributes and controls pursuant to the teachings of the present invention;

FIGURE 9 illustrates a preferred methodology for applying codes produced in accordance with the present invention to a particular term; FIGURE 10 illustrates a preferred methodology for utilizing the coded arrangement of the present invention to obtain a variety of information about a given patient; and

FIGURE 11 illustrates an exemplary configuration of a computer system whereupon the principles of the present invention may be implemented and utilized.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENTS

The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The system and methodology of the present invention, also referred to herein as the Physician's Information Exchange (PIE) Coding Scheme, may be best understood by describing several salient features of the technique.

Categorization of Segment Entries The PIE coding scheme preferably includes a collection of segments that contain multiple terms. These segments are utilized in such a way as to essentially code medical information about a single patient and individual encounters . The PIE codes are preferably integrated into a Specialized Entry Tool (SET) and are hierarchical, as described in more detail hereinbelow. The hierarchy is created by coding forms, controls, and attributes that are linked. The highest order of the hierarchy is on the form, next the control, and last the attribute. The codes are linked together to represent a fact or piece of information about a patient. Terms can modify other terms. Modifiers are indicated by indenting the term under the one being modifying, becoming, in essence, a child of the term being modified and, as such, represents a hierarchy within a hierarchy. One of the advantages of this coding scheme is that a value/type can modify a term and specify variation. For example, using the aforementioned situation, a patient presents to the physician with urinary frequency for the past three days associated with abdominal pain in the supra pubic region and occasional hematuria . The PIE code would be : Note Section: Chief complaint Body System: GU Problem/finding: frequency Value/type: urinary

Descriptor: associated with Problem/finding: pain Body part : abdomen

Aspect : supra pubic Problem/finding: hematuria

Value/type: intermittent As is clear to one skilled in the art, there is an obvious benefit to using the PIE Coding Scheme. In one of the aforementioned less flexible systems, these three sets of information would not enhance each other, and would just be three sets of data with disjoint sets of information. These codes are created at design time but are utilized at the point of care and record the findings and impression in real time. Although the codes are static, the various combinations of the terms represent a dynamic process. The granularity of the data collected allows review and analysis over time to show progression or resolution of a disease state.

Data Warehousing a set of facts

The PIE Coding Scheme allows the clinical team to collect a set of facts about a patient. These facts collectively provide a picture of the condition of the patient and their medical history.

Because of the structure of the facts, they fit nicely into a multi-dimensional data warehouse. The warehouse can be thought of as a collection of facts about numerous unidentified patients. It is the ability to formulate queries regarding those facts that gives the data warehouse value. In order to gather a set of facts from the data warehouse satisfying certain criteria, a user simply pulls out the facts with the appropriate values (problem=headache and drug=aspirin) . An implementation of this scheme in a data warehouse would have individual tables for each segment and a table for the patient facts . With reference now to FIGURE 1 of the Drawings, a patient fact table 100 would tie together the various values of the segments for each individual fact, e.g., a body location table 110, a body system table 120, a procedure table 130, a problem table 140, a drug table 150 and a demographics table 160. Patient fact table 100, along with the segment tables discussed in more detail hereinbelow, can then be queried for sets of facts that satisfy a certain criteria. The resulting set of the query can then be analyzed further. Each fact would also have an associated date and time so studies of effects or changes over time can also be done in an efficient manner. Collection of Medical Information and History

It should be understood that the contents of any data warehouse are accumulated from sources other than the data warehouse itself. In the above scenario, the data sources can be an automated medical records system, transcripts of physician notes or other suitable sources.

Existing Medical Record Systems

None of the existing medical record systems provide for the collection of information in such a manner as to allow significant queries to be made. They typically allow for searching for individual or sets of records based on a certain characteristic or keyword, but do not provide any analysis capabilities across sets of records. As any health professional knows, this capability is needed to obtain meaningful results from a large enough sampling so that it is statistically significant.

PIERS Data Entry Tools

The Physicians Information Exchange Record System (PIERS) contains sophisticated data entry tools that allow clinicians to capture health care information and data in real time at the point of care. PIE Codes are used within the system to apply context to clinical data using natural language. The result is clinically significant data of a finely granular nature. There is a higher degree of validity in the data because it is not subject to interpretation by non-clinical personnel, such as transcriptionists or data entry clerks.

These sources will contain encoded data, textual descriptions or a combination of the two. The encoded data may be in a standard or in a proprietary manner. The source data will be processed so that it will fit into the data warehouse in such a way that it can be queried. Encoded data will be mapped to PIE Codes by electronic import, an authoring tool like the PIE Specialized Entry Tool (SET) Authoring Tool, or another tool that has a dictionary of the existing PIE Codes and the ability to move data with a mapped code to a different coding system. Encoded data already containing PIE Codes can be imported from applications that associate PIE Codes to forms, interviews, question and answer dialogs, tree views, or any other user interface that automatically assigns the PIE Codes to the input data.

PIE codes apply only to data entered using SET. That is PIERS Specialized Entry Tools. The code is embedded into this Specialized Entry Tool at the time that the tools are created. The tools are created using the SET Authoring and occur as follows: The data to be entered is chosen by selecting a node on a tree. That node has a corresponding form, the form has controls on it and there are attributes associated with these controls. The form has PIE codes, the control has PIE codes and the attributes have PIE codes . They all link together in a hierarchical manner, that is, attributes inherit the code of the control and the controls inherit the code of the forms. Each of the codes associated with the form, control and attributes are all made up of PIE codes that are segments and terms. Terms belong to the segments and the 'words' that constitute the code that reads like a sentence. Therefore, the only information that is coded in the PIERS database is information that has been entered using the SET data entry tools that have previously been coded using what we refer to as PIE codes, that is the terms that belong to the segments . With reference now to FIGURE 2, there is illustrated an implementation of a graphical user interface (GUI) generally designated by the reference numeral 200, employing the principles of the present invention. In particular, the GUI tool shows various hierarchically arranged nodes within a tree structure, both the nodes and the tree designated generally by the reference numeral 210. Each node shown, particularly a Descriptors node 220, is linked to forms as discussed. With the node descriptor 220 highlighted, all of the controls and attributes illustrated in this figure and discussed in connection therewith pertain to this type of control. A control or descriptor 230 labeled "Location" has three multiselect list boxes set forth therebelow, i.e., an abdomen box 230A, a radiation box 230B and a denies box 230C, each having a variety of attributes for selection, e.g., by use of a mouse, as a tab key, or other selection mechanism. Similarly, a second descriptor 240, labeled "Severity" has multiselect boxes also, i.e., an initial box 240A, a current box 240B and a history box 240C, each with respective attributes. An additional descriptor includes a Frequency per day descriptor 250 with single line edit boxes associated therewith, i.e., an initial box 250A and a current box 250B with a value selection box 250C for selecting pertinent values therefrom. A single line edit box 230D and a value selection box 230E are associated with the descriptor 230. Further descriptors and associated attributes include an occurrence descriptor 255, a quality descriptor 260, a starts descriptor 265, a resolves descriptor 270 and a history descriptor 275. A clear button 280 and clear all button 285 are used to clear inputted information and a back button 290A and a next button 290B are used to navigate between discrete pages within the GUI tool 200.

The Inventive Coding Schema

The coding scheme preferably includes 13 segments presently labeled as problems/findings, general, subject, note section, body system, methods, units, descriptor, value/type, body part, aspect, procedure, and drugs. Segment problems/findings generally are those things that are coded in standard ICD-9 codes. They relate to diagnoses, findings, and symptoms. The general segment refers to a broad category such as infectious disease, bacterial disease, viral disease, malignant disease, carcinoma, etc. Terms within the subject segment include nouns, verbs, and gerunds. The note section contains parts of a medical record notes such as chief complaint, present illness, review of systems, social history, family history, physical examination, etc., and would also have sections for procedures, such as indication for procedure and general broad categories of a note section that one might normally find in a document . The body systems are those body systems that have been defined by Medicare, which include cardiovascular, respiratory, and gastrointestinal, etc. Methods includes such things as methods for doing tests but also methods of eliciting history such as interview or methods for determining the finding, inspections, percussion, hospitalization, etc. Units include standard things such as centigrade, Fahrenheit, ccs, inches, feet, meters, etc. Descriptors are those things that describe what is to be found, such as associated with, relieved by, etc.

Value/type are those things that would normally be of value, such as a number. Type II is a type of diabetes and Essential is a type of hypertension. Body Part is self-explanatory. We consider it a body part if it is removable. Aspect is a modifier of a body part and would be a part of the body that would not necessarily be removable, such as the mitral area or frontal area. Procedures include individual lab tests and terms that describe procedures or parts of procedures . Drugs are published by First Databank. Modifiers are a very important part of this 'near natural language' as noted below.

Encoded data that uses other coding schemes will be handled by looking up the meaning of the encoded data and processing it as a textual input or cross-referencing a table to locate the appropriate PIE Code.

A representation of a cross reference table, generally designated by the reference numeral 300, is illustrated in FIGURE 3. As shown, the table 300 includes mapping functionality for mapping conventional codes, e.g., ICD-9, ICD-10, CPT, NOMESCO, FDB, SNOMED, UMLS and HCPCS to the PIE codes of the present invention.

Processing of Natural Language Input

Information gathered during a patient encounter has typically been recorded using handwritten notes or dictation and transcription tools. Case studies or research of any kind required poring over individual patient charts, finding pertinent data and recording those facts into a separate spreadsheet or other application.

Using the PIERS data entry tools, the textual data sources are preferably processed as natural language input, i.e., broken up into phrases or sentences, then parsed and mapped to PIE Codes . As each individual word is parsed out of the input, its PIE Code is looked-up and saved. The input is then examined to determine if there are recognizable phrases that can be assigned PIE Codes. These phrases are typically entries in one of the segment tables. All of the PIE Codes are then saved in the data warehouse as attributes of the same fact .

For example, begin with the phrase 'patient has a pain that starts in the chest and radiates to the upper left chest while increasing in intensity' . While each word will be coded, the focus is on the more meaningful words in the sentence. The word 'pain' describes the problem and the word 'chest' describes the location . More detailed information can be obtained by looking for descriptive phrases. The phrase 'upper left chest' provides a more detailed location. PIE Codes will be assigned to the words pain and chest but also to the phrase upper left chest. In order to identify phrases, matches will be cross- referenced to the segment tables defined for the data warehouse. This provides a hierarchical layer of the varying levels of detail, as illustrated in the description of the segments shown in FIGURE 4. A segment table, generally designated by the reference numeral 400, includes a segment columns portion 410 and a segment rows portion 420 for marked elements. In the current example, 'chest', 'left chest' and

'upper left chest' are terms in the Body Location and aspects segments. "Left" and "Upper" are terms in the aspect segment. This allows a search for problems in the chest, left chest, and upper left chest to obtain meaningful results.

The PIE Coding Scheme is being referred to as a 'multi-segmental mark-up code' . As discussed, there are currently 13 segments consisting of the following: Problems/Findings, Subjects, Note Sections, Body Systems, Methods, Units, Descriptors, Value/Type, Body Parts, Locations, Tests, Procedures, and Drugs.

The Segment Table is preferably composed of Segment Columns and Rows of 'marked' terms. The 'mark' associated with each Term uniquely identifies the Term as belonging to that particular segment.

A table of currently preferred pairings is shown in FIGURE 5 where an identifying mark within mark column 510 is uniquely paired with a particular segment within segment column 520. It should be understood that by so abbreviating the designations for segments in this protocol countless trillions of data bytes would be saved in the medical databases employing the principles of the present invention.

Each Segment has a 'mark' and each Segment has many Terms. Each Term is uniquely identified by its 'mark' that indicates the Segment that it belongs to as noted above . A Term may belong to more than one Segment and its uniqueness is guaranteed by its 'mark' . The use of the word 'mark-up' when referring to codes is abstractly similar although not identical to its meaning when referring to 'mark-up languages' .

A PIE Code can be made up of a single 'marked Term' or a combination of 'marked Terms' . When the Pie Code is composed of a combination of 'marked Terms' , each 'marked Term' will be separated from the others by its 'mark' .

The PIE codes are used to code various parts of the medical record such as chief complaint, present illness, past history, physical examination, impression, plan, etc. They are also used to code procedures. Each section of the record has a Note Section that identifies which part of the record contains the data. This allows clinicians to know if a blood pressure is part of the present illness, past illness or part of the family history.

Using the coding tools: In general, the design and coding process follows a few basic steps:

1. Thinking about the methods used to record patient data manually, i.e., checklists, questionnaires, dictation formats, etc., sketch the layout of the form and its contents on paper, as illustrated and discussed in more detail hereinbelow in connection with FIGURE 6.

2. Use the SET Authoring Design Tool to create the Form.

3. Insert the necessary Controls into the Form, as illustrated and discussed in more detail hereinbelow in connection with FIGURE 7.

4. Enter the appropriate Attributes into each control, as illustrated and discussed in more detail hereinbelow in connection with FIGURE 8. 5. Assign PIE Codes to the Form, as illustrated and discussed in more detail hereinbelow in connection with FIGURE 9.

6. Assign PIE Codes to the Controls 7. Assign PIE Codes to the Attributes

8. Create the Narrative Summary

9. Review and test the Form, as illustrated and discussed in more detail hereinbelow in connection with FIGURE 10.

As shown in FIGURE 6, a flow chart 600 outlines a methodology for sketching a form pursuant to PIE coding.

After starting (step 605) , a form to model is selected

(step 610) and a decision made as to which items to include therein (step 615) . An iterative process is then commenced to determine first (step 620) whether another item is to be included: if yes, control transfers to step 625 where the user places the correct field on the form; otherwise, control transfers to finished (step 640) . After step 625, a determination is made (step 630) whether the item requires PIE encoding: if yes, a PIE encoding occurs (step 635) , and in either event control transfers to box 620 to ascertain whether item entry is complete. An exemplary control form, generally designated by reference numeral 700, for item insertion is shown in FIGURE 7, wherein a node and tree structure is illustrated. A given node, i.e., a CC node 720, is shown selected within nodal structure 710. A group of pre- created control selections are illustrated within design tool portion 730, and a button control portion 740 selected therein. This selection activates a control portion 750 and deactivates another portion 760, as illustrated.

As also described in connection with FIGURE 2, an attributes and codes form is generally designated by the reference numeral 800 in FIGURE 8. As shown, a node and tree structure 810 includes a highlighted node 820, i.e., Right Upper Lobe, therein. A design tool portion 820 and a Right Upper Lobe control portion 830 having a variety of proposed attributes therein, e.g., a percussion portion 840 and an auscultation portion 850, the latter of which is illustrated in a highlighted position. As shown within rightmost attribute portion 860, particularly, a PIE code portion 870, the highlighted portion (auscultation) is designated as the method and a note as to insertion point is associated therewith in a subordinate, indented fashion.

With reference now to FIGURE 9, there is shown a methodology, generally designated by the reference numeral 900, for coding a term pursuant to the teachings of the present invention. After starting (step 905), a determination (step 910) is made as to the most important part of the term. An iterative process is then entered

(step 915) to determine whether any additional segments are to be evaluated: if yes, the next segment is selected

(step 920) and a further determination made whether there is an element within the segment that should be part of the code (step 925), if yes, the element is added (step

930) and control reverts to step 925, if not, control reverts back to step 915.

If there are no further segments for evaluation

(step 915) , a determination is then made (step 935) to determine if any of the segments describing the term can be more completely described and whether there is another segment that can be described in more detail (step 940) : if yes, the current segment is utilized to limit the definition of the current term (step 945) and control transferred back to step 910; otherwise, the item is fully coded (step 950) and permanently saved (step 955) prior to finishing (step 960) .

With reference now to FIGURE 10, there is illustrated a methodology, generally designated by the reference numeral 1000, for reviewing and testing a coded tree according to the present invention. After starting (step 1005), a user logs onto Applicant's PIERS system, opens a patient file, goes into a SET runtime and opens an existing SET tree (step 1010) . Selection of a first node (step 1015) within the tree causes a tree object to give the tree a control identification to load (step 1020) , whereupon the database is accessed (step 1025) , particularly, the child control for this control. The associated PIE codes for the respective child control (s) are retrieved (step 1030) and all the obtained information from the database is retrieved: database information, PIE codes, patient ID, date, etc. (step 1035) . The user can then modify or otherwise choose various functions and controls (step 1040) , additions/deletions (step 1045) mode, storage (step 1050) and a determination whether the user has then selected another node: if yes, control reverts back to step 1020; otherwise, the routine finishes (step 1060) .

Basic Definitions; Attribute: a characteristic or quality describing data gathered during a patient encounter Control: a data entry box or tool used to record patient encounter data into a form. A control may be items such as an edit box, a check box, a single or multi select list box, a numeric, time or temperature keypad, graphic control, or a clear or select button, etc.

Form: an organized combination, arrangement or style of controls and attributes used to record data about a patient encounter

Graphic Control: a data entry box containing some type of graphical image used to record patient encounter findings

Hot Spot: a specific area or trouble spot marked on a graphic control

The basic codes required for a Form are: A Procedure Segment is required if the data entry tool is for a procedure.

A Note Section is required on all forms that deal with history and physical . Certain Note Segments are Present Illness, Review of Systems, Family History, and Physical Exam.

A Body System and or a Body Part should be on each form although this is not necessary when dealing with a general form such as Chief complaint . Both should be included whenever possible.

A Problem/Finding is used to denote an Attribute and is typically the starting point for coding a present illness. An Insertion Point is used to indicate the level (hierarchical) that the first term of the control will reference. Insertion Points are removed when the hierarchy is connected. Edit boxes do not require insertion points. A Value Point is similar to an Insertion Point, but it is not removed. The Value Point assigns a number to an edit box to denote the term to which it applies. Present Illness:

Each form requires a Note Segment: Present Illness. The present illness note segment requires a body system and a problem/finding. The common Controls on the Present Illness use the following Segments, all of which are Descriptors: Onset, Duration, Frequency Pattern, Relieved by, Associated with, Exacerbated by, Progression and sometimes Quantity, Color, Character, Mode of Onset, Mode of Resolution, Severity, Location, and Radiation. Each Control also requires an Insertion Point. The Attributes on the Controls in Present Illness are mostly Value/Types and Subjects although the Segments Body Parts and Aspects are used to reference parts of the body. Numbers are also Value/Types and are used to denote days, weeks, etc. Problem/Findings are also used to denote Attributes. When coding Attributes for the Present Illness, the highest level starts with the Problem/Finding, and then the other Segments follow and modify the Problem/Finding. If there is no Problem/Finding then the Subject is next followed by the Body Part and then the Aspect. If a phrase ends in the word disease or syndrome then the Problem/Finding is listed as a compound phrase and does not need modifiers. Subjects are modified by Value/Type segments. Body Part is modified by Aspect.

Review of Systems:

The form always needs a Note Segment of Review of Systems, which also requires a Body System and Insertion Point. The Body System Segment may be the first part of a Control if multiple body systems are included on the same form. In the latter case only one Insertion Point may be on the form and all of the other information is at the beginning of each control . That is the body system information is repeated on each Control when it is not on the form. If the Control has multiple Attributes that are not common then the Body System Segment must be repeated at the beginning of each Attribute since is was not referenced at the control level .

Descriptors are used to clarify Attributes: For example painful hematuria could be coded as : Problem/Finding: hematuria Descriptor: associated with

Problem/Finding: pain

It would also be appropriate to code it as: Problem/Finding: hematuria

Problem/Finding: painful

Similarly, painless hematuria could be coded: Problem/Finding: hematuria

Descriptor: associated with Problem/Finding: pain

Value/Type: no, not, non Family History always requires the Note Section: Family History on the form. Past History always requires the Note Section: Past History on the form. Social History always requires the Note Section: Social History on the form. The codes on the Controls and Attributes for these three items are handled the same way as Present Illness. Some of the Controls in social history are not Descriptors; they are Subjects such as education, status, etc.

Physical Examination:

The form must always have a Note Segment: Physical Exam, Body System, and the Body Part. The Insertion Point must modify the Body Part. If the Body Part Segment is not included on the form it should be the first Segment on the control. The remainder of the Segments fall in the order appropriate for modifiers.

Procedures :

The form should start with the name of the procedure, the

Body System referenced by the procedure if indicated. The Body Part Segment should be next. The Note Segment:

Indication for Procedure is also required and should be on the first form. Preparation and medications are important terms for Procedures and should always be included.

Descriptor and Problem/Finding make up most of the Segments on the Controls.

Additional points to consider in reference to the present invention include the following:

• Descriptors are categories; i.e. 'caused by' and 'secondary to' are descriptors and are also synonyms • The 'subject' segment includes nouns, verbs, and gerunds .

• The segment 'value/type' includes modifiers, numbers, prepositions.

• The 'unit' segment refers to units of measure. A unit has a value associated with it; i.e. unit: day, value/type: three. On the other hand, daily is a value/type that does not have an associated number.

• Muscles are entered as compound terms and are Body Parts . • The segment 'Body part' refers to parts of the body that can be removed. Exceptions are chest wall, back, and abdomen. Bronchoaleveoli and alveolus are examples of body parts .

• Body parts that are adjectives should be used as the noun form, i.e. testicles for testicular and scrotum for scrotal .

• The 'aspect' segment refers to areas of the body.

We do not have a 'location' segment. Location is an element of the segment 'descriptor' .

• Right and left belong to the 'aspect' segment. The term 'both' is not an element. When we mean both, we code right and left. Bilateral is an aspect, we are not using the word both, and we made an exception for bilateral, which does mean both, both sides of the body. • When a modifier refers to a body part, it belongs to the 'aspect' segment. Examples include pedal, bronchoalveolar, pulmonic, pretibial, etc.

• Left upper quadrant, left lower quadrant are coded as LUQ and LLQ in the 'aspect' segment. When it refers to the breast as inner outer, we will make inner outer a modifier of the quadrants. That breaks them down into smaller more finely granular codes .

• Duodenum, cecum, and ileum are body parts not aspects of the colon or small bowel. • The 'body part' segment does not have plural terms for parts of the body that are limited to two. For example, to code legs, we will code leg, right, and left. On the other hand, when there are many multiples of body parts or whatever, we will have plurals of the terms. An example is vein and veins.

• Systemic disease such as liver cancer would be coded, Problem: cancer, body part liver.

• Tracts and ducts are areas that are aspects. Body system: gastrointestinal, Aspect tract. Urinary tract would be coded Body system: GU, Aspect: tract,

Aspect: urinary. Urinary tract infection would be coded, Problem: infection, Body system: GU, Aspect: tract, Aspect: urinary.

• The 'method' segment refers to laboratory methods, methods of examination such as inspection, palpation, percussion etc. , and any other procedural method. • The 'note' segment refers to parts of the medical note such as CC, PI, PHx etc.

• The 'Problem' segment is composed of diagnoses, symptoms and findings. Examples are, headache, nausea, diabetes mellitus and essential hypertension. They would be coded as, Problem: headache, Problem: nausea, Problem: diabetes, Value/type: mellitus, and Problem: hypertension, Value/type: essential. Examples compound terms are, Bartter's syndrome or Cushing's disease. They are coded, Problem: Bartter's syndrome and, Problem: Cushing's disease. Problems that end with syndrome and disease are always compound. Chronic Obstructive Lung Disease is coded Problem: Chronic Obstructive Lung Disease. The acronym COPD is a synonym.

• If the root of a word is a problem, then all words related to that root are problems, e.g., ulcerated.

• If the root of a word is a subject then all words related to that root are subjects, i.e., overlapping.

• The 'Procedure' segment is reserved for any procedure that exists in the CPT code. Tests, assays and biopsies are in the 'procedure' segment and are considered the same as diseases and syndromes under the 'problem' segment; that is, they are legitimate compound terms by the fact that it says test, assay or biopsy.

• The 'Drug' segment is reserved for drugs in the MediSpan database .

• The general segment refers to general categories such as, infectious disease, malignant disease, genetic and, congenital disease. This is comparable to the 'isa' in SnoMed RT.

• Indent insertion point for all controls.

• Don't need insertion point for Edit Boxes.

• Don't indent under body system.

• Associated with - means two events occurring simultaneously that may not be related.

• Secondary to - is the physiological cause.

• Precipitating factors - a stimulus that occurred prior to the phenomenon caused the phenomenon. • Related to - means as long as it occurs the phenomenon exists, (concurrent) • In the PE note section the body part comes before the problem.

• Classification :

o Problem: xyz ^■ Subject: classification

• Method: Keith Wagener, Duke, etc

o Unit: grade, stage, etc.

^■ Value/type: 1,2, ABC, etc.

• When two elements can each separately modify a parent then each of the two children should modify at the same level .

• If indenting does not add meaning, it is understood to not employ indenting.

• A descriptor comes after what it's describing. With reference now to FIGURE 11, there is illustrated a computer system 1100 upon which a user may access, input and modify patient information pursuant to the teachings of the present invention. As shown in the figure, the computer system 1100 is interconnected with other computers, e.g., computer 1105, via an intranet or the Internet, generally designated by the reference numeral 1110. A mouse 1115, a keyboard 1120 and other devices, e.g., a scanner, transcriber or other device, generally designated by the reference numeral 1125, may receive or transmit information to/from the computer system 1100. Similarly, it should be understood that the computer system 1100 may comprise a conventional desktop unit, a portable PC or be a portable device configured to implement the teachings of the instant invention. Databases 1100A and 1105A, as well as other memory storage systems, may be employed to store, distributed or local, the information pertaining to a given patient.

The previous description is of a preferred embodiment for implementing the invention, and the scope of the invention should not necessarily be limited by this description. The scope of the present invention is instead defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A medical information system for encoding a plurality of medical information about at least one patient, said medical information system comprising: a storage device for storing said medical information; and coding means for coding said plurality of medical information, said coding means comprising a hierarchical code structure having a form means, a control means and an attribute means, each element of said medical information having a given form means, a given control means and a given attribute means associated therewith.

2. The medical information system according to claim 1, wherein said form means, control means and attribute means are hierarchically linked together.

3. The medical information system according to claim 1 further comprising: data input means for modifying said medical information pertaining to a given patient.

4. The medical information system according to claim 1, wherein said plurality of medical information about said at least one patient comprises medical history, conditions and treatment information pertaining to said at least one patient.

5. The medical information system according to claim 1, wherein said coding means employs at least segment pertaining to said at least one patient.

6. The medical information system according to claim 5, wherein said at least one segment contains a plurality of terms therein, each of said terms corresponding to said elements .

7. A medical information device for encoding a plurality of medical information about at least one patient, said medical information system comprising: a display device for displaying said medical information; and coding means for coding said plurality of medical information, said coding means comprising a hierarchical code structure having a form means, a control means and an attribute means, each element of said medical information having a given form means, a given control means and a given attribute means associated therewith.

8. In a medical information system, a methodology for encoding a plurality of medical information about at least one patient, said method comprising the steps of: gathering, upon request of a user, said plurality of medical information about said at least one patient; and displaying said plurality of medical information on a display device, said plurality of medical information having a hierarchical code structure associated therewith and comprising a form means, a control means and an attribute means, each element of said medical information having a given form means, a given control means and a given attribute means associated therewith.

9. A database for storing therein a plurality of medical information about at least one patient, said database comprising: an interface means for interfacing with a requesting device; and coding means for coding said plurality of medical information stored therein, said coding means comprising a hierarchical code structure having a form means, a control means and an attribute means, each element of said medical information having a given form means, a given control means and a given attribute means associated therewith.

10. The database according to claim 9, wherein said coding means employs at least one segment pertaining to said at least one patient wherein said at least one segment is stored as a segment table within said database, and wherein said coding means stores said plurality of medical information about said at least one patient in a patient table.