Go to the first, previous, next, last section, table of contents.

The LabEventInfo Table


The cvgateway program needs information about CareVue LabEvents, in order to bring observation results into the right unit needed for carevue and to adjust the format and precision of the measurement value. The LabEventInfo table has the following attributes:

LOINC code number (or some other observation identifier).
CareVue's LabEventClass
CareVue's property of the LabEventClass, usually `value1'
CareVue's MsmtClass
unit of measure in which the measurement is expressed in CareVue
unit of a constant that can be used to convert between two related units. Typically specifies molar masses for conversion between substance concentration and mass concentration
value of the conversion constant
minimal allowed value for the measure in CareVue
low alarm boundary
low boundary of reference value
high boundary of reference value
high alarm boundary
maximal allowed value for the measure in CareVue
increment configured in CareVue (e.g. `0.001')
precision configured in CareVue (e.g. `3'). Functionally dependent with increment.

This database exists in two forms: the tabular (`source code') form is used by humans to edit the table, while the compiled, hashed form is used for fast access by the cvgateway program. The tabular form simply specifies one tuple (row) per line and separates the columns by colons (`:'). Commentary lines are allowed to start with a number sign (`#') as the first character of the line. An empty numeric field is treated as zero and an empty string field is treated as NULL. The checking of boundaries is turned off by setting the boundary equal to the high boundary (preferably both to zero).

Specialities of cvgateway

The cvgateway program has some special interpretations to the entries of the LabEventInfo database. Since the laboratory result are currently received only from the ABL,(3) and since our CareVue configuration distinguishes between venous and artherial ABL results in order to perform calculations with the two. Some measurements, like hemoglobin, had to be doubled in the LOINC code to provide for the additional knowledge about the exact specimen source. On the other hand, the LOINC specimen source code lacks exact differentiation of venous blood between peripheral venous, central venous and mixed venous.

There is an implied entry in the LabEventInfo database defining the `BGATYPA' and `BGATYPV' parameter. The values that are currently transmitted to CareVue for these "observations" are from and ad-hoc code table, that does neither respect any standard, nor is it good for international use (german abbreviated word `unbek.' for "unknown"). However, this is an ad-hoc solution that was quickly programmed and can be changed in the cvgateway sourcecode(4).

soapbox This shows the enormous interoperability problems evolving when coding systems are not complete. Every work around this problem is essentially a hack, the interim solution can be to facilitate coding systems mapping (which is not trivial) but this will never be a final solution. A successful EDI standard must provide a consistent and complete set of coding systems for use among all implementation in order to grant interoperability. end soapbox

If the property value is set to `*BGATEMP*' the cvgateway will look up the observation identifiers `BGATEMPA' or `BGATEMPV' depending on the specimen source being arterial or venous respectively. The freedom to define additional `LOINC+' codes is stressed too much if we defined artherial and venous temperatures.


Some example lines for this database are:

# Admit weight, height and BSA
# type of blood specimen 
# temperature (map 9984-6/"BODY TEMPERATURE" to BGATEMPA or BGATEMPV)
# PO2
# Hb. HbO2. HbCO. metHb
# K+, Na+, Ca++, Cl-, Glucose


the tabular source version
the compiled, hashed file

See Also

odbm(3), gdbm(3), section Managing the Results Mapping.

Go to the first, previous, next, last section, table of contents.