Laboratory

Overview

The Laboratory Domain Information Model (DMIM) captures the information needed to support messaging related to laboratory observations, including specimen information where appropriate. In particular, the DMIM supports the needs of laboratory order processing, and results reporting, including microbiology.

Trigger Events and Control Acts

It is important to realize that messaging related to observations draws on common control structures particularly the ControlAct. For a discussion of these structures, please refer to discussion of the trigger event control act in the Message Control Act Infrastructure Domain within Infrastructure Management. When an Observation-Act (event, order, or promise, and any Act in general) is created, it will include information such as who is responsible for creating the Act, who is responsible for entering Act related information, etc, which is captured as Participations of the Observation-Act (Participations are discussed below.) However, subsequent transactions on that same Act, such as cancellations, holds, suspensions, etc., will show the responsibilities for those transactions as participations to the ControlAct which represent the transactions (e.g., cancellation.) At the same time, the responsibilities associated with the original Observation-Act will continue to be maintained as participations of that Observation-Act.

Focal Classes Exposed

The model is focused on the Observation. In the chemical or physiological Laboratory, such Observations are also known as "tests".

Moods

The model supports transactions related to (a) orders, (mood = RQO), (b) promises (mood = PRMS), and (c) events (mood = EVN). That is to say, this model shows the Act in several moods. These moods distinguish the different aspects of the lifecycle of an observation. These moods, which are central concepts for the D-MIM, are defined as followed.

• RQO (Request): An Observation-order is a request for the performance of an Observation. Typically the request is made by a clinician, and recorded within one computer system, and then transmitted to a second system for performance.
• PRMS (Promise): An Observation-promise is the statement of commitment to perform an Observation as specified in the promise. A promise could be triggered by the receipt of an order message across a messaging interface, or it could be triggered by a phone call or verbal request from the ordering clinician, or could be triggered spontaneously based on certain business rules or other decisions made by a performer of another Observation.
• EVN (Event): An Observation-event records the performance of an Observation including its obtained results (if any).

Components

It is important to note that a laboratory act is not an atomic thing. An act can be composed of components. This is a general principle, and allows composite acts to be constructed with any desired and appropriate sub-component structure. This structure accommodates a number of functionally relevant situations. For example, a laboratory may define a test, such as CBC (Complete Blood Count), which is a combination of several individual tests. This allows several related tests to be initiated with a single order or intent. Composite tests or batteries are created to support several different functional situations. It is also possible to create tests that require a series of acts extending over a period of time for their completion, and for the creation of a meaningful result, for example a glucose tolerance test. In this case, an individual test is ordered, and broken down into components each of which is performed at a particular time, by particular participants.

An Observation can be composed of multiple steps. Each step is treated as an order, promise or event in its own right. For example, when an order is defined for communication to another system, that order could be composed of several steps and the sending system might want to communicate this structure to the receiving system. That is done by associating each component with its composite via the ActRelationship of type component. A promise might be broken into components in response to a simple order to reflect the need to schedule the different steps with separate resources. Events are of course split into components to report individual results.

Fulfillment

Observations in different moods are linked by the fact that promises can be created to fulfill orders, and events can be created to fulfill promises.

The reader should note that some relevant model structures such as order, promise, and event do not appear as such in the laboratory DMIM. These are subsumed and represented by the acts found in "ActChoice". By the same token, recursive relationships to ActChoice such as Component, Replacement, and Fulfillment discussed above are all replaced by a single ActRelationship labeled "sourceOf/targetOf". This has been done to reinforce the key notion that attributes, and participations are consistent (even if not universally) relevant across all the moods of Act. Another benefit is that the model becomes more compact. It is also important to note that Refined-Message Information Models (RMIM's) do expose the different moods and Act.classCodes of the involved acts as independent clones.

Laboratory Domain Information Model Classes

Entry into the DMIM is through the ActChoice. There are two classes within the ActChoice box, Observation and Act. The need for the Observation class is obvious, laboratory results are observations. The Act class is present to support report headers, substance administrations, procedures, etc. that are also needed in models created from this DMIM.

The ActChoice has the following Acts:

ActChoice 1:

Observation: The observation class captures information pertinent to an Observation-Act across its many moods. This is the central concept of the DMIM, and all the other classes shown are only interesting and relevant in relationship to this Observation-Act. The relevant information items, the attributes and associations have a consistent meaning for observation definitions, for orders, for promises, and for events.

ActChoice 2:

Act: The unconstrained Act class is present in the DMIM to support modeling in RMIM's which do not derive from Observation. For instance in the Order RMIM the PlacerGroup the Act.classCode is not OBS (Observation), instead it is ENTRY (a header grouping other acts).

ActChoice Act Relationships

The following act relationships are defined for an act. In principal, any of these associations can be valued for any of the ActChoice's moods. However, depending on the mood, the semantics of the act relationship can vary. For example, in event mood, the consentEvent captures the consents given for the act; in definitional mood the consentEvent(s) would indicate the consent types that are necessary for the act. Each association captures the relationship between the act and another act that plays a significant part in the order, promise, or event.

• sourceOf/targetOf: This fundamental act relationship captures all the ways that one act can be linked to another. As a general matter, it is possible to link any act to many other acts. Several different ways of linking acts have been identified. These have been subsumed within a single ActRelationship in this D-MIM but are distinguished by the ActRelationship.typeCode. Some of the most significant of these ActRelationship.typeCodes are exposed below. Note, in some cases, RMIM's will clone this act relationship class in order to single out particular ways in which one observation is linked to another:
  • Relationship to Observation Step (COMP): Supports the creation and communication of order panels, batteries, and complex tests and results whose steps need to be exposed for transmission to the sending system. Note, an observation step is a part of one and only one observation.
  • Relationship to Replacement (RPLC): Makes it possible to identify a prior order (or report) which this one replaces.
  • Relationship to Observation Definition (INST): A link to the definition information associated with this particular type of order.
  • Relationship to Promise or Order that is being fulfilled (FLFS): This relationship links an act to the promise or order that it fulfills.
  • Relationship to Normal Ranges (REFV): Provides a way to evaluate the information associated with an observation value by offering interpretations of possible related values.
  • Relationship from Occurrence to its repeating Act (OCCR): Links all the individual occurrences of a repeating Act to that repeating Act (aka "parent").
  • Relationship to a Note (Annotation) (SUBJ): Any of the ActChoice Acts may the subject Of Annotations. These Annotations handle any sort of text-based notes or comments regarding the associated act. The annotation includes author and data enterer participations to the R_AssignedEntity CMET.
  • Relationship to Control Act (SUBJ): Any of the ObservationEventChoice Acts may the subject Of a control act. These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query repsonses and composite order communications. The control act includes authorOrPerformer participations to the R_AssignedPerson and R_AssignedDevice CMETs in a ParticipationChoice box . The control act includes overseer, dataEnterer, and informationRecipient participations to the R_AssignedPerson CMET as appropriate.
• componentOf(Encounter): The encounter in the context of which this act occurs. The patient encounter is an act extending over a period of time that becomes a container (for both clinical and financial analysis) for acts related to an instance of patient care. Encounters are most frequently created to support patients receiving inpatient care. Encounter information is contained in the A_Encounter CMET.
• subjectOf3(ConsentEvent): The record of a patient's or patient representative's consent to this act. The particular use case for this consent to be attached to typically an order is for advanced beneficiary notices. Consent information is contained in the ConsentEvent class. Note that the ConsentEvent is not the consent document itself, rather it records that the consent took place.
• controlVariable(OrderOptions): The acts within the ActChoice may have control variables associated with them. The control variables are represented by the A_ControlVariable (universal CMET). The A_OrderOptions CMET is used to specify additional information specific to laboratory orders. The information provided can be used by automation systems to specify additional configurable parameters related to the automated analysis of a specimen.
• subjectOf2(Annotation): Notes or annotations (text-based) for the associated act. The A_Annotation CMET is used to specify this information.
• subjectOf1(ControlActEvent): The action which directly affects the associated target act. Having a control act for each act in a compositional hierarchy allows for fine-grained control over the actions for each act in the hierarchy.
• component(ProcessStep): The acts within the ActChoice may have process steps associated with them.
• pertinentInformation(SupportingClinicalStatement): Each act has, as pertinent information, zero to many other acts. This association makes it possible to link an act with another act that provides supporting information of some kind. This information is contained within the A_SupportingClinicalStatement CMET. Note that observations pertinent to the patient and part of the patients medical record should be carried in the R_Patient clinical CMET (see recordTarget below).
• reason(SupportingClinicalStatement): Each act has, as a reason, zero to many other acts. This association makes it possible to link an act with another act that provides a reason for the act. This information is contained within the A_SupportingClinicalStatement CMET.
• derivedFrom(SupportingClinicalStatement): Derivation only applies to Observations. An Observation may be derived from another observation. The SupportingClinicalStatement CMET is used to carry the observations from which the Observation is derived.

ActChoice Participations

The following partipations are defined for any ActChoice. In principal, any of these associations can be valued for any of the ActChoice moods. However, depending on the mood, the semantics of the participation can vary. For example, in event mood, the entering device for an act captures the device that recorded an act; in definitional mood the entering device(s) would indicate a device type (or actual physical device) that was capable of capturing the act. Each association captures the relationship between the act and an entity that plays a significant part in the order, promise, or event.

The following participations may be associated with each of the choices in ActChoice.

• recordTarget(Subject): The medical record that holds the documentation of this ActChoice. In other words, the party that the ActChoice "is for". A subject may be a person , animal (non-person living thing) or investigative subject. An ActChoice that is a step or component of another act can inherit the patient context from that act and does not need its own recordTarget participation. Patient information is specified with the R_Patient [clinical] and R_Patient [universal] CMETs. Note, in many cases acts are associated with pertinent clinical information to support the need to provide information, e.g., weight, sex, body surface area, to assist with performance of the act and/or with its interpretation. These observations are defined within the R_Patient [clinical] CMET. These pertinent observations will be available here if they are part of the patient's medical record.
• author(AssignedEntity): The party that is responsible for creating the ActChoice. For orders, this is the party who placed the order, for events, the party who principally authors the test result/report (commonly known as the filler). Information about the author is captured in the R_AssignedEntity CMET. This CMET can represent the individual author and the organization that the author represented in this act, either one or both can be specified.
• verifier(AssignedEntity): Parties who verify information related to the ActChoice, and who may have the responsibility of reviewing authorization of the act. For example, a resident writes an order and needs countersignature by a staff physician. Similar things can happen for results. Verifier information is defined within the R_AssignedEntity CMET. This CMET can represent the individual verifier and the organization that the verifier represented in this act, either one or both can be specified.
• transcriber(AssignedEntity): The transcriptionist who enter the information of the act. In some cases, multiple parties will be involved. In other cases, the identity of the party involved could be inherited from the context, or may not need to be communicated as part of the act. Transcriber party information is defined within the R_AssignedEntity CMET. This CMET can represent the individual transcriber and the organization that the transcriber represented in this act, either one or both can be specified.
• informationRecipient(AssignedEntity): Includes urgent notification contact (a.k.a. callback) and secondary recipients (a.k.a. trackers, result-cc). If these information recipients are attached to the order, the fulfiller is required to notify and copy respectively. Information recipient information is defined within the R_AssignedEntity CMET. This CMET can represent the individual informationRecipient and the organization that the informationRecipient represented in this act, either one or both can be specified.
• performer(PatientOrAssigned): The party who takes part in actually carrying out the act. In event-mood, the actual performer, in order or promise mood the designated performer. There may be multiple performers because several parties may collaborate in performance of the act. There may not be any specified, because these details will be left to the discretion of the author of the event. Performer is not required.
• callBackContActChoice(NotificationParty): The party to be contacted regarding the act if the author is unavailable. Call back contact information is specified with the R_NotificationParty CMET.
• dataEntryLocation(LocationLocatedEntity): The location where the information for the act was entered. Location information is specified with the R_LocationLocatedEntity CMET.
• specimen(Specimen): The subject is the entity that is directly acted on by the test. This participation deals with acts that are done directly on a specimen. That is to say, the subject of the test, if one is recorded, is a specimen. A specimen is an item of material, usually taken or extracted from a source, possibly the patient. Specimen information is defined within the R_Specimen CMET.
• device(LabTestKit): The lab test kit device used by the act. Lab test kit information is specified with the R_LabTestKit CMET.
• consumable1(LabTestKit): The lab test kit is a consumable used by the act. Lab test kit information is specified with the R_LabTestKit CMET.
• consumable(Reagent): A reagent is a chemical substance that, by causing, catalyzing or otherwise taking part in a chemical reaction with the specimen, brings forth a measurable effect from which the observation result is inferred. Reagent information is specified with the R_Reagent CMET.

Laboratory Domain Derived CMETs

The Laboratory Observation domain defines a number of Common Message Element Types (CMET) as well as messages. Each of the CMETs discussed below represents a specialized or particular use of the Laboratory Observation DMIM. These CMETs are further discussed within the Common Message Element Types Domain under Common Domains.

• A_OrderOptions: Order options allow the recording of control information related to the performance of an order. Currently, this CMET is used to support the needs of messaging related to laboratory automation.
• R_LabTestKit: A test kit that is used in the laboratory testing process. The LabTestKit role is structured as follows:
  • LabTestKit: The lab test kit is a manufactured product role played by a manufactured material entity (TestKit). The role is scoped by the organization (E_Organization) manufacturing the test kit.The scoping organization is mandatory when the manufactured material entity (TestKit) lotNumberText attribute is populated.
  • Organization: The entity that manufactured the lab test kit product.
  • TestKit: The manufactured test kit representing the actual lab test kit.
• R_Reagent: A chemical that is used in the testing process. The Reagent role is structured as follows:
  • ManufacturedProduct1: The reagent in the role of a manufactured product. The manufactured product is scoped by an organization entity (the manufacturer). The manufactured material role is played by a manufactured material entity (TestReagent).
  • Organization: The entity that manufactured the reagent product.
  • TestReagent: The manufactured material representing the actual reagent.

Microbiology Overview

Microbiology presents some interesting challenges when trying to maintain a common representation of structured result data relating to specimens, isolates and observations carried out on them.

The exact way in which the various attributes of the Entities and Acts are populated partly depends on the terminology being used. Some terminologies combine multiple axis vocabularies into a single attribute or allow for the 'post-coordination' of codes in a CD datatype. However, the principle of the relationships between the entities and the acts will remain the same.

In this document, a text description of what the code would represent has been used rather than examples of codes from specific terminologies.

Content

This example will identify the recommended method for the carriage of the results obtained from the culture of a single specimen which results in the isolation of an organism and its associated susceptibility results. This profile was agreed in discussion with delegates from the international community within the HL7 Lab Work Group.

Data to be communicated:

Lesion Swab Ulcer; Right Foot

• Observations:
  • Gram Stain: Gram Positive cocci
  • Aerobic Culture: Heavy growth of Staphylococcus

Culture results are processed and any significant pathogens identified and worked up. In this example, one isolate is represented but the structure allows for multiple isolates by repetition of the SpecimenObservationCluster (see below) as components of the Event act.

• Isolate:
  • Staph aureus

• Antibiotic Sensitivity:
  • Ampicillin Sens test - Sensitive etc (repeated for each antibiotic)

Representation:

Note: The model fragments have had attributes removed in order to concentrate on the significant ones for demonstration purposes.

Lab Report:

Because of the nature of the microbiology report and the need to relate observations to the material (Specimen/Isolate) on which they were performed, an 'Organizer' (entry) is used to organize the multiple components of the report. This serves to link the original specimen to observations carried out upon it as the 'Subject' of those observations and to link any isolate entities both back to the original sample and the test(s) reported upon the isolate itself. These may be more than just susceptibility tests but this example will concentrate on these specific tests.

This example deals with the 'Final' report on the completed laboratory testing but this does not preclude the ability to message 'Partial' results such as the initial observations in an earlier message utilizing the same profile.

The Organizer may carry a generic act.code such as 'Lab Report', or be more specific such as 'Microbiology report'. It may also be left blank. Where a code is carried, this should represent the report as a whole and will depend on the available codes in the terminology.

Specimen Information

The Report act has a 'Subject' relationship to the specimen on which the results of the tests reported were performed. This links these observations to the specimen. The details of the specimen are carried in the Specimen CMET and consist of:-

• Specimen Entity: which carries the code for the actual entity (Specimen Type etc) which in this case is a serum or urine sample. Depending on the terminology, this may contain more detail but it always carries some representation of the specimen type.
• Specimen Role: which carries the specimen identifier.
• Specimen collection process (Procedure) of which the specimen is a product. This carries:
  • the collection process code (Specimen collection, timed collection etc)
  • the target site code (Ulcer, Right foot)
  • the effective time (collection Date/Time)

In some terminologies, the target site information may be carried as part of the specimen type. Correctly done, this should be equivalent with carrying the information in the target site attribute.

Any specific criteria that may apply to the collection (e.g. Post dose) would be carried in the Criterion act. (Some terminologies incorporate this into the collection process or the specimen type). There are none in this example.

Specimen Observations

The Entry has one or more component observations which carry the results of observations carried out on the specimen itself.

The Observation.code carries the terminology code for the observation/lab procedure. (Gram Stain, Aerobic Culture etc) and the result of that observation is carried in the Observation.value. This may be done as a 'List' of values or by providing a separate Observation for each.

Alternatively, if the system allows and terminology used has the appropriate values, a Gram observation in which multiple observations are made carry these as components of the Gram Stain.

Separate observations under the Gram stain act

Batteries of tests (not shown) may also be performed on the initial specimen and are represented as component acts (BATTERY Class). Each Battery may have multiple component Observations (OBS) each utilizing the code/value of the observation to convey the observation and result information.

Isolates and Observation on Isolates

Isolates revealed by the culture process and their results that are going to be reported are organized by a SpecimenObservationCluster, of which the Isolate is the subject, which is a component of the Report Event. The 'Specimen' Entity associated with the SpecimenObservationCluster carries the code for the isolate in the Entity and the isolate ID in the Role, the specimen role also identifies that this is an isolate.

For ease of representation only one isolate is depicted in the model fragment. Each additional isolate shall be carried as a separate 'component' of the Entry class.

The SpecimenObservationCluster may carry an act.code such as 'Isolate Identified'. A link should be made between the Isolate and the observation that first revealed it using the ActRef in the Specimen CMET to carry the ID of the source observation or by restating the Procedure.

For reporting results on each isolate, each SpecimenObservationCluster has a number of components. In this example, there is an observation 'amount of growth' and a susceptibility battery of observations that carry the results of the susceptibility testing for that isolate. Identification tests could equally be carried either as individual tests (Serotyping, Catalyze, API Profile etc) or as a battery of Identification Tests.

The Observation that carries the Amount of Growth carries an ObservationEvent.code identifying the act as 'amount of growth' and a value which is a qualitative or quantitative representation of the amount of growth (+++; >106cfu/ml).

The susceptibility battery carries a ObservationBattery.code identifying it as a Susceptibility 'Panel' and the component observations carry Susceptibility test and antibiotic as the ObservationEvent.code, the method, unless combined in the observation code, in the ObservationEvent.method, the interpretation of the test (S,R,I) in the ObservationEvent.interpretationCode.

Any zone size measurement, MIC etc shall be carried in the ObservationEvent.value. The following attribute is not used for susceptibility test results:

• ObservationEvent.reasonCode

General Chemistry Overview

This General Chemistry example will identify the recommended method for carrying the results obtained from the order of a single test or a battery (panel/profile).

Data to be communicated:

ObservationEvents:

• Creatinine, Serum
• Creatinine, 24 Hour Urine
• Body Surface Area
• Urine Volume
• Urine Flow Rate

Supporting Clinical Statements:

• Height Centimeters
• Height Inches
• Weight Kilograms
• Weight Pounds

Other Information:

• Specimen Collection Date/Time

Some of these observations may or may not be reported depending on the lab processing the result. All values are needed to calculate the result.

Lab Report

This example deals with the 'Final' report on the completed laboratory testing but this does not preclude the ability to message 'Partial' results such as the initial observations in an earlier message utilizing the same profile.

The Organizer may carry a generic act.code such as 'Lab Report', or be more specific such as 'Chemistry report'. It may also be left blank. Where a code is carried, this should represent the report as a whole and will depend on the available codes in the terminology.

Specimen Information

The Report act has a 'Subject' relationship to the specimen on which the results of the tests reported were performed. This links these observations to the specimen. The details of the specimen are carried in the Specimen CMET and consist of:-

Any specific criteria that may apply to the collection (e.g. Post dose) would be carried in the Criterion act. (Some terminologies incorporate this into the collection process or the specimen type). There are none in this example.

• Specimen Entity: which carries the code for the actual entity (Specimen Type etc) which in this case is a serum or urine sample. Depending on the terminology, this may contain more detail but it always carries some representation of the specimen type.
• Specimen Role: which carries the specimen identifier.
• Specimen collection process (Procedure) of which the specimen is a product. This carries:
  • the collection process code (Specimen collection, timed collection etc)
  • the effective time (collection Date/Time)

Any specific criteria that may apply to the collection (e.g. Post dose) would be carried in the Criterion act. (Some terminologies incorporate this into the collection process or the specimen type). There are none in this example.

Specimen Observations

The Entry has one or more component observations which carry the results of observations carried out on the specimen itself.

Individual ObservationEvents (Results) and ObservationBattery (Panel/Profile)

The ObservationEvent.code or ObservationBattery.code carries the terminology code for the observation/lab procedure. (Creatinine Clearance) and the result of that observation is carried in the ObservationEvent.value. This may be done as a 'List' of values (e.g. ObservationBattery grouping one or more ObservationEvent instances) or by providing a parent ObservationEvent and one or more child ObservationEvents or by providing a single ObservationEvent.value.

Batteries of tests (not shown) may also be performed on the initial specimen and are represented as component acts (BATTERY Class). Each Battery may have multiple component ObservationEvents (OBS) each utilizing the code/value of the observation to convey the observation and result information.