FHIM::Lab::_Lab Diagram _Lab This is the main diagram for the Laboratory domain. As noted in the package documentation, this domain is concerned primarily with laboratory orders and result reporting.There are four potential "focal classes" or "entry points" to this model, which are the Specimen Collection Request, the Laboratory Request, the Specimen Collection Promise, and the Laboratory Promise. This allows use cases to begin with either the Request (aka the order), or the Promise (which is the order from the perspective of the filling service). It is important to note that the two Request classes are subtypes of a more general Healthcare Order class, and the two Promise classes are subtypes of the more general Healthcare Promise class. These classes therefore inherit all the properties of the respective super types, which are described in the Orders package. See the Orders domain for more details.Laboratory processes begin when a clinician orders a test. Logically, there exist simultaneously two orders: one to the laboratory to perform the test, but also one to obtain specimen(s) from the patient. In practice, the order to the collect the specimen is not written or even articulated, but rather occurs automatically according to some pre-determined set of policies and procedures. For example, an outpatient doctor orders a lipid panel. The office personnel direct the patient to the phlebotomist down the hall who draws the appropriate amount of blood (into the appropriate tubes), all based on standing procedures. In this case, there is no separate specimen collection order. But in other cases, the patient may be sent to the laboratory, and an order is communicated to the laboratory to direct them to collect the specimen. Furthermore, the “promise” to conduct the specimen collection is rarely articulated, it simply occurs based on standard procedures. Nevertheless, these concepts logically exist, and the FHIM contains both the specimen collection request and promise, even though the properties often might be blank or might repeat data found in the laboratory test request and promise.The specimen collection request / promise process will usually result in one or more Specimen Collection Events during which one or more Specimens are collected. The Specimen Collection Event class describes the event, the specimen(s) collected, who performed the collection, and where the collection occurred. The Specimen class describes each specimen, the container(s) in which the specimen is contained, and any processing that was performed on the specimen. The class also links to information regarding transport or storage of the specimen to include temperature information. The specimen transport classes will be expanded in the future to accommodate chain of custody information. The Specimen class is also associated with a Defined Patient Event class that links the specimen to a particular event or condition, for example blood drawn before or after a glucose challenge. Once the specimen is collected, Assessments may be made over time to determine the appropriateness of the specimen for various laboratory procedures.The Lab Test Promise class is the record of the order from the laboratory’s perspective. The Promise might be related to other promise(s) or might be referred to another laboratory, the results from which are collated and reported by the originating laboratory to the ordering clinician. The laboratory will typically assign one or more Accession numbers to the promise; these accession numbers are typically closely associated with the specimen received. The laboratory will perform various procedures and tests. A link to the common Procedure class is provided to accommodate billing procedures (typically CPT codes), which are often at a different level of granularity from the lab test codes (typically LOINC or SNOMED codes) used to identify the test. It is noted that a single class (LabTest) is used for the test ordered, the test promised, and the test performed. The values for the instances of LabTest may come from different coding systems and may be of different levels of granularity. For example, a clinician might order one Chem 7 using a local order code, the lab might promise a Chem 7 using LOINC, and the results will be reported as seven individual tests (blood urea nitrogen, serum sodium, etc.) using LOINC.The results of the test and any information concerning procedures performed are accommodated by the Reportable Results class. Subtypes of this class accommodate differing data structures that are associated with broad categories of results. For example, the Measurement With Reference Range is intended for tests that result in a numeric or ordinal value, such as the concentration of potassium in a blood sample (e.g. 4.5 mmol/L), the ratio of blood urea nitrogen to creatinine (e.g., 17), or the turbidity of a urine sample (e.g., cloudy). Another common characteristic is that many of these tests have an associated reference range, which describes the range of values (low and high) considered to be normal in healthy individuals. For a given test, there may be multiple normal ranges depending on such factors (Reference Range Criterion) as the patient’s age, gender, or race.Another category of tests and results is the identification of microbes in a sample, such as bacteria, parasites, or viruses. Upon receipt, a portion of the sample is placed in a culture medium and allowed to grow. Often a stain test is performed to identify the category(ies) of microbes present. Later any organisms found are identified, along with an indication of the number of organisms (i.e., bacteria are often measured in colony-forming units). If the microbes are bacteria, an antibiotic sensitivity test may be performed as well. If the microbes are parasites, an additional observation is noted with respect to whether adults, larvae, eggs, or some combination, are present. A key characteristic of these tests is that the overall process requires considerable time, so intermediary reports are created and sent to the ordering clinician as information becomes available. Therefore, multiple results will be sent for a single ordered test, typically with some kind of status indicating that the report is a preliminary or intermediate finding. Each subsequent revision generally will include all the text of the previous report(s), until the last report, the status of which will be marked as Final. It is noted that even Final reports can be amended, although not routinely so – final reports will generally be amended to correct or augment previously reported information. The Related Result class is used to link the versions of the report, usually by using replaces/replaced by relationships.Note also that multiple personnel may be involved in the performance of tests, especially microbiology cultures, which require more than a day to complete. The potential for multiple Reportable Results to exist for one Lab Test Promise also allows for the identification of the multiple persons involved.All Reportable Results can have an interpretation associated with it. The Interpretation Event class contains the interpretation as either a code or a free-form text or both, and indicates who provided the interpretation. Reportable Results can be transcribed, especially for pathology reports. The Transcription Event provided the date/time of the transcription and identifies the transcriptionist. The Comment Event allows for any individual in the process to add remarks; the author of the comment event identifies the person making the comment. Reportable Results may identify the device(s) used to produce the results – the association to Device Instance provides access to Common Product model hierarchy which contains the manufacturer model number, etc. as needed.A separate Reportable Result sub-type exists to report Test Exceptions. This sub-type would be used to communicate reasons why a test was unable to be performed. It may indicate that the quantity of specimen was insufficient, that the specimen was contaminated, that the specimen is inappropriate for the kind of test ordered, etc.Finally, there is a subtype of Reportable Result for Pathology Results. Pathology results generally take the form of documents, which in turn are composed of sections containing free-form text. The College of American Pathologists lists a number of sections that a well-formed pathology report should or may contain. The Pathology Result class therefore is comprised of Lab Report Sections, the Section Title of which should come from some pre-defined vocabulary. The report may also contain images and diagnoses. It is noted that this entire structure could easily be replaced by a Clinical Document; in the future we may point to Clinical Document rather than maintain a separate Pathology Result structure. On the other hand, we may wish to be more specific in this model, defining the specific kinds of sections directly in the model.
