 ANSI/HL7 V3 LBRESULT, R1-2009 HL7 Version 3 Standard: Laboratory; Result Topic, Release 1 12/15/2009 |
Content Last Edited: 2011-07-13T15:35:19
2.2 Storyboards
2.3 Application Roles
2.4 Trigger Events
2.5 Refined Message Information Models
2.6 Hierarchical Message Descriptions
2.7 Interactions
This topic covers Laboratory Observation Events, commonly called Results. The topic includes the storyboards, application roles, trigger events, static models and interactions for results.
Times in Laboratory Messages
Identification of the Effective Time of a Laboratory Observation Event (Result):
Identification of the Effective Time of a Laboratory Observation within the Laboratory domain, the 'Clinically Significant Time' of an Observation is generally the collection time of the specimen which was the 'Subject' of the ObservationChoice. This may be a Point in Time (TS), an Interval IVL [TS] or a more complex time component (GTS). In the Laboratory Result ObservationEvent messages, this is carried as the effectiveTime.
The Specimen CMET provides the Time of Collection which is carried as the effectiveTime in the collection procedure (PROC) act.
The Laboratory messages allow for both an Order Centric and a Specimen Centric message structure.
Irrespective of the focus, Observations are carried out in the context of a specimen when it is either directly related to the individual observation or conducted down to it, via context conduction, through a parent ObservationEvent OBS or one of the other ObservationChoice Organizer classes (ENTRY, BATTERY, CLUSTER).
It should not be necessary to repeat the effectiveTime in any act for which there is a 'Specimen' with a collection time unless that time needs to be overridden. So, the effectiveTime of the specimen collection act is taken as the effective time of all observations carried out on that specimen.
If as individual observation carries an effectiveTime, this will override the effectiveTime conducted from a specimen.
Where an Organizer class carries an effectiveTime, this will provide the effectiveTime for all component acts unless specifically stated with a specific component act. Thus a Battery may carry an effectiveTime that applies to all component observations. It is not necessary to repeat the effective time for all components of an Organizer class unless there is a need to override the effective time stated in a parent act.
For Observations where there is no specimen involvement, the effectiveTime shall be carried in the focal ObservationEvent act, effectiveTime of the parent ObservationEvent act, or Organizer class author participation of the parent act.
For derived/calculated observations that are based on multiple specimens, the effectiveTime shall be carried in the ObservationEvent.
Identification of the Time an Observation was Made or Performed:
Where it is required that the time an observation was made or performed, the time is carried in the Participation relationship to the Performer. The Performer Participation time applies to all acts that fall within the context of that performer.
|
||||||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
The purpose of this storyboard is to illustrate a complex laboratory result message involving a substance administration and several specimen collections over a period of time. A preliminary and final report will be messaged.
Presentation
Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Patricia Primary. Eve reports extreme thirst, fatigue, and recent unexplained weight loss. She also reports having a family history of diabetes. Dr. Patricia Primary wants to rule out diabetes mellitus by performing a GTT2HR
Scheduling and order is out of scope for this storyboard
The GTT2HR needs to be scheduled with the lab. At this lab, the procedure is scheduled before an order can be placed. Patient is informed that they must complete an overnight fast prior to the test.
-
A clerk finds the order for the GTT2HR.
-
The system assigns the accession number, and prints specimen labels. The clerk notifies the phlebotomist to collect the fasting specimen.
-
The phlebotomist reviews the procedure, confirms that patient is fasting, and collects the fasting glucose specimen.
-
The initial specimen will be collected and immediately sent to the lab as a STAT.
-
The glucola will be administered and the remaining specimen collected after the report is reviewed.
Fasting Glucose Final Result
The fasting glucose result report is available and is within acceptable protocol range for the phlebotomist to proceed. A preliminary report is released by the laboratory (POLB_IN224100UV result in progress).
Preliminary Report (Report View)
Preliminary Report (Minimal View)
The Challenge
The phlebotomist collects and labels the remaining specimens based on the appropriate protocol for administration of the glucola and specimen collection. The following specimens will be collected:
-
Glucose 1-Hour post glucola administration
-
Glucose 2-Hour post glucola administration
The date and time of each specimen collection is recorded in the laboratory system and the specimens are delivered to the lab for testing.
Result Processing
Bill Beaker performs the tests, reviews the results and determines whether or not they are critical or panic values that would require immediate physician notification (none of them are).
Final Results
Upon the release of the results for the complete GTT2HR test, the laboratory system reports all the results in a single message (POLB_IN224200UV final result complete).
| Chemistry Observation/Test Name | Result Value/Flag | Units | Reference Range | Collection Date/Time | Observation Date/Time |
| Glucose Fasting | 80 | mg/dL | 65-99 | 10/31/2007 0700 | 10/31/2007 0710 |
| Glucose 1 Hour | 129 | mg/dL | <130 | 10/31/2007 0830 | 10/31/2007 1100 |
| Glucose 2 Hour | 202 HH | mg/dL | <130 | 10/31/2007 0930 | 10/31/2007 1100 |
Final Report (Report View)
Final Report (Minimal View)
Conclusion
Dr. Primary reviews and rules out diabetes mellitus and signs off the results on the result reporting system.
The purpose of this storyboard is to illustrate a laboratory result corrected.
Presentation
A 24-year old female, Eve Everywoman, presents at Community Urgent Care with severe headaches, numbness and tingling. Dr. Harold Hippocrates examines the patient and learns that she is employed in the Manufacturing Industry where she is exposed to Lead based products. Dr Hippocrates wants to rule out Lead poisoning.
Final Result
Bill Beaker performs the test and determines that the level is within OSHA guidelines. He releases the final report to Dr. Hippocrates.
|
Chemistry Observation/Test Name |
Result Value/Flag |
Units |
Reference Range |
Collection Date/Time |
Observation Date/Time |
|
Lead, Blood |
30 |
ug/dl |
< 40 |
12/24/2005 0830 |
12/24/2005 0900 |
Final Report (Report View)
Final Report (Minimal View)
The laboratory system sends the final result to the clinical information system (POLB_IN224200UV).
Physician Review
Dr Hippocrates reviews the result and questions the result because it does not appear to correlate with his diagnosis. He calls the laboratory and asks for the test to be performed again on the initial specimen.
Corrected Result
Bill Beaker re-runs the Lead Level on the initial specimen. He reviews the result and reports it out as corrected.
|
Chemistry Observation/Test Name |
Result Value/Flag |
Units |
Reference Range |
Collection Date/Time |
Observation Date/Time |
|
Lead, Blood |
111 HH |
ug/dl |
< 40 |
12/24/2005 0830 |
12/27/2005 1200 |
He notifies Dr. Stan Slide, Laboratory Pathologist of the discrepancy. The laboratory system sends the corrected result to the clinical information system (POLB_IN224201UV Result Corrected).
Corrected Report (Report View)
Corrected Report (Minimal View)
Panic Value Protocol
Bill Beaker initiates the panic value protocol which includes releasing the corrected result with note attached indicating that Dr. Hippocrates was notified on December 27, 2005 at 1200. The information is sent to the appropriate regulatory agencies governing Lead testing.
Conclusion
Based on the results, Dr. Hippocrates determines that Eve does have Lead poisoning and initiates chelation therapy. He continues other diagnostic testing to determine the cause of her pain.
The purpose of this storyboard is to illustrate a misreported final result for an incorrect patient. Nullified results are sent to the incorrect patient record and final results are reported for the correct patient.
Presentation
Eve Everywoman arrives at Good Health Hospital Emergency Room (GHH ER) with classic hepatitis symptoms. Dr. Eric Emergency issues a verbal order for the Acute Hepatitis Panel to Nancy Nightingale, GHH ER Triage Nurse.
Specimen Received in Laboratory
Oscar Orderly delivers the specimen to Rita Receptionist in the GHH Laboratory. Rita finds an order in the laboratory system for Evelyn Everywoman. She enters the date and time the specimen was received in the GHH Laboratory. The laboratory system assigns an accession number. (POLB_IN224000UV) Accession number assigned, specimen received in lab will be assumed. Rita applies the laboratory system-generated label on top of the hand-written label. This occurs because Rita mistakenly assumes that the name "Eve" on the specimen is shorthand for Evelyn. She delivers the specimen to Bill Beaker.
Final Results Reported
Bill Beaker enters the result for the Acute Hepatitis Panel test in the laboratory system. He reviews the results and reports them out as final.
|
Hematology Observation/Test Name |
Result Value/Flag |
Result Comment(s) |
Reference Range |
Collection Date/Time |
Observation Date/Time |
|
Hepatitis A IGM Antibody |
Non-reactive |
. |
Non-reactive |
11/20/2007 0730 |
11/20/2007 0800 |
|
Hepatitis B Core IGM Antibody |
Reactive / A |
Hepatitis B Core IGM Antibody has been detected in most acute infections and is a reliable marker for acute disease. |
Non-reactive |
11/20/2007 0730 |
11/20/2007 0800 |
|
Hepatitis B Surface Antigen |
Present |
. |
Not present |
11/20/2007 0730 |
11/20/2007 0800 |
|
Hepatitis C Antibody |
Non-reactive |
. |
Non-reactive |
11/20/2007 0730 |
11/20/2007 0800 |
Final Result -Data Error Misreported Result (Report View)
Final Result - Data Error Misreported Result (Minimal View)
He calls Dr. Emergency who is not available and leaves a phone message that results are available for Evelyn Everywoman. The laboratory system sends the final results to the clinical information system (POLB_IN224200UV).
Error Discovery
Later, Dr. Emergency accesses Eve Everywoman's record on the clinical information system to enter a progress note and to sign-off on the final results. He is unable to find the results in Eve's record. He notices in his electronic inbox that new results are available for Evelyn Everywoman. He reviews these and determines they belong to Eve Everywoman. He alerts Nurse Nightingale to follow the hospital protocol for an erroneous chart entry and authorizes the laboratory to release the results on Eve Everywoman.
Nullify Results
Nurse Nightingale alerts Rita Receptionist in the laboratory of the erroneous order. Rita retrieves the original specimen tube and determines that the original collection label had Eve Everywoman's name on it. Rita marks the final results for Evelyn Everywoman as erroneous and inactivates them on the laboratory system. The laboratory system sends a nullified results message indicating the data error to the clinical information system (POLB_IN224500UV).
Nullify Report (Report View)
Nullify Report (Minimal View)
Final Results for Correct Patient
Bill Beaker re-enters the results and reports out the final result on Eve Everywoman.
|
Hematology Observation/Test Name |
Result Value/Flag |
Result Comment(s) |
Reference Range |
Collection Date/Time |
Observation Date/Time |
|
Hepatitis A IGM Antibody |
Non-reactive |
. |
Non-reactive |
11/20/2007 0730 |
11/20/2007 0800 |
|
Hepatitis B Core IGM Antibody |
Reactive / A |
Hepatitis B Core IGM Antibody has been detected in most acute infections and is a reliable marker for acute disease. |
Non-reactive |
11/20/2007 0730 |
11/20/2007 0800 |
|
Hepatitis B Surface Antigen |
Present |
. |
Not present |
11/20/2007 0730 |
11/20/2007 0800 |
|
Hepatitis C Antibody |
Non-reactive |
. |
Non-reactive |
11/20/2007 0730 |
11/20/2007 0800 |
Data Error Correction of Misreported Result (Report View)
Data Error Correction of Misreported Result (Minimal View)
He calls Dr. Emergency who is not available and leaves a phone message stating that results are available for Eve Everywoman. The laboratory system sends the final results to the clinical information system (POLB_IN224200UV).
Conclusion
Dr. Eric Emergency reviews the final results and determines that Eve Everywoman has contracted Hepatitis B. Evelyn Everywoman's doctor is notified by phone of the error and that it has been corrected.
The purpose of this storyboard is to illustrate a microbiology result with isolate(s) including Minimum Inhibitory Concentration observations and interpretations.
Example used: Aerobic and Anaerobic Bacterial Cultures with Gram Stain
Presentation
Dr. Eric Emergency, an emergency room physician, sees a male diabetic patient, Adam Everyman, for an ulcer on the right foot with necrotic (dead) tissue. Suspecting an ulcer with infection, Dr. Emergency decides to order a Gram Stain, Aerobic and Anaerobic Culture.
Included in the microbiology storyboard are symbols intended to help explain the storyboard. The graphic below is an index of the symbols that are used in this explanation.
First Preliminary Report - Final for Gram Stain, Report to follow for Culture
Bill Beaker, a microbiology lab technician, receives the sample with the specimen source annotated on the container. He inoculates the specimen into various culture media in preparation for the Aerobic and Anaerobic Cultures. He then makes a smear on a glass slide and performs a Gram Stain. Frances Sella, a microbiologist, reads the Gram Stain. The Gram Stain report includes the following results:
Aerobic & Anaerobic Cultures with Gram Stain
Source: R Foot Ulcer
Report Status: Preliminary
Gram Stain: No White Blood Cells; Gram-positive cocci in clusters +; Gram-negative bacilli ++
Result Status: Final
Further results to follow
A first preliminary report is released by the laboratory (POLB_IN224100UV).
Second Preliminary Report for Aerobic Culture
The following morning Frances Sella reads the aerobic culture plates and observes a mixed growth of Staphylococus spp. and Coliform bacilli. No results are available yet for the anaerobic culture. The Second Preliminary report for culture reported the following results:
Aerobic & Anaerobic Cultures with Gram Stain
Source: R Foot Ulcer
Report Status: Preliminary
Gram Stain: No White Blood Cells, Gram-positive cocci in clusters +, Gram-negative bacilli ++
Result Status: Final
Aerobic Culture: (1) Staphylococcus spp. ++; (2) Coliform bacilli, scant
Result Status: Preliminary
Further results to follow
A second preliminary report is released by the laboratory (POLB_IN224100UV).
Third Preliminary Report for Anaerobic Culture
The next morning, Frances Sella observes the culture plates from the anaerobic culture and does not see any significant growth. The Third Preliminary for culture reported the following results:
Aerobic & Anaerobic Cultures with Gram Stain
Source: R Foot Ulcer
Report Status: Preliminary
Gram Stain: No White Blood Cells, Gram-positive cocci in clusters +, Gram-negative bacilli ++
Result Status: Final
Aerobic Culture: (1) Staphylococcus spp. ++; (2) Coliform bacilli, scant
Result Status: Preliminary
Anaerobic Culture: No Growth
Result Status: Preliminary
Further results to follow
A third preliminary report is released by the laboratory (POLB_IN224100UV).
Final Result
One day later, Frances Sella reads the sensitivity tests results. She now releases the final results for the entire report, including the gram stain, aerobic and anaerobic cultures and susceptibility tests:
Aerobic & Anaerobic Cultures with Gram Stain
Source: R Foot Ulcer
Report Status: Final
Gram Stain: No White Blood Cells, Gram-positive cocci in clusters +, Gram-negative bacilli ++
Result Status: Final
Aerobic Culture: (1) Staphylococcus aureus ++; (2) Klebsiella oxytoca, scant
Result Status: Final
Anaerobic Culture: No Growth
Result Status: Final
ANTIMICROBIAL SUSCEPTIBILITY REPORT
| ISOLATE #1 (S. aureus) | ISOLATE #2 (K. oxytoca) | |
| ANTIMICROBIAL AGENT | MIC INTERP | MIC INTERP |
| AMPICILLIN | > 16 R | |
| CEPHALOTHIN | <= 2 S | |
| CIPROFLOXACIN | <= 0.5 S | |
| LEVOFLOXACIN | > 4 R | |
| GENTAMICIN | > 8 R | |
| OXACILLIN | 0.5 S | |
| IMIPENEM | <= 1 S | |
| VANCOMYCIN | <= 1 S |
| INTERPRETATIONS: |
| INTERP = "NCCLS" INTERPRETATION |
| S = SUSCEPTIBLE (SHOULD BE INHIBITED ATUSUAL DOSAGE) |
| I = INTERMEDIATE (MAY BE INHIBITED AT MAXIMUM DOSAGE OR WHERE DRUG CONCENTRATES - I.E. IN URINE |
| R = RESISTANT (WILL NOT BE INHIBITED AT USUALLY ACHIEVABLE LEVELS) |
| MIC = MINIMUM INHIBITORY CONCENTRATION |
| NP = "MIC" WAS NOT PERFORMED;INTERPRETATION IS BASED ON DISKDIFFUSION (KIRBY-BAUER) METHOD |
| NR = NOT REPORTED (SUSCEPTIBILITY RESULT IS NOT REPORTED IN ACCORDANCE WITH NCCLS GUIDELINES) |
Result Status: Final
A final report is released by the laboratory (POLB_IN224200UV).
Conclusion
Based on the gram stain results, Dr. Eric Emergency suspects a mixed Staphylococcal and gram negative infection. He debrides the ulcer and decides to give the patient treatment of 10 days Tamoxifen for the ulcer and Levofloxacin to treat the infection. He then advises Adam Everyman to check with his family physician, Dr. Fred Family, and informs him that he will have a copy of the test results sent to Dr. Family. Three days later Mr. Everyman sees Dr. Family for a follow-up evaluation. The ulcer still shows signs of active infection, and Dr. Family checks the final culture report, which shows that the Staph is resistant to Levofloxacin. However, the Staph is sensitive to first-generation cephalosporins (Cephalothin). Because the concomitant infection with Klebsiella is sensitive to floroquinolones (Ciprofloxacin), Dr. Family decides to continue the Levofloxacin and add Cephalexin to the antibiotic regimen. Mr. Everyman faithfully takes both medications, and on a further follow-up visit with Dr. Family 10 days later, the infection has cleared and the ulcer is healing well.
The purpose of this storyboard is to illustrate a query for specific test result(s) for a single patient over a specified period of time.
| Find Result Query |  POLB_IN354000UV01 |
| Find Result Query Response | POLB_IN364000UV01 |
Presentation
Eve Everywoman is brought to the Good Health Hospital Emergency Department via ambulance on July 7, 2003. She is comatose and is a known diabetic. Dr. Eric Emergency begins treatment and also wants to know her fasting blood sugar history over the last four months.
Find Result Query
Good Health Hospital has connectivity to the Northwest Region Diabetic Registry (NWRDR) which maintains lab values pertinent to diabetes across the Northwest Region. ER Triage Nurse, Nancy Nightingale logs onto the Good Health Hospital clinical information system and specifies the query parameters to determine if Ms. Everywoman has fasting blood sugar results stored in the Northwest Region Diabetic Registry for the last 4 months. The clinical information system places a query to NWRDR employing the required security protocols and query parameters specified by Nurse Nightingale (POLB_IN354000UV).
The following query parameters are specified:
|
Parameter |
Value |
Comment |
|
Hospital Provider ID |
777 |
Good Health Hospital's ID that qualifies Hospital Medical Record Number |
|
Hospital Medical Record Number |
123456 |
Primary Patient Identifier |
|
Patient Last Name |
Everywoman |
Secondary Patient Identifier used for confirmation |
|
Patient First Name |
Eve |
Secondary Patient Identifier used for confirmation |
|
Patient Gender |
F |
Secondary Patient Identifier used for confirmation |
|
Patient Date of Birth |
July 4, 1979 |
Secondary Patient Identifier used for confirmation |
|
Test Identifier |
FBS |
The NWRDR umbrella code representing all LOINC codes for FBS tests |
|
Query Start Date |
March 7, 2004 |
. |
|
Query End Date |
July 7, 2004 |
. |
|
User ID |
nnightingale |
NWRDR ID of person submitting the query |
|
Authenticated Security Access |
(Encrypted) |
NWRDR User authentication method ( PKI certificate) |
Find Result Response
The NWRDR system determines that it understands and is capable of fulfilling the query. Then it verifies the credentials presented by the clinical information system and determines that Nancy Nightingale is entitled to view the query results. The query is executed and results are returned to the clinical information system. (POLB_IN364000UV).
|
Chemistry Observation/Test Name |
Result Value/Flag |
Units |
Reference Range |
Collection Date/Time |
Observation Date/Time |
|
FBS |
145 HH |
mg/dl |
65-99 |
07/04/2004 0800 |
07/04/2004 0900 |
|
FBS |
132 H |
mg/dl |
65-99 |
06/04/2004 0840 |
06/04/2004 0900 |
|
FBS |
150 HH |
mg/dl |
65-99 |
05/19/2004 0545 |
05/19/2004 0600 |
|
FBS |
137 H |
mg/dl |
65-99 |
05/04/2004 0845 |
05/04/2004 0900 |
|
FBS |
130 H |
mg/dl |
65-99 |
04/15/2004 0815 |
04/15/2004 0900 |
The clinical information system receives the response and formats the Fasting Blood Sugar (FBS) results for display to Nancy Nightingale.
Find Result Query Response - Report View
Find Result Query Response - Minimal View
Conclusion
Dr Eric Emergency admits Ms. Everywoman to ICU. She responds to treatment and is released with a modified treatment plan.
|
||||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
The Order Placer is the application role that places an order (requests fulfillment) from an order fulfiller. The Order Placer manages the state of that order (an Act in RQO mood). This application role is responsible for communicating changes to state of the order. The order placer is expected to manage the state of the order in response to changes to related promises and events.
The Order Fulfiller is a laboratory system that receives orders and sends observation results. The order fulfiller manages the state of promises and events. This application role is responsible for communicating changes to the state of both promises and events. This application is expected to receive orders and respond with promises and events. The order fulfiller is expected to manage the state of promises and events in response to changes in the state of orders.
The Result Receiver tracks Laboratory Result (event) messages. The Result Receiver is a tracker application that is capable of receiving a message from another system about any state change of a laboratory observation. Note: this does not imply such a tracker stores the observation event. This does not preclude the event tracker from also storing the event.
A Result Query Placer application originates queries for results. The query placer is capable of receiving query response. The query placer is not required to store the data from a query response. The query placer is allowed to store the query response.
The Result Query Filler is an application responsible for satisfying a request message from a Query Placer. Normally this means the query filler must either be a receiver of result messages, or must be the originator of that information.
|
||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: | User request |
A result event has been activated. This is the first time this result has been reported.
- Focal Act: The end state of the focal act must be Active. The only allowed state transition for the focal act is activate.
- Component (COMP) Acts: The end state of component (COMP) acts are restricted to Active, Suspended and Completed states. The allowed state transitions are jump (to one of the 3 allowed states).
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- No Equivalent Value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- F - Final results; Can only be changed with a corrected result
| Type: |
The result event has been aborted and no additional work will be done performing the associated testing.
- Focal Act: The end state of the focal act of the message is must be Aborted. The only allowed state transition is abort.
- Component (COMP) Acts: Component (COMP) acts must end in a "final" state. Final states include Aborted, Completed, Nullified and Obsolete. The allowed state transition is abort. Component acts cannot transition to Completed, or Nullified as part of this trigger event, they must already be in those states prior to this trigger event occurring. Note that component acts in the Active or Suspended states must transition to the Aborted state. In other words the Result Aborted trigger event cascades down to child component acts which are Active or Suspended.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- X - No result available; Order cancelled
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- X - Results cannot be obtained for this observation
| Type: | State-transition based |
| State Transition: | ObservationEventChoice (POLB_RM004000UV01) |
This is a combined trigger event, involving completing both a result event and a promise. First, the event indicates that the completion (satisfaction) of a laboratory observation has occurred. The observations are considered final. The event also signals completion of the filler's promise for the result. No further activity is expected by the filler (although corrections may still occur).
- Focal Act: The focal act for the message must end in the Completed state. The complete and jump (to Completed) state transition are allowed.
- Component (COMP) Acts: The end state of all component acts must be in a "final" state. The allowed final states are Completed, Aborted, or Nullified. Allowed state transitions are those that transition to these final states including complete, abort, and nullify. Jump (to Completed) and revise (on Completed) state transitions are also included to allow replacement or revision of previously completed component observations.
- FullfillerPromise (FLFS) Acts: The FulfillerPromise Act in the message is required to end in the Completed state. Only the complete state transition is allowed.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- F - Final results; results stored and verified. Can only be changed with a corrected result
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- No equivalent value
| Type: |
This trigger event involves completing a result event. The completion of the result did not involve the completion of an order or promise. Possible situations where this may occur include the lab it reporting results for a recurring order (where multiple results will be reported) or where there is not associated order or promise to be fulfilled.
- Focal Act: The focal act for the message must end in the Completed state. The complete and jump (to Completed) state transition are allowed.
- Component (COMP) Acts: The end state of all component acts must be in a "final" state. The allowed final states are Completed, Aborted, or Nullified. Allowed state transitions are those that transition to these final states including complete, abort, and nullify. Jump (to Completed) and revise (on Completed) state transitions are also included to allow replacement or revision of previously completed component observations.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- F - Final results; results stored and verified. Can only be changed with a corrected result
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- F - Final results; Can only be changed with a corrected result
| Type: | State-transition based |
| State Transition: | ObservationEventChoice (POLB_RM004000UV01) |
Results (observation events) were created erroneously, and should be treated as if it never existed.
- Focal Act: The focal act is only allowed to end in the nullified state. The allowed focal act states prior to nullification are Active, Aborted, Suspended or Completed. The only allowed state transition is nullify.
- Component (COMP) Acts: The component acts must all end in the nullified state. The allowed component act states prior to nullification are Active, Aborted, Suspended or Completed. The only allowed state transition is nullify. Note that nullifying the focal act cascades down to the component acts, forcing all component acts to become nullified also.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- No equivalent value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- D - Deletes the OBX record
- W - Post original as wrong, e.g., transmitted for wrong patient
| Type: | Interaction based |
Information regarding a result (observation event) has been found in response to a request.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- No equivalent value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- No equivalent value
| Type: | User request |
Information about a result (observation event) is being requested.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- No equivalent value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- No equivalent value
| Type: |
Rejection of a result interaction. This trigger indicates the result interaction has been received and rejected due to order placer business rules.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- No equivalent value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- No equivalent value
| Type: |
This trigger indicates the result interaction has been received and confirmed due to order placer business rules
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- No equivalent value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- No equivalent value
| Type: | State-transition based |
| State Transition: | ObservationEventChoice (POLB_RM004000UV01) |
This is a revision of a completed result (observation event). The corrected results are considered complete. This trigger event is only used when a previously completed result (reported via the Result Complete trigger event) is being revised.
- Focal Act: The focal act must be in the completed state. The only allowed state transition is revise (on complete).
- Component (COMP) Acts: The component acts must end in one of the following "final" states: Completed, or Nullified. The allowed state transitions are jump (to Completed), revise (on completed), or nullify. This allows previously reported complete observations to be removed or revised.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- C - Correction to results
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- C - Record coming over is a correction and thus replaces a final result
| Type: | State-transition based |
| State Transition: | ObservationEventChoice (POLB_RM004000UV01) |
Indicates that the issuing of a laboratory observation has occurred, and that preliminary results are available. If the observation is composed of component observations, some of the component observations may be changing status (including complete). The status of the overall observation remains active. This trigger event should be used when actual result observations are being reported.
- Focal Act: The focal act is restricted to the Active state. Only the revise state transition is allowed for the focal act. This means the Result In Progress trigger event is never used to report that the focal act is completed.
- Component (COMP) Acts: The component acts are allowed to be in a wide variety to states including Active, Aborted, Suspended, Completed, and Nullified. The allowed state transitions for the component acts are jump (to an allowed normal state), abort, suspend, resume, complete, revise, or nullify. This means the Result In Progress trigger event can be used to communicate preliminary or complete observations where the message focal act remains Active or Suspended.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- A - Some, but not all, results available
- P - Preliminary: A verified early result is available, final results not yet obtained
- R - Results stored; not yet verified
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- P - Preliminary results
- R - Results entered -- not verified
- S - Partial results
| Type: | State-transition based |
| State Transition: | ObservationEventChoice (POLB_RM004000UV01) |
Some aspect of an events (results) status has changed. The only changes (including state changes) allowed for this trigger event are for the ProcessStep acts (and associated participation's, roles and entities) found in the Result Event model. Changes to any other part (including the focal act) of the message are not allowed with this trigger event.
- Focal Act: The state of the focal act of the message is not allowed to change. The only allowed state for the focal act is Active.
- Component (COMP) ProcessStep Act: The state of component (COMP) ProcessStep acts are allowed to change. ProcessSteps are restricted to Aborted, Active, Suspended and Completed states. The allowed state transitions are jump (to one of the 4 allowed states), abort, suspend, resume, revise and complete.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- I - No results available; specimen received, procedure incomplete
- S - No results available; procedure scheduled, but not done
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- I - Specimen in lab; results pending
| Type: |
The result has experienced some sort of state or status change. No distinction is made between changes to the focal act or the component acts. This trigger event is used to report any kind of changes that occur to a result to a tracker type application role.
ObservationReport, ObservationBattery, SpecimenObservationCluster or Focal ObservationEvent: HL7 Table 0123 Result Status
- Any value
Component ObservationEvents: HL7 Table 0085 Observation result status codes interpretation
- Any value
|
||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Laboratory Observation (POLB_DM000000UV) |
RMIM Overview
This model captures the data and associations that are needed when a Laboratory Fulfiller generates observations. This model - and its accompanying diagram - is very similar to the Laboratory Observation Domain Information Model (DMIM), and the reader should refer to that discussion before reviewing the RMIM.
The discussion of this model takes up features that do not explicitly exist in the DMIM, and were not directly addressed in the review of that model. As noted in the discussion of the DMIM; a Laboratory Result Event is a record of the observation(s) on a specimen. This may be in response to an Order or a Promise.
Most of the participations encountered in this model have already been addressed in the discussion of the DMIM. Where they are constrained for use in this RMIM, they are described in the walk through below.
The ObservationEventChoice has the following Acts:
ObservationEventChoice 1
ObservationReport: The ObservationReport act serves as an optional header for a group of related reports, batteries, clusters or observations. Its target may be another ObservationReport, ObservationBattery, SpecimenObservationCluster, or an ObservationEvent.
Specimen centric ObservationReports will associate the specimen at the ObservationReport level, allowing this specimen to be inherited by component acts. In the case of specimen centric reports, component acts may have additional specimens associated with them, but they should be aliquot or isolates of the specimen associated with the ObservationReport.
Non-Specimen centric ObservationReports normally will not have specimens related at this level. Specimens associated with component acts may have specimens associated with them, but those specimens are not necessarily related.
ObservationEventChoice 2
ObservationBattery: The ObservationBattery represents a set of observations. These observations typically have a logical or practical grouping for generally accepted clinical or functional purposes, such as observations that are run together because of automation. A battery can define required and optional components and, in some cases, will define complex rules that determine whether or not a particular observation is made. Examples include "Full blood count", "Chemistry panel". The ObservationBattery may have ObservationEvents as components. It shall not have ObservationReports or SpecimenObservationClusters as components.
An ObservationBattery may inherit the specimen from an ObservationReport (if one is present). The ObservationBattery may also be the initial act in a Result Event message. In that case any specimen associated with the battery would be inherited by the component acts of the battery.
ObservationEventChoice 3
SpecimenObservationCluster: The SpecimenObservationCluster represents a set of batteries and observations. All the batteries and observations are related to the specimen associated with the SpecimenObservationCluster. For microbiology the SpecimenObservationCluster represents all the batteries and observations related to a single isolate. The subject of a SpecimenObservationCluster must be either a specimen isolate or a specimen aliquot. The target of a SpecimenObservationCluster must be either an ObservationBattery or an ObservationEvent.
An SpecimenObservationCluster may inherit the specimen from an ObservationReport (if one is present). Normally, the SpecimenObservationCluster will identify its own specimen, but that specimen must be an isolate or aliquot of the specimen inherited from the ObservationReport. The SpecimenObservationCluster may also be the initial act in a Result Event message. In that case any specimen associated with the cluster would be inherited by the component acts of the cluster.
ObservationEventChoice 4
ObservationEvent: The ObservationEvent represents a related group of observations. Observations are actions performed in order to determine an answer or result value. Observation result values (Observation.value) include specific information about the observed object. The ObservationEvent is distinguished from the other 3 choices within ObservationEventChoice in that it is the choice which can carry a value (i.e., an actual result). The target of an ObservationEvent may be another ObservationEvent. ObservationReport, ObservationBattery, and SpecimenObservationCluster may not be targets of an ObservationEvent.
The ObservationEvent may be the component of an ObservationReport, ObservationBattery, SpecimenObservationCluster, or ObservationEvent. In this case the ObservationEvent can inherit any specimens associated with the parent act. If the parent has a specimen associated with it, and ObservationEvent also has a specimen, the specimen associated with the ObservationEvent must be an isolate or aliquot of the parent acts specimen. The ObservationEvent may also be the initial act in a Result Event message. In that case any specimen associated with the ObservationEvent would be inherited by the component acts of the cluster.
It should be noted that there is an entire school of result messaging which will only utilize the ObservationEvent choice within the ObservationEventChoice. ObservationEvent can essentially replace each of the ObservationReport, ObservationBattery, and SpecimenObservationCluster.
ObservationEventChoice Act Relationships:
The following act relationships may be associated with each of the acts within the ObservationEventChoice. In clockwise order around the RMIM:
- component1: For each message instance, one of the acts within the ObservationEventChoice shall be selected as the 'Focal act' for the
result. If there is a requirement for observations to be grouped together, this may be achieved using the Component Act Relationship
recursion. For example, the ObservationReport act may serve as the focal act, with multiple component items carried in the
ObservationBattery, SpecimenObservationCluster or ObservationEvent acts. The recursion carries a number of constraints:
- The ObservationReport may have ObservationReports, ObservationBattery's, SpecimenObservationClusters, and ObservationEvents as components. This allows for repeating report headers within a result.
- The ObservationBattery may have ObservationEvents as components.
- The SpecimenObservationCluster may have ObservationBattery's and ObservationEvents as components.
- The ObservationEvent may have ObservationEvents as components.
- componentOf: Provides a link between any of the ObservationEventChoice Acts and the encounter by means of the A_Encounter CMET.
- subjectOf2: Any of the ObservationEventChoice Acts may be the subject Of A_Annotation CMET. These Annotations handle any sort of notes or comments regarding the associated act.
- subjectOf1: Any of the ObservationEventChoice Acts may be the subject Of a Control Act. These Control Acts communicate the trigger event and other "action" information regarding the associated act. One particularly important use is to communicate that an observation event has been "corrected". The Result Corrected (POLB_TE004201UV) trigger event is used. In this case the ObservationEvent.statusCode shows as "completed", so the ControlActEvent.code carrying the corrected trigger event is the only mechanism indicating the ObservationEvent has been corrected.
- definition: Provides a link between the ObservationEventChoice and an ActDefinition that communicates definitional information about that Act.
- inFulfillmentOf: This association provides a mechanism to relate zero to many orders or promises to each ObservationEventChoice. The model
provides a choice of a FulfillerPromise or PlacerOrder in which to convey information about the Promises and Placer Order(s)
being fulfilled.
The FulfillmentChoice has the following Acts:
- FulfillerPromise: The promise which this ObservationEventChoice fulfills. This is essentially a stub which identifies the promise. One thing to note is the inclusion of the statusCode attribute here. When the ObservationEventChoice act is being marked as completed, the filler can also communicate that the associated promise being fulfilled is also complete. This can be done because the filler manages the state of both the event and the promise.
- PlacerOrder: The order which this ObservationEventChoice fulfills. This is a stub which identifies the order. No status attribute is included here because the filler does not manage the PlacerOrder.
The FulfillmentChoice has the following Act Relationship:
- inFulfillmentOf: This inFulFillmentOf act relationship connects to the FulFillmentChoice, but there is a constraint that the target of the relationship must be PlacerOrder. This allows the complete chain of fulfillment to be represented in the message: ObservationEventChoice -> FulfillerPromise -> PlacerOrder.
- reason: Each ObservationEventChoice may have zero to many reasons associated with it. The A_SupportingClinicalStatement CMET is used to carry this information.
- pertinentInformation: An ObservationEventChoice is associated with zero to many items of supporting clinical information that are pertinent to the event. The information is carried in the A_SupportingClinicalStatement CMET.
- component2: Each ObservationEventChoice act may have one or more component ProcessSteps. ProcessSteps cover activities such as accessioning, collection, transportation, and result processing. Virtually any workflow step in the laboratory can be communicated here; however specimen processing should be messaged using the ProcessSteps within the Specimen CMET. The statusCode attribute has been provided to allow the filler to indicate the state of a process step (including completion).
ObservationEvent Act Relationships:
- derivedFrom2: The source ObservationEvent is derived from the target ObservationEvent. The derivedFrom.localVariableName attribute provides a variable name for the target observation value that is used in the source observations derivationExpression.
- referenceRange: The target act defines an interpretation range for the source act. Interpretation ranges are essentially descriptors of a
class of result values or changes in result values assumed to be "normal", "abnormal", or "critical" etc. Those can vary
by sex, age, or any other criterion. Source and target are observations, the target is in criterion mood. Note that the source
act is not ObservationEventChoice, rather it is ObservationEvent.
- Target of referenceRange - InterpretationRange: Interpretation Ranges may be presented as a pair of values (Lo - Hi) of the same datatype as the observation to which they apply (carried as an IVL). In some instances there may only be a Lo or a Hi rather than a pair of values. Some systems supply ranges as a String. Interpretation range may also carry a Reference Change Value (RCV) either as a percentage or absolute value. InterpretationRange has an Precondition act relationship to Criterion for the reference range. An example of a criterion is an age range for an age based reference range. The value attribute of the criterion defines what the age range is and the interpretation code attribute of the criterion gives a general term for the age range, such as "middle aged". Criterion may also be used to define Interpretation Ranges for abnormal conditions. For example a patient on renal dialysis may have a different Interpretation Range for electrolytes and creatinine than a patient with normal kidney function. Criterion.interpretationCode would be used to provide a rough interpretation of the Criterion value in this case.
- derivedFrom1: The source ObservationEvent is derived from the target SupportingClinicalStatement. The derivedFrom1.localVariableName attribute provides a variable name for the target SupportingClinicalStatement that is used in the source observations derivationExpression.
Participations from the ObservationEventChoice
The following participations may be associated with each of the acts in the ObservationEventChoice (continuing in clockwise order):
- specimen: Used to identify the specimen on which the observations are made. The specimen may be any of the entities available in the specimen CMET playing the role of Specimen/Isolate/Aliquot. (see specimen CMET walk through).
- informationRecipient: The intended recipient(s) of the observations. This is used to identify copy recipients of results. These may be individuals, organizations or devices and are carried in the AssignedEntity CMET.
- transcriber: Identifies the person/device transcribing the data, details of which are carried in the AssignedEntity CMET.
- performer: Identifies the performer of the observation. This may be an person acting in the employ of an organization, device or patient. The details about the performer are carried in the AssignedPerson CMET, the AssignedDevice CMET, or the Patient Clinical CMET.
- verifier: Identifies one or more individuals who verify the content of the ObservationEventChoice, details of which are carried in the R_AssignedEntity CMET.
- author: The entity responsible for creating the ObservationEventChoice. This may be an organization, device or individual. For observations generated by a device it would be the device.
- recordTarget: This participation is used to identify the patient or investigativeSubject to whom the ObservationEventChoice relates. Details of the patient or investigativeSubject are carried in the R_Subject CMET. The Subject identified here is not necessarily the source of the specimen. Where there is a requirement to identify a different source for the specimen, this is achieved through the specimen CMET via the subject participation. There is a constraint on the recordTarget that it will only be associated with the root ObservationEventChoice.
Participations from the ObservationBattery Act
- device: The R_LabTestKit participates as a device in the testing of an ObservationBattery.
- consumable2: Lab Test Kit as carried in the R_LabTestKit CMET participates as a consumable in the testing of an ObservationBattery.
- consumable1: Reagent as carried in the R_Reagent CMET participates as a consumable in the testing of an ObservationBattery.
Participations from the ObservationEvent Act
- consumable3: Reagent as carried in the R_Reagent CMET participates as a consumable in the testing of an ObservationEvent.
- consumable1: Lab Test Kit as carried in the R_LabTestKit CMET participates as a consumable in the testing of an ObservationEvent.
- device: The R_LabTestKit participates as a device in the testing of an ObservationEvent.
Participations from the Criterion Act
- device: The R_LabTestKit participates as a device with the testing of a Criterion.
- consumable2: Lab Test Kit as carried in the R_LabTestKit CMET participates as a consumable in the testing of a Criterion.
- consumable1: Reagent as carried in the R_Reagent CMET participates as a consumable in the testing of a Criterion.
| Result Event | POLB_HD004000UV01 |
| Parent: | Query Control Act (QUQI_DM000000UV) |
R-MIM Overview
This model captures the data and associations that are needed when querying for a Laboratory Result. This RMIM defines a set of parameters used for Laboratory Result queries. Unlike the other RMIM's in the Lab Domain, this RMIM is not directly derivable from the Laboratory DMIM. All the classes found in this design are derived from the Communication Infrastructure subject area of the RIM, and would simply clutter the Laboratory DMIM without providing any real value.
Entry Point: QueryByParameterPayload
Entry is into the QueryByParameter class with the local name QueryByParameterPayload. This class contains the definition of a Query by Parameter. The query format is considered a closed query because a data server specifies a fixed list of parameters published in a query conformance statement.
QueryByParameterPayload Associations
QueryByParameterPayload has association with the following classes:
- ObservationType(ParameterItem): This carries an Observation type code as the parameter.
- ObservationEffectiveTime (ParameterItem): This carries a range of time within which the observations occurred.
- ObservationStatusCode (ParameterItem): This is the status of the observation being queried for.
- ProviderID (ParameterItem): This is the authoring provider for the observation.
- SpecimenCollectionProcessEffectiveTime (ParameterItem): This carries a range of time within which the specimen collection process is effective. This is the collection time which is the clinically significant time for tests carried out on that specimen.
- ProcessStepCode (ParameterItem): This carries a code for laboratory process steps such as Specimen received in lab, Container registration, Specimen accession, or Specimen treatment.
- ProcessStepEffectiveTime (ParameterItem): This carries a range of time for such events as: Specimen received in lab, Container registration, Specimen accession, or Specimen treatment.
- ActMoodCode (ParameterItem): This carries the mood of the Act. For POLB_IN354000UV (Find Result) interaction it must be in Event ("EVN") mood.
- ActId (ParameterItem): This parameter is the set of order, promise or event Act identifiers being queried for.
- PatientDOB (ParameterItem): This carries a Patient date of birth parameter.
- PatientAdministrativeGender (ParameterItem): This carries a patient gender parameter.
- PatientName (ParameterItem): This carries a patient name parameter.
- PatientID (ParameterItem): A ParameterItem represents name, value pair which identifies a parameter and the value of the parameter to be used for a query. In this case the parameter is a set of Patient identifiers.
- InvestigativeSubjectID (ParameterItem): A ParameterItem represents name, value pair which identifies a parameter and the value of the parameter to be used for a query. In this case the parameter is a set of InvestigativeSubject identifiers.
- SortControl (SortControl): Holds specification of sort order for instance matches to a query.
Attributes related to the QueryByParameterPayload classes listed above can be found by double-clicking in the Result Event Query RMIM diagram and expanding any class and its attribute level descriptions.
| Query | POLB_HD300000UV01 |
|
||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
Message types based upon this HMD are be used to communicate laboratory observations. These can be as simple as an observation for single test, observations associated with a battery of tests, or more complex observations such as micro-biology results.
| A_EncounterUniversal | COCT_MT010000UV01 |
| R_PatientClinical | COCT_MT050004UV01 |
| R_SpecimenUniversal | COCT_MT080000UV09 |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedDeviceUniversal | COCT_MT090300UV01 |
| R_AssignedDeviceUniversal | COCT_MT090300UV01 |
| R_ReagentUniversal | COCT_MT250000UV03 |
| R_LabTestKitUniversal | COCT_MT430000UV09 |
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| R_SubjectUniversal | COCT_MT560000UV07 |
| A_AnnotationUniversal | COCT_MT590000UV |
| Result Event | POLB_MT004000UV01 | |
Message types based upon this HMD are be used to communicate queries for observations. These can be as simple as queries for single test, order for a battery of tests, or more complex groupings of tests such as microbiology observations.
| Result Query | POLB_MT300000UV01 | |
|
||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
This interaction is a Result Activate. This interaction indicates that the Laboratory has information regarding the result to be communicated but the preliminary report is not yet available. The state of the initial lab observation is set to active.
| Trigger Event | Result Activate | POLB_TE004102UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is a Result Abort. This interaction signals the result was stopped prior to completion.
| Trigger Event | Result Abort | POLB_TE004301UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is a Result Complete. This interaction signals the completion of a result report. Other reports are expected to be sent until a final result is submitted which (with the initial components) fulfill the original order.
This result is not intended to completely fulfill the associated order and/or promise. This interaction is used when a result is associated with a repeating order; so each result is in response to the order but does not fulfill the entire order.
| Trigger Event | Result Complete | POLB_TE004202UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is a Result Complete. This interaction signals completion of the result reporting. No other reports will be sent, unless there is a corrected report. The state is complete and the result report is final.
This result is intended to fulfill the associated order and/or promise.
| Trigger Event | Result Complete with Fulfillment | POLB_TE004200UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is a Result Nullify. This interaction is used when the filler nullifies a result that was previously reported.
| Trigger Event | Result Nullify | POLB_TE004500UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
| Trigger Event | Result Confirm | POLB_TE004001UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Minimal Event Act Reference Message | COMT_MT700010UV |
| Sender | Order Placer | POLB_AR010000UV01 |
| Receiver | Order Fulfiller | POLB_AR020000UV01 |
This interaction is a Result Reject. This is used by the order placer to reject a result.
| Trigger Event | Result Reject | POLB_TE004002UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Minimal Event Act Reference Message | COMT_MT700010UV |
| Sender | Order Placer | POLB_AR010000UV01 |
| Receiver | Order Fulfiller | POLB_AR020000UV01 |
This interaction is a Result in Progress. This interaction indicates that the Laboratory observation has occurred and preliminary results are being communicated with this notification. The state continues to be active.
| Trigger Event | Result in Progress | POLB_TE004100UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is a Result Corrected. This interaction is used when the filler must correct (i.e., change) results that were previously reported as completed. The state change is completed for this order.
| Trigger Event | Result Corrected | POLB_TE004201UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is a Result Status. This interaction is used in those situations where Laboratory system sends a status message indicating where the lab is in the process of completing the result. This interaction should not be used to communicate actual results. This includes process steps such as:
-
Specimen collected
-
Specimen received in lab
-
Specimen accessioned
-
Testing begun
And other process steps that maybe appropriate. There is no state change and the report continues to be pending.
| Trigger Event | Result Status | POLB_TE004000UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Order Placer | POLB_AR010000UV01 |
This interaction is used by the order fulfiller to communicate any changes to the state of a result. This is used to communicate the state of a result to a result receiver (tracker).
| Trigger Event | Result Tracking | POLB_TE004007UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Result Event | POLB_MT004000UV01 |
| Sender | Order Fulfiller | POLB_AR020000UV01 |
| Receiver | Result Receiver | POLB_AR034000UV01 |
This interaction is a request for information regarding a result. The expected response is the information being requested. Note that the Query Parameter ActMoodCode is constrained to be "EVN" in this interaction.
| Trigger Event | Find Result | POLB_TE304000UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV |
| Control Act Wrapper | Query Control Act Request : Parameter List | QUQI_MT020001UV01 |
| Query Definition | Result Query | POLB_MT300000UV01 |
| Reason | Trigger Event | Interaction |
| POLB_TE304001UV01 | POLB_IN364000UV01 |
| Sender | Result Query Placer | POLB_AR350000UV01 |
| Receiver | Result Query Filler | POLB_AR360000UV01 |
This interaction is the response to a Find Result query. The response contains the requested result information.
| Trigger Event | Find Result Response | POLB_TE304001UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV |
| Control Act Wrapper | Query Control Act Response / Acknowledgement | QUQI_MT120001UV01 |
| Query Response Type | Result Event | POLB_MT004000UV01 |
| Query Definition | Result Query | POLB_MT300000UV01 |
| Sender | Result Query Filler | POLB_AR360000UV01 |
| Receiver | Result Query Placer | POLB_AR350000UV01 |
| Return to top of page |