StandardLabData:

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.

labDataHeader:

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

results:

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

testName:

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.

specimens:

DEFINITION:
		This is a set of specimen descriptors.  See LabSpecimen for
		detailed description.
OLE MAPPING:
	Not Supported:

verifiedDateTime:

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.

resultReceivedDateTime:

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.

fillerOrderNumber:

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.

placerOrderNumber:

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.

testStatus:

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.

resultingTechnicians:

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.

codedComments:

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.

textComments:

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.

L-ResultingTechnicians:

DEFINITION:
	See resultingTechnicians.

L-ResultingTechnician:

DEFINITION:
	See resultingTechnicians

LabSpecimens:

DEFINITION:
	This is a set of specimen descriptors.  See LabSpecimen for
	detailed description.

LabSpecimen:

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.

collectionDateTime:

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.

specimenReceivedDateTime:

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.

aggregateSpecDescript:

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.

specimenDescript:

DEFINITION:
	This is the set of information that describes a specimen.  See
	Specimen Descript.

collectors:

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.

collectionLocation:

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.

codedComments:

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.

textComments:

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.

setId:

DEFINITION:
 I don't know what this is

L-Collectors:

DEFINITION:
	See collectors.

L-Collector:

DEFINITION:
	See collectors.

SpecimenDescript:

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.

bodySite:

DEFINITION:
 	See clintype.a1 BodySite.

aggregateBodySite:

DEFINITION:
 	See clintype.a1

specimenType:

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.

specimenCollectionMethod:

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.

volume:

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.

fuzzyVolume:

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.

collectionDevice:

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.

pathologicLesion:

DEFINITION:
 		See clintype.a1 PathologicLesion

color:

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.

odor:

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.

consistency:

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.

patientPosition:

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.

prostheticDevice:

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.

ObservationValue:

DEFINITION:
	This is a set of the valid types of values that may
	be asscociated with an observation id.

observation:

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.

negation:

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.

numericOperator:

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.

uncertainty:

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.

machineProbability:

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.

userStatedProbability:

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.

fuzzyStatement:

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.

units:

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.

StdLabObservations:

DEFINITION:
	The results of a laboratory test.  See StdLabObservation.

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.

observationId:

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.

observationValue:

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.

referencesRange:

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.

abnormalFlag:

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.

resultStatus:

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.

deltaFlag:

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.

reportingFlag:

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.

textComments:

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.

codedComments:

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.

setId:

DEFINITION:
 we don't know what this is

obsId:

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.

obsValue:

DEFINITION:
  The value of the clinical Observation including a ranges, units, time of
  observation and any error codes or text.
DATABASE MAPPING:
  ClinicalObservation

refRange:

DATABASE MAPPING:
  ClinicalObservation:ReferenceRange

abnFlag:

DATABASE MAPPING:
  ClinicalObservation:

status:

DATABASE MAPPING:
  ClinicalObservation:

deltaFlag:

DATABASE MAPPING:
  ClinicalObservation:

reportFlag:

DATABASE MAPPING:
  ClinicalObservation:

comments:

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:

display:

DATABASE MAPPING:
  ClinicalObservation:Display

obsMods:

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.

aggObs:

DATABASE MAPPING:
  ClinicalObservation:

format:

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:

actionsInfo:

DATABASE MAPPING:
  ActionInfo:

setId:

DATABASE MAPPING:
  ClinicalObservation:HL7_SETID

ClinObsHeader:

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.

obsBatId:

DATABASE MAPPING:
  ClinicalEventHeader:

fillerOrderNumber:

DEFINITION:
  Should be implemented using semantic links in the future.
DATABASE MAPPING:
  ClinicalEventHeader:

placerOrderNumber:

DEFINITION:
  Should be implemented using semantic links in the future.
DATABASE MAPPING:
  ClinicalEventHeader:

testStatus:

DATABASE MAPPING:
  ClinicalEventHeader:

obsDateTime:

DATABASE MAPPING:
  EventHeaderTimeInterval:

observedBy:

DATABASE MAPPING:
  ClinicalEventHeader:

comments:

DEFINITION:
  Used for comments for version 5 and later.
DATABASE MAPPING:
  CommentGroup:, CommentItem:, CommentDoc:

type:

DEFINITION:
  Used first in alerts to distinguish critical lab, meds monitoring
DATABASE MAPPING:
  ClinicalEventHeader:

severity:

DEFINITION:
   The severity of observation.  See alert.a1 severity for a discussion
  on the severity of alerts and their assigment.
DATABASE MAPPING:
  ClinicalEventHeader:

severityValue:

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.

productionStatus:

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.

alertKey:

DEFINITION:
  See AlertKey for a discussion of this field, found in alert.a1.
DATABASE MAPPING:
  ClinicalEventHeader:

alertObject:

DEFINITION:
    See alert.a1 for further discussion of the alert object (AOE).
DATABASE MAPPING:
  ClinicalEventHeader:AlertObject

chain:

DEFINITION:
  Using original alert message as a trigger for other AOEs.  See alert.a1
  for a discussion on chaining.
DATABASE MAPPING:
  ClinicalEventHeader:

notifications:

DEFINITION:
  Used for distribution of the alert messages.  See alert.a1 for discussion
  on notificaitons.
DATABASE MAPPING:
  Notification

display:

DATABASE MAPPING:
  ClinicalEventHeader:Display

aggObs:

DATABASE MAPPING:
 ClinicaleventHeader:

format:

DATABASE MAPPING:
  ClinicalEventHeader:

displayOrder:

DATABASE MAPPING:
  DisplayOrder:

AlertKey:

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.

transId:

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.

seq:

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.

AlertObject:

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.

Notifications:

DEFINITION:
  This is the set of alert destinations/notifications.

Notification:

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.

desType:

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.

value:

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.

id:

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.

deliverySystem:

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.

NotificationId:

DATABASE MAPPING:
  Notification:ValueText

coded:

DATABASE MAPPING:
  Notification:ValueCodedNcid

text:

DATABASE MAPPING:
  Notification:ValueText

DisplayText:

DATABASE MAPPING:


ReferenceRange:

DATABASE MAPPING:


TextComments:

DATABASE MAPPING:


LocationDescription:

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.

actionsInfo:

DATABASE MAPPING:
C-1,9,10,11,12,13,14,15,16,18,19

EventActionsInfo:

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

clinician:

DEFINITION:
 The ID of the clinician who performed the action.
 This may be the same as the 'enteredBy' persion.

actionId:

DEFINITION:
 Related to ORC-1 in HL7, also used to store
 information about every action which happens

enteredBy:

DEFINITION:
 Corresponds to ORC-10
 This identifies who actually entered the data into
 the system.

enteredTime:

DEFINITION:
 Corresponds to ORC-9

effectiveTime:

DEFINITION:
 Corresponds to ORC-15

location:

DEFINITION:
 Corresponds to ORC-13, ORC-18
 The location where data was entered into the system.

pointOfCare:

DEFINITION:
 The location where care was provided.

textComments:

DEFINITION:
 Obsolete.  Should only use prior to version 5.

codedComments:

DEFINITION:
 Obsolete.  Should only use prior to version 5.

associatedActions:

DEFINITION:
 Used for counterSignatures, etc.

elementPaths:

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.

editVersion:

DEFINITION:
 This is filled in by DSS to indicate what editVersion of
 the event the EventActionInfo was originally stored with.

pkiCertificate:

DEFINITION:
 This is filled by a client program when the clinician
 electronically signs the document

locationInfo:

DEFINITION:
 The location where data was entered into the system.

pointOfCare:

DEFINITION:
 The location where care was provided.

application:

DEFINITION:
 The application that was the proximal source of the message.

userid:

DEFINITION:
 The person who actually entered the data into the system.
 Note that this may be different from the Clinician providing
 the care.  This gets copied by DSS to the 'enteredBy' node
 in the EventActionInfo structure.

time:

DEFINITION:
 The time that a message was sent from an application.

clinician:

DEFINITION:
 The person who actually entered the data.  This gets
 gets mapped by DSS to the 'clinician' node in the
 EventActionInfo structure.

reason:

DEFINITION:
 The reason for this insert/update/delete.  This gets copied
 to the 'reason' node in the EventActionInfo structure.

comments:

DEFINITION:
 Any comments on this insert/update/delete.  This gets copied
 to the 'comments' node in the EventActionInfo structure.

WLAdminTrans:

EXAMPLES:
PORTS WLQueryTrans;

DynamicSqlTransaction:

DEFINITION:
 DynamicSqlTransaction is a message type which can be used in
 the 'trans' field of a 'HemsInfo' message.  It is a sequence
 of dynamic sql statements which will be processed as a single
 transaction in the SQLSERV Tuxedo service.

DynamicSqlStatement:

DEFINITION:
 This is the basic structure used to define a SQL statement to be
 executed by the SQLSERV Tuxedo service.  This structure also
 supports the return of data to the caller.

sqlId:

OTHER NOTES:
 If sqlId = 1450582 (Magic_NCID) then the text of the SQL
 statement must be supplied in the 'sqlStatement' field and
 can have bind variable place holders.  If sqlId is set to
 Procedure_NCID then the name of the stored procedure to be
 called must be supplied in the 'procName' field and all parameters
 must be supplied as bind variables.  For all other values of
 sqlId the context 2000 representation of the NCID will be retrieved
 as the SQL statement's text, which will support bind variable place
 holders.  This SQL statement can be any DML, query, or PL/SQL block.

sqlStatement:

OTHER NOTES:
 On input 'sqlStatement' must contain the text of the SQL statement
 to be executed if 'sqlId' = 1450582 (Magic_NCID).  Otherwise this
 field will be ignored as input.  For output purposes, this field
 will not be present unless a configuration parameter is set in
 SQLSERV for debug purposes.

procName:

OTHER NOTES:
 On input, 'procName' must contain the the name of the stored
 procedure to be called if 'sqlId' = Procedure_NCID.  Otherwise it
 should be empty on input.  This field will never be present in
 the output from the SQLSERV Tuxedo service.

statementFlags:

OTHER NOTES:
 The 'statementFlags' field contains some messaging related flags
 On input, the 'rowsReturned' field can be used to indicate the
 maximum number of rows which should be returned.  On output,
 the 'rowsReturned' field indicates the total number of rows
 returned and the 'moreRows' field indicates if the number of
 rows returned is less than what was actually available because
 the maximum number of rows was reached.

columnNames:

OTHER NOTES:
 The 'columnNames' field returns the names of the
 columns corresponding to the rows returned in
 the 'rows' field.  The first column name
 in the 'columnNames' sequence matches the first
 value in each member of the 'rows' sequence, etc.

rows:

OTHER NOTES:
 The 'rows' field is used to return a result set
 if the SQL statement was either a query or a
 stored procedure call with a parameter which is
 a cursor variable.

bindVars:

OTHER NOTES:
 The 'bindVars' field on input must contain as many
 instances as there are bind variable placeholders in
 the SQL statement to be executed.  The first instance
 in the bindVars sequence corresponds to the first bind
 variable place holder in the SQL statement, etc.  All
 'inBindVars' will be set to a zero length string on
 output unless a configuration parameter is set in the
 SQLSERV Tuxedo service for debug purposes.  All 'inOutBindVars'
 will be set to the value of the bind variable after the
 SQL statement is executed.

DynamicSqlText:

DEFINITION:
 The DynamicSqlText type is simply equated to a BasicString.

DynamicSqlProcName:

DEFINITION:
 The DynamicSqlProcName type is simply equated to a BasicString.

DynamicSqlFlags:

DEFINITION:
 The DynamicSqlFlags type is used for messaging related flags.
 On input, the 'rowsReturned' field can be used to indicate the
 maximum number of rows which should be returned.  On output,
 the 'rowsReturned' field indicates the total number of rows
 returned and the 'moreRows' field indicates if the number of
 rows returned is less than what was actually available because
 the maximum number of rows was reached.

DynamicSqlColumnNames:

DEFINITION:
 The DynamicSqlColumnNames type is an ordered list of
 column names associated with the result set.

DynamicSqlColumnName:

DEFINITION:
 The DynamicSqlColumnName type is simply equated to a BasicString.

DynamicSqlRows:

DEFINITION:
 The DynamicSqlRows type is an ordered list of the rows
 returned in a result set.

DynamicSqlColumns:

DEFINITION:
 The DynamicSqlColumns type is an ordered list of the values which
 comprise a row of data in a result set.  The order of the values
 corresponds to the order of the column names in a sequence of type
 DynamicSqlColumnNames.

DynamicSqlValue:

DEFINITION:
 The DynamicSqlValue type represents a single value representing either
 a value for a bind varaible or a column in a
 row of a result set.  Numeric values will be returned as ASCII
 strings which can be converted to their binary form in the
 receiving application.  All dates and date/times will be represented
 in the 'date' field in UTC format.  It is the responsibility of the
 calling application to convert the UTC formatted string as needed.

DynamicSqlBindVars:

DEFINITION:
 The DynamicSqlBindVars type is an ordered sequence of bind variable
 parameters.

DynamicSqlBindVar:

DEFINITION:
 The DynamicSqlBindVar type provides a way to both provide a value
 and indicate whether the value is for input only, or for output also
 (i.e. returned to the caller).  The 'cursorVar' option is simply a
 flag indicating that the bind variable should be handled as a cursor
 variable and that the result set returned in the SQL statement
 execution should be fetched and returned separately as rows of
 values.