DEFINITION:
means 0 to many
OTHER NOTES:
means 1 to many
DEFINITION:
Labdata.a1 contains the data structure for standard laboratory data.
This is laboratory data that is non-Microbiology data. It is composed
of a header portion and the results portion. These are detailed in
the sections that describe header and results.
In general, laboratory data is acquired on the HEMS product through an
interface to a laboratory interface system.
EXAMPLES:
Examples of laboratory data that are use this data structure are hematology,
chemistry, coagulation, and serology. As stated before microbiology,
anatomic pathology, and blood bank are not handled within this structure.
DATABASE MAPPING:
Patient Event, Observation, Lab_Test, Specimen, Specimen_Descript
HL7 MAPPING:
OBX, OBR, ORC, Segments
OLE MAPPING:
Supported:
OLE data type: CLabData object
ALERT REQUIREMENTS:
Alerts use this data. See specific elements for their use.
DEFINITION:
The laboratory header contains management type data. This includes
information about the test that is done, the type of specimen, various
dates asscociated with the test, test status, who resulted, comments
about the entire test, and text comments about the entire test.
OLE MAPPING:
All supported labDataHeader information is exposed as properties of
the CLabData object
DEFINITION:
The results are a the set of observations,values, flags, normals,
comments, etc that are done as part of a test.
EXAMPLES:
For example the test SMA-7 or CHEM-7 are composed of 7 observations
and their accompanying flags and values : sodium, potassium,
chloride, CO2, blood urea nitrogen, glucose, and creatinine.
OLE MAPPING:
Supported: Get
Property: CLabData::Results
OLE data type: CObservations collection object
DEFINITION:
The test name is required. This is a coded value and represents the type of
of laboratory test that is to be performed. This must be coded
to be considered a valid laboratory test on our system.
EXAMPLES:
Examples of laboratory tests include CBC (complete blood count),
Blood Ammonia Level, Gentamycin Level, Chemistry Panel 7, PT, PTT,
etc.
DATABASE MAPPING:
Lab_Test:Test_Ncid
HL7 MAPPING:
OBR-4 Universal Service Id
OLE MAPPING:
Supported: Get
Property: CLabData::TestName
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Required. The test name (code) is one way that you can use to map data to an
alert object.
DEFINITION:
This is a set of specimen descriptors. See LabSpecimen for
detailed description.
OLE MAPPING:
Not Supported:
DEFINITION:
This is the date and time that the laboratory test as a whole
was "verified". In the clinical laboratory this is when the
technologist reviews the results and "blesses" them. This
step is similar to the verification that may be done by a
pharmacist to a pharmacy order.
This does not seem to be being used or sent to us at this
time.
EXAMPLES:
Once a lab test is received in the lab, say a Chem 7, the
specimen is prepared for analysis, it is then analyzed (the
test performed), the result posted preliminary (at which time
clinicians may have access to the data), then the results are
reviewed by a tech or pathologist, once reviewed they are
verified and the status is changed to final.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currenlty not used.
DEFINITION:
This is the date and time that the result was received on the
the HEMS system. This time is the date and time we store
the lab test.
EXAMPLES:
An example might be that a Chem-7 was collected 10/10/96.13:00,
the analysis done and the test verified 10/10/96.13:30 and received
on the HEMS side at 10/10/96.13:31.
DATABASE MAPPING:
HL7 MAPPING:
Not sent through HL7.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a unique number, which consists of a system ncid (coded) and
and the alphanumeric number. This is the service or facility
that "fills" the order. See clintype.a1 UniqueReferenceId.
EXAMPLES:
An example specific to lab would be the system number for the
clinical lab and their order number respective to the order
that was done.
DATABASE MAPPING:
Lab_Test:Filler_Number
HL7 MAPPING:
OBR-20 Filler Field 1+
OLE MAPPING:
Supported: Get/Set
Property: CLabData::FillerNumber maps to refNum (BSTR)
Property: CLabData::FillerSystem maps to system (CCodedCtrl)
ALERT REQUIREMENTS:
Currently not used specifically by the logic. However,
it is required that either this number or the placer number is
unique so that updates to data strings can be performed.
DEFINITION:
This is a unique number, which consists of a system ncid (coded)
and the alphanumeric number. This number is assigned by the
system responsible for "placing or requesting the order". See clintype.a1
UniqueReferenceId.
EXAMPLES:
An example would be on a legacy HIS a placer number of a Chem-7
would be assigned, the order sent to the lab, the lab assigns the
fillernumber, the results are passed to the LDR with both the
filler and placer numbers. This would link where the order occurred
and how the order was filled.
DATABASE MAPPING:
Lab_Test:Placer_Number
HL7 MAPPING:
OBR-18 Placer Field 1
OLE MAPPING:
Supported: Get/Set
Property: CLabData::PlacerNumber maps to refNum (BSTR)
Property: CLabData::PlacerSystem maps to system (CCodedCtrl)
ALERT REQUIREMENTS:
Currently not used specifically by the logic. However,
it is required that either this number or the placer number is
unique so that updates to data strings can be performed.
DEFINITION:
This is the status of the result as it is being processed by
the laboratory. In general, lab tests start as preliminary
which denotes that the test has not been verified or completed
and then progress to finalized.
EXAMPLES:
Examples of test status include : preliminary, pending, cancelled,
complete, finalized.
DATABASE MAPPING:
Lab_Test:Test_Status_Ncid
HL7 MAPPING:
OBR-25 Result Status +
OLE MAPPING:
Supported: Get
Property: CLabData::TestStatus
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Will be used by Infectious Disease.
DEFINITION:
This is the set of person or persons that are responsible for
either performing the test or verifying the results. This can be
either coded or represented by text.
EXAMPLES:
An example would be that R. Dupont student Tech performs a 24
hour Fecal Fat. S. Harada Pathologist verifies the results and
finalizes the test.
DATABASE MAPPING:
Coded - Resulting_Technician:Technician_Ncid
Not Coded - Resulting_Technician:Technician_Text ????? not in interface document
HL7 MAPPING:
OBR-34 Technician+
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used in logic ... however, if you want to route alert messages
back to persons who are responsible for the posting of values
you would want to code this field.
DEFINITION:
This is a set of comments that are associated with the entire
test.
EXAMPLES:
An example might be that the "Sample Hemolyzed" or
"Quantity Insufficient".
DATABASE MAPPING:
HL7 MAPPING:
NTE Segment ???? this says freetext but interface refers to this
OLE MAPPING:
Supported: Get
Property: CLabData::CodedComments
OLE data type: CCodedComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a set of comments that are not coded by the lab and
are, in general, free text comments regarding the test as
a whole.
EXAMPLES:
An example would be "Nurse Dupont was called and ask to
provide collection time for the sample".
DATABASE MAPPING:
HL7 MAPPING:
NTE ????
OLE MAPPING:
Supported: Get
Property: CLabData::TextComments
OLE data type: CTextComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
See resultingTechnicians.
DEFINITION:
See resultingTechnicians
DEFINITION:
This is a set of specimen descriptors. See LabSpecimen for
detailed description.
DEFINITION:
This is the set of information that describes the specimen.
The descriptors include the type of specimen, times asscociated
with the specimen, who collected the specimen, and comments
asscociated with the specimen.
EXAMPLES:
Examples of a specimen description is a pleural fluid, collected
10/10/96.13:02, received in the laboratory at 10/10/96.13:30,
collected by the physician Dr. D. Brown and R. Dupont RN. Collected
in Radiology with a text comment check for metastatic cells.
DATABASE MAPPING:
Specimen Specimen_Descript
HL7 MAPPING:
OBR
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Future alerts may need to look at specimen descriptors. We should
encourage sites where possible to at least code the sterile body
fluid locations.
DEFINITION:
The date and time that the specimen for testing was collected. This
should be the date and time the blood was drawn or the sample was obtained
from the patient.
EXAMPLES:
Chem-7 drawn 10/10/96.06:00
DATABASE MAPPING:
Specimen:Collection_Start_Gmtime
HL7 MAPPING:
OBR-7 Observation Date/Time
OLE MAPPING:
Supported: Get/Set
Property: CLabData::CollectionDateTime
OLE data type: DATE
ALERT REQUIREMENTS:
Required.
DEFINITION:
The date and time the specimen (sample) was received in the laboratory
for testing.
EXAMPLES:
Chem-7 collected 10/10/96.06:00 received in the laboratory 10/10/96.08:00.
DATABASE MAPPING:
Specimen:Specimen_Received_Gmtime
HL7 MAPPING:
OBR-14 Specimen Received Date/Time
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Required.
DEFINITION:
This is an Ncid that represents a full description of
a body site. This is for sites that cannot represent the parts
of a specimen in atomic representation.
EXAMPLES:
For example, right lower leg would be assigned an ncid instead
of assigning 3 ncids for right, lower, and leg.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Spported:
ALERT REQUIREMENTS:
Not used.
DEFINITION:
This is the set of information that describes a specimen. See
Specimen Descript.
DEFINITION:
This is the person or persons that were responsible for collecting the
specimen. Ideally this should be a coded person, however, the structure
supports text.
EXAMPLES:
specimen collected by R. Dupont, phlebotomist.
DATABASE MAPPING:
Specimen_Collector:Collector_Ncid
HL7 MAPPING:
OBR-10 Collector Identifer Note: in HL7 the collector
can be a person, department, or facility. We currently seem
to only support person. However, facilities seem to be handled
in the collectionLocation portion of this definition.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Not used.
DEFINITION:
CollectionLocation is where the specimen was obtained. This could a
physical location such as a room/bed, nursing Division, service area, buildFloor, or
facility. All of the above are coded. In addition a collection location can
also be a terminal location either coded or text.
EXAMPLES:
An example of this would be a pleural fluid, which might be collected in
the radiology department as a by product of a thoracentesis. This is then
sent to the laboratory for cell counts and culture and sensitivities.
DATABASE MAPPING:
Specimen_Collector:Collector_Ncid?
HL7 MAPPING:
? we think this is OBR-10 however we don't think we support locations?
OLE MAPPING:
Supported: Get
Property: CLabData::CollectionLocation
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
These are coded comments that are relative to the specimen collection.
EXAMPLES:
An example might be a coded comment that translated to "specimen was
difficult to obtain" or "venous draw" or "arterial draw".
DATABASE MAPPING:
Currently not stored in the relational tables.
HL7 MAPPING:
This is not supported in HL7. We have created what is termed a ZTE
which is a 3M segment that supports coded and text comments.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
These are text comments that are relative to the specimen collection.
EXAMPLES:
An example might be "Patient was argumentative during collection of
blood."
DATABASE MAPPING:
Currently not stored in the relational tables.
HL7 MAPPING:
OBR-13 Relevant Clinical Information
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
I don't know what this is
DEFINITION:
See collectors.
DEFINITION:
See collectors.
DEFINITION:
This is the set of data that describes the source of
of the specimen, the quantity, the qualitative, and
quantitative features of the source.
DEFINITION:
See clintype.a1 BodySite.
DEFINITION:
See clintype.a1
DEFINITION:
This is the type of specimen not necessarily related to body site. It should
be noted that the "common" specimen types are included in the LOINC definition of
the test or observation. Therefore, most of the time we will not receive specimen
types for the common lab tests. In situations where body fluids are being tested,
like cell counts etc these will usually have a specimen type.
EXAMPLES:
Examples of this include serum, whole blood, urine, peritoneal fluid, etc.
DATABASE MAPPING:
Specimen_Description:Description_Ncid
HL7 MAPPING:
OBR-15 Specimen Source
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is the method of collecting the specimen. It can be either
coded or represented as free text.
EXAMPLES:
For instance a urine might have been obtained via a suprapubic
catheter.
DATABASE MAPPING:
HL7 MAPPING:
OBR-15 Specimen Source free text portion of the specimen source.
Appears we support coded but not free text.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
The volume of the specimen that was sent to the laboratory for analysis.
EXAMPLES:
An example would be a CSF (Cerebral Spinal Fluid) which might have a volume
of 3 cc (milliliters).
DATABASE MAPPING:
HL7 MAPPING:
OBR-9 Collection Volume. Does not appear to be supported at this time.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a statement of the volume qualitatively NOT quantitatively.
EXAMPLES:
An example might be scant amount of CSF (Cereberal Spinal Fluid).
DATABASE MAPPING:
HL7 MAPPING:
Fuzzy volumes appear not to be supported in HL7 currently.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
If a specimen is recovered or obtained via a device this area
allows for the recording of this device. Allows for the storage
of the device (coded or text), a model number, and a serial number.
EXAMPLES:
An example of a collection device might be Hickman Catheter.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
See clintype.a1 PathologicLesion
DEFINITION:
This is the color of the specimen that was sent
for analysis.
EXAMPLES:
Examples : urine yellow, peritoneal fluid amber.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is the odor of the sample. Although not commonly commented
on there are certain odors that can be clinically significant.
EXAMPLES:
Commonly when a patient is infected with Pseudomonas aeruginosa
there can be a faint odor of grapes. Also clinicians will often
comment if the specimen had a "foul" odor which might denote
a bacterial process.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currenlty not used.
DEFINITION:
This is a statement as to the viscosity or particulate matter
that may be present in a specimen.
EXAMPLES:
An example might be comments as to a body fluid be thick or
viscous with fine particulate matter.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a comment as to the position of the patient when the specimen
was obtained. There are lab test that are performed once while the
patient is supine (lying on their back) and sitting or standing.
EXAMPLES:
An example of this is serum aldosterone levels which are collected
supine before the patient gets up for the morning and then the
upright sample is collected at least 2 hours after they have been
sitting or standing.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currenlty not used.
DEFINITION:
Often times in laboratory testing a prosthetic device may be sent
for analysis. In general, this is most often done for microbiology
testing. However if the device has a captured level of fluid from
where it was placed the fluid might be extracted and tested.
EXAMPLES:
A penrose drain or shunt is sent to the laboratory for cell analysis.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a set of the valid types of values that may
be asscociated with an observation id.
DEFINITION:
An observation value can be represented as a numeric (decimal,
integer, range (1-5), titer (1:32), another coded (positive,
negative), or a date and time. See observation for primitive
types.
DATABASE MAPPING:
Observation
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Alerts expect valid numerics, ranges, titers, or coded results.
Alert logic cannot use text.
DEFINITION:
Negation is combined with the observation id to produce an
existance statement. See the example below. It is a coded
field.
EXAMPLES:
If you were testing for a serologic finding of Clostridia
difficile toxin you might use negation to make the finding
of NOT Clostridia difficile Toxin. To determine the complete
result you would need to use this node with the observation
id node.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used. Future releases of alerts would require
this node to be coded if logic were to run against a result
that had negation.
DEFINITION:
The numeric operator is a field that is used in conjuction
with a numeric value to denote quantities greater than or
less than some value. See the example below. This is used in
many cases where the testing produces a qualitative rather than
quantitative result.
EXAMPLES:
R. Dupont ICU nurse performs a glucose test on patient S. Schrank,
who is a fragile diabetic. R Dupont uses a glucometer.
Since the pesky glucometer looses sensitivity after 400 mg it
reports the glucose on Mr. Schrank as > 400 mg/dl. The '>' becomes
the numeric operator on our system. This is usually coded on the
Hems system.
DATABASE MAPPING:
Observation:Numeric_Operator_Ncid
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently the alerts only alert on numeric values that do not
have numeric operators. It is therefore very important that a
site always codes the set of numeric operators that will be used.
DEFINITION:
Uncertainty are those "weasel" words that are asscociated
with a lot of qualitative findings. Weasel words being
words like possible, probably, maybe, sort of kind of, etc.
EXAMPLES:
R. Dupont rooky med tech is working late one evening when through
the ER a new patient is seen. The patient has a very very low
white count, < 1.0 mmm/cu. He does a differential on the patient based
on only 25 cells. The cells don't look right...he knows he can't call it...
he needs to turf it to Dr. Huff to validate they are myeloblasts ...
to get the result to the ER he makes the statement on the differential
probable atypical myelocytes ...wah lah weasel word.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
Machine probility is a probability that is arrived at
by a machine. This could be a monitoring device or could
be a probability assigned by alert logic or decision support
software.
EXAMPLES:
?
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a probability that is stated by a person. This
would be paired with the observation id.
EXAMPLES:
An example might be if Dr. Huff, Pathologist was reviewing
a differential (cell count) and identified a myeloblast and
and placed a 95% confidence that it was a myeloblast.
(we try).....
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
Unlike fuzzy bears, fuzzy statements are superlatives. These
are statements like very, best, most, greatest, etc.
EXAMPLES:
Dr. Huff, the greatest Pathologist, is reviewing a differential
that night tech R. Dupont has ask him to review. He sees myeloblasts
they are not typical... he might comment as very atypical
myeloblasts seen.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
Units are standard quantity used as a measure, such as milligrams for
every decaliter. This is required so that measurements can be
compared within patients and facilitites.
EXAMPLES:
Glucose results are measured in mg/dl (miligrams per decaliter).
DATABASE MAPPING:
Observation:Units_Ncid
HL7 MAPPING:
OBX-6 Units
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Release 5x of the alerts will allow the matching of units.
Coding of units is required.
DEFINITION:
The results of a laboratory test. See StdLabObservation.
DEFINITION:
This is the set of the observations that constitute a test. It
includes the observaiton code, values, reference ranges,
abnormal flags, delta flags, reporting flags, and observation
specific comments and result status.
EXAMPLES:
A Chem 7 test consists of the following set of observations :
Sodium, Potassium, Chloride, CO2, Blood Urea Nitrogen,
Glucose, and Creatinine.
DATABASE MAPPING:
Observation
HL7 MAPPING:
OBX
OLE MAPPING:
Supported:
Property: ClabData::Results.item()
OLE data type: CObservation object
ALERT REQUIREMENTS:
Observations are used by Critical Lab, Medication Monitoring,
ADEs, and Infectious Disease, there will be more in the future.
They need to be coded and have coded, numeric, range, or titer values.
Text results are not supported.
DEFINITION:
The observation id is the coded (ncid) of the observation. This
represents the analyte that was being tested.
EXAMPLES:
Examples of observation id's include 6164-Creatinine, 6004-Calcium Total,
6343-Glucose, and 7585 Digoxin.
DATABASE MAPPING:
Observation:Observation_Ncid
HL7 MAPPING:
OBX-3 Observation Identifier
OLE MAPPING:
Supported: Get
Property: CObservation::ResultName
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Observations are used by Critical Lab, Medication Monitoring,
ADEs, and Infectious Disease, there will be more in the future.
They need to be coded and have coded, numeric, range, or titer values.
Text results are not supported.
DEFINITION:
This is the measurement of the observation. How much of thing
was there. See ObservationValue and observation.
EXAMPLES:
An example of 6164-Creatinine would be 1.2 mg/dl. The value 1.2
would be stored in value the units mg/dl would be stored in
the units area. See ObservationValue and observation.
DATABASE MAPPING:
Observation:Numeric, Titer_Low Titer_High, Range_Low Range_High, Text_Value,
Numeric_Operator_Ncid, Coded_Ncid
HL7 MAPPING:
OBX-5 Observation ValueX
OLE MAPPING:
Supported: Get
Property: CObservation::CodedValue
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Observations values are used by Critical Lab, Medication Monitoring,
ADEs, and Infectious Disease, there will be more in the future.
They need to be have coded, numeric, range, or titer values.
Text results are not supported. In some cases units may be needed.
DEFINITION:
This is the normal values as sent from the laboratory system. These
are the values that are considered within healthy limits for the person.
They can be based on age, sex, or race. They are usually set per
facility and are based on the patient population and the instrumentation
used to perform the tests. We usually get only free text in this area.
EXAMPLES:
An example would be the hematocrit reference range for a 32 year old female
is 36-42%.
DATABASE MAPPING:
Observation:References_Range
HL7 MAPPING:
OBX-7 References Range
OLE MAPPING:
Supported: Get/Set
Property: CObservation::ReferencesRange
OLE data type: BSTR
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a flag that is placed on a result and is used to communicate
to a clinician if a result is out of the normal reference range.
Usually the flag also trys to communicate the severity of the
difference between the result and the reference range of the result.
These flags should be coded. The flagging of the results is controlled
by the laboratory computer system and is part of clinical laboratories
internal quality control.
EXAMPLES:
A potassium of 2.1 would be flagged low critical. A potassium
of 5.5 might be flagged High. A potassium of 6.7 would be flagged
high critical.
DATABASE MAPPING:
Observation:Abnormal_Flag_Ncid
HL7 MAPPING:
OBX-8 Abnormal Flags
OLE MAPPING:
Supported: Get
Property: CObservation::AbnormalFlag
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Will be used by the Critical Labs Release 5x. Could be used by other
logic in the future.
DEFINITION:
This status is reflects the current completion status of the
results for one observationId. This differs from the testStatus
which defines the current completion for the entire test
which may have multiple observationIds.
EXAMPLES:
A chem-7 is resulted with Sodium 125, Potassium 5.8, Chloride 100,
Urea Nitrogen 32, glucose 92, and CO2 22. The chem-7 is sent again
with each result the same except the Potassium 3.5 with a result status
indicating that the result has been corrected.
DATABASE MAPPING:
Currently not used.
HL7 MAPPING:
OBX-11 Ovserv Result Status. It does not appear that it is supported
by the current interface.
OLE MAPPING:
Supported: Get
Property: CObservation::ResultStatus
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a flag that is placed on a result and is used to communicate
to a clinician if a result has changed significantly from the previous
value. These flags should be coded. The flagging of the results is
controlled by the laboratory computer system and is part of clinical
laboratories internal quality control.
EXAMPLES:
A glucose level has a result of 105; a period of time passes and another
glucose level is drawn with the result of 270. This result gets flagged
with a delta flag that indicates that is value has significantly changed
upward.
DATABASE MAPPING:
Observation:Delta_flag_ncid.
HL7 MAPPING:
OBX-8 Abnormal Flags. This same field is used for both abnormal and
delta flags. The interface specification appear to support delta flags.
OLE MAPPING:
Supported: Get
Property: Cobservation::DeltaFlag
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Currently not used in version 4x. Planned enhancement for version 5x.
will be the use of delta flag for critical labs.
DEFINITION:
This is a coded field that indicates whether a result or observation
should be available for reporting, alerting or display. The flag may indicate
that the result is not publically available due to research, patient
confidentiality, or a number of other reasons.
EXAMPLES:
Often times the result of an HIV test is not publically available and the
results are given person to person only.
DATABASE MAPPING:
Observation:Report_Flag_Ncid
HL7 MAPPING:
OBX-13 User Defined Access Checks But this doesn't look like it is supported
as it is not documented in our interface documentation.
OLE MAPPING:
Supported: Get
Property: CObservation::ReportingFlag
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Required by critical labs, medication monitoring, ADEs, Infectious
Disease and possibly future packages. The alerting packages use the
reporting flag to determine whether the result is a candidate to be
used in the alert logic.
DEFINITION:
This is a free text comment that allows the entering of information
relative to the observation.
EXAMPLES:
For example, if a result could only be done once the tech might
post the following "Unable to repeat the result. To validate
send more sample".
DATABASE MAPPING:
HL7 MAPPING:
We believe this comes from the NTE segment maybe??
OLE MAPPING:
Supported: Get
Property: CObservation::TextComments
OLE data type: CTextComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a coded comment. This allows the entering of "canned"
information about the observation.
EXAMPLES:
For example, if a result was done in error you might see a
coded comment of "Result posted in error".
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Supported: Get
Property: CObservation::CodedComments
OLE data type: CCodedComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
we don't know what this is
DEFINITION:
obsId has now been added back into this structure.
The 'id' in the INSTANCE-OF-SUBTYPE structure refers
to the ASN1 structure or subtype being used to store
and validate the data. The obsId Ncid identifies the
actual data being stored.
DEFINITION:
The value of the clinical Observation including a ranges, units, time of
observation and any error codes or text.
DATABASE MAPPING:
ClinicalObservation
DATABASE MAPPING:
ClinicalObservation:ReferenceRange
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ClinicalObservation:
DEFINITION:
An html text description of the complete observation. (Can also include other forms
of text such as sgml, rtf or regular text.)
DATABASE MAPPING:
CommentGroup:, CommentItem:, CommentDoc:
DATABASE MAPPING:
ClinicalObservation:Display
DEFINITION:
This is a coded data element that represents a complete representation of the
observation, including the observation name, the observation value, and any
observation modifier. For example: "Patient has coarse rales in the right
upper lobe."
DATABASE MAPPING:
Same as ClinObs.
DATABASE MAPPING:
ClinicalObservation:
DEFINITION:
Format is a Voser stored representation that allows runtime insertion of
variables into the display expression (similar to the "=" in PTXT. A schedule
for implementing this function has not been set, but it will be after
Version 5.0.
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ActionInfo:
DATABASE MAPPING:
ClinicalObservation:HL7_SETID
DEFINITION:
The goal is to unify the representation of all clinical observations as much as
possible. ClinObsHeader is the parent type from which LabDataHeader and
PatObsHeader will be derived.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Should be implemented using semantic links in the future.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Should be implemented using semantic links in the future.
DATABASE MAPPING:
ClinicalEventHeader:
DATABASE MAPPING:
ClinicalEventHeader:
DATABASE MAPPING:
EventHeaderTimeInterval:
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Used for comments for version 5 and later.
DATABASE MAPPING:
CommentGroup:, CommentItem:, CommentDoc:
DEFINITION:
Used first in alerts to distinguish critical lab, meds monitoring
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
The severity of observation. See alert.a1 severity for a discussion
on the severity of alerts and their assigment.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
The value asscociated with a severity. See alert.a1 severityValue
for a discussion on the severity and severity value.
DATABASE MAPPING:
Currently not defined, will be defined in future releases.
DEFINITION:
Where in the install process an alert is, live or test. See
alert.a1 for a complete discussion on productionStatus.
DATABASE MAPPING:
Currently not defined, will be defined in future releases.
DEFINITION:
See AlertKey for a discussion of this field, found in alert.a1.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
See alert.a1 for further discussion of the alert object (AOE).
DATABASE MAPPING:
ClinicalEventHeader:AlertObject
DEFINITION:
Using original alert message as a trigger for other AOEs. See alert.a1
for a discussion on chaining.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Used for distribution of the alert messages. See alert.a1 for discussion
on notificaitons.
DATABASE MAPPING:
Notification
DATABASE MAPPING:
ClinicalEventHeader:Display
DATABASE MAPPING:
ClinicaleventHeader:
DATABASE MAPPING:
ClinicalEventHeader:
DATABASE MAPPING:
DisplayOrder:
DEFINITION:
This is a set of unique identifiers which are assigned by the
CAM to identify alert object executables with the triggering
event. It allows the logic that is fired (no matter the number
of aoes) to be linked to the transaction that triggered the
logic.
EXAMPLES:
For instance, a lab result for potassium is stored. This data
is then sent to the alert infrastructure for processing both
the Critical Labs and Medication Monitoring (lab->drug) logic
is executed. These two aoes will share transId (say 1) but have
sequential seq (1, 2). So Critical Labs has the Alert Key 1-1 and
Medication Monitoring Lab->Drug has Alert Key 1-2.
DEFINITION:
The transId is the number used to link the AOEs that are
executed as a result of one trigger event.
EXAMPLES:
If a lab result comes through the CAM it will be given a
transId incremented by one since the last data string that
came through the system.
DATABASE MAPPING:
State_Table:Tx_Id
HL7 MAPPING:
Currently not supported.
OLE MAPPING:
ALERT REQUIREMENTS:
Assigned by the CAM required to link data events to aoes.
DEFINITION:
The number assigned by the CAM to each executable object
that is executed.
EXAMPLES:
One piece of data may trigger several AOEs. The transId
is held steady while the seq is incremented for each AOE
that is executed against the data.
DATABASE MAPPING:
State_Table:Seq_Num
HL7 MAPPING:
Not Currently supported.
OLE MAPPING:
ALERT REQUIREMENTS:
Assigned by the CAM required to link data events to aoes.
DEFINITION:
The name of the AOE (alert object) that was responsible
for creating the alert message. See alert.a1 for complete
description of this item.
DEFINITION:
This is the set of alert destinations/notifications.
DEFINITION:
This is the distribution of the alert message. This set of
information is used to distribute messages to users. Currently
this is done as part of the Alert Management system.
DEFINITION:
desType describes how the DestinationValue was arrived at. For
instance, the DestinationValues may have been arrived at by using
a piece of code that determined the attending physician. It could
also specify that the destination was arrived at by picking a person or
place off a list.
EXAMPLES:
For example, when a Medication Monitoring alert fires and is positive
you may want to send the message to the Attending Doctor and the pharmacy
department. The attending doctor value was arrived at by running logic
that looked in the Encounter role tables for the patient and determined
the Ncid of the atttending doctor. The pharmacy department was arrived at
by picking the department off a list.
DATABASE MAPPING:
Notification:
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
ALERT REQUIREMENTS:
The Alert Management software will fill this field.
DEFINITION:
value (DestinationValue) is the value of the destination. This could be an Ncid
or could be an actual text representation of an e-mail address. In either case
it denotes who or what gets the alert message. It may be arrived at by running
logic that determines a notification list, such as the attending doctor, or
it might be arrived at by picking a place or person from a list.
EXAMPLES:
Examples of what might be in this field include : Ncid of a person or place,
an actual e-mail address.
DATABASE MAPPING:
Notification:
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
ALERT REQUIREMENTS:
The Alert Management software will fill this field.
DEFINITION:
id(NotificationId) is a unique identifier that ties a notification
back to a message. It is possible that a single message may have
multiple notifications.
EXAMPLES:
A patient has a critical high serum potassium, 6.8 meq/L. The
the Critical Lab alerts creates an alert message. The message
is sent to the attending physician, the nursing division, and
the QA department. Each of the notifications will have a unique
identifier that ties it back to the alert message.
DATABASE MAPPING:
Notification:ValueText
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
ALERT REQUIREMENTS:
Created by the Alert Management software.
DEFINITION:
deliverySystem defines how your organization delivers it messages. This, in general,
will be through the HEMS system, however it is possible that one enterprise may
select to use a product such as Groupwise to deliver messages.
DATABASE MAPPING:
Currenlty not defined, will be defined in future releases.
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
Currently not defined, will be defined in future releases.
ALERT REQUIREMENTS:
This field will be filled by the Alert Management software.
DATABASE MAPPING:
Notification:ValueText
DATABASE MAPPING:
Notification:ValueCodedNcid
DATABASE MAPPING:
Notification:ValueText
DATABASE MAPPING:
DATABASE MAPPING:
DATABASE MAPPING:
DEFINITION:
Obsolete. This is the Rel04 style of body location.
LocationDescription stores body site information. This information
is usually collected in physical examination, radiological exams,
anatomic pathology and other information that details the location
of the findings.
EXAMPLES:
Breath sounds are diminished in the right upper quadrant of the lungs.
The leison was found on the left lower leg.
DATABASE MAPPING:
HL7 MAPPING:
????
OLE MAPPING:
ALERT REQUIREMENTS:
Currently not used.
DATABASE MAPPING:
C-1,9,10,11,12,13,14,15,16,18,19
DATABASE MAPPING:
C-11 will be one occurrence of this SET
C-12 will be one occurrence of this SET
C-19 will be one occurrence of this SET
DEFINITION:
The ID of the clinician who performed the action.
This may be the same as the 'enteredBy' persion.
DEFINITION:
Related to ORC-1 in HL7, also used to store
information about every action which happens
DEFINITION:
Corresponds to ORC-10
This identifies who actually entered the data into
the system.
DEFINITION:
Corresponds to ORC-9
DEFINITION:
Corresponds to ORC-15
DEFINITION:
Corresponds to ORC-13, ORC-18
The location where data was entered into the system.
DEFINITION:
The location where care was provided.
DEFINITION:
Obsolete. Should only use prior to version 5.
DEFINITION:
Obsolete. Should only use prior to version 5.
DEFINITION:
Used for counterSignatures, etc.
DEFINITION:
Used when the action only applies to a subpart of the
patient Event. XXX Probably not needed because old and new could
be compared in audit file, redundant when used in conjunction with
semantic links.
DEFINITION:
This is filled in by DSS to indicate what editVersion of
the event the EventActionInfo was originally stored with.
DEFINITION:
This is filled by a client program when the clinician
electronically signs the document
DEFINITION:
means 0 to many
OTHER NOTES:
means 1 to many
OTHER NOTES:
Concept 'BodyAnatomy': Ncid is 1134UL2 , Rsid is 31091UL2
BodySiteMod is new as of July 1998. It replaces the following
types: BodySide, BodyLaterality, Depth, RelativeDepth, Level
RelativeLevel, RelSideOrLaterality
OTHER NOTES:
Concept 'Trend': Ncid is 31097UL2 , Rsid is 160275UL2
OTHER NOTES:
Concept 'Severity': Ncid is 30920UL2 , Rsid is 160136UL2
OTHER NOTES:
Concept 'Chronicity': Ncid is 84293UL2 , Rsid is 1055783UL2
OTHER NOTES:
Concept 'GeneralObservationModifier': Ncid is 83858UL2 , Rsid is 1055313UL2
OTHER NOTES:
Terminal Concept 'ApplicationId', Ncid is 14707639UL2 , Rsid is 15559203UL2
OTHER NOTES:
Concept 'EffectiveAge': Ncid is 119304UL2 , Rsid is 3886581UL2
OTHER NOTES:
Concept 'ExacerbatingFactors': Ncid is 119305UL2 , Rsid is 3886584UL2
OTHER NOTES:
Concept 'AlleviatingFactors': Ncid is 119306UL2 , Rsid is 3886566UL2
OTHER NOTES:
Concept 'ObservationMethod': Ncid is 30692UL2 , Rsid is 159908UL2
OTHER NOTES:
Concept 'Uncertainty': Ncid is 1482UL2 , Rsid is 239UL2
DEFINITION:
The value of AssociatedDateTimeObs is always a date time, but in the future it can contain
additional obsMods that describe the observation, eg. the transcriptionist, the interface id, etc.
It contains DateTime information that is a single time, not an interval
OTHER NOTES:
For now this is the same domain as AssociatedDateTimeInfo
HL7 MAPPING:
DG1.3.3 Diagnosis Coding Method
PR1.3.3 Procedure Coding Method
HL7 MAPPING:
DG1.17 DiagnosisClassification
HL7 MAPPING:
DG1.6 DiagnosisType
HL7 MAPPING:
DG1.18 Confidential Indicator
OTHER NOTES:
Terminal Concept 'ClinicianRole', Ncid is 1365UL2 , Rsid is 82UL2
ClinicianRole is a domain, ncid 1365 - new memebers for Procedure Practioner, Anesthesiologist,
Diagnosing Clinician are needed in this domain
OTHER NOTES:
Terminal Concept 'AssociatedClinician', Ncid is 14707640UL2 , Rsid is
15559205UL2
OTHER NOTES:
Concept 'Diagnosis': Ncid is 105328UL2 , Rsid is 3859412UL2
DEFINITION:
PatientObservation is mostly a template to follow when
creating ClinicalObservation subtypes for the WITH TYPES
clause of the clinObs in a subtype of PatientEvent.
OTHER NOTES:
Concept 'ModelNum': Ncid is 114038UL2 , Rsid is 3859477UL2
OTHER NOTES:
Concept 'SerialNum': Ncid is 114039UL2 , Rsid is 3859480UL2
OTHER NOTES:
Concept 'ProstheticDevice': Ncid is 114040UL2 , Rsid is 3859484UL2
HL7 MAPPING:
PR1.6 Procedure Function Type
OTHER NOTES:
Terminal Concept 'ProcedureFunctionalType', Ncid is 14707645UL2 , Rsid is 15559215UL2
ProceedureFunctionalType is a domain, ncid ??
HL7 MAPPING:
PR1.13 Consent Code
OTHER NOTES:
Terminal Concept 'ConsentCode', Ncid is cidConcentCode, Rsid is 15559207UL2
ConsentCode is a domain, ncid
OTHER NOTES:
Terminal Concept 'ProcedureType', Ncid is 14707647UL2 , Rsid is 15559219UL2
ProceedureType is a domain, ncid ??
HL7 PR1.14 Procedure Priority
OTHER NOTES:
Terminal Concept 'ProcedureDuration',Ncid is 14707644UL2 ,Rsid is 15559213UL2
HL7 PR1.7 Procedure Minutes
OTHER NOTES:
Terminal Concept 'ProcedureCodeModifier', Ncid is 14707643UL2 , Rsid is rsidProcedureCodemodifier
ProceedureCodeModifier is a domain, ncid ??
HL7 PR1.16 Procedure Code Modifier
OTHER NOTES:
Terminal Concept 'DRGProcedureRank', Ncid is 14707642UL2 , Rsid is 15559209UL2
ProceedureDRGType is a domain, ncid ??
HL7 PR1.17 Procedure DRG Type
OTHER NOTES:
Terminal Concept 'ProcedureTissueType', Ncid is 14707646UL2 , Rsid is 15559217UL2
ProceedureTissueType is a domain, ncid ??
HL7 PR1.18 Tissue Type
OTHER NOTES:
Terminal Concept 'AnesthesiaDuration', Ncid is cidAnesthesiaDuration, Rsid is rsidAnesthesiaDuration
HL7 PR1.10 Anesthesia Minutes
OTHER NOTES:
Terminal Concept 'AnesthesiaCode', Ncid is cidAnesthesiaCode, Rsid is rsidAnesthesiaCode
AnesthesiaCode is a domain, ncid
HL7 PR1.9 Anesthesia Code
OTHER NOTES:
Concept 'MedicalProcedure': Ncid is 82750UL2 , Rsid is 1055156UL2
OTHER NOTES:
Concept 'FuzzyVolume': Ncid is 1396UL2 , Rsid is 117UL2