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.

ProbabilityObs:

DEFINITION:
 Probability (OBX-9)

UserDefinedAccessObs:

DEFINITION:
 User Defined Access Checks (OBX-13)
OTHER NOTES:
  New domain

OrderObservationObs:

HL7 MAPPING:
   obsId OBX.3.1 Universal Service Identifier
   obsValue OBX.5 Observation ValueX 
   refRange OBX.7 Reference Range
   abnFlag OBX.8 Abnormal Flag
   status OBX.11 Status
   comments  OBX NTE's Comments 
   setId OBX.1 Set Id
OTHER NOTES:
  Observation ValueX  (in OBX-5), Units (in OBX-6)

PharmacyOrder:

DEFINITION:
	This structure details the contents of a pharmacy order.
	This is the order as it is placed by either a clinician, such
	as a physician or placed in a system by a nurse for a physician.
	It may also represent the order as placed by the pharmacist.
EXAMPLES:
	An example of a pharmacy order is : Digoxin .125 mg give 1
	Tablet PO (orally) QD (every day).
DATABASE MAPPING:
	RX_Order, Drug, Drug_Comment, Drug_Coded_Comment, Ingredient,
	RX_Route, Rx_Comment, RX_Instruction, RX_Admin, RX_Instruction_MD
HL7 MAPPING:
	ORC, RXE, RXR, RXC

	RXE-1:  'QuantityTiming' is not needed here because it is in the orderInfo

	RXE-13: 'OrdProviderDeaNumber' is redundant-> is a surface form of the
				ClinicianId stored in the ActionInfo with an ActionId of 'place order'.

	RXE-14: 'PharmacistVerifierId' is not needed here, an occurrence of
				ActionInfo contains this information in detail.
OLE MAPPING:

ALERT REQUIREMENTS:
	The Medication Monitoring, ADE, and Infectious Disease require
	pharmacy orders.

drugs:

DEFINITION:
 	Drugs is the set of medications that are included in this order.
	This consists of the base or additive, the medicaiton, the dose,
	the form of the drug (tablet etc), the total daily dose, the
	ingredients (parts), comments both coded and text.

	See Drug for complete description.
HL7 MAPPING:
	RXE-2 Give Code RXE-3 Give Amount-Min RXE-4 Give Amount-Max
	RXE-5 Give Units, RXE-6 Give Dosage Form, RXE-19 Total Daily Dose
	RXC Component Types, Code, Amount, and Unit
ALERT REQUIREMENTS:
	Required for alerting.  Pretty much all of the above.

routeInfos:

DEFINITION:
	This is the method of drug administration, i.e. how do you
	take the medication.  See RouteInfo for complete details.
EXAMPLES:
	An example of a route would be PO, oral.  Another example
	would be IM, intra muscular.
HL7 MAPPING:
	RXR
ALERT REQUIREMENTS:
	Required for alerting.

providerAdminInstructions:

DEFINITION:
	The instructions for the administration of the medication that
	was provided by the ordering physician.  These instructions
	are given to either the patient or the provider that is responsible
	for administering the medication.   This is free text on HEMS.
EXAMPLES:
	Dr. Baskett has ordered Mylanta to be given after meals to patient
	Gerard.  Nurse Brown is supposed to give patient Gerard Mylanta
	after each meal. "Give after meals" is an administration instruction.
DATABASE MAPPING:
	RX_Instruction_MD:Text
HL7 MAPPING:
	RXE-7	Providers Administration Instructions
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

deliverToLocation:

DEFINITION:
		The location (inpatient or outpatient) to which the pharmacy is to
		deliver the drug (if applicable).  This is either an address or
		a coded location in the enterprise (room, bed, nursing division,
		service area, building facility).  See clintypes.a1 Address and
		mmitypes.a1 for the definition of physical locations.
EXAMPLES:
	R. Dupont is a patient with a malabsorption syndrome who lives at
	home but requires total parenteral nutrition (TPN) on a daily basis.
	The outpatient pharmacy receives the order for the TPN with it many
	components and within the order is a deliver to location of R.Dupont's
	home address.
DATABASE MAPPING:
	RX_Order:deliver_to_loc_ncid, RX_Order:deliver_to_loc_street1,
	RX_Order:deliver_to_loc_street2, RX_Order:deliver_to_loc_city,
	RX_Order:deliver_to_loc_county, RX_Order:deliver_to_loc_state,
	RX_Order:deliver_to_loc_post_code, RX_Order:deliver_to_loc_country_
HL7 MAPPING:
	RXE-8 Deliver-to Location
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used

substitutionStatus:

DEFINITION:
 	When a physician writes an order for a medication; the physician, hospital or
		insurance companies may implement plan for a drug substitution. These
		substittutions are  usually done based on cost, inventory, supply, policies, etc.
		Valid substitution statuses are:  none, generic or therapeutic.  A generic
		substitution the main ingredients are the same but the drug is made by another
		manufacturer.	For a therapeutic substitution, the medicaiton is in a similar drug
		classification but the ingredients are different.
EXAMPLES:
	Dr Culpepper has ordered Motrin 800mg orally qid (four times a day) for R. Dupont
	who is a patient with rheumatoid arthritis.  R. Dupont's insurance requires
	generic substitution of any medication unless the physician specifically requests
	no substitution.  K. Stevenson, registered pharmacist fills the order with
	Ibuprofen rather than the Motrin ordered.
DATABASE MAPPING:
	RX_Order:Substitution_Ncid
HL7 MAPPING:
  RXE-9  Substitution Status
OLE MAPPING:

ALERT REQUIREMENTS:
	Inadvertantly used by alerts ends up being the drug ingredient.

dispensed:

DEFINITION:
	 	This field is usually used only in an outpatient pharmacy setting.  This defines
		the quantity of the drugs to be given to the patient for home use. Typically this
		dispensed quantity is part of the prescription (physician order), but is usually
		written as the number of days supply to be given.

		For the definition of QuantityUnits see clintype.a1.
EXAMPLES:
	Patient R Dupont who suffers from Rheumatoid Arthritis is given Motrin 800
	mg PO (by mouth) QID (four times a day).  The quantity that is dispensed when
	he fills his prescription at Killpack Pharmacy for 30 days will be 120 tablets
	(assuming that 1 tablet is equal to 800 mg).  Here is the math 30 days * 4
	tablets a day (800 mg) = 120 tablets.
DATABASE MAPPING:
	RX_Order:Dispense_Quantity RX_Order:Dispense_Units_Ncid
HL7 MAPPING:
	RXE-10 Dispense Amount
	RXE-10 Dispense Units
ALERT REQUIREMENTS:
	Currenty not used.

numberOfRefills:

DEFINITION:
 	This field is used only in an outpatient pharmacy setting.  This defines
	the number of times that you can have this medication refilled.  Typically
	number of refills is part of the prescription (physician order).  This is
	represented as number.
EXAMPLES:
	R Dupont who suffers from Rheumatoid Arthritis has been using 800 mg PO
	(by mouth) for many months.  Dr Imboden when she wrote his last prescription
	for the Motrin limited the number of refills to 1.  R Dupont will then need
	to return for a visit to Dr Imboden so she can evaluate how he is tolerating
	the high dose of Motrin.
DATABASE MAPPING:
	RX_Order:Number_of_Refills
HL7 MAPPING:
	RXE-12 Number of Refills
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

prescriptionNumber:

DEFINITION:
		This field is primarily used in an outpatient pharmacy setting.  It is a
		unique identifier that is asscociated with each prescription filled at
		a pharmacy locationn.  Typically this identifier is assigned by the
		pharmacy responsible for filling the prescription.  On HEMS this number is a
		combination of the system identifier and a unique reference number.
EXAMPLES:
	R Dupont takes his prescription for Colace 250 mg PO (by mouth)
	QHS (at night) to Acme Pharmacy.  Pharmacist N Reading
	enters the prescription into the pharmacy system.  At the time
	the pharmacy order is entered a unique number is assigned to the
	prescription, A1837484.  This number plus the system ncid for the
	pharmacy becomes the prescriptionNumber on HEMS.
DATABASE MAPPING:
	RX_Order:Prescripton_Number RX_Order:Prescrip_Sys_Ncid
HL7 MAPPING:
	RXE-15 Prescription Number
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

numberOfRefillsRem:

DEFINITION:
		This field is used only in an outpatient pharmacy setting.
		It is the number of refills remaining on a prescription.  In other
		words is as you have a prescription filled this number decrements.
EXAMPLES:
	R Dupont who suffers from Rheumatoid Arthritis has been using 800 mg PO
	(by mouth) for many months.  Dr Gerard when she wrote his last prescription
	for the Motrin limited the number of refills to 1.  After taking the
	Motrin for 1 month, R Dupont returns to Acme Pharmacy.  The pharmacy refills
	the Motrin (a 30 day supply).  Pharmacist H Solbrig reminds R Dupont
	that he will need to return to Dr Gerard as he has no remaining refills
	on this prescription.  The math : The prescription originally had one
	refill (that means after the original he can have it filled 1 more time).
	The second time he goes in 1-1 = 0 left.
DATABASE MAPPING:
	RX_Order:Num_Refills_Remain
HL7 MAPPING:
	RXE-16 Number of Refills Remaining
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

numberOfRefillsDis:

DEFINITION:
	This field is used only in an outpatient pharmacy setting.   It is
	the number of refills that the pharmacist has filled on a prescription.
	In other words, as you have the refills "filled" this number increments.
EXAMPLES:
	R Dupont who suffers from Rheumatoid Arthritis has been using 800 mg PO
	(by mouth) for many months.  Dr K Hatch when she wrote his last prescription
	for the Motrin limited the number of refills to 2.  After taking the
	Motrin for 1 month, R Dupont returns to Acme Pharmacy.  The pharmacy refills
	the Motrin (a 30 day supply).  Pharmacist Beeny reminds R Dupont
	that he has only one more refill. Pharmacist Beeny puts the number of refills
	dispensed to 1.  So the number of remaining refills is 1 and the number of
 	refills dispensed is 1.
DATABASE MAPPING:
	RX_Order:Num_Refills_Dispens
HL7 MAPPING:
	RXE-17 Number of Refills/Doses Dispensed
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

dtMostRecentDoseDis:

DEFINITION:
	This field is the last date and time that the pharmacy order was
	dispensed.
EXAMPLES:
	R Dupont who suffers from Rheumatoid Arthritis has been using 800 mg PO
	(by mouth) for many months.  Dr Westberg when he wrote his last prescription
	for the Motrin limited the number of refills to 2.  After taking the
	Motrin for 1 month (9/1/96), R Dupont returns to Acme Pharmacy.
	The pharmacy refills	the Motrin (a 30 day supply). The dtMostRecentDis
	is set to 10/1/96.
DATABASE MAPPING:
	RX_Order:Date_Last_Dispensed
HL7 MAPPING:
	RXE-18 D/T of Most Recent Refill or Dose Dispensed
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

needsHumanReview:

DEFINITION:
	This field has either a yes or no.  A yes indicates that
	a warning is present and the application receiving the
	pharmacy order should warn the person administering the drug
	to pay attention to the text of the pharmacy special dispensing
	instructions (RXE-21).
EXAMPLES:
	needsHumanReview is set to yes and the pharmacist special
	dispensing instructions is to administer slowly over an interval
	of 5 minutes
DATABASE MAPPING:
	RX_Order:Needs_Review_Ncid
HL7 MAPPING:
	RXE-20 Needs Human Review
OLE MAPPING:


pharmacySpecialIns:

DEFINITION:
	This field is either coded or text and is a pharmacy generated special
	instructions to the provider or the person administering the drug.
EXAMPLES:
	An example is "this medication should be taken with meals".
DATABASE MAPPING:
	Coded - RX_Instruction_Admin:Coded_Comment_Ncid
	Not Coded - RX_Instruction_Admin:Text
HL7 MAPPING:
	RXE-21 Pharmacy Special Dispensing Instructions
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

ivVolumeRate:

DEFINITION:
	This field is a combination of ivGiveTime and ivAmount.  It
	details the time to give and the amount to give for an infusion.

	See clintypes.a1 Duration and QuantityUnits for details on
	ivVolumeRate.
EXAMPLES:
	R. Dupont is a patient with a malabsorption syndrome he
	requires total parenteral nutrition (TPN) on a QD (daily) basis.
	The TPN is infused (given) intravenously (in your arm) at a
	rate of 80 mls per hour (ml/hr) over 12 Hours.  This is a volume rate
	and the 12 Hours is the infusion.
DATABASE MAPPING:
	RX_Order:IV_Rate_Dur_Value RX_Order:IV_Rate_DUR_Ncid
	RX_Order:IV_Rate_Qty_Value	RX_Order:IV_Rate_Qty_Units_Ncid
HL7 MAPPING:
	RXE-22 Give Per (Time Unit)
	RXE-23 Give Rate Amount
	RXE-24 Give Rate Units
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

ivSpecialRate:

DEFINITION:
	This field is sort of kind of like ivVolumeRate in that it breaks
	down to a ivGiveTime and a ivAmount.  However, it has in addtion
	an attachment to a medication (product).  This allows the medication
	to be infused at it own "special" rate.

	See clintypes.a1 Duration and QuantityUnits for details on
	ivVolumeRate.
EXAMPLES:
	R Dupont who suffers from malabsorption syndrome and receives
	daily TPN administration.  On testing it was found that his
	serum potassium has become dangerously low (2.5 meq/L).  His
	potassium needs to be supplemented.  Dr Sawdey orders 80 meq/L
	Potassium Chloride in 100 mls of D5W ("sugar water") to be
	given at 10 meq per hour.  So the 10 meq per hour is the special
	rate and it is based on the Potassium Chloride.
DATABASE MAPPING:
	Coded - RX_Order:IV_Spec_Product_Ncid
	Not Coded - RX_Order:IV_Spec_Product_Name
	RX_Order:IV_Spec_DUR_Value, RX_Order:IV_Spec_Dur_Ncid, RX_Order:IV_Spec_Qty_Value,
	RX_Order:IV_Spec_Qty_Units_Ncid
HL7 MAPPING:
	Not currently defined.
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

codedComments:

DEFINITION:
 Obsolete.  Only for use in version 4.

prescriptionType:

DEFINITION:
	The prescription type is an indicator that associates the drug to the type of
	disease or symptom being treated.  The valid choices are acute or chronic.
	In other words, is drug A being prescribed for a chronic disease and therefore
	we expect the drug to be given to the patient for a long time.  This field
	will be implemented by the Clinical Workstation (CW) medication manager.
EXAMPLES:
	R. Dupont is a brittle (unstable) diabetic, adult onset.  He is receiving
	Insulin SQ (subcutaneously) twice a day depending on the glucose level that
	he checks before breakfast, sometimes before lunch but always before night.
	The Insulin would be the "chronic" or long term medication.  For CW this
	drug remains on the current list until it is manually discontinued or removed.
DATABASE MAPPING:
	Not currently defined.
HL7 MAPPING:
	Not currently defined.
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used

comments:

DEFINITION:
	We assume this has to do with administration of the medication.
	However, currently a coded comment is required and text is not
	stored.  If someone knows more then this then fill this in for us.
DATABASE MAPPING:
	?
HL7 MAPPING:
	Would be supported in NTE segment.
OLE MAPPING:
	?
ALERT REQUIREMENTS:
	Currently not used.

sortIndicator:

DEFINITION:
	The primary purpose of this field is to provide a
     mechanism for the GUI to sort/group orders on the screen.
DATABASE MAPPING:
	?
HL7 MAPPING:
	?
OLE MAPPING:
	?
ALERT REQUIREMENTS:
	?

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 , a height, weight and pulse might be included
 with a drug order.  This is where they would come.
HL7 MAPPING:
   OBX's and NTE's at the end of the message

PrescriptionNumber:

DEFINITION:
 	See PrescriptionNumber for details.

Drugs:

DEFINITION:
	See Drug for details.

Drug:

DEFINITION:
	The Drug section details information regarding the
	medication that has been ordered.  This represents
	the medication as ordered.  The following are detailed
	in the Drug section.  The component type (base, additive, etc),
	the component (the actual drug), the dose (how to give),
	the form of the drug (tablet etc.), the total dose,
	the ingredients (what the drug is made of), coded and
	text comments.
EXAMPLES:
	An example of this section would be :   Dopamine Drip
	Dopamine is the additive and D5W (sugar water) is the
	base.  The dose on the following might be 90 mg/Kg , form
	intravenous, the total dose would be what ever was calculated
	for the body weight, ingredients of this would be dopamine,
	dextrose water.  Any additional information might be kept in
	the comments section.
DATABASE MAPPING:
	RX_Order, Drug, Ingredient, Drug_Comment
HL7 MAPPING:
 RXC, RXE
OLE MAPPING:

ALERT REQUIREMENTS:
	Components, ingredients,

rXComponentType:

DEFINITION:
	The rXComponentType field specifices whether a drug
	is an additive or a base.  Normally used for infusions
	(things that are given with a needle...owww!).  However, HL7
	allows dermatologic preparations to use rXComponentTypes, in
	this case a salve can be prepared where one medication is the
	normal base (such as petroleum jelly) where the other medications
	become the additives.
EXAMPLES:
	An example of this section would be :   Dopamine Drip
	Dopamine is the additive and D5W (sugar water) is the
	base.
DATABASE MAPPING:

HL7 MAPPING:
	RXC-1 RX Component Type
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

componentCode:

DEFINITION:
	This field represents the drug.  The pharmacy system usually
	sends to HEMS the NDC of the drug (this represents the entire
	enchilada ... the drug, the strength, the form (tablet etc),
	the packaging (100 tablets per bottle) and the manufacturer (like
	3M).  We take the NDC and transmutate into an Ncid that represents
	this product.
EXAMPLES:
 	An example would be the NDC code of 00081024256 (NDC codes are always
 	11 digits).  This is the NDC code for Lanoxin (Digoxin), 0.125mg, tablet, the
 	Ncid is equal to 2139041.  This drug will be composed of the ingredient
	DIGOXIN-0593 where the Ncid of the ingredient DIGOXIN is equal to 2100577.
DATABASE MAPPING:
	Coded - Drug:Product_Ncid
	Not Coded - Drug:Product_Name but this probably won't store
HL7 MAPPING:
	RXC-2 Component Code also in RXE-2 Give Code
OLE MAPPING:

ALERT REQUIREMENTS:
	Required for alerting.  This must be coded.

doseUnits:

DEFINITION:
	This is how much of the medication should be given.
	See DoseUnitInfo for complete information on this
	field.
EXAMPLES:
	While climbing in Yosemite Park (El Capitan) R Dupont
	experienced a crushing chest pain.  Dr Harada, park
	physician, diagnosed Mr Dupont as having angina (Aunt Jenna).
	Before leaving her clinic she prescribed for Mr Dupont
	Nitroglycerin .3 mg (milligram) tablet sublingually (under the tongue)
	PRN (as needed...anytime your hanging off a mountain).  So
	in this example the .3 mg is the strength and the dose
	is one tablet as needed.  The math : dose = .3mg * 1 tablet.
DATABASE MAPPING:
	Drug
HL7 MAPPING:
	RXE, RXC
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used but likely to be used in ADEs
	(Adverse Drug Events) or if we wanted to do dosing
	alerts.

giveDosageForm:

DEFINITION:
	The giveDosageForm is the form (how it comes) of the
	medication that should be given.
EXAMPLES:
	Examples of drug forms would be tablet, capsules, foam, aerosol,
	ampules, syringes, bars, cakes, soap, stick, dressing, dental, plaster,
	poultice and a partridge in a pear tree (OK, its a joke about the partridge)
DATABASE MAPPING:
	Coded - Drug:Give_Form_Ncid
	Not Coded - Drug:Give_Form_Text
HL7 MAPPING:
	RXE-6 Give Dosage Form.  It does not appear that we currently support
	this field in the interface document.
OLE MAPPING:

ALERT REQUIREMENTS:
 	Currently not used.

totalDailyDose:

DEFINITION:
	This is the total dose given in a 24 hour period for a
	medication.
EXAMPLES:
	The fall season has come, along with the influenzae season.  R. Dupont presents
	with the following symptoms: tired, febrile, nausea and some vertigo.  Dr. Clay
	diagnoses Haemophilus influenze and prescribes amoxicillin 500 mg (milligrams)
	capsule, 1 capsule PO (orally) tid (three times a day).
	The math:  dose = 500 mg * 1 tablet.  schedule = 3 per 24 hours
 	Total Daily dose = 500 mg * 1 tablet * 3 = 1500 mg
DATABASE MAPPING:
	Drug:Tot_Day_Dose_Value,  Drug:Tot_Day_Dose_Units_Ncid
HL7 MAPPING:
	RXE-19 Total Daily Dose.
OLE MAPPING:

ALERT REQUIREMENTS:
 	Currently not used.

ingredients:

DEFINITION:
	The ingredients are the parts or components that make up the drug
	product.  Granted there are many small components that we do not put in
 	as a part (like red dye lot 3)..just the big chunks.  See Ingredient for
	a complete description.
DATABASE MAPPING:
	Ingredient
HL7 MAPPING:
	Not supported;  however the interface uses the NDC (National Drug Code)
	to identify the drug and determine the individual ingredients which
	have been defined in the dictionary.
OLE MAPPING:

ALERT REQUIREMENTS:
	Required for alerting.

codedComments:

DEFINITION:
	These should be coded comments that are NOT  pharmacy special instructions.
	See PharmacySpecialIns  Due to the legacy pharmacy systems, splitting out
	the comments to the appropriate locations may not be	possible.
EXAMPLES:
	Unknown
DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

textComments:

DEFINITION:
	These should be coded comments that are NOT provider Administration
	instructions or pharmacy special instructions.  See PharmacySpecialIns
	and providerAdminInstructions.  Due to the legacy pharmacy systems,
	splitting out the comments to the appropriate locations may not be
	possible.
EXAMPLES:
	Unknown
DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

setId:

DEFINITION:
	Don't know what this is????

DoseUnitInfo:

DEFINITION:
	DoseUnitInfo is the amount of medication that is to be
	administered.  This includes standard and sliding dose.
	See standardDose and slidingDose for more information.
EXAMPLES:
	While climbing in Yosemite Park (El Capitan) R Dupont
	experienced a crushing chest pain.  Dr Harada, park
	physician, diagnosed Mr Dupont as having angina (Aunt Jenna).
	Before leaving her clinic she prescribed for Mr Dupont
	Nitroglycerin .3 mg (milligram) tablet sublingually (under the tongue)
	PRN (as needed...anytime your hanging off a mountain).  So
	in this example the .3 mg is the strength and the dose
	is one tablet as needed.  The math : dose = .3mg * 1 tablet.
DATABASE MAPPING:
	Drug
HL7 MAPPING:
	RXE, RXC
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used but likely to be used in the ADEs (
	Adverse Drug Events) or if we wanted to do dosing
	alerts.

standardDose:

DEFINITION:
	Standard dose is the amount of medication that is to
	be administered.  A standard dose is usually, a single
	quantity and unit.
EXAMPLES:
	An example would be .3mg Nitroglycerin.
DATABASE MAPPING:
	Drug:Low_Dose_Value, Drug:Dose_Units_Ncid
HL7 MAPPING:
	RXE-3 Give Amount-Minimum
	RXE-5	Give Units
	RXC-3 Component Amount
	RXC-4 Component Units
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used but likely to be used in the ADEs
	Adverse Drug Events) or if we wanted to do dosing
	alerts.  Must be numeric values and coded units.

slidingDose:

DEFINITION:
	A sliding dose is a statement of a low and high
	amount of medication that may be given whenever the
	drug is administered.  It is a range that represents
	a minimum and a maximum value and a single unit.
EXAMPLES:
	An example would be Morphine given 2-10 mg (milligrams)
	Intramuscular (in your arm or hip) PRN (as needed).
DATABASE MAPPING:
	Drug:Low_Dose_Value, Drug:High_Dose_Value, Drug:Dose_Units_Ncid
HL7 MAPPING:
	RXE-3 Give Amount-Minimum
 RXE-4 Give Amount-Maximum
	RXE-5	Give Units
	RXC-3 Component Amount
	RXC-4 Component Units
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used but likely to be used in the ADEs
	Adverse Drug Events) or if we wanted to do dosing
	alerts.  Must be numeric values and coded units.

SlidingDose:

DEFINITION:
 	The value of the dose that will be given.  See SlidingDose for
	a general discussion of sliding dose quantities.  The value is
	a decimal number which represents the quantity of drug that is
	to be given.
 	The units of the dose that will be given.  See SlidingDose for
	a general discussion of sliding dose quantities.  The unit is
	coded and represents the units of the dose of drug that is
	to be given.
EXAMPLES:
	An example would be Morphine given 2-10 mg (milligrams)
	Intramuscular (in your arm or hip) PRN (as needed).
	An example would be Morphine given 2-10 mg (milligrams)
	Intramuscular (in your arm or hip) PRN (as needed). The 'mg'
	is the units.
DATABASE MAPPING:
	Drug:Low_Dose_Value, Drug:High_Dose_Value
	 Drug:Dose_Units_Ncid
HL7 MAPPING:
	RXE-3 Give Amount-Minimum
	RXE-4 Give Amount-Maximum
	RXC-3 Component Amount
	RXE-5	Give Units
	RXC-4 Component Units
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used but likely to be used in the ADEs
	Adverse Drug Events) or if we wanted to do dosing
	alerts.  Must be numeric values and coded units.
	Currently not used but likely to be used in the ADEs
	Adverse Drug Events) or if we wanted to do dosing
	alerts.  Must be numeric values and coded units.

Ingredients:

DEFINITION:
 See Ingredient for details

Ingredient:

DEFINITION:
	The ingredient section details information regarding the
	parts that make up the drug product.  The ingredient is
 	composed of ingredient (the chemical compound - part),
	dose, and units.
	The set of ingredients that make up each medication
	component in an order.  See pharmord.a1 ingredientId
	for a complete description.
EXAMPLES:
	R. Dupont has been diagnosed with H Influenze.  The current
	Dr. Enger, who  prescribes Augmentin 250, 250-125mg tablet to be
	taken 2 tablets orally every 8 hours.
	The ingredients are :  Amoxicillin sodium 250 mg, and potassium
	clavulanate 125 mg.  both are salted ingredients.
DATABASE MAPPING:
	Ingredient
HL7 MAPPING:
	Currently not supported;  The innterface uses the NDC code
	of the medication product to determine the ingredient(s) and
	places them into the appropriate locations.
OLE MAPPING:

ALERT REQUIREMENTS:
	Ingredient

ingredientId:

DEFINITION:
 The ingredient section details information regarding the
	parts that make up the drug product.  The ingredient is
	composed of ingredient (the chemical compound - part),
	dose, and units.
EXAMPLES:
	R. Dupont has been diagnosed with H Influenze.  The current
	Dr. Mortensen, who  prescribes Augmentin 250, 250-125mg tablet to be
	taken 2 tablets orally every 8 hours.
	The ingredients are :  Amoxicillin sodium 250 mg, and potassium
	clavulanate 125 mg.  both are salted ingredients.
DATABASE MAPPING:
	Ingredient:Ingredient_ncid
HL7 MAPPING:
	Currently not supported;  The innterface uses the NDC code
	of the medication product to determine the ingredient(s) and
	places them into the appropriate locations.
OLE MAPPING:

ALERT REQUIREMENTS:
	Ingredients are required for alerting

amountUnits:

DEFINITION:
		This is the dose (how much) of each ingredient was included in the
		Medication Product. This would include the dose and units of the ingredients.
		Currently, this information is not available in the data dictionary (HDD).
		See DoseUnitInfo for further details.
DATABASE MAPPING:
	Ingredient:low_dose_value.    Ingredient:high_does_value
HL7 MAPPING:
	Currently not supported.
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

setId:

DEFINITION:
		Don't know what this is.....

RouteInfos:

DEFINITION:
	This is the set of routes for the medication that is
	being ordered.  It represents how you take the medicine.
	See RouteInfo for complete details.  There may be more
	than one route because a drug may be given as IV in the
	the hospital but be given orally at home.  The NDC of the
	drug is the same no matter how given.

RouteInfo:

DEFINITION:
		RouteInfo is how you give the drug.  This includes information
		like how it is given (oral, iv, etc), administration site (where
		on the body do you give it arm), or through what device do you give
		it.
EXAMPLES:
		R Dupont who has been undergoing chemotherapy for the last few months
		to treat his recently diagnosed AML (Acute Myelocytic Leukemia) reports
		to Oncologist Gayler that his mouth has white patchy sores and it "hurts
		all the time".  Dr Gayler examines R Dupont and observes white patchy
		exudates (you don't want to know)... Dr Gayler determines R Dupont is
		suffering from Thrush (a fungal infection of the mouth).  He prescribes
		for R Dupont Lotrimin Vaginal Suppositories (yes they do this) TID
		(three times a day) PO (by mouth) hold in mouth till disolved.  In this
		example (strange but true) the route info is PO by mouth.
DATABASE MAPPING:
		Coded - RX_Route:Route_Method_Ncid
		Text - RX_Route:Route_Method_Text
HL7 MAPPING:
		We cheated we combined 2 fields in HL7 ...
		RXR-1 Route and RXR-4 Administration method
OLE MAPPING:

ALERT REQUIREMENTS:
		Used by Medication Monitoring, ADE, and potentially Infectious
		Disease alert logic.  Must be coded.

routeAndMethod:

DEFINITION:
		RouteInfo is how you give the drug.  This includes information
		like how it is given (oral, iv, etc), administration site (where
		on the body do you give it arm), or through what device do you give
		it.
EXAMPLES:
		R Dupont who has been undergoing chemotherapy for the last few months
		to treat his recently diagnosed AML (Acute Myelocytic Leukemia) reports
		to Oncologist Gayler that his mouth has white patchy sores and it "hurts
		all the time".  Dr Gayler examines R Dupont and observes white patchy
		exudates (you don't want to know)... Dr Gayler determines R Dupont is
		suffering from Thrush (a fungal infection of the mouth).  He prescribes
		for R Dupont Lotrimin Vaginal Suppositories (yes they do this) TID
		(three times a day) PO (by mouth) hold in mouth till disolved.  In this
		example (strange but true) the route info is PO by mouth.
DATABASE MAPPING:
		Coded - RX_Route:Route_Method_Ncid
		Text - RX_Route:Route_Method_Text
HL7 MAPPING:
		We cheated we combined 2 fields in HL7 ...
		RXR-1 Route and RXR-4 Administration method
OLE MAPPING:

ALERT REQUIREMENTS:
		Used by Medication Monitoring, ADE, and potentially Infectious
		Disease alert logic.  Must be coded.

adminSite:

DEFINITION:
		This is where in the heck you administer this.  This might
		be bilateral eyes, bilateral nares, nebulized etc.  For complete
		description you should look at aggregateBodySite - PharmAdminSite.
EXAMPLES:
		This am R Dupont woke up as usual and started getting ready for work.
		As he walked to the bathroom he was struck by a sharp and debilitating
		pain in his flank.  The pain was significant enough that he begged
		his wife to take him to the ER, fearing his back had gone out.  On
		arrival at the ER Dr. Clark examines R Dupont and diagnosis a kidney
		stone.  He informs R Dupont that only time will tell and suggests
		he remains in the ER until the stone passes.  To ease the pain that
		is now extreme Dr. Clark prescribes Demerol 100 mg IM (in your muscle)
		PRN (as needed).  Nurse Greely administers the first dose of Demerol
		to R Dupont in the right ventralgluteal muscle (in his hiney oww!).
		Like it or not the right ventralgluteal muscle is the administration
		site.
DATABASE MAPPING:
		Coded - RX_Route:Admin_Site_Ncid
		Text - RX_Route:Admin_Site_Text
HL7 MAPPING:
		RXR-2  Site
OLE MAPPING:

ALERT REQUIREMENTS:
		Currently not used.

adminDevice:

DEFINITION:
		An adminDevice is a mechanical device used to aid in the
		administration of a medication.  For details on the
		complete description see clintypes.a1 DeviceInfo.
EXAMPLES:
		R Dupont, who is president of the local Cat Fanciers Club,
		is ask to judge the Persian 'Cat'agory.  It is only a few
		minutes into the judging where upon he realizes he can't
		breathe and is making a whistle like noise every time
		he inhales.  A local veterinarian, K Marchant quickly
		takes action and borrows a friends nebulizer and administers
		Bronchosol Inhaler giving 2 puffs to R Dupont.  After a
		few minutes R Dupont is breathing normally.  The nebulizer
		is an administratition device and R Dupont should judge
		Mexican Hairless in the future.
DATABASE MAPPING:
		Coded - RX_Route:Admin_Device_Ncid
		Text	-
HL7 MAPPING:
		RXR-3 Administration Device
ALERT REQUIREMENTS:
		Currently not used.

setId:

DEFINITION:
 	Don't know what this is....

AdminSite:

DEFINITION:
	See pharmord.a1 for a description on how adminSite is used
	with regards to a pharmacy order.

	The Coded of the AdminSite is constrained to the domain of the
	Body Locations where a drug may be administered.  (i.e. mouth,
	left arm, etc.)

	See clintypes.a1 Body Site

AdminDevice:

DEFINITION:
	The administration Device.  See pharmord.a1 adminDev and
	clintype.a1 DeviceInfo for more information.

ProviderAdminInstructions:

DEFINITION:
	See pharmord.a1 providerAdminInstructions.

ProviderAdminInstruction:

DEFINITION:
	See pharmord.a1 providerAdminInstructions.

DeliverToLocation:

DEFINITION:
	See clintypes.a1 Address and mmi.a1 location.

PharmSpecialInstructInfos:

DEFINITION:
	See pharmord.a1 pharmacySpecialIns.

PharmSpecialInstructInfo:

DEFINITION:
	See pharmord.a1 pharmacySpecialIns.

IvRate:

DEFINITION:
	See pharmord.a1 ivVolumeRate.

ivGiveTime:

DEFINITION:
	See pharmord.a1 ivVolumeRate.
HL7 MAPPING:
	RXE-22 Giver Per (Time Unit)

ivAmount:

DEFINITION:
	See pharmord.a1 ivVolumeRate.
HL7 MAPPING:
	RXE-23 Give Rate Amount
	RXE-24 Give Rate Units

IvSpecialRate:

DEFINITION:
 	See pharmord.a1 ivSpecialRate.

ivRate:

DEFINITION:
	See pharmord.a1 ivSpecialRate.

attachedToProduct:

DEFINITION:
	See pharmord.a1 ivSpecialRate.
	This item is used to identify the particular component in the
	order which necessitates the use of a special rate.  Note that
	this assumes that any one component will occur at most once in
	an order.

GroupPatientOrder:

DEFINITION:
	These are multiple orders for a single patient.  These orders may be cross
	departmental (pharmacy, radiology, laboratory, etc).  Typically these orders
	are standing order sets which are a set of orders placed on all patients that
	may have the same attending physician for a diagnosis, all patients that are
	admitted to an Intensive Care Unit (ICU), etc.  The group patient orders consist
	of groupOrderDateTime, placerGroupOrderNumber, fillerGroupOrderNumber, ordersInGroup
	sequenceIngroup and patientOrder.
	Currently GroupPatientOrder is not supported by DSS.
EXAMPLES:
	R. Dupont has been scheduled for bowel surgery (he wouldn't tell us the exact
	diagnosis...too much Latin). Dr. Holt, surgeon has a routine set of orders for
	patients scheduled for bowel surgery.  The night before surgery Dr. Holt  has written
	the following bowel prep orders.  Magnesium citrate 2 bottles, Erythromycin 1 GM
	(gram) PO (oral) x3 (3 doses) 1 hour apart.  Neomycin 1 GM (gram) PO (by mouth)
	x3 (3 doses) 1 hour apart.  Ducolax 5mg tablet, 2 tablets after the Magnesium citrate,
	Erythromycin and Neomycin are given.
	Diet:  Clear liquids tonight and NPO (Nothing by mouth) after midnight.
	Activity:  ad lib (as tolerated).
DATABASE MAPPING:
	Group_Order, Group_Patient_Order, Group_Order_Comment
	Same tables required for pharmacy order.  See Pharmord.a1
HL7 MAPPING:
	Currently there in the ORC segment are discussions of the parent and child
	orders, wherein there is the concept of spawning of a "child" order from a
	"parent" order.  The parent (original order)does not change.  According to our
	in-house experts, this is limited model of group ordering.  HL7 is in the process
	of enhancing this model.
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not supported.

groupOrderDateTime:

DEFINITION:
	groupOrderDateTime is the date and time that the orders as a whole
	are placed.
EXAMPLES:
	R. Dupont has been scheduled for bowel surgery (he wouldn't tell us the exact
	diagnosis...too much Latin). Dr. Holt, surgeon has a routine set of orders for
	patients scheduled for bowel surgery.  The night before surgery Dr. Holt  has written
	the following bowel prep orders.  Magnesium citrate 2 bottles, Erythromycin 1 GM
	(gram) PO (oral) x3 (3 doses) 1 hour apart.  Neomycin 1 GM (gram) PO (by mouth)
	x3 (3 doses) 1 hour apart.  Ducolax	5mg tablet, 2 tablets after the Magnesium citrate,
	Erythromycin and Neomycin are given.
	Diet:  Clear liquids tonight and NPO (Nothing by mouth) after midnight.
	Activity:  ad lib (as tolerated).  The groupOrderDateTime for this R Holts (Mr.
	Clean Standing Order) is 10/15/96.08:00.  All orders in this standing order
	set would have this date and time.
DATABASE MAPPING:
	Group_Order:Order_GMTime
HL7 MAPPING:
	Unknown.
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

placerGroupOrderNumber:

DEFINITION:
		Currently not used.

fillerGroupOrderNumber:

DEFINITION:
		Currently not used.

ordersInGroup:

DEFINITION:
		Currently not used.

comments:

DEFINITION:
		Currently not used.

OrdersInGroup:

DEFINITION:
	Only used in group orders.  This is not used yet.

sequenceInGroup:

DEFINITION:
	Currently not used.

patientOrder:

DEFINITION:
		See patorder.a1 PatientOrder for description of a single order
		on a patient.  Group orders currently not used.

setId:

DEFINITION:
		Don't know what this is.

PatientOrder:

DEFINITION:
	PatientOrder is the structure that supports the information
	collected during the ordering process.  Things that are ordered
	in a medical setting include things like laboratory tests,
	radiology tests, central service supplies, medications,
	dietary.  Currently the only orders that are placed into the
	HEMS system are medication orders.

	This is made up of 2 nodes : orderInfo and orderDetail.
	For complete information see patorder.a1 GeneralOrderInfo
	OrderDetail.
EXAMPLES:
	R Dupont makes an appointment with his primary care physician
	Dr Lau.  Dr Lau tells R Dupont to go to the clinical labs
	before coming to her office and have a Chem 20 drawn.   Dr
	Lau orders a Chem 20 on R Dupont and sends the paper work to
	the lab so it is there when R Dupont shows up.
DATABASE MAPPING:
	Patient_Order, Timing_Qty, Frequency, Time_To_Do, Order_Comment,
	Complex_Order_Sequence
HL7 MAPPING:
	ORC Segment
OLE MAPPING:

ALERT REQUIREMENTS:
	Some parts of the General Order Info are used : specifically
	the timingQuantities for pharmacy orders.

orderInfo:

DEFINITION:
	See patorder.a1 GeneralOrderInfo for detail.

orderDetail:

DEFINITION:
	See pharmorder.a1 pharmacy order.  Currently pharmacy
	is the only order that is defined.

GeneralOrderInfo:

DEFINITION:
	This is information on the order that details the status
	of the order, the management numbers associated with the
	the order, the times the order should be done, who (clinician)
	should receive the report, and comments (coded and text).

orderStatus:

DEFINITION:
 	The orderStatus field details the current status of the order.
 	This status reflects the status as it is known by the sending
 	application at the time the information is sent.
EXAMPLES:
	R Dupont while building a fence smashes his thumb with a
	hammer.  After jumping around and holding onto his finger
	he realizes that his thumb doesn't look straight anymore.
	He hops in his car and drives to the local "Doc in the Box".
	Dr Tutor decides that an x-ray of the thumb is required.
	He orders it and sends R Dupont to the small x-ray lab
	across the street.  The Radiologist on call only practices
	one day a month.  He does a "preliminary" read of the xray
	and determines the thumb is fractured.  He sends his report
	but marks the order as Preliminary.  The order status is
	is preliminary.
DATABASE MAPPING:
C-4:  'PlacerGroupNumber' is handled by groupPatientOrder
C-6:  'ResponseFlag' is not needed in the database, it is
C-8:  'Parent' is not needed, it is used in HL7 to specify
C-17: 'EnteringOrganization' is not needed in the database
	Coded - Patient_Order:Order_Status_Ncid
	Not Coded - Patient_Order:Order_Status_Text
HL7 MAPPING:
	ORC-5 Order Status
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring.  Future will be
	used for ADEs and Infectious Disease.  This field needs
	to be coded.

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 for Dilantin
	would be assigned (by the legacy system), the order sent to the pharmacy,
	the pharmacy would assign the fillerOrderNumber
	the order is 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:
C-5
 	Patient_Order:Placer_Number, Patient_Order:Placer_System_Ncid
HL7 MAPPING:
	ORC-2 Placer Order Number
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used specifically by the logic.  However,
	it is required that either this number or the filler number is
	unique so that updates to data strings can be performed.

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 is as a Dilantin order is filled the pharmacy system
	will assign a unique identifier to the order.
DATABASE MAPPING:
C-2
 	Patient_Order:Filler_Number, Patient_Order:Filler_System_Ncid
HL7 MAPPING:
	ORC-3 Filler Order Number
OLE MAPPING:

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.

timingQuantities:

DEFINITION:
		This is when the order should be done.  See patorder.a1
		TimingQuantity for details.
HL7 MAPPING:
	ORC-7, RXE-1

reportToClinicians:

DEFINITION:
 	This is the clinician associated with the order,  it consists
 	of the clinician Role and the clinician ncid.  See clintype.a1
 	RelatedClinicianInfo for details.
DATABASE MAPPING:
C-7, RXE-1

textComments:

DEFINITION:
 	 Obsolete.  Only for use in version 4.

placerGroupNumber:

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 places the order.  See clintype.a1 UniqueReferenceId.
EXAMPLES:
	An aspirin is ordered with a glass of water as two disparate orders.
  This number would be used to group the two orders.
DATABASE MAPPING:

HL7 MAPPING:
	ORC-4 Placer Group Number
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used specifically by the logic.

OrderDetail:

DEFINITION:
	The Order detail consists of the specific of departmental ordering
 	such as laboratorry, pharmacy, radiology or dietary.  Currently, the
 	only departmental ordering defined is pharmacy for drug orders.  See
	pharmord.a1 for details on the drug orders.

	This probably should be changed to MIOC in the future.

TimingQuantities:

DEFINITION:
		This is when the order should be done.  See patorder.a1
		TimingQuantity for details.

TimingQuantity:

DEFINITION:
		TimingQuantity structure specifies when the order should be
		done.  This includes things like the frequency, the duration,
		the start and end dates, the priority.
EXAMPLES:
		An example would be Digoxin .125 mg (milligrams) QD (every
		day) PO (orally).  In this example the timing quantity is
		QD (every day).
DATABASE MAPPING:
		Timing_Qty, Frequency
HL7 MAPPING:
		ORC, RXE
OLE MAPPING:

ALERT REQUIREMENTS:
		Used in alerts in the Medication Monitoring, the ADEs, and
		Potentially Infectious Disease.  We need the order start time,
		frequency (coded), would like the stop time.

quantityUnits:

DEFINITION:
	quantityUnits is number of orders to be provided at each service
	interval.
EXAMPLES:
	For instance 2 blood cultures to be obtained every 4 Hours, in
	this case the quantity would be two and there would be no units.
DATABASE MAPPING:
	Timing_Qty:Qty_Value, Timing_Qty:Qty_Units_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

interval:

DEFINITION:
		The interval of an order is the time between repeated services.
		This is where you have a "named" frequency (BID, TID, QID...) or
		you have the interval frequencies Q 4 to 6 Hours.
EXAMPLES:
	R Dupont while cruising the mediterranian on Hollandaise America
	Cruise Lines enters the Rocky Balboa raw eggs swallowing contest.
	He WINS!!!! he swallows over 2 dozen raw eggs in less than 5 minutes.
	Unfortunately, the next am he does not want eggs for breakfast.  His
	wife begs him to remove himself from the bathroom.  She calls the
	ship doctor.  Dr Gurr arrives bag in hand and examines R Dupont.  After
	hearing of the last nights fiesta Dr Gurr informs R Dupont that he
	suspects Salmonella enteritidis.  Dr Gurr prescribes Ciprofloxacin 500 mg
	(milligrams) BID (twice a day) PO (by mouth).  As Dr Gurr leaves he
	issues a stern warning to R Dupont to not participate in such
	nonsense again!  The frequency in this example is BID and it is
	what we would call a named frequency as it directly maps to a coded
	frequency.
DATABASE MAPPING:
	See documentation for patorder.a1 Frequency.
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
ALERT REQUIREMENTS:
	Required for Medication Monitoring, ADEs, and potentially
	Infectious Disease alerts.

duration:

DEFINITION:
 	This indicates how long a service should continue after it is started.
 	The default for duration is indefinite.  It is composed of the number
		of times and the duration (which is a time and units).
EXAMPLES:
	Healthcare facilities have polcies and procedures defining the acceptable
	duration of a drug order before it must be discontinued.  Before the drug
	may be reordered the patient must be re-evaluated.
DATABASE MAPPING:
	Timing_Qty:Duration_Value Timing_Qty:Duration_Unit_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

orderStartDateTime:

DEFINITION:
		This is the date and time that the order should begin.
EXAMPLES:
	For example a physician may order Lasix 40 mg (milligrams)
	PO (by mouth) BID (twice a day) to start 10/10/96.13:30.
	10/10/96.13:30 is the start date and time for this medication.
DATABASE MAPPING:
	Timing_Qty:Start_GM_Time
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Used in Medication Monitoring, ADEs, and potentially Infectious
	Disease alerts.

orderEndDateTime:

DEFINITION:
	This is the date and time that the order should be
	discontinued (stopped).
EXAMPLES:
	For example a physician may order Lasix 40 mg (milligrams)
	PO (by mouth) BID (twice a day) to start 10/10/96.13:30.
	and be discontinued (stopped) 10/15/96.13:30.
	The order end date is 10/15/96.13:30 for this medication.
DATABASE MAPPING:
	Timing_Qty:End_GM_Time
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Used in Medication Monitoring, ADEs, and potentially Infectious
	Disease alerts.

priorityType:

DEFINITION:
		This is a coded field that represents how the priority
		is applied : such as collecting the specimen, processing,
		or reporting.
EXAMPLES:
	For instance, a physician might ask that a blood be drawn
	Stat (collected) and processed Routine (at normal schedule).
DATABASE MAPPING:
	Timing_Qty:Priority_Type_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
	TQ-9 (handles 'C' option of TQ-9)
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

priority:

DEFINITION:
		This field represents the sense of urgency of the
		order.  How soon should this order be executed.  This
		will be for all orders not just pharmacy.  In pharmacy
		this priority is usually stated as a frequency,
		such as Dilantin Stat, where Stat means Now!

		In addition, you can also represent time critical
		orders.   Such as give Gentamycin Stat then draw peak
		level 2 hours after the dose of Gentamycin.  This
		is represented as a priority and a critical time.
EXAMPLES:
	R Dupont while driving to the post office to submit
	a passport application is struck by a garbage truck.
	He is rushed to the hospital where he is seen by
	Emergency Room physician Dr Tinker.  Dr Tinker is
	worried that R Dupont might have internal bleeding
	She orders a CBC (complete blood count) Stat and
	2 Units of Blood to be typed and crossmatched Stat.
	In addition she orders a Sma-20 to be done Routine.
	The priority Stat means right now and routine will
	be combined on the next batch of work.
DATABASE MAPPING:
	Timing_Qty:Priority_Ncid,
	Timing_Qty:Priority_Interval_Value,
	Timing_Qty:Priority_Interval_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
	TQ-7
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

condition:

DEFINITION:
		This field describes the condition under which
		the medication should be given.
EXAMPLES:
	For instance, PRN for pain or PRN to keep blood
	pressure below 110.
DATABASE MAPPING:
	Coded - Timing_Qty:Condition_Ncid
	Not Coded - Timing_Qty:Condition_Text
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
	Corresponds to TQ-7
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

timeQuantityDisplay:

DEFINITION:
		This field is the full text version of the instructions
		for the order frequency.  This is used to display to the
		clinician the frequency of an order in a way that they
		will clearly understand.
EXAMPLES:
	For instance if a medication is prescribe Q4-6Hours PRN..
	the clinicians would understand this order... in HL7
	this frequency would be broken into several parts which
	would not necessarily be understood by the end users.
DATABASE MAPPING:
	Timing_Qty:Timing_Qty_Display
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
	Corresponds to TQ-8
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

conjunction:

DEFINITION:
		A non null component indicates that a second timing
		specification is to follow.  This field can take
		three values S=synchronous, A=asynchronous, C=
		is an actuation time.  It appears that the C
		is currently not supported.
EXAMPLES:
	An example of synchronous would be to measure blood
	pressures Q 15 Minutes for the first hour and then
	Q 2 Hours for the next hour.  An asynchronous example
	would be Prednisone 1 tablet Monday, Wednesday, Friday and
	1/2 tablet on Tuesday, Thursday, Saturday, and Sunday.
DATABASE MAPPING:
	Timing_Qty:Conjuction_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
	Corresponds to TQ-9 ('C' not handled here, no date)
	We don't think we support this yet.
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

complexOrderSeq:

DEFINITION:
		This is where you have a series of orders that are
		executed in a fixed sequence.
EXAMPLES:
	Examples would be things like alternating infusions,
	tapering corticosteroids, etc.
DATABASE MAPPING:
	Complex_Order_Sequence:
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
	Corresponds to TQ-10
	We don't think we support this yet.
ALERT REQUIREMENTS:
	Currently not used.

setId:

DEFINITION:
		Don't know what this is.

softOrderEndDateTime:

DEFINITION:
	This field represents a soft stop date
DATABASE MAPPING:
	Table Timing_qty: soft_end_gm_time
HL7 MAPPING:
	There is no field in that corresponds to soft stop date

Interval:

DEFINITION:
	This field represents the frequency for an order
	including the frequency statement and the times
	that the order should be done.
EXAMPLES:
	Portable Chest PA/Lateral BID 0600 1600. Which is
	Chest Xray at bedside twice a day at 6:00 am and
	4:00 pm.
ALERT REQUIREMENTS:
	Used by Medication Monitoring, ADEs, and potentially
	Infectious Disease alerts.

frequencies:

DEFINITION:
	See Frequency for patorder.a1 for details.

timesToDo:

DEFINITION:
	This field details the times (in military time)
	that the order should be done.
EXAMPLES:
	Potassium Choloride tablets 30 meq QID (4 times
	a day) at 0900, 1300, 1500, 2100.  So the Potassium
	Chloride would be taken/given at 9:00 am, 1:00 pm,
	3:00 pm, and 9:00 pm.
DATABASE MAPPING:
	Time_To_Do:Time, Time_To_Do:Time_Unit_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently not used.

Frequencies:

DEFINITION:
	See patorder.a1 Frequency for details.

Frequency:

DEFINITION:
	This field details the number of times that an
	order should be done.  It includes named frequencies
	(BID, TID, etc), valued frequencies Q4Hr Every 4 hours,
	ranges like Q4To6Hr (every 4 to 6 hours), the day of
	the week, the day of the month, unixCronFrequency which
	is when it is automatically started from a cron job????
DATABASE MAPPING:
	Frequency
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring, ADEs, and
	potentially Infectious Disease alerts.

namedFrequency:

DEFINITION:
	This field is the frequency that an order should be
	done and is stated using the latin derivative of the
	frequency, such as BID, TID, QID, PRN, etc.  No values
	are included in the frequency, they are coded.
EXAMPLES:
	R Dupont is admitted to the ER after receiving injuries
	in a MVA (motor vehicle accident aka garbage truck).
	He is transfered to the surgical ward to await surgery.
	Dr England orders Valium 10 mg (milligrams) IM (in your
	muscle) On Call to the Operating Room.  On Call, which
	means when his name comes up to go into surgery, is the
	named frequency in this example.
DATABASE MAPPING:
	Frequency:Named_Frequency_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring, ADEs, and
	potentially Infectious Disease alerts.

valuedFrequency:

DEFINITION:
		This field is a frequency that has a single value and units
		indicating an interval between execution of the order, like
		Q4Hr (every 4 hours).
EXAMPLES:
	After returning from surgery R Dupont complains to
	the Chief Resident Johnson that he feels nauseated.  Dr
	Johnson orders 25 mg (milligrams) Compazine Suppositories
	per Rectum Q12Hrs PRN (as needed) for nausea.  So
	the valued frequency in this example is Q12Hrs (every
	12 hours).
DATABASE MAPPING:
	Frequency:Range_Frequency_Low_Val
	Frequency:Timed_Frequency_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring, ADEs, and
	potentially Infectious Disease alerts.

frequencyRange:

DEFINITION:
		This field is a frequency that has a low and a
		high value and units that denote the lowest and
		highest frequency that an order may be given, like
		Q2to4Hrs (every 2 to 4 Hours).
EXAMPLES:
	R Dupont 12 hours post surgery is complaining of
	of pain.  The attending physician, Dr Bagley,
	prescribes Demerol 50-100 mg (milligrams)
	IM (in your muscle) Q2to4Hrs PRN (as needed)
	pain (whenever he whines).  In this example,
	Q2to4Hrs is a frequency range.  The Demerol could be
	given every 2, every 3, or every 4 hours or
	any fraction between 2 and 4 as needed.
DATABASE MAPPING:
	Frequency:Range_Frequency_Low_Val
	Frequency:Range_Frequency_High_Val
	Frequency:Range_Frequency_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring, ADEs, and
	potentially Infectious Disease alerts.

dayOfWeekFrequency:

DEFINITION:
		This field denotes the day of the week that
		an order should be executed.  It is a combination
		of the day of week and a code which denotes how
		often.  Day of the week is coded and represents
		Monday, Tuesday, Wednesday, Thursday, Friday,
		Saturday, Sunday. How often can be every, every
		other, every 3rd.
EXAMPLES:
	An example of this would be Prednisone 10 mg
	(milligrams) PO (by mouth) QMonday, QWednesday,
	QFriday .  Prednisone would be taken
	every Monday, Wednesday, and Friday.
DATABASE MAPPING:
	Coded - Frequency:Day_Of_Week_Ncid
	Not Coded - Frequency:Day_Of_Week_Text
	Frequency:How_Often_Day_Week_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring, ADEs, and
	potentially Infectious Disease alerts.

dayOfMonthFrequency:

DEFINITION:
		This field denotes the a day of the month that an order should
		be executed.  So it is a value for the day (1-31) and a coded
		how often.  The how often can be every, every other, every 3rd.
EXAMPLES:
	An example would be someone on long term Coumadin therapy might
	have a PT drawn on the 5th of every month.
DATABASE MAPPING:
	Frequency:Day_Of_Month
	Frequency:How_Often_Day_Month_Ncid
HL7 MAPPING:
	ORC-7	Quantity-Timing and also RXE-1 Quantity/Timing
OLE MAPPING:

ALERT REQUIREMENTS:
	Currently used in Medication Monitoring, ADEs, and
	potentially Infectious Disease alerts.

unixCronFrequency:

DEFINITION:
 	You guess.

UnixCronFrequency:

DEFINITION:
	See patorder.a1 unixCronFrequency.

ValuedFrequency:

DEFINITION:
	See patorder.a1 Frequency for details.

FrequencyRange:

DEFINITION:
	See patorder.a1 Frequency for details.

DayOfWeekFrequency:

DEFINITION:
	See patorder.a1 Frequency for details.

DayOfMonthFrequency:

DEFINITION:
	See patorder.a1 Frequency for details.

DayOfMonth:

DEFINITION:
	See patorder.a1 Frequency for details.

TimesToDo:

DEFINITION:
	See details in patorder.a1 timesToDo.

TimeToDo:

DEFINITION:
	See details in patorder.a1 timesToDo.
 Want to derive from TimeAttribute in the future. The current
 definition is consistent with storage in Version 4.0.

DurationInfo:

DEFINITION:
	See details in patorder.a1 duration.

NumberOfTimes:

DEFINITION:
	See details in patorder.a1 NumberOfTimes

OrderStartDateTime:

DEFINITION:
	See details in patorder.a1 OrderStartDateTime

OrderEndDateTime:

DEFINITION:
	See details in patorder.a1 OrderEndDateTime

OrderPriority:

DEFINITION:
	See the description of priority in
	patorder.a1

priority:

DEFINITION:
 	The urgency of the order.  See priority in patorder.a1
	for a complete description.

criticalTime:

DEFINITION:
 	The in combination with the priority the timing of the
	critical order.  See priority in patorder.a1
	for a complete description.

CriticalTime:

DEFINITION:
	For description of Duration see clintype.a1 Duration.

ConditionInfo:

DEFINITION:
	For details see patorder.a1 condition.

TimeQuantityDisplay:

DEFINITION:
	For details see patorder.a1 timeQuantityDisplay.

ComplexOrderSeq:

DEFINITION:
	Not supported yet.

SequenceTimingInfo:

DEFINITION:
	Not supported yet.

MaxRepeats:

DEFINITION:
	Not supported yet.

ClinicalTextData:

DEFINITION:
	SemanticLinks at the StringHeader level are used to link
	an addendum to a primary document, or to link coded
	data to the text document.
EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported:
	OLE data type: CClinicalText object
ALERT REQUIREMENTS:


eventDate:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Not Supported:
ALERT REQUIREMENTS:


reportType:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::ReportType
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


reportStatus:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::ReportStatus
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


contextInfo:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::ContextInfo
	OLE data type: CAcquisitionInfo
ALERT REQUIREMENTS:


reportText:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::ReportText
	OLE data type: CAsnText
ALERT REQUIREMENTS:


abnormalFlag:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::AbnormalFlag
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


compressionScheme:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::CompressionScheme
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


pointOfCare:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::PointOfCare
	OLE data type: CPointOfCare
ALERT REQUIREMENTS:


documentId:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::DocumentId
	OLE data type: CUniqueReferenceId
ALERT REQUIREMENTS:


reportingFlag:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::ReportingFlag
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


textComments:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::TextComments
	OLE data type: CTextComments
ALERT REQUIREMENTS:


codedComments:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CClinicalText::CodedComments
	OLE data type: CCodedComments
ALERT REQUIREMENTS:


AcquisitionInfo:

DEFINITION:


TranscriptionInfo:

DEFINITION:


EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	OLE data type: CAcquisitionInfo object
ALERT REQUIREMENTS:


enteredBy:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::EnteredBy
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


dateTimeOfDictation:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get/Set
	Property: CAcquisitionInfo::TimeOfDictation
	OLE data type: DATE
ALERT REQUIREMENTS:


dateTimeOfTranscription:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get/Set
	Property: CAcquisitionInfo::TimeOfTranscription
	OLE data type: DATE
ALERT REQUIREMENTS:


dictatingClinician:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::DictatingClinician
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


dictatedForClinician:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::DictatedForClinician
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


DirectEntryInfo:

DEFINITION:


EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	OLE data type: CAcquisitionInfo object
ALERT REQUIREMENTS:


enteredBy:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::EnteredBy
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


IncomingPhoneNoteInfo:

DEFINITION:
 IncomingPhoneNoteInfo contains both the question and the response
 for an interaction that was started as a call from a patient to a
 clinician.  This circumstance is modelled as two separate
 interactions:  a) the logging of the initial question, and b) the
 logging of the response to the question.  OutgoingPhoneInfo is for
 logging information when the call is initiated by the clinician
 and there is only one interaction.
 Identification of the patient that this note is about happens
 in the PatientId portion of PatientData.

 Note that there is only one text blob associated with a given
 note.  There are not separate "message" and "response" fields
 in this version of the database.

 Calls that are not related to a patient are not yet defined
 but would be created as messages under the NonPatientData
 branch of HemsInfo.

 Names and dates of when and where call was received, logged,
 updated, etc. are found in EventActionsInfo in StringHeader.
EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	OLE data type: CAcquisitionInfo object
ALERT REQUIREMENTS:


toClinician:

DEFINITION:
 	the clinician to whom the call was directed
EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::ToClinician
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


caller:

DEFINITION:
 	the person that placed the incoming call
EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::Caller
	OLE data type: CCallPersonInfo
ALERT REQUIREMENTS:


callerRelationship:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::CallerRelationship
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


priority:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::Priority
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


status:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::Status
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


callerPhones:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::CallerPhones
	OLE data type: CPhones collection
ALERT REQUIREMENTS:


typeOfCall:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::TypeOfCall
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


OutgoingPhoneNoteInfo:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	OLE data type: CAcquisitionInfo object
ALERT REQUIREMENTS:


fromClinician:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::FromClinician
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


personCalled:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::PersonCalled
	OLE data type: CCallPersonInfo
ALERT REQUIREMENTS:


calledRelationship:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::CalledRelationship
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:


calledPhones:

DEFINITION:

EXAMPLES:

DATABASE MAPPING:

HL7 MAPPING:

OLE MAPPING:
	Supported: Get
	Property: CAcquisitionInfo::CalledPhones
	OLE data type: CPhones
ALERT REQUIREMENTS:


CallPersonInfo:

DEFINITION:


AllergyInfo:

DEFINITION:
	Allergy hemsInfo definition is used to store abnormal sensitiveness
	to foods, medications, or environmental "allergens".  This information
	is important to know before prescribing medications or placing the
 	the patient on diets.  This information is usually collected by the
	physician or nurse during what is called the patient history and
	is usually part of the long term patient record.  At many sites the
	allergies are actually entered into the system by a pharmacist and
 	transmitted to the HEMS product via a pharmacy interface (either
	acute care (inpatient) or outpatiennt.
EXAMPLES:
	Examples of allergies include : medications (penicillins, codeine, aspirin),
	food (eggs, milk, nuts), non-food plant (olive tree, primrose, alders),
	microorganisms (Canidida albicans, echinococcus),  non-food animal
 	allergens (hornet venom, mouse urine, sheep epithelium), non-medication
	chemicals (latex, house dust, ethylene oxide).
DATABASE MAPPING:
	Allergy, Allergen, Reaction Tables
HL7 MAPPING:
 AL1
OLE MAPPING:
	Supported:
	OLE data type: CAllergyInfo object
ALERT REQUIREMENTS:
	Required for ADE, Infectious Disease, Medication Monitoring

allergyType:

DEFINITION:
	Indicates the general allergy category, the type of allergy
	that is being reported.
EXAMPLES:
	Examples of this would include drug, medication, food, pollen,
	etc.
DATABASE MAPPING:
	Coded - Allergy:Allergy_Type_Ncid
	Not Coded - Allergy:Allergy_Type_Text
HL7 MAPPING:
	AL1-2 Allergy Type Recommended Types (DA-drug, FA-food, MA-miscellaneous
	allergy, MC-miscellaneous contraindication).
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::AllergyType
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
	Allergy type is required to determine the type of allergy being
 	processed.  Without this code specific allergy logic cannot be
	executed.

allergyId:

DEFINITION:
	The unique identifier per allergy.  Each allergy in a patient's
	record will have a unique identifier assigned to it if it comes
 across an interface. Allergies entered through CW will not have an
 allergyId.  When it is present, you can look
 	at this as fulfilling the same role as the filler order number in
	patient orders.
EXAMPLES:
 	Patient is allergic to penicillin, allergy identifier is 1A.
	Patient is also allergic to cats, allergy identifier is B.
DATABASE MAPPING:
	Allergy:Allergy_Id
HL7 MAPPING:
	AL1-1	Set Id-Allergy
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::AllergyId
	OLE data type: CUniqueReferenceId
ALERT REQUIREMENTS:
	Required of the database (oracle).  Not used by alerts.

compositeSubstance:

DEFINITION:
	The substance to which the patient is allergic. This can be
 a medication, food, or environmental substance.  It can be a
 single pure substance, or a mixture of substances.  The value of
 this item can be entered through the 3M CW or via an interface.
	If data is from an interface, the legacy system sends an NDC (National Drug
	Code) to us. Whether the data is from an interface or from CW, the
 item is translated to its corresponding NCID and a list of
 ingredients is produced by traversing the "has-ingredient"
 relationships that exist for that item in the 3M HDD.  The list of
 	ingredients is stored as a set of allergen ids (see below).
EXAMPLES:
 	An example would be the NDC code of 00081024256 (NDC codes are always
 	11 digits).  This is the NDC code for Lanoxin (Digoxin), 0.125mg, tablet, the
 	Ncid is equal to 2139041.  This drug will be composed of the ingredient
	DIGOXIN-0593 where the Ncid is equal to 2100577.
DATABASE MAPPING:
	Coded - Allergy:Med_Product_Ncid
	Not Coded - Allergy:Med_Product_Text.
HL7 MAPPING:
	AL1-3	Allergy Code/Pneumonic/Description (broken into multiple
	components.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::MedProduct
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
	Must be coded to perform logic in the ADE, Infectious Disease,
	medication monitoring software, or any other logic that requires
	medication allergy information.

allergenIds:

DEFINITION:
	This field is the result of the interface decomposing the allergen
	into its various components.
EXAMPLES:
 	An example of this would be a medication	like Tylenol #3, which is
	composed of acetamenophen and codeine.  The ncids for both the
	acetamenophen and codeine would be placed in this area.
DATABASE MAPPING:
	Coded - Allergen:Allergen_Ncid
	Not Coded - Allergen:Allergen_Text
HL7 MAPPING:
	No HL7 this field is a by-product of the interface processing.  Or
	OLE entry.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::AllergenIds
	OLE data type: collection of CAllergenIds objects
ALERT REQUIREMENTS:
	Must be coded to perform logic in the ADE, Infectious Disease,
	medication monitoring software, or any other logic that requires
	medication allergy information.

severity:

DEFINITION:
	This is the severity of the allergic reaction... in other words
	how bad did it get.
EXAMPLES:
 	If your throat swells up and the paramedics are called whenever
 	you have mango supreme ice cream, this is a severe food allergy
	and would be coded as such.
DATABASE MAPPING:
	Allergy:Severity_Ncid
HL7 MAPPING:
	AL1-4 Allergy Severity.  They have 3 categories they are Severe,
	Moderate, and Mild.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::Severity
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
	Currently not used in the alerts.

reactions:

DEFINITION:
	This is a description of the general allergic reaction.  What
 	happened (the clinical manifestation) as a result of this allergic reaction.
EXAMPLES:
 	Examples would include itching, sneezing, swelling, convulsing, etc
DATABASE MAPPING:
	Coded - Reaction:Reaction_Ncid
	Not Coded - Reaction:Reaction_Text.
HL7 MAPPING:
	AL1-5 Allergy Reaction.  No coded suggestions.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::Reactions
	OLE data type: collection of CReactions objects
ALERT REQUIREMENTS:
	Currently not used in the alerts.

identificationDate:

DEFINITION:
	The date and time that the allergic reaction occurred.  We suspect
 	that for older incidents you may only see a year or perhaps a month
	and year.  It is highly probable you will not have a complete date
	and time for these reactions.
EXAMPLES:
 	Example 6/6/1956 reaction to Chloraphenicol that was administered
 	prior to appendectomy.  Reaction hives, redness, and slight fever.
DATABASE MAPPING:
	Allergy:Identification_Date
HL7 MAPPING:
	AL1-6 Identification Date.
OLE MAPPING:
	Supported: Get/Set
	Property: CAllergyInfo::IdentificationDate
	OLE data type: DATE
ALERT REQUIREMENTS:
	Currently not used in the alerts.

sourceOfInfo:

DEFINITION:
	This is the person who provided the information on the allergy.
	This can be the patient, the guardian, the spouse, etc.
EXAMPLES:
 	Normally whenever clincical data is acquired from a patient or
	family member the source is noted.  So if you tell your doctor
	that you are allergic to mangoes he will note that the source
	was patient.
DATABASE MAPPING:
	Allergy:Source_Of_Info_Ncid or if not coded
	Allergy:Source_Of_Info_Text
HL7 MAPPING:
	Not defined in HL7.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::SourceOfInfo
	OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
	Currently not used in the alerts.

codedComments:

DEFINITION:
	This field was added "just in case".  We anticipate that in the
	future there may arise the need to include coded comments which
	further describe the allergic reaction or allergy.
EXAMPLES:
 	No one is currently using this feature.
DATABASE MAPPING:
	Currently not reflected in the relational tables.
HL7 MAPPING:
	Not defined in HL7.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::CodedComments
	OLE data type: CCodedComments object
ALERT REQUIREMENTS:
	Currently not used in the alerts.

textComments:

DEFINITION:
	This field was added "just in case".  We anticipate that in the
	future there may arise the need to include text comments which
	further describe the allergic reaction or allergy.
EXAMPLES:
 	No one is currently using this feature.
DATABASE MAPPING:
	Currently not reflected in the relational tables.
HL7 MAPPING:
	Not defined in HL7.
OLE MAPPING:
	Supported: Get
	Property: CAllergyInfo::TextComments
	OLE data type: CTextComments object
ALERT REQUIREMENTS:
	Currently not used in the alerts.

AllergyId:

DEFINITION:
	See the definition of allergyId.

L-AllergenIds:

DEFINITION:
	This is a set of allergens.  This allows for the storing of
	multiple related allergens.  Such as a drug that may have
	several components of which the patient may be allergic.
	See the example of allergenIds.

L-AllergenId:

DEFINITION:
	See allergenIds, the single occurrence of the allergen.

L-Reactions:

DEFINITION:
	This is the set of reactions that you may have given
	the allergen.

L-Reaction:

DEFINITION:
		See reactions, the single occurrence of the reaction.

IdentificationDate:

DEFINITION:
		The base type of the date and time of the allergic reaction.

actionsInfo:

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