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

PatAlertHeader:

DEFINITION:
	The is the identification of the battery of laboratory tests to be done.
 	This should only be used for laboratory tests with specimens.
	FillerOrderNumber,PlacerOrderNumber allow prospective alerts to
	link the alert message to the POE Placer Order number when the
	order is not yet in the CDR (no event_id).
 	This is the resource type id.  This maps to the alert_type_id.
 		This is the severity of the alert message.  That is how bad is the
 		situation that has been found by the alert.  Severity in release 5
 		will be limited to a set of numbers.  The severities are as follows
 		90 critical, 85 requires action, 80 abnormal, 30 informational,
 		20 quality, 15 regulartory, 1 surveillance.

 		Severities can be assigned at the CAM level as it fires the AOE or
 		can be assigned by the aoe itself as it determines the findings.

		Severities are used to communicate the how critical an alert and
		allows clinicians to on the fly manipulate the destination of an
		alert message.
		The alertKey is a combination of two fields the trans_id (transaction id)
		and the seq (sequence number).  See clintype.a1 AlertKey for complete
		information on this field.
		This is the AOE (alert object) that was responsible for creating the
		alert message.  It is the name of an executable.  Only the name of the
		executable is placed in this field.  The complete path is not as the
		AOE executables are placed in a single directory on the system.
		After an AOE (alert object) has created an alert message and is stored into the
		alert output table, it is sent to the datadrive queue as a trigger for
		other AOEs.  The transId will be the same for the original AOE and the subsequent
		AOEs it triggers.
 		This is the severity value of the alert message and is related to the
		severity (coded).  That is how bad is the	situation that has been found
		by the alert.  Severity in release 5 will be limited to a set of numbers.
		The severities are as follows	90 critical, 85 requires action, 80 abnormal,
		30 informational,	20 quality, 15 regulartory, 1 surveillance.  The numeric
		portion of the severity, aka 90, will be stored in this field and is used
		exclusively by Alert Management software and logic.  It is used to route
		message distribution and promote severity values as they become more critical.

 		Severities can be assigned at the CAM level as it fires the AOE or
 		can be assigned by the aoe itself as it determines the findings.

		Severities are used to communicate the how critical an alert and
		allows clinicians to on the fly manipulate the destination of an
		alert message.
 		The productionStatus is where in the installation process is the
		alert logic.  Whenever alerts are installed they are usually placed
		first in the test environment where they are run in a limited fashion.
		They are then quickly moved to production.  In most cases this is the
		only place where you can get the volume and variety of data that will
		adequately test the alerts.  During this phase sites usually
		refine data point values and content used by the alerts.  In this phase
		it is desirable that the alert messages that will be created only be
		seen by the analysts and clinicians testing the alert.  To keep these
		alert messages from being viewed in the CWA application this status
		will be set by the Alert Management system.  It will be coded and
		specify at first whether an alert message is live or in test.  In the
		future their may be other status that will be classified as live or test.
		A domain for live and test will be created.
		Alert notification is the communication of the alert message to individual
		alert locations.  The goal of the distribution is to get the urgent messages
		to the individuals that can act on them in a timely manner.  Notification is
		closely tied to the severity of the AOE.
		This display is an HTML format, which is currently not used.
		See clintypes.a1 display.
		?
 	Format is a Voser stored representation that allows run time insertion
	of variables into the display expression (similar to the '=' that
	was used in PTXT on HELP).  Currently not implemented on HEMS.
EXAMPLES:
		A potassium value of 2.1 would be a critical lab value and would be
 	flag as such in the Critical Lab alerts.  A severity of 90 would be
		asscociated with this alert message.  A physician can then say that
		any alerts with severities equal to or higher than 90 should beep
		him, all others should go to passive review in CW.  In contrast a
		albumin that is low may be given a severity of 80.  In the previous
		example this alert would go to CW and would not beep the physician,
		i.e. the severity of 80 was less than 90.
		For example, critical lab alerts are created by the "clv" object.  Therefore,
		"clv"	would be placed in this field.
		Currently it is not used.
		A potassium value of 2.1 would be a critical lab value and would be
 	flag as such in the Critical Lab alerts.  A severity of 90 would be
		asscociated with this alert message.  A physician can then say that
		any alerts with severities equal to or higher than 90 should beep
		him, all others should go to passive review in CW.  In contrast a
		albumin that is low may be given a severity of 80.  In the previous
		example this alert would go to CW and would not beep the physician,
		i.e. the severity of 80 was less than 90.
		You are installing the CL package.  You have installed to the test
		environment at the site.  However, only a few lab tests are sent
		to the test environment each day.  You move the software to the
		live environment and set the productionStatus to Test.  You have
		determined that yourself and the Chief Pathologist, Dr. Stan Huff
		are the only persons who can view the CL alert messages.  You
		customize the CWA application to allow you and Dr. Huff to view
		the alerts, all others will not see these alerts.
		A glucose level of 300 would be a critical lab value, which would be flagged
		by the critical lab alerts.  A severity of 90 (critical) would be associated
		with the alert message.  The users could determine the method of notification
		associated with critical messages.  An example would be page the physician with
		severity greater than or equal to 90.  In this case if a laboratory value
		had a severity of 80 (abnormal) it would be available for passive review by
		the clinical workstation.
DATABASE MAPPING:


		Currently not defined, will be done in future releases.
		Currently not defined, will be done in future releases.



HL7 MAPPING:
	Currently not defined.
	Currently not defined.
	Currently not defined.
	Currently not defined.
	Currently not defined.
	Currently not defined.


OLE MAPPING:


	Currenlty not defined, will be done in future releases.
	Currently not defined, will be done in future releases.



ALERT REQUIREMENTS:
		Severities of alert messages are assigned by CAM or the AOE (alert
		logic itself).
		Object names are placed into the alert message by the CAM.
		The CAM sends the alert message to the datadrive queue.  The alert notification
		would be batch together after all of the AOEs have finished processing.
		Severities of alert messages are assigned by CAM or the AOE (alert
		logic itself).
		productionStatus is set in the configuration tables for an aoe.  The
		productionStatus is placed in the alert_msg table by the Alert Management
		software as alert messages are created.  It is also kept in the
		Asn.1 string.
		The CAM alert output servers determines the distribution of the alert messages.
		The alert distribution server handles the communication of the alert messages
		to the individual alert locations.
		Currently not used.
		Currently not used.
		Currently not used.

PatAlertEvent:

DEFINITION:
 	An alert event is a subtype of clinical observation which is created
	as a result of logic processing.  The data created by the logic is
	created as a product of machine processing.  This logic may belong to an
	actual alert package, such as Critical Labs or Medication Monitoring,
	or be the product of an alert that was created through the alert
	writer.  In either case the alert event usually contains process
	information, clinical information from the data strings that were used,
	and additional suggestions or findings that are determined by the actual
	logic.
EXAMPLES:
	Examples Critical ValueX  alerts, which state the type of alert, the
	lab observation, its value, a high or low flag, and additional processing
	information which is added by the Clinical Alert Management software.
DATABASE MAPPING:

HL7 MAPPING:
	Currently not defined.
OLE MAPPING:

ALERT REQUIREMENTS:
	Required for the alert software to produce a coded alert message. Filled
	by both CAM and the alert logic.  Some of the parts of the message may
	come from DSS or the trigger that sent the data to the alerting system.

ReportFlagObs:

DEFINITION:
 Flag indicating if the data should be available for review by
 all clinical users or restricted to a defined subset of users based
 on the application and datatype.
 Yes=anyone, No=restricted
 Domain, YesNo(1485) (Yes 1022, or No 1023)
OTHER NOTES:
 means 1 to many

AssociatedDateTimeObs:

DEFINITION:
 The value of AssociatedDateTimeObs is always a date time, but in the future it can contain
 additional obsMods that describe the observation, eg. the transcriptionist, the interface id, etc.
 It contains DateTime information that is a single time, not an interval
OTHER NOTES:
 For now this is the same domain as AssociatedDateTimeInfo

OnsetTimeObs:

DEFINITION:
 Time the ADE Occurred

ResolutionTimeObs:

DEFINITION:
 When the ADE was resolved

PatientObservation:

DEFINITION:
 PatientObservation is mostly a template to follow when
 creating ClinicalObservation subtypes for the WITH TYPES
 clause of the clinObs in a subtype of PatientEvent.

NormalizedValueObs:

OTHER NOTES:
 Concept 'NormalizedObsId': Ncid is 114021UL2 , Rsid is 3859448UL2

NormalizedLengthObs:

OTHER NOTES:
 Concept 'Centimeters': Ncid is 1617UL2 , Rsid is 1407UL2

HeightMeasureMethodObs:

OTHER NOTES:
 Concept 'HeightMeasurementMethod': Ncid is 2059UL2 , Rsid is 68357UL2

PatConditionObs:

OTHER NOTES:
 Concept 'PatientObsCondition': Ncid is 2060UL2 , Rsid is 68358UL2

PatTimingObs:

OTHER NOTES:
 Concept 'PatientObsTiming': Ncid is 2128UL2 , Rsid is 68426UL2

HeightMeasureInstrumentObs:

OTHER NOTES:
 Concept 'HeightMeasurementInstrument': Ncid is 114025UL2 , Rsid is 3859462UL2

PatPositionObs:

OTHER NOTES:
 Concept 'PatientPosition': Ncid is 1439UL2 , Rsid is 174UL2

HeightObs:

OTHER NOTES:
 Concept 'HeightId': Ncid is 110675UL2 , Rsid is 3000230069UL2

NormalizedWeightObs:

OTHER NOTES:
 Concept 'Grams': Ncid is 1630UL2 , Rsid is 1420UL2

WeightMeasureInstrumentObs:

OTHER NOTES:
 Concept 'WeightMeasurementInstrument': Ncid is 114027UL2 , Rsid is 3859463UL2

WeightMeasureMethodObs:

OTHER NOTES:
 Concept 'WeightMeasurementMethod': Ncid is 2183UL2 , Rsid is 68481UL2

WeightObs:

OTHER NOTES:
 Concept 'WeightId': Ncid is 2178UL2 , Rsid is 68476UL2

EffectiveAgeInfo:

OTHER NOTES:
 Concept 'EffectiveAge': Ncid is 119304UL2 , Rsid is 3886581UL2

PatientLocationObs:

DEFINITION:
 Any patient location that does not resolve to Facility, NursingDivsion, Room or Bed

EventLocationObs:

DEFINITION:
 Patient's location (NursingDivision/Room/Bed) when the adverse event occurred
 Make use of existing domains for Facility, NursingDivision, Room and Bed

HospitalServiceObs:

DEFINITION:
 Diagnostic Serv Sect Id (OBR-24)
 HospitalServiceObs taken from advserse.a1
OTHER NOTES:
  Use existing domain, ncid 372

AllergyDocumentQuestionObs:

DEFINITION:
 Domain of questions
    Allergies documented on MAR?
    Allergies documented on FrontofChart?
    Allergies documented InChart?
 YesNoNA (Yes 1022, or No 1023, or NA(NotApplicable))

AllergyDocumentationObs:

DEFINITION:
 Allows specifying if the allergies were documented at the time the ADE occurred


BodyLoc:

OTHER NOTES:
 Concept 'BodyAnatomy': Ncid is 1134UL2 , Rsid is 31091UL2
 BodySiteMod is new as of July 1998.  It replaces the following
 types:  BodySide, BodyLaterality, Depth, RelativeDepth, Level
 RelativeLevel, RelSideOrLaterality

ModelNumber:

OTHER NOTES:
 Concept 'ModelNum': Ncid is 114038UL2 , Rsid is 3859477UL2

SerialNumber:

OTHER NOTES:
 Concept 'SerialNum': Ncid is 114039UL2 , Rsid is 3859480UL2

MedAdminDeviceObs:

DEFINITION:
 Similar to 'SpecCollectionDevice'
 A structure to specify the Administration Device.
OTHER NOTES:
 Domain Device is an existing domain 1136
 Concept 'Device': Ncid is cidDevice, Rsid is rsidDevice
 From RXR-3

SpecProstheticDevice:

OTHER NOTES:
 Concept 'ProstheticDevice': Ncid is 114040UL2 , Rsid is 3859484UL2

DrugRoute:

DEFINITION:
 The Medication Route
HL7 MAPPING:
 RXA-1 (Route) and RXA-4 (Administration Method) map to an LCoded value in the
    RouteObs in the domain 'RouteAndMethod'.
 RXA-2 (Site) maps to the 'BodyLoc' ASN1 structure.
 RXA-3 (Administration Device) maps to an LCoded value in the MedAdminDeviceObs
   structure in the domain 'MedAdminDevice'.
OTHER NOTES:
 Concept 'RouteAndMethod': Ncid is 1459UL2 , Rsid is 198UL2

DoseObs:

DEFINITION:
 The amount and units as used in a dose.
HL7 MAPPING:
 When mapping a Medication Administration:
 RXA-6 and RXA-7 should be mapped 'DoseObs'
 RXA-6 (Administered Amount) maps to a decimal value and RXA-7 maps to an
    LCoded value in the domain 'DoseUnits'.
OTHER NOTES:
 New terminal concept 'Dose'
 Concept 'Dose': Ncid is 153705UL2 , Rsid is 8020876UL2
 Units appropriate for medications
 DoseUnits is an existing domain used by the pharmacyOrder structure.

DrugClassObs:

DEFINITION:
 For indicating a drug classification that is not deriveable from the
 ingredient hierarchy of the pharmacy item
 This is a subjective grouping of the drug by the person entering the report

DosesGivenObs:

OTHER NOTES:
 terminal ncid, DosesGiven
 Should also belong to the domain ObservationIdenifier

NamedFrequencyObs:

DEFINITION:
 coded frequency, all others can go in err_text for now

PatientTypeObs:

DEFINITION:
 terminal ncid
 In SuspectedDrugObs the PatientType is used to indicate if the therapy
 was started as inpatient or outpatient.
 Can simply indicate inpatient or outpatient but allows subcategorizing outpatient

StartTimeObs:

DEFINITION:
 DateTime the started

StopTimeObs:

DEFINITION:
 DateTime stopped

GivenTimeObs:

DEFINITION:
 DateTime given

IndicationObs:

DEFINITION:
 Indication-Why was the drug being given
HL7 MAPPING:
 RXA-19 (Indication) maps to an LCoded value in the IndicationObs structure
    in the domain 'Indication'.
OTHER NOTES:
 New terminal concept 'Indication'
 Concept 'Indication': Ncid is 153708UL2 , Rsid is 8020825UL2
 New domain 'Indication'

SuspectedDrugObs:

DEFINITION:
 records the drug(s) suspected of causing the reaction

ConcurrentDrugObs:

DEFINITION:
 A list concurrent medical products, at time of ADE.
 would not necessarily be in LDR, problably really want drugs the patient
 is actively taking as opposed to scheduled meds

DescriptionObs:

DEFINITION:
 Text description of event

ReactionDocumentQuestionObs:

DEFINITION:
 Domain of questions
    Reaction documented in Chart?
    Reaction documented in NursingNotes?
 YesNoNA (Yes 1022, or No 1023, or NA(NotApplicable))

ReactionDocumentationObs:

DEFINITION:
 Domain listing locations site wants to check off indicating where reactions
 were documented following it's occurrence

ADEAdmitFlagObs:

DEFINITION:
 ADEAdmitFlag=Yes means the ADE was the reason for admission, No means it was not

ReactionObs:

DEFINITION:
 terminal ncid Reaction, 68230
 Obsolete - use ADEReactionObs

TreatmentObs:

DEFINITION:
 terminal ncid
 Coded values such as: drug discontinued, antidote given, dose held

OutcomesObs:

DEFINITION:
 Outcomes records consequences to patient such as:
    hospitalization required or prolonged
    disability
    life-threatening
    death

 Should also belong to the domain ObservationIdentifier

OrdinalProbabilityObs:

DEFINITION:
 OrdinalProbability records the probability this is really an Adverse Drug Event
 in terms of specified categories
 Should also belong to the domain ObservationIdentifier
 Categories such as Definite, Probable, Possible

ADEProbabilityIndicatorObs:

DEFINITION:
 Codes describing why the Definite, Probable, Possible category was assigned
 Examples:
   Reaction corresponded with starting of suspected drugs
   Reaction reappeared after reintroduction of suspected drugs
   Reaction abated after stopping suspected drugs

ScaledRatingObs:

DEFINITION:
 Allows assigning a numeric scale to the severity code
 terminal ncid indicating a site defined numeric scale value is assigned to
 the severity
 Should also belong to the domain ObservationIdentifier
 Numeric rating for the severity

ADESeverityObs:

DEFINITION:
 ADESeverity is a domain with members of different severity scales
 in use. Such as 3PartScale: Mild-Moderate-Severe or the
 4PartScale: NoAction-Moderate-Severe-Fatality or the
 7PartScale in use at Promedica
 obsId has code of specific scale in use at this site
 Should also belong to the domain ObservationIdentifier
 Code indicating a severity category within the scale selected by obsId
 Example: No action required, Moderate, Severe, Fatality

ClinicalTrendObs:

OTHER NOTES:
 Concept 'Trend': Ncid is 31097UL2 , Rsid is 160275UL2

ClinicalSeverityObs:

OTHER NOTES:
 Concept 'Severity': Ncid is 30920UL2 , Rsid is 160136UL2

ChronicityObs:

OTHER NOTES:
 Concept 'Chronicity': Ncid is 84293UL2 , Rsid is 1055783UL2

GeneralObsModifier:

OTHER NOTES:
 Concept 'GeneralObservationModifier': Ncid is 83858UL2 , Rsid is 1055313UL2

ApplicationIdObs:

OTHER NOTES:
 Terminal Concept 'ApplicationId', Ncid is 14707639UL2 , Rsid is 15559203UL2

ExacerbatingFactorsObs:

OTHER NOTES:
 Concept 'ExacerbatingFactors': Ncid is 119305UL2 , Rsid is 3886584UL2

AlleviatingFactorsObs:

OTHER NOTES:
 Concept 'AlleviatingFactors': Ncid is 119306UL2 , Rsid is 3886566UL2

ObservationMethodObs:

OTHER NOTES:
 Concept 'ObservationMethod': Ncid is 30692UL2 , Rsid is 159908UL2

UncertaintyObs:

OTHER NOTES:
 Concept 'Uncertainty': Ncid is 1482UL2 , Rsid is 239UL2

BillingCodeObs:

HL7 MAPPING:
 DG1.3.3 Diagnosis Coding Method
 PR1.3.3 Procedure Coding Method

DiagnosisClassificationObs:

HL7 MAPPING:
 DG1.17 DiagnosisClassification

DiagnosisTypeObs:

HL7 MAPPING:
 DG1.6 DiagnosisType

ConfidentialIndicatorObs:

HL7 MAPPING:
 DG1.18 Confidential Indicator

ClinicianRoleObs:

OTHER NOTES:
 Terminal Concept 'ClinicianRole', Ncid is 1365UL2 , Rsid is 82UL2
 ClinicianRole is a domain, ncid 1365 - new memebers for Procedure Practioner, Anesthesiologist,
 Diagnosing Clinician are needed in this domain

AssociatedClinicianObs:

OTHER NOTES:
 Terminal Concept 'AssociatedClinician', Ncid is 14707640UL2 , Rsid is
 15559205UL2

DiagnosisAndFindingObs:

OTHER NOTES:
 Concept 'Diagnosis': Ncid is 105328UL2 , Rsid is 3859412UL2

ContributingFactorObs:

DEFINITION:
 Contributing factors related to the patient's condition
  race, pregnancy, smoking & alcohol use, hepatic/renal dysfunction
  if other - store text comments

PreventabilityQuestionObs:

DEFINITION:
 Domain PreventablilityQuestions children are Questions to ask user on
 the AdverseEvent form such as:
       Was ADE preventable in investigators opionion?(Y/N)
       Was Dose/route/freq appropriate for age/wt/organ function disease?(Y/N/NA)
       Was a TOXIC serum drug level documented?(Y/N/NA)
 YesNoNA (Yes 1022, or No 1023, or NA(NotApplicable))

PreventabilityObs:

DEFINITION:
 Preventablility is the investigator's opinion concerning if the incident
 could have been avoided

CountConcurrentDrugObs:

DEFINITION:
 Number of other drugs the patient was on at the time

ConcurrentDrugCountClassObs:

DEFINITION:
 Number of other drugs patient is taking by a category (0-1, 2-4, 5-7, >7)

ReportToObs:

DEFINITION:
 Who should get this ADE report
 ReportTo domain, members such as FDA, P&T Committee

ReportByObs:

DEFINITION:
 Who did the reporting

ReportByRoleObs:

DEFINITION:
 Role of person who reported the ADE to pharmacy

ReportTimeObs:

DEFINITION:
 Date/Time the report was made

ReportInfoObs:

DEFINITION:
 For documenting reporting information regarding this ADE report
 Examples: 'ReportBy - Nancy Nurse' or
           'ReportTo - P&T Committee, ReportTime - 1 Jan 1 1998, ReportedBy - RX Pharmacist'
           'ReportTo - FDA' merely indicates it should be reported to FDA, not that it was
           'ReportedByRole- nurse' category indicating the source that reported the ADE was a nurse
                       sources could be a nurse, dietician, coded diagnosis, pharmacist, etc
 Terminal concept, ReportedInfo ncid


ReportFormTimeObs:

DEFINITION:
 Time spent preparing form and collecting data for it
 Terminal concept

ADEReactionObs:

DEFINITION:
 terminal ncid ADEReactions, 154675

AdverseDrugEvent:

DEFINITION:
 Should be member of ObsBatteryId 90780
 Seems likely we may not need the status? (Final, Preliminary, Verified)
 Time AdverseEvent noted by clinician
 will be used to populate stringHeader->eventDateTime and becomes the event_start_gmtime
 Clinician preparing form (stringHeader->enteredBy)
 ReactionObs obsolete - use ADEReactionObs

BodySide:

OTHER NOTES:
 Concept 'Side': Ncid is 91046UL2 , Rsid is 20722UL2

BodyLaterality:

OTHER NOTES:
 Concept 'Laterality': Ncid is 1412UL2 , Rsid is 140UL2

Depth:

OTHER NOTES:
 Concept 'BodyDepth': Ncid is 1356UL2 , Rsid is 73UL2

RelativeDepth:

OTHER NOTES:
 Concept 'BodyRelativeDepth': Ncid is 1358UL2 , Rsid is 75UL2

Level:

OTHER NOTES:
 Concept 'BodyLevel': Ncid is 1357UL2 , Rsid is 74UL2

RelativeLevel:

OTHER NOTES:
 Concept 'BodyRelativeLevel': Ncid is 1359UL2 , Rsid is 76UL2

RelSideOrLaterality:

OTHER NOTES:
 Concept 'RelativeSideOrLaterality': Ncid is 1453UL2 , Rsid is 189UL2

SpecimenReceivedTime:

OTHER NOTES:
 Concept 'SpecimenReceivedTimeId': Ncid is 114034UL2 , Rsid is 3860878UL2

SpecType:

OTHER NOTES:
 Concept 'SpecimenType': Ncid is 114035UL2 , Rsid is 3860884UL2

DecimalVolumeObs:

OTHER NOTES:
 Concept 'DecimalVolumeId': Ncid is 114042UL2 , Rsid is 3859485UL2

FuzzyVolumeObs:

OTHER NOTES:
 Concept 'FuzzyVolume': Ncid is 1396UL2 , Rsid is 117UL2

SpecModifier:

OTHER NOTES:
 Concept 'SpecimenModifiers': Ncid is 114043UL2 , Rsid is 3859486UL2

Specimen:

OTHER NOTES:
 Concept 'ClinicalSpecimen': Ncid is 10446UL2 , Rsid is 34300UL2

PathLesionModifier:

OTHER NOTES:
 Concept 'PathoLesionModifier': Ncid is 114036UL2 , Rsid is 3858268UL2

PathoLesion:

OTHER NOTES:
 Concept 'PathologicStructure': Ncid is 1437UL2 , Rsid is 172UL2

SpecCollectionMethod:

OTHER NOTES:
 Concept 'SpecimenCollectionMethod': Ncid is 1148UL2 , Rsid is 35988UL2

SpecCollectionDevice:

OTHER NOTES:
 Concept 'CollectionDevice': Ncid is 114037UL2 , Rsid is 3859467UL2

NormalizedTemperatureObs:

OTHER NOTES:
 Concept 'DegreeCelsius': Ncid is 1639UL2 , Rsid is 1429UL2

NormalizedBSAObs:

OTHER NOTES:
 Concept 'SquareCentimeters': Ncid is 1655UL2 , Rsid is 1519UL2

ChartNotesEvent:

DEFINITION:
 means 0 to many
 The ChartNotesEvent structure is intended to be used for data stored by
 ChartNotes which does not have a specific structure.  Some examples
 of specific structures are VitalSigns, HeightWeight, EKG, etc.
OTHER NOTES:
 Domain concept 'ProfileDomain': Ncid is cidProfileDomain, Rsid is rsidProfileDomain
 Will contain Ncids representing the ChartNotes profiles as they are created.


RelevantClinicalInfoObs:

DEFINITION:
 Revlevant Clinical Information from (OBR-13)
OTHER NOTES:
  Domain PatObsId, not created yet
  Domain PatObsComment, ncid 90781

StudyReasonReimburseObs:

DEFINITION:
  According to HL7 this should be used to hold a coding method
 (such as ICD9CM) and a code from that coding method.
OTHER NOTES:
  Existing domain, ncid 129, cid needs to be be changed
  Members are ICD9, CPT4, etc.


EKGHeader:

OTHER NOTES:
  Universal Service ID (OBR-4)
  EKGObsBatId is a new domain of EKG test names
  eg.  12-Lead, Stress Test
  Ncid assigned is 107947, not yet created in the HDD
  Filler Order Number (OBR-3)
  Placer Order Number (OBR-2)
  Result Status (OBR-25)
  Observation Date/Time (OBR-7) and Observation End Date/Time (OBR-8)
  Previously used for Technician (OBR-34) which has been moved to
  EventActionInfo in StringHeader
  Consider removing unless used by more
  Domain

ProbabilityObs:

DEFINITION:
 Probability (OBX-9)

UserDefinedAccessObs:

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

EKGObservation:

OTHER NOTES:
  EKGResults is a new domain containing EKG obsevations
  LOINC is used as a starter set
  Observation Identifier (OBX-3)
  Observation ValueX  (in OBX-5), Units (in OBX-6)
  Probability (in OBX-9) has been subtyped from ClinicalObservation,
  see below, but can be stored in the userStatedProbability of att
  References Range (in OBX-7)
  Abnormal Flags (OBX-8)
  Observ Result Status (OBX-11)
  See EventActionsInfo below
  Set ID (OBX-1)

ProcedureFunctionalTypeObs:

DEFINITION:
 means 0 to many
HL7 MAPPING:
 PR1.6 Procedure Function Type
OTHER NOTES:
 means 1 to many
 Terminal Concept 'ProcedureFunctionalType', Ncid is 14707645UL2 , Rsid is 15559215UL2
 ProceedureFunctionalType is a domain, ncid ??

ConsentCodeObs:

HL7 MAPPING:
 PR1.13 Consent Code
OTHER NOTES:
 Terminal Concept 'ConsentCode', Ncid is cidConcentCode, Rsid is 15559207UL2
 ConsentCode is a domain, ncid

ProcedureTypeObs:

OTHER NOTES:
 Terminal Concept 'ProcedureType', Ncid is 14707647UL2 , Rsid is 15559219UL2
 ProceedureType is a domain, ncid ??
 HL7 PR1.14 Procedure Priority

ProcedureDurationObs:

OTHER NOTES:
 Terminal Concept 'ProcedureDuration',Ncid is 14707644UL2 ,Rsid is 15559213UL2
 HL7 PR1.7 Procedure Minutes

ProcedureCodeModifierObs:

OTHER NOTES:
 Terminal Concept 'ProcedureCodeModifier', Ncid is 14707643UL2 , Rsid is rsidProcedureCodemodifier
 ProceedureCodeModifier is a domain, ncid ??
 HL7 PR1.16 Procedure Code Modifier

DRGProcedureRankObs:

OTHER NOTES:
 Terminal Concept 'DRGProcedureRank', Ncid is 14707642UL2 , Rsid is 15559209UL2
 ProceedureDRGType is a domain, ncid ??
 HL7 PR1.17 Procedure DRG Type

ProcedureTissueTypeObs:

OTHER NOTES:
 Terminal Concept 'ProcedureTissueType', Ncid is 14707646UL2 , Rsid is 15559217UL2
 ProceedureTissueType is a domain, ncid ??
 HL7 PR1.18 Tissue Type

AnesthesiaDurationObs:

OTHER NOTES:
 Terminal Concept 'AnesthesiaDuration', Ncid is cidAnesthesiaDuration, Rsid is rsidAnesthesiaDuration
 HL7 PR1.10 Anesthesia Minutes

AnesthesiaObs:

OTHER NOTES:
 Terminal Concept 'AnesthesiaCode', Ncid is cidAnesthesiaCode, Rsid is rsidAnesthesiaCode
 AnesthesiaCode is a domain, ncid
 HL7 PR1.9 Anesthesia Code

ProcedureObs:

OTHER NOTES:
 Concept 'MedicalProcedure': Ncid is 82750UL2 , Rsid is 1055156UL2

MmiNumberInfo:

OTHER NOTES:
 Concept 'MmiNumber': Ncid is 119307UL2 , Rsid is 3886614UL2

NameIndexObs:

OTHER NOTES:
 New concept NameIndexId: cid is 154816UL2 , rsid is 8035571UL2

NameTypeObs:

OTHER NOTES:
 New concept NameTypeId: cid is cidNameTypeId, rsid is rsidNameTypeId

LastNameObs:

OTHER NOTES:
 New concept LastNameId: cid is 154817UL2 , rsid is 8035559UL2

LastName2Obs:

OTHER NOTES:
 New concept LastName2Id: cid is 154818UL2 , rsid is 8035576UL2

FirstNameObs:

OTHER NOTES:
 New concept FirstNameId: cid is 154819UL2 , rsid is 8035552UL2

MiddleNameObs:

OTHER NOTES:
 New concept MiddleNameId: cid is 154820UL2 , rsid is 8035567UL2

MiddleName2Obs:

OTHER NOTES:
 New concept MiddleName2Id: cid is 154821UL2 , rsid is 8035577UL2

NameSuffixObs:

OTHER NOTES:
 New concept NameSuffix: cid is 154822UL2 , rsid is 8035572UL2

NameTitleObs:

OTHER NOTES:
 New concept NameTitle: cid is 154823UL2 , rsid is 8035573UL2

NameDegreeObs:

OTHER NOTES:
 New concept NameDegree: cid is 154824UL2 , rsid is 8035569UL2

FullNameObs:

OTHER NOTES:
 New concept FullNameId: cid is 154825UL2 , rsid is 8035553UL2

NameObs:

DEFINITION:
 = 0 to many
 A NameObs is defined to hold any type of name which needs to be
 broken down into pieces (or even if it doesn't!) and optionally
 needs to specify the type of name (current name, previous name, etc.)
 and/or give order or precedence to a list of names (using the
 NameIndexObs obsMods).
OTHER NOTES:
 New concept NameId: cid is 154815UL2 , rsid is 8035570UL2

FamHistoryRelativeInfo:

OTHER NOTES:
 Concept 'ToPatientRelationship': Ncid is 1012UL2 , Rsid is 10980UL2

FamilyHistoryObs:

OTHER NOTES:
 Concept 'FamilyHistory': Ncid is 105329UL2 , Rsid is 3858183UL2

ProcedureDateTime:

DEFINITION:
 means 0 to many
HL7 MAPPING:
 PR1.5 Attestation Date/Time
OTHER NOTES:
 means 1 to many

DiagnosisDateTimeObs:

HL7 MAPPING:
 DG1.5 DiagnosisDate/Time

AttestationDateTimeObs:

HL7 MAPPING:
 DG1.19 Attestation Date/Time

BillingDiagnosisCodesObs:

HL7 MAPPING:
   DG1.3 DiagnosisCode

EncodedDataEvent:

DEFINITION:
 means 0 to many
OTHER NOTES:
 The patient identification information is contained in the stringHeader which
 is common to all events.  Both MPI number and encounter number can be specified.
 The 'pid' field in the sample 'chart' database would map to MPI and encounter number.
 for the EandM codes while PID(3) will map to medical record Number and PV1() will map to
 encounter number for the Diagnoses and Proceedures

 Terminal concept 'EncodedData' Ncid is cidEncodeData, Rsid is rsidencodedData
 The obsDataTime should be set to the time the diagnosis was determined.


MedComponentTypeObs:

DEFINITION:
 means 0 to many
 means 0 to many
 A structure to specify the component type of a drug.  (i.e. Base or Additive)
HL7 MAPPING:
 This information is not specified by a HL7 record.

OTHER NOTES:
 Terminal concept 'RXComponentType': Ncid is 1460UL2 , Rsid is 199UL2

 Domain concept 'RXComponentType': Ncid is 1460UL2 , Rsid is 199UL2
 RXComponentType is an existing domain used by the pharmacyOrder structure.


MedAdminSequenceObs:

DEFINITION:
 A structure to specify the sequence number of a medication
 administration.  This is typically used for immunizations to specify
 whether this immunization is the first or second, etc. in a series.
 This is the stated sequence number for a vaccine class, however
 it is not necessarily a VALID immunization for that sequence number.
HL7 MAPPING:
 RXA-2 (Administration Sub-ID Counter) maps to an integer value in the
    MedAdminSequenceObs structure.

OTHER NOTES:
 Terminal concept 'MedAdminSequenceId': Ncid is 154785UL2 , Rsid is 8035622UL2

 Domain concept 'ImmunizationSequence': Ncid is cidImmunizationSequence, Rsid is rsidImmunizationSequence
 ImmunizationSequence contains members such as '#1', '#2', 'Primary Sequence Complete',
    'Booster'.  The 'numeric' members of this domain will have a representation in the
    AlertContext (101963) which can be translated to a numeric value for use in
    the reminder logic.


VaccineClassObs:

DEFINITION:
 A structure used as an obsMods to associate a clinicalObservation with
 a particular vaccine class.
OTHER NOTES:
 Terminal concept 'VaccineClassId': Ncid is 1601201UL2 , Rsid is 8123125UL2

 Domain concept 'MajorVaccineClass': Ncid is cidMajorVaccineClass, Rsid is rsidMajorVaccineClass


LotNumberObs:

DEFINITION:
 A structure to specify the LotNumber
HL7 MAPPING:
 RXA-15 (Substance Lot Number) maps to a string value in the LotNumberObs
    structure.

OTHER NOTES:
 Terminal concept 'LotNumberId': Ncid is 154782UL2 , Rsid is 8035560UL2


ExpireDateObs:

DEFINITION:
 A structure to specify the Expiration date
HL7 MAPPING:
 RXA-16 (Substance Expiration Date) maps to a dateTime value in the
    ExpireDateObs structure.

OTHER NOTES:
 Terminal concept 'ExpireDate': Ncid is 154780UL2 , Rsid is 8035551UL2


DocumentIdObs:

DEFINITION:
 A structure to collect the Document id.  In the context of immunizations
 this will be used to track the VIS (Vaccine Information Statement) version or
 pulication date which was given to a patient or guardian.
HL7 MAPPING:
 This information is not specified by a HL7 record.

OTHER NOTES:
 Terminal concept 'DocumentId': Ncid is 90579UL2 , Rsid is 152395UL2


MedClassSequenceObs:

DEFINITION:
 Information about the sequence # and or Vaccine class associated with a Medication
 administration.  This observation has a value of 'Present' and exists solely to
 allow association of a particular vaccine class with a sequence number, but
 without making either one of these pieces of data dependent on the others presence.
 This allows the Vaccine classes to still be specified for a Combo vaccine without
 forcing presence of the sequence #.
OTHER NOTES:
 Terminal concept 'MedClassSequenceId': Ncid is 1601209UL2 , Rsid is 8124085UL2

 Terminal concept 'Present': Ncid is 1076UL2 , Rsid is 34358UL2


MedFormObs:

DEFINITION:
 A structure to specify the form of the Medication product
HL7 MAPPING:
 RXA-8 (Administered Dosage Form) maps to an LCoded value in the MedFormObs
    structure from the domain 'GiveDosageForm'

OTHER NOTES:
 Terminal concept 'GiveDosageForm': Ncid is 1398UL2 , Rsid is 120UL2

 Domain concept 'GiveDosageForm': Ncid is 1398UL2 , Rsid is 120UL2
 GiveDosageForm is an existing domain used by the pharmacyOrder structure.


MedStrengthObs:

DEFINITION:
 A structure to specify the Strength of the medication product
HL7 MAPPING:
 RXA-13 (Administered Strength) maps to a decimal value and RXA-14
    (Administered Strength Units) maps to a Coded value in the MedStrengthObs
    structure from the domain 'DoseUnits'.

OTHER NOTES:
 Terminal concept 'MedStrengthId': Ncid is 154786UL2 , Rsid is 8035566UL2

 Domain concept 'DoseUnits': Ncid is cidDoseUnits, Rsid is rsidDoseUnits
 DoseUnits is an existing domain used by the pharmacyOrder structure.


ManufacturerObs:

DEFINITION:
 A structure to specify the Manufacturer
HL7 MAPPING:
 RXA-17 (Substance Manufacturer Name) maps to an LCoded value in the
    ManufacturerObs structure from the domain 'VaccineManufacturer'.

OTHER NOTES:
 Terminal concept 'Manufacturer': Ncid is 154783UL2 , Rsid is 8035621UL2

 Domain concept 'VaccineManufacturer': Ncid is cidVaccineManufacturer, Rsid is rsidVaccineManufacturer

 Domain concept 'ClinObsComment': Ncid is cidClinObsComment, Rsid is rsidClinObsComment


VISGivenToObs:

DEFINITION:
 A structure to record that something (identified by the obsId) was given to
    someone (indicated by the LCoded value.
HL7 MAPPING:
 This information is not specified by a HL7 record.

OTHER NOTES:
 Terminal concept 'VISGivenToId': Ncid is 154787UL2 , Rsid is 8035578UL2

 Domain concept 'PatObsComment': Ncid is cidPatObsComment, Rsid is rsidPatObsComment

 Domain concept 'ToPatientRelationship': Ncid is 1012UL2 , Rsid is 10980UL2


MedAdminDrugObs:

DEFINITION:
 A structure for specifying a Medication and its associated administration information
HL7 MAPPING:
 RXA-5 (Administered Code) maps to an LCoded value in the MedAdminDrugObs structure
    from the domain 'PharmacyItem'.

OTHER NOTES:
 Terminal concept 'MedAdminDrugId': Ncid is 154784UL2 , Rsid is 8035565UL2

 Domain concept 'VaccineItem': Ncid is cidVaccineItem, Rsid is rsidVaccineItem
 'PharmacyItem' is an existing domain which should be used by the pharmacyOrder structure.
   The 'PharmacyItem' domain includes both GCN sequence and NDC codes.  In the future the
   interface may start sending both as separate fields.  If and when this happens we
   will add new optional 'obsMods' - one for the GCN sequence information and another
   for the NDC information.  This value, however, would continue to get populated and
   if both pieces of info were present we would need to designate which one we want
   here.  This approach lets us handle the possibility of both while not making
   the current structure overly complicated and allows for a transition mechanism.
 Since we do not want to add members of the reminder hierarchy to the 'PharmacyItem'
   domain (at least for now) we will start off using the 'VaccineItem' domain.


SourceOfInfoObs:

OTHER NOTES:
 Terminal concept 'SourceOfInfo' 1462
 Generic identifier indicating who provided the information
 ie. Sister, Patient
 This domain is also used by the non-ClinicalEvent event AllergyInfo

RemoteEventLocationObs:

DEFINITION:
 A structure to store the facility, etc. where an event happened in cases
 where the event occurred outside the enterprise.  This would typically
 be used when collecting historical information from/about a patient.
OTHER NOTES:
 Terminal concept 'RemoteEventLocation': Ncid is 162174UL2 , Rsid is 8095833UL2


IsCDCVaccineObs:

DEFINITION:
 A structure to store whether a given vaccine was subsidized by CDC funds
HL7 MAPPING:
 This information is not specified by a HL7 record.

OTHER NOTES:
 Terminal concept 'IsCDCVaccine': Ncid is 154781UL2 , Rsid is 8035558UL2

 Domain concept 'YesNoNA': Ncid is cidYesNoNA, Rsid is rsidYesNoNA


MedAdminEventType:

DEFINITION:
 The MedAdminEvent structure is intended to hold Medication Administration
 records.  Immunizations are a special case of a Med Administration and
 need to be handled by this structure.  Actually, this version of the structure
 will need to be expanded to handle many types of Medication Administration.
HL7 MAPPING:
 This ASN1 structure is used for the RXA segment and its associated RXR segment
 when a RAS message is received.

 RXA-1 (Give Sub-ID Counter) will not be mapped to the ASN1
 RXA-11 (Administered at Location) maps to the 'pointOfCare' field in
 'actionsInfo' in the 'stringHeader'.
 RXA-21 (Action Code) does not map to the ASN1 structure.  It is essentially
 an operation (Insert, Delete, Update) indicator to the interface application
 receiving the HL7 message.

 RXA-22 (System Entry Date/Time) maps to the 'enteredTime' field in
 an 'actionInfo' node in the 'stringHeader'.  The 'actionInfo' node should
 be an 'associatedAction' to a node with an ActionId of either 1520 (Entered)
 or 1518 (Modified) and would have an ActionId of (TransactionTime), a new concept.

 ORC-3 (FillerOrderNumber) maps to 'fillerOrderNumber'.

 ORC-2 (Placer Order Number) maps to 'placerOrderNumber'.

 RXA-20 (Completion Status) is the Completion Status (Given,
 Partially Administered, Invalid, and Refused).  It maps to 'testStatus'.

 RXA-3 (Date/Time Start of Administration) and RXA-4 (Date/Time End
 of Administration) both map to 'obsDateTime' (which is a time interval).

 RXA-10 (Administering Provider) maps to 'observedBy'.

 RXA-9 (Administration Notes) map to 'comments'.

OTHER NOTES:
 When documenting that an immunization was given previously at a different
 location outside the enterprise the pointOfCare in 'actionsInfo' will be
 left blank.  If desired, a comment in the header can be used to specify
 where the immunization occurred.

 Domain concept 'MedAdminEvent': Ncid is cidMedAdminEvent, Rsid is rsidMedAdminEvent
 Will contain members 'ImmunizationEvent' and 'ImmunizationHistoryEvent', etc.

 Domain concept 'MedAdminStatus': Ncid is cidMedAdminStatus, Rsid is rsidMedAdminStatus
 Possible values for 'testStatus' include:
   'Given'         - Person was given Medication.
   'Partial Admin' - Person was only given a partial administration.  This should
                     be considered invalid for immunization reminder logic purposes.
   'Invalid'       - Although an medication administration (or partial administration
                     was noted it should considered invalid for reminder logic
                     purposes.
   'Refused'       - Person refused the medication.

 When documenting an immunization given elsewhere the obsDateTime may be a fuzzy date,
 but it is still required and will still be used as the 'EventStartTime'
 although without the 'fuzzy' information.  It may be best to train users
 to always put in a full date (with 'fuzzy' information if permitted by
 the input mechanism) which reflects the latest possible date the immunization
 was given since immunizations are concerned mostly with a minimum interval
 between doses.

 When documenting an immunization given elsewhere the observedBy field can
 be left blank.  (Please note that this field cannot accept text at all!)
 The comments field can be used if desired in this case to enter any
 available information about the Adminstering Provider.

 Domain concept 'PharmacyCodedComment': Ncid is cidPharmacyCodedComment, Rsid is rsidPharmacyCodedComment

 MedAdminDrugObs may need to be optional (0 to many) for general Med
   administrations since the order already contains the information.


ImmunizationEventType:

DEFINITION:
 means 0 to many
 means 0 to many
 The ImmunizationEventType is an instance of type MedAdminEventType used
 to document that an immunization has just been given to the patient.
OTHER NOTES:
 Terminal concept 'ImmunizationEvent': Ncid is 154789UL2 , Rsid is 8035554UL2

 Please note that at least one MedAdminDrugObs is required for an ImmunizationEvent.


ImmunizationHistoryEventType:

DEFINITION:
 means 0 to many
 means 0 to many
 The ImmunizationHistoryEventType is an instance of type MedAdminEventType used
 to document historical information about a patient's past immunizations.
OTHER NOTES:
 Terminal concept 'ImmunizationHistoryEvent': Ncid is 154790UL2 , Rsid is 8035555UL2

 Please note that at least one MedAdminDrugObs is required for an ImmunizationEvent.


SpecificVaccineInfoObs:

DEFINITION:
 means 0 to many
 The value of SpecificVaccineInfoObs will contain a more specific recommendation
 within the 'class' of immunization being reminded for when appropriate.
 If there is no specific recomendation within the class then this node will
 not be present.
OTHER NOTES:
 Terminal concept 'Vaccine': Ncid is 153422UL2 , Rsid is 8018028UL2

 Domain concept 'Vaccine': Ncid is 153422UL2 , Rsid is 8018028UL2
 The coded value of this structure is a member of the hierarchy
 of vaccine classes 'MajorVaccineClass'.  This is the same domain as for the ObsBatId
 but the ObsBatId should only be a direct child of 'MajorVaccineClass'.


ImmunizationReminderObs:

DEFINITION:
 Data specific to Immunization Reminders.  The ObsBatId contains the 'class' of
 Immunization Reminder such as 'Polio'.  This node is to group together any other
 information which is specific to Immunization Reminders such as 'Recommend IPV
 as 2nd dose'.
OTHER NOTES:
 Terminal concept 'ImmunizationReminder': Ncid is 162169UL2 , Rsid is 8095828UL2

 Terminal concept 'Present': Ncid is 1076UL2 , Rsid is 34358UL2


ReminderObject:

DEFINITION:
 The ReminderObject is a placeholder for information that is specific to the
 type of reminder being generated.  The list of subtypes will probably grow
 with time.

EarliestRecommendedDateObs:

DEFINITION:
 The beginning of the recommended time range.
OTHER NOTES:
 Terminal concept 'EarliestRecommendedDate': Ncid is 162168UL2 , Rsid is 8095827UL2


LatestRecommendedDateObs:

DEFINITION:
 The end point of the recommended time range.
OTHER NOTES:
 Terminal concept 'LatestRecommendedDate': Ncid is 162173UL2 , Rsid is 8095832UL2


EarliestAllowedDateObs:

DEFINITION:
 The earliest Date this intervention should be done.  For ImmunizationReminders,
 a vaccine given before this date would be considered invalid and should
 be given again.  This date is specific to the vaccine specified in
 SpecificVaccineInfoObs if that node is present.  Otherwise it is
 general to the vaccine class.
OTHER NOTES:
 Terminal concept 'EarliestAllowedDate': Ncid is 162167UL2 , Rsid is 8095826UL2


LatestAllowedDateObs:

DEFINITION:
 The latest Date this intervention should be done.  For ImmunizationReminders,
 a vaccine no longer makes sense and would no longer be administered after
 this date.  This date is specific to the vaccine specified in
 SpecificVaccineInfoObs if that node is present.  Otherwise it is
 general to the vaccine class.
OTHER NOTES:
 Terminal concept 'LatestAllowedDate': Ncid is 162172UL2 , Rsid is 8095831UL2


LastDoneDateObs:

DEFINITION:
 The date the intervention was last done, where applicable.  This
 is essentially the date the Reminder Logic used to calculate the
 EarliestRecommendedDate, LatestRecommendedDate, EarliestAllowedDate,
 and LatestAllowedDate if the intervention has already been performed
 at least once.
OTHER NOTES:
 Terminal concept 'LastDoneDate': Ncid is 162170UL2 , Rsid is 8095829UL2


ReminderEvent:

DEFINITION:
 ReminderEvent is a structure for keeping track of information
 about a particular Reminder so that reports and reminders can be viewed.
 In the event that we want to keep track of postcards sent to patients the
 actionsInfo structure in the stringHeader can be used to mark these events
 in the life cycle of the Reminder.

 The term 'intervention' is used in this documentation to refer to the
 object (ObsBatId) of the Reminder.

 Since this structure is derived directly from ClinicalEvent this will be
 a new EventType.

 Semantic Links:
   1.  There will be a semantic link to the triggering data if it was clinical data.
       Relationship_ncid = cidAlertTriggerEvent (AlertTriggerEvent)
   2.  There will be a semantic link to any events that are indications, precautions,
       or contra-indications, etc. of the reminder.  The triggering event may or
       may not be an indication or contr-indication.  If it is, it will appear
       twice as a semantic link.
       This functionality and the concepts to represent the relationships will be
       added at a future date.
   3.  For immunizations, there will be a semantic link to previous documentation
       that the logic considers invalid.  Different relationship ncids will be
       used to indicate why the immunization was considered invalid.  This will
       be used only to indicate that an Immunization that is marked as 'Given'
       is not being considered valid in the logic.  Immunization documentation
       events that actually have a status of 'Invalid' will not have a semantic
       link.
       Relationship_ncid = cidDoesNotFill (DoesNotFill)
   4.  When a Reminder is marked as 'Documented', there will be a semantic link
       to the data which 'filled' the Reminder.
       Relationship_ncid = cidFilledBy (FilledBy)
EXAMPLES:
		A potassium value of 2.1 would be a critical lab value and would be
 	flag as such in the Critical Lab alerts.  A severity of 90 would be
		asscociated with this alert message.  A physician can then say that
		any alerts with severities equal to or higher than 90 should beep
		him, all others should go to passive review in CW.  In contrast a
		albumin that is low may be given a severity of 80.  In the previous
		example this alert would go to CW and would not beep the physician,
		i.e. the severity of 80 was less than 90.

		For example, critical lab alerts are created by the "clv" object.  Therefore,
		"clv"	would be placed in this field.

		You are installing the CL package.  You have installed to the test
		environment at the site.  However, only a few lab tests are sent
		to the test environment each day.  You move the software to the
		live environment and set the productionStatus to Test.  You have
		determined that yourself and the Chief Pathologist, Dr. Stan Huff
		are the only persons who can view the CL alert messages.  You
		customize the CWA application to allow you and Dr. Huff to view
		the alerts, all others will not see these alerts.

ALERT REQUIREMENTS:
		Severities of alert messages are assigned by CAM or the AOE (alert
		logic itself).

		Object names are placed into the alert message by the CAM.

		productionStatus is set in the configuration tables for an aoe.  The
		productionStatus is placed in the alert_msg table by the Alert Management
		software as alert messages are created.  It is also kept in the
		Asn.1 string.

OTHER NOTES:
 Domain concept 'Reminder': Ncid is cidReminder, Rsid is rsidReminder
 Should contain the type or class of reminder.
 Members will include 'DPT', 'Polio', 'Mammography', etc.

 Domain concept 'ReminderEventStatus': Ncid is cidReminderEventStatus, Rsid is rsidReminderEventStatus
 Possible values for 'testStatus' include:
   'Active'      - Person needs specified intervention and should come in.
   'Cancelled'   - Person did not receive specified intervention but not longer
                   needs reminded because they refused, are allergic, or are
                   simply not an active patient anymore, etc.
   'Documented'  - Person received specified intervention-see semantic link
                   for specific data stored.
   'Do Not Give' - Person has a contra-indication for specified intervention.
                   This status is planned for use at a future date.
   'Past Due'    - Person did not receive the specified intervention and this
                   reminder has now expired.  This will happen for reminder
                   which are not 'filled' and have passed the 'LatestAllowedDate'.

 'obsDateTime' is the Date/Time the Reminder was created.
 (Will be used to populate stringHeader->eventDateTime and becomes the event_start_gmtime)

 	This is the resource type id.  This maps to the alert_type_id.

 		This is the severity of the alert message.  That is how bad is the
 		situation that has been found by the alert.  Severity in release 5
 		will be limited to a set of numbers.  The severities are as follows
 		90 critical, 85 requires action, 80 abnormal, 30 informational,
 		20 quality, 15 regulartory, 1 surveillance.

 		Severities can be assigned at the CAM level as it fires the AOE or
 		can be assigned by the aoe itself as it determines the findings.

		Severities are used to communicate the how critical an alert and
		allows clinicians to on the fly manipulate the destination of an
		alert message.

		The alertKey is a combination of two fields the trans_id (transaction id)
		and the seq (sequence number).  See clintype.a1 AlertKey for complete
		information on this field.

		This is the AOE (alert object) that was responsible for creating the
		alert message.  It is the name of an executable.  Only the name of the
		executable is placed in this field.  The complete path is not as the
		AOE executables are placed in a single directory on the system.

 		The productionStatus is where in the installation process is the
		alert logic.  Whenever alerts are installed they are usually placed
		first in the test environment where they are run in a limited fashion.
		They are then quickly moved to production.  In most cases this is the
		only place where you can get the volume and variety of data that will
		adequately test the alerts.  During this phase sites usually
		refine data point values and content used by the alerts.  In this phase
		it is desirable that the alert messages that will be created only be
		seen by the analysts and clinicians testing the alert.  To keep these
		alert messages from being viewed in the CWA application this status
		will be set by the Alert Management system.  It will be coded and
		specify at first whether an alert message is live or in test.  In the
		future their may be other status that will be classified as live or test.
		A domain for live and test will be created.

 Domain concept 'ReminderComment': Ncid is cidReminderComment, Rsid is rsidReminderComment


ImmunizationReminderEvent:

DEFINITION:
 means 0 to many
 A structure for specifying an Immunization Reminder.
 ImmunizationReminderEvent is a subtype of ReminderEvent used to store Reminders
 for Immunizations. It constrains the obsBatId to only Immunzation Reminders and
 specifically requires the ImmunizationReminderObs in the clinObs.
OTHER NOTES:
 Domain concept 'MajorVaccineClass': Ncid is cidMajorVaccineClass, Rsid is rsidMajorVaccineClass
 Domain 'MajorVaccineClass' will contain the type or class of Immunizaiton Reminder.
 Children should include 'DPT', 'Polio', etc.  Only direct children of
 domain 'MajorVaccineClass' should be used in this field.


PreventiveReminderEvent:

DEFINITION:
 means 0 to many
 PreventiveReminderEvent is a subtype of ReminderEvent used to store Reminders
 for Preventive Services. It constrains the obsBatId to only Preventive Service Reminders.
 No ReminderObject is required.
OTHER NOTES:
 Domain concept 'MajorWellnessClass': Ncid is 162045UL2 , Rsid is 8094883UL2
 Members will include 'PAP Class', 'Mammograpy Class', etc.


MmiBirthDateUsedObs:

DEFINITION:
 means 0 to many
 MmiBirthDateUsedObs is used to keep track of the birthDate in the MMI_ID record
 at the time the ReminderStatusEvent was last stored.  This is used to determine
 if the birthdate has changed, which requires that Reminders be recalculated.
OTHER NOTES:
 Terminal concept 'MmiBirthDateUsed': Ncid is 1601182UL2 , Rsid is 8122963UL2


MmiRaceUsedObs:

DEFINITION:
 MmiRaceUsedObs is used to keep track of the race_cid in the MMI_ID record
 at the time the ReminderStatusEvent was last stored.  This is used to determine
 if the race has been changed, which requires that Reminders be recalculated.
OTHER NOTES:
 Terminal concept 'MmiRaceUsed': Ncid is 1601183UL2 , Rsid is 8122964UL2


MmiSexUsedObs:

DEFINITION:
 MmiSexUsedObs is used to keep track of the sex in the MMI_ID record
 at the time the ReminderStatusEvent was last stored.  This is used to determine
 if the sex has been changed, which requires that Reminders be recalculated.
OTHER NOTES:
 Terminal concept 'MmiSexUsed': Ncid is 1601184UL2 , Rsid is 8122965UL2


LastTouchedValueObs:

DEFINITION:
 The value associated with the last update of the ReminderStatusEvent.
 Processes which have been assigned a lower value should not update a
 ReminderStatusEvent which already has a higher LastTouchedValue.  This
 is principally to keep batch processes from starting reminders back up
 on patients for whom clinicians have specifically turned Reminders off.
OTHER NOTES:
 Terminal concept 'LastTouchedValue': Ncid is 162171UL2 , Rsid is 8095830UL2


MinRecommendedIntervalObs:

DEFINITION:
 Minimum number of days between the last time the preventive service was done
 and when it should be done again.
OTHER NOTES:
 Terminal concept 'MinRecommendedInterval': Ncid is 162177UL2 , Rsid is 8095836UL2


MaxRecommendedIntervalObs:

DEFINITION:
 Maximum number of days between the last time the preventive service was done
 and when it should be done again.
OTHER NOTES:
 Terminal concept 'MaxRecommendedInterval': Ncid is 162178UL2 , Rsid is 8095837UL2


GenerateReminderWithinObs:

DEFINITION:
 Number of days before the reminder is due to actually
 store the reminder in the LDR.  For instance, for a tetanus shot due
 in 10 years you may want the reminder generated only a year in advance.
OTHER NOTES:
 Terminal concept 'GenerateReminderWithin': Ncid is 162179UL2 , Rsid is 8095838UL2


PatientSpecificScheduleObs:

DEFINITION:
 Used to override the default reminder schedule for this patient and wellness class
OTHER NOTES:
 Terminal concept 'PatientSpecificSchedule': Ncid is 162176UL2 , Rsid is 8095835UL2


PreExpirationStatusObs:

DEFINITION:
 PreExpirationStatus, as with LastTouched is it set by Stop and checked by Start
 When active reminder status events exist at the time a patient
 is marked as expired by an auto-stop process save the previous ReminderStatusEvent
 status in this field. If the 'expired' state of the patient is then cancelled then
 the ReminderStatusEvent can be restored to it's previous state.
OTHER NOTES:
 Terminal concept 'PreExpirationStatus': Ncid is 50037UL2 , Rsid is 8095800UL2


ReminderStatusEvent:

DEFINITION:
 ReminderStatusEvent is a structure for storing an event
 which controls the generation of a particular type or class of
 Reminders for a person.  This structure is also used to notify
 (remind) applications if a person's history should be collected.

 Since this structure is derived directly from ClinicalEvent this will be
 a new EventType.
OTHER NOTES:
 Domain concept 'Reminder': Ncid is cidReminder, Rsid is rsidReminder
 Should contain the type or class of reminder.
 Members will include 'DPT', 'Polio', 'Mammography', etc.
 This is the same domain specified for ReminderEvents.  This is
 it is important that ReminderEvent and ReminderStatusEvent each
 be their own EventType.

 Domain concept 'ReminderStatusEventStatus': Ncid is cidReminderStatusEventStatus, Rsid is rsidReminderStatusEventStatus
 Possible values for 'testStatus' include:
       'Generate'        - This type of Reminder should be generated for this person.
       'History'         - A history is needed for this person and reminders
                           will not be generated till it is collected.
       'Do Not Generate' - Specifically do NOT generate this type of Reminders for
                           this persion.

 'obsDateTime' is the Date/Time the ReminderStatusEvent was created.
 (Will be used to populate stringHeader->eventDateTime and becomes the event_start_gmtime)

 Domain concept 'ReminderComment': Ncid is cidReminderComment, Rsid is rsidReminderComment


WellnessClassObs:

DEFINITION:
 means 0 to many
 A structure for specifying more explicitly what preventive service was done.
OTHER NOTES:
 New domain 'MajorWellnessClass'. Will contain the class
 of preventive service.  The MajorWellnessClass members may
 also be members of the 'Reminder' domain.
 Members will include 'Mammography Class', 'PAP Class', etc.

 codedObsVal will be member of the MajorWellnessClass
 Members will include 'Mammography Class', 'PAP Class', etc.

PreventiveServiceObs:

DEFINITION:
 A structure for specifying more explicitly what preventive service was done.
OTHER NOTES:
 New terminal concept 'PreventiveService'
 Concept 'PreventiveService': Ncid is 162166UL2 , Rsid is 8095825UL2

 The coded value of this structure can be a PreventiveService class
 or a member of the hierarchy of PreventiveService class.
 This is either a duplicate of the obsBatId, or a member of its hierarchy.
 Additional information can go in the comments since it is
 unlikely we'd have the specifics to code the data in fields
 SRS refers to Name, address of facility and name of person
 administering the preventive service.

PreventiveHistoryEvent:

DEFINITION:
 PreventiveHistoryEvent will be derived from PatObsEvent.  This structure
 is the generic Wellness version of the ImmunizationHistoryEvent.  It
 gives the clinician a place to document that a wellness screen has taken
 place in the past when the wellness screen results are not stored in
 the LDR.
 Semantic Links:
    Probably not used
 StringHeader & ActionsInfo
    The identity of the clinician documenting the preventive service will
    be stored in the 'clinician' node of actionsInfo.
OTHER NOTES:
 Members will include 'Mammography Class', 'PAP Class', etc.

 Possible values for 'PreventiveServiceTestStatus' domain include:
   'Completed'     - Take my word for it - this was done.
   'Refused'       - Patient refused service
   'Ordered'       - Clinician ordered test but who knows
                   - if the patient got it done.

 'obsDateTime' is the Date/Time the PreventiveService was done.
 (Will be used to populate stringHeader->eventDateTime and becomes
  the event_start_gmtime)
 This will need to be collected as a fuzzy type of date.
 The date this PreventiveServiceEvent is created and documented
 is in actionsInfo
 If this is really optional, the PreventiveHistoryEvent will
 lose its value for supporting Reminders.

QuantitativeMicroResult:

DEFINITION:
 means 0 to many
 means 0 to many
OTHER NOTES:
 New domain, should contain quantitative terms like 1+, 2+
 Concept 'QuantitativeLabCodedValues': Ncid is 119265UL2 , Rsid is 3886633UL2

NumericQuantGrowthObs:

OTHER NOTES:
 Concept 'NumericQuantGrowthObsId': Ncid is 119267UL2 , Rsid is 3886625UL2
 Domain QuantitativeGrowthUnits is new,
 should contain members like CFU (Colony Forming Units), CFU/ml

RangeQuantGrowthObs:

OTHER NOTES:
 Concept 'RangeQuantGrowthObsId': Ncid is 119268UL2 , Rsid is 3886636UL2

QuantitativeGrowthObs:

DEFINITION:
 A quantitative growth observation can be:
 descriptive, eg. 1+, 2+, heavy, light (QuantitativeLabCodedValues),
 or numerical, eg. 10000 CFU (NumericQuantGrowthObs),
 or a range, eg. 10000 to 20000 CFU (RangeQuantGrowthObs)

QualitativeMicroResult:

OTHER NOTES:
 New domain, should contain qualitative terms like clumps
 Concept 'QualitativeLabCodedValues': Ncid is 119266UL2 , Rsid is 3886629UL2

MicrobioSlideObservation:

DEFINITION:
 MicrobioSlideObservation holds the observations from the slide exam,
 eg. 3+ Gram positive cocci
OTHER NOTES:
 Our customers have not separated out microbio coded values from
 non-microbio coded values,
 so everything has been placed into LabCodedValues 1050
 We'll create four subdomains under it,
 AggregateLabCodedValues to hold "compound" sentences
 like 3+ G+ Cocci in clumps,
 SlideObsValues to hold decomposed, clinically important results of slide exams
 like G+ Cocci, WBC;
 QualitativeLabCodedValues to hold decomposed qualitative modifiers like "clumps",
 and QuantitativeLabCodedValues to hold decomposed quantitative modifiers like 3+.
 AggregateLabValueCodes has three subdomains under it, NonNegationLabValueCodes,
 NegationLabValueCodes, and NegationMicroorganisms.
 AggregateLabCodedValues will hold codes that needs to be decomposed,
 eg. "1+ G+ Cocci", "No WBC", "No Staph. Aureus".
 The 3 codes are in the subdomains NonNegationLabValueCodes,
 NegationLabValueCodes, and NegationMicroorganisms respectively.
 "1+ G+ Cocci" will be decomposed into
 1+ in the QuantitativeLabCodedValues domain,
 and G+ Cocci in the SlideObsValues domain.
 QuantitativeLabCodedValues domain will hold anything that pertains to amount.
 QualitativeLabCodedValues domain holds qualitative modifiers
 including biochemical and other non-quantitative characteristics
 of microorganisms like beta-lactamase testing, color, motility etc.
 NegationMicroorganism will hold the codes from customers that have
 negations and microorganisms, eg. No Staph. Aureus,
 that can be decomposed into No (1023) and a microorganism.
 The ncid of No (1023) is stored as the value of negation,
 which is expecting an ncid from the domain of Negation.
 NegationLabValueCodes is used similarly for things like "No WBC"
 that has negation but not against microroganisms.
 We need two different negation domains because microorganisms and
 slide exam results are stored in different ASN1 structures.
 Concept 'SlideObsValues': Ncid is 115026UL2 , Rsid is 3865795UL2
 When a code containing a negation is received,
 eg. No G+ Cocci or Negative for G+ Cocci,
 it should be decomposed into No (ncid 1023) and G+ Cocci
 So whenever one of the results of a decomposition is ncid 1023,
 negation is to be used.
 Contain quantitative slide exam results like 1+, 2+ or numeric data
 such as ">25".
 Contain qualitative slide exam results like clumps

SlideExamResult:

OTHER NOTES:
 Domain SlideExams is new, it will be a subdomain under ObservationId (552)
 Its members will be the LOINC items pertaining to different stain procedures
 Eg. MICROSCOPIC OBSERVATION:PRID:PT:XXX:QL:GRAM STAIN
 Concept 'SlideExams': Ncid is 119263UL2 , Rsid is 3886641UL2
 notes in labrec.SlideExamResult
 domain, ncid 1049

MicrobioHeader:

OTHER NOTES:
 universalServiceIdent in OBR-1
 MicrobioObsBatId is a new domain of microbiology test names,
 eg. urine culture, blood culture
 It will also be a subdomain under SpecificLabTest (600)
 From OBR-1.
 From OBR-1.
 observationDateTime in OBR-1;
 Use this for specimen collection time
 technician in OBR-1.
 fillersFieldNumber1 in OBR-1.
 cultureModifiers in ZBR-4;
 Most customers do not separate out microbio comments from non-microbio lab comments,
 so, instead of making this another domain just use LabCodedComments 1049
 Made specimen required in microbio

SusceptibilityInterpretation:

DEFINITION:
 Domain SusceptibilityResults is new
 Members will be Sensitive, Intermediate, Resistant, Very Sensitive, Very Resistant
OTHER NOTES:
 Concept 'SusceptibilityResults': Ncid is 119277UL2 , Rsid is 3886648UL2

NumericDrugConcentration:

OTHER NOTES:
 Concept 'NumericDrugConcentrationId': Ncid is 119279UL2 , Rsid is 3886623UL2
 Domain ConcentrationUnits is ncid 1580

StringDrugConcentration:

OTHER NOTES:
 Concept 'StringDrugConcentrationId': Ncid is 119280UL2 , Rsid is 3886644UL2

DiameterSuppressedGrowth:

OTHER NOTES:
 New terminal concept 'DiameterSuppressedGrowthId'
 Concept 'DiameterSuppressedGrowthId': Ncid is 119278UL2 , Rsid is 3886576UL2
 Domain LengthUnits is ncid 1571

KirbyBauerSusceptibility:

DEFINITION:
 There will be a new domain KBExams, which will be a subdomain under ObservationId (552).
 KBExams will contain the LOINC procedures for microorganism susceptibility with KB as method
 Eg. AMPICILLIN SUSCEPTIBILITY:PRID:PT:XXX:QL:KIRBY BAUER
 There will be another new domain called SusceptibilityTestDrugs,
 which contains the antibiotics used in susceptibility testing, eg. ampicillin.
  There is a one-to-one relationship ("uses") between a LOINC procedure in the KBExams domain
 and an antibiotic in the SusceptibilityTestDrugs domain, for instance,
 between the LOINC procedure example and the antibiotic example above.
 The members of the SusceptibilityTestDrugs domain are expected to be Ingredient and
 Salted Ingredient.  When a LOINC procedure uses a combination of antibiotics,
 eg. Sufamethazole/Trimethoprim, which is like a "combination ingredient" not in the dictionary,
 a new concept for it will be created and placed in the SusceptibilityTestDrugs domain.
 HasIngredient (1273) relationships between this new concept and its component ingredients
 will also be created.
OTHER NOTES:
 Concept 'KBExams': Ncid is 119273UL2 , Rsid is 3886590UL2
 SusceptibilityInterpretation contains the result of susceptibility testing,
   eg.  Sensitive, Intermediate, Resistant
 In anticipation of handling route specific susceptibility testing in the future
 TestingDrugConcentration contains the concentration of the testing drug or drugs

KirbyBauerSusceptSet:

DEFINITION:
 To date, the methods used in microbiology susceptiblity testing are
 Kirby Bauer (KB), Minimum Inhibitory Concentration (MIC),
 Minimum Bactericidal Concentration (MBC), and Synergy testing.
 KB is done by seeing whether the diameter of suppressed bacterial growth
 on a disc impregnated with the testing drug, at a particular drug
 concentration, exceeds a predetermined threshold
 (for resistance, susceptibility, intermediate status).
 MIC and MBC use a serial dilution method,
 by putting the bacteria in tubes containing different concentrations of the
 testing drug and seeing which ones stay clear (bacteria growth inhibited).
 For MIC, the minimum concentration that inhibits growth is then
 compared to a predetermined threshold.
 MBC is done by checking all the clear tubes (no growth) to see which ones
 actually killed the bacteria as opposed to merely stopping its growth.
 The minimum concentration that kills the bacteria is then compared to a
 predetermined threshold.
 Synergy testing determines whether the addition of a second antibiotic will
 increase or decrease the susceptibility to a first antibiotic.
OTHER NOTES:
 New terminal concept 'KirbyBauerSusceptGroup'
 Concept 'KirbyBauerSusceptGroup': Ncid is 119269UL2 , Rsid is 3886592UL2

SerialDilutionInstrument:

DEFINITION:
 Domain DilutionInstruments is new, should contain members like Autobac, Vitec and Microscan,
 which are commercial instruments used in MIC and MBC testing
OTHER NOTES:
 Concept 'DilutionInstruments': Ncid is 119281UL2 , Rsid is 3886578UL2

MinInhibitorySusceptibility:

DEFINITION:
 Similar to the case for Kirby Bauer, there will be a new domain MICExams,
 which will also be a subdomain under ObservationId (552). MICExams will
 contain the LOINC procedures for microorganism susceptibility with MIC as method.
 Eg. AMPICILLIN SUSCEPTIBILITY:PRID:PT:XXX:QL:MIC
 Again, there is a one-to-one relationship ("uses") between a LOINC procedure
 in the MICExams domain and an antibiotic in the SusceptibilityTestDrugs domain
OTHER NOTES:
 Concept 'MICExams': Ncid is 119274UL2 , Rsid is 3886598UL2

MinInhibitorySusceptSet:

OTHER NOTES:
 New terminal concept 'MinInhibitorySusceptGroup'
 Concept 'MinInhibitorySusceptGroup': Ncid is 119270UL2 , Rsid is 3886611UL2

MinBactericidalSusceptibility:

DEFINITION:
 Similarly, there will be a new domain MBCExams,
 which will also be a subdomain under ObservationId (552). MBCExams will
 contain the LOINC procedures for microorganism susceptibility with MBC as method.
 Eg. AMPICILLIN SUSCEPTIBILITY:PRID:PT:XXX:QL:MBC
 Again, there is a one-to-one relationship ("uses") between a LOINC procedure
 in the MBCExams domain and an antibiotic in the SusceptibilityTestDrugs domain
OTHER NOTES:
 Concept 'MBCExams': Ncid is 119275UL2 , Rsid is 3886596UL2

MinBactericidalSusceptSet:

OTHER NOTES:
 New terminal concept 'MinBactericidalSusceptGroup'
 Concept 'MinBactericidalSusceptGroup': Ncid is 119271UL2 , Rsid is 3886608UL2

SynergySusceptibility:

DEFINITION:
 Similarly, there will be a new domain SynergyExams,
 which will also be a subdomain under ObservationId (552). SynergyExams will contain the
 LOINC procedures for microorganism susceptibility with Synergy Testing as method.
 Eg. AMPICILLIN SUSCEPTIBILITY:PRID:PT:XXX:QL:Synergy Testing
 Again, there is a one-to-one relationship ("uses") between a LOINC procedure
 in the SynergyExams domain and an antibiotic in the SusceptibilityTestDrugs domain
OTHER NOTES:
 Concept 'SynergyExams': Ncid is 119276UL2 , Rsid is 3886652UL2

SynergySusceptSet:

OTHER NOTES:
 New terminal concept 'SynergySusceptGroup'
 Concept 'SynergySusceptGroup': Ncid is 119272UL2 , Rsid is 3886653UL2

HL7SubIdObs:

DEFINITION:

OTHER NOTES:
 Concept 'HL7SubIdObsId': When there are both preliminary and final results
 This is the HL7 subId

MicrobioObservation:

HL7 MAPPING:
 organismName from labrec.ZMC
OTHER NOTES:
 Domain Microorganisms is new
 Concept 'Microorganisms': Ncid is cidMicroorganisms, Rsid is rsidMicroorganisms
 6/28/2000 bjb alter Term Microorganisms to Domain MicrobioResults to allow
 interface to send Preliminary and Final Results in the same HL7 message
 We were loosing data by rigidly allowing only one category.
 The domain of LabValueCodes will have to contain a subdomain
 called NegationMicroorganisms to hold the codes from customers
 that have negations and microorganisms, eg. No Staph. Aureus,
 that can be decomposed into No (1023) and a microorganism from the
 Microorganisms domain.
 Domain, ncid 1049
 QuantitativeGrowthObs from ZMC describes the amount of growth
 QualitativeMicroResult describes the non-quantitative growth observations,
 eg. motility, color, morphology, fermentation, beta lactamase reaction

AdminInfoObs:

OTHER NOTES:
 I have no idea what domain this is really supposed to be,
 Values are Internal, External, specific relSFormNumId Domain?

MultiMediaImageHeader:

OTHER NOTES:
  The domain MultiMediaImageObsBatId has as members MMIImageObsBatId, ClinicalImageObsBatId,
  and LabImageObsBatId
  The clinObs in the header represent administrative clinObs
  The AdminInfoObs is a new clinObs representing where the
  the original image was created:  either internal or external

OriginationDateObs:

OTHER NOTES:
  New ObsMod
  Orgination Date is the date the image was created.

ReceivedDateObs:

OTHER NOTES:
  New ObsMod
  Received Date is the date the image was scanned and entered into
  this system

AnnotationObs:

OTHER NOTES:
  Existing observation NameObs
  Will not  change the definition
  Will fit the author name into the current definition

MultiMediaImageObs:

OTHER NOTES:
  The domain MultiMediaId has for its members the following types of specific scanned images:
  DriversLicense, SocialSecurityCard, WoundPicture, ScannedLabResults, DoctorNote, etc
  NameObs is an existing ObsMod Already defined in
  FamHistoryRelativeInfo.  A new obsId will be created
  to support a NameType of author
  Existing ObsMod

MultiMediaImageEvent:

OTHER NOTES:
  Notation
  *  0-many (Optional)
  %  0-1 (Optional)
  +  1-many
  The MultiMediaImageEvent stores images and relevent information associated with either
  an MMI record (Demographic Information), and Encounter Record, Clinical Note, or
  StandardLabData.  Examples of images stored within this event
  are drivers's license, medical card, doctor's note, wound picture,,
  and living wills.

OrderControlObs:

DEFINITION:
 means 0 to many
 means 0 to many
HL7 MAPPING:
 ORC.1 Order Control

PlacerGroupNumberObs:

HL7 MAPPING:
 ORC.4 Placer Goup Number

ResponseFlagObs:

HL7 MAPPING:
 ORC.6 Response Flag

PlacerNumberObs:

HL7 MAPPING:
 ORC.8.1.1 Parent

FillerNumberObs:

HL7 MAPPING:
 ORC.8.2.1 Parent

AQuantityTimingObs:

HL7 MAPPING:
 ORC.7 QuantityTiming
 ORC.7.1 T/Q Quantity
 ORC.7.2 T/Q Interval
 ORC.7.3 T/Q Duration
 ORC.7.3 T/Q Duration
 ORC.7.4 T/Q StartDate
 ORC.7.5 T/Q EndDate
 ORC.7.6 T/Q Priority
 ORC.7.7 T/Q Condition
 ORC.7.8 T/Q Text
 ORC.7.9 T/Q Conjunction
 ORC.7.10 T/Q OrderSequence

QuantityTimingsObs:

HL7 MAPPING:
 ORC.7 QuantityTiming

OrderParentObs:

HL7 MAPPING:
 ORC.8 Parent

CallBackPhoneObs:

HL7 MAPPING:
 ORC.14 Call Back Phone Number
 OBR 17 Call Back Phone Number

OrderEffectiveTimeObs:

HL7 MAPPING:
 ORC.15 OrderEffectiveTime

OrdCntlReasonObs:

HL7 MAPPING:
 ORC.16.1 Order Control Reason

SpecActionCodeObs:

HL7 MAPPING:
 OBR.11 Specimen Action Code

DangerCodeObs:

HL7 MAPPING:
 OBR.12.1 Danger Code

RelClinicalInfoObs:

HL7 MAPPING:
 OBR.13 Relevant Clinical Info

TransportationModeObs:

HL7 MAPPING:
 OBR 30  TransportationMode 

ReasonforStudyObs:

HL7 MAPPING:
 OBR 31.1 Reason for Study

XportArrangeResponsibilityObs:

HL7 MAPPING:
 OBR 40.1 Transport Arrangement Responsibility

XportArrangedObs:

HL7 MAPPING:
 OBR 41 Transport Arranged

EscortRequiredObs:

HL7 MAPPING:
 OBR 42 Escort Required

PlannedPatXportCommentsObs:

HL7 MAPPING:
 OBR 43.1 Planned Patient Transport Comment

DiagOrderObs:

HL7 MAPPING:
 obsId                OBR.4.1 Universal Service Identifier
 status               OBR.25 Result Status
   comments  OBR NTE's Comments 
 OBR 27.1  Quantity/Timings 

DietServicePeriodObs:

HL7 MAPPING:
 ODS.2 Service Period

DietSupplementPreferenceObs:

HL7 MAPPING:
 ODS.3 Diet, Supplement, or Preference Code

DietaryOrderObs:

HL7 MAPPING:
   obsId ODS.1 Type
   comments  Comment Text Comment Text 
   comments  ODS Text ODS Text 

DietaryTrayObs:

HL7 MAPPING:
   obsId ODT.1 Tray Type
   comments  Comment Text Comment Text 
   comments  ODT Text ODT Comments 

RequisitionLineNoObs:

HL7 MAPPING:
 RQD.1 Requisition Line Number

DeptCostCenterObs:

HL7 MAPPING:
 RQD.7 Dept. Cost Center

ItemNaturalAccountCodeObs:

HL7 MAPPING:
 RQD.8 Item Natural Account Code

SupplyDeliverToIDObs:

HL7 MAPPING:
 RQD.9 Deliver To ID

SupplyDateNeededObs:

HL7 MAPPING:
 RQD.10 Date Needed

StockOrderObs:

HL7 MAPPING:
   obsId RQD.2 Item Code - Internal
   obsId RQD.3 Item Code - External
   obsId RQD.4 Hospital Item Code
   obsValue RQD.5 Requisition Quantity
   obsValue RQD.6 Requisition Unit of Measure
   comments  Comments Text Comments 

AnticipatedPriceObs:

HL7 MAPPING:
 RQ1.1 Anticipated Price

ManufacturedIDObs:

HL7 MAPPING:
 RQ1.2 Manufactured ID

ManufacturersCatalogObs:

HL7 MAPPING:
 RQ1.3 Manufacturer's Catalog

VendorIDObs:

HL7 MAPPING:
 RQ1.4 Vendor ID

VendorCatalogObs:

HL7 MAPPING:
 RQ1.5 Vendor's Catalog

TaxableObs:

HL7 MAPPING:
 RQ1.6 Taxable

SubstituteAllowedObs:

HL7 MAPPING:
 RQ1.7 Substitute Allowed

NonStockOrderObs:

HL7 MAPPING:
   comments  Comments Comments 

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)

OrderEvent:

HL7 MAPPING:
 ORC.10 Entered By->ActionsInfo
 ORC.11 Verified By->ActionsInfo
 ORC.12 Ordering Provider->ActionsInfo
 ORC.13 Enter's Location->ActionsInfo


 fillerOrderNumber    ORC.2 Filler Order Number
 placerOrderNumber    ORC.3 Placer Order Number
 testStatus           ORC.5 Test Status
 obsDateTime          ORC.9 Transaction Date 
OTHER NOTES:
 The Following show as 0 to many, but at least 1 of the first 5 must be present, and
 the first 5 are mutually exclusive.
 Many combinations don't make sense or are not allowed in HL7

SignatureSnapShotObs:

DEFINITION:
 means 0 to many
 means 0 to many
OTHER NOTES:
 means 1 to many
 means 1 to many

PKCCouplerDBRevisionNumObs:

DEFINITION:
 means 0 to many
OTHER NOTES:
 means 1 to many

ProblemHeader:

OTHER NOTES:
 The values to be stored in obsBatId are the immediate children of Problem (30789),
 which is either Diagnosis (105328), MedicalProcedure (82750), or
 FamilyHistory (105329).
 When it is a diagnosis:  the ncid of the PatDatumObject is ProblemEvent (90803),
 the obsBatId is Diagnosis (105328), the ClinicalObservation subtype is
 FindingsObs (new), the obsId is Diagnosis (105328), the obsValue is the actual
 diagnosis, eg. Diabetes or Chest Pain.
 When it is a family history:  the ncid of the PatDatumObject is ProblemEvent (90803),
 the obsBatId is FamilyHistory (105329), the ClinicalObservation subtype is
 FamilyHistoryObs (new), the obsId is FamilyHistory (105329), the obsValue is the
 diagnosis, eg. Diabetes or Chest Pain, of the patient's relative.
 When it is a procedure:  the ncid of the PatDatumObject is ProblemEvent (90803),
 the obsBatId is MedicalProcedure (82750), the ClinicalObservation subtype is
 ProcedureObs (new), the obsId is MedicalProcedure (82750), the obsValue is the actual
 procedure, eg. Appendectomy.
 ProblemStatus is a domain, ncid 90808, no children currently.
 PatientProblemComment is a domain, ncid 90778
 PatProblemAggObs is a domain, ncid 90786

ProblemEvent:

OTHER NOTES:
 This specialization requires that values within clinObs must
 not only be stored in subtypes of ClinicalObservation, but must be
 added as items in the Problem domain (30789) before they can
 legally be used as part of a ProblemEvent
 The values to be stored in obsId are the immediate children of Problem (30789),
 which is either Diagnosis (105328), MedicalProcedure (82750) or
 FamilyHistory (105329).
 Diagnosis inclues findings - signs, symptoms, lab results.
 FamilyHistory is a terminal node, not a domain, as any diagnosis
 can potentially be a family history.
 There may need to be additional domain(s) in the future for behavioral or social problems
 like alcoholism or drug abuse, or environmental or occupational problems like
 exposures to lead, mercury, etc., for now they are all included in Diagnosis (105328).
 So really Diagnosis can be defined as "Not a Procedure"!

RawMedcinPrefixObs:

DEFINITION:
 means 0 to many
OTHER NOTES:
 means 1 to many

RawMedcinObs:

DEFINITION:
 A structure for specifying a Medication and its associated administration information
OTHER NOTES:
 Terminal concept 'MedcinId': Ncid is cidMedcinId, Rsid is rsidMedcinId

 Since we do not want to add members of the reminder hierarchy to the 'PharmacyItem'

 All integer types are 32bit unsigned long.
 All string types are variable length and support up to 2000 bytes.

RawMedcinDataEvent:

DEFINITION:
 The RawMedcinDataEvent structure is intended to hold 'raw' Mecdin data.
 This is clinical information created using the Medcin tools.  Information
 is stored 'as is' meaning that it is not translated into standard CI CDR data
 structures and types.  Essentially, this structure allows Medcin data
 to be stored physically in the CI CDR even though it is not in a form which
 the CI CDR can 'understand' and do logic against.  The only benefit for
 storing this data in the CI CDR is that no coding was required to support
 data storage and retrieval.  Logically, this data will still 'act' as though
 it were in a completely separate database was is not even interfaced into
 the CI CDR.
OTHER NOTES:
 The patient identification information is contained in the stringHeader which
 is common to all events.  Both MPI number and encounter number can be specified.
 The 'pid' field in the sample 'chart' database would map to MPI and encounter number.

 Terminal concept 'RawMedcinData': Ncid is 14516239UL2 , Rsid is 14581065UL2

 The obsDataTime should be set to the time the Medcin Data was originally gathered.

 Each row in the sample 'chart' table will be an occurrence of the MedcinObs
 in this event.

BPMeasureInstrumentObs:

DEFINITION:
 means 0 to many
OTHER NOTES:
 Concept 'BloodPressureMeasureInstrument': Ncid is 114020UL2 , Rsid is 3859446UL2

BPMeasureMethodObs:

OTHER NOTES:
 Concept 'BloodPressureMeasureMethod': Ncid is 1981UL2 , Rsid is 68282UL2

PatBreathingPhaseObs:

OTHER NOTES:
 Concept 'PatientBreathingPhase': Ncid is 1982UL2 , Rsid is 68283UL2

HRCharacteristicsRhythmObs:

OTHER NOTES:
 Concept 'HeartRateCharacteristicsRhythm': Ncid is 2052UL2 , Rsid is 68350UL2

HRMeasureInstrumentObs:

OTHER NOTES:
 Concept 'HeartRateMeasureInstrument': Ncid is 114022UL2 , Rsid is 3859458UL2

RRMeasureMethodObs:

OTHER NOTES:
 Concept 'RespRateMeasureMethod': Ncid is 2127UL2 , Rsid is 68425UL2

RRMeasureInstrumentObs:

OTHER NOTES:
 Concept 'RespRateMeasureInstrument': Ncid is 114023UL2 , Rsid is 3859460UL2

TempMeasureInstrumentObs:

OTHER NOTES:
 Concept 'TemperatureMeasureInstrument': Ncid is 2156UL2 , Rsid is 68454UL2

TempMeasureMethodObs:

OTHER NOTES:
 Concept 'TemperatureMeasureMethod': Ncid is 2157UL2 , Rsid is 68455UL2

TemperatureObs:

OTHER NOTES:
 Concept 'TemperatureId': Ncid is 2154UL2 , Rsid is 68452UL2

SystolicBPObs:

OTHER NOTES:
 Concept 'SystolicBPId': Ncid is 1985UL2 , Rsid is 68286UL2
 Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2

DiastolicBPObs:

OTHER NOTES:
 Concept 'DiastolicBPId': Ncid is 1976UL2 , Rsid is 68277UL2
 Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2

HeartRateObs:

OTHER NOTES:
 Concept 'HeartRateId': Ncid is 2051UL2 , Rsid is 68349UL2
 Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2

RespiratoryRateObs:

OTHER NOTES:
 Concept 'RespiratoryRateId': Ncid is 2124UL2 , Rsid is 68422UL2
 Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2

VitalSignsEvent:

OTHER NOTES:
 Concept 'VitalSignsBatteryId': Ncid is 110669UL2 , Rsid is 3000230065UL2

BSAMeasureMethodObs:

DEFINITION:
 means 0 to many
OTHER NOTES:
 Concept 'BSAMeasurementMethod': Ncid is 2151UL2 , Rsid is 68449UL2

BodySurfaceAreaObs:

OTHER NOTES:
 Concept 'BSAId': Ncid is 114028UL2 , Rsid is 3860872UL2

HeightWeightEvent:

OTHER NOTES:
 Concept 'HeightWeightId': Ncid is 110670UL2 , Rsid is 3000230067UL2

OrthostaticSystolicBP2Obs:

DEFINITION:
 means 0 to many
OTHER NOTES:
 means 1 to many

OrthostaticSystolicBPObs:

OTHER NOTES:
 Concept 'SystolicBPId': Ncid is 1985UL2 , Rsid is 68286UL2
 Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2

OrthostaticDiastolicBPObs:

OTHER NOTES:
 Concept 'DiastolicBPId': Ncid is 1976UL2 , Rsid is 68277UL2
 Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2

OrthostaticHeartRateObs:

OTHER NOTES:
 Concept 'HeartRateId': Ncid is 2051UL2 , Rsid is 68349UL2
 Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2

OrthostaticRespiratoryRateObs:

OTHER NOTES:
 Concept 'RespiratoryRateId': Ncid is 2124UL2 , Rsid is 68422UL2
 Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2

OrthostaticVitalsEvent:

OTHER NOTES:
 Concept 'OrthostaticVitalsId': Ncid is 110676UL2 , Rsid is 3000230071UL2

ResultInterpretationObs:

DEFINITION:
 Additional Information and interpretation about the result of this test
HL7 MAPPING:
   setId      OBX.1   Set Id
   "CE"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue OBX.5     Observation ValuE

ResultAmendmentHistoryObs:

DEFINITION:
 Additional Information and interpretation about the result of this test
HL7 MAPPING:
   setId      OBX.1   Set Id
   "CE"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue OBX.5     Observation ValuE

CertifiedDateTimeObs:

DEFINITION:
 Information about the date/time that the result was verified
HL7 MAPPING:
   setId		OBX.1	Set Id
   "CE"        OBX.2   ValuE Type
   obsId		OBX.3.1	Observation Identifier
				   First Component is used to link this obsMod back to Parent ClinicalObservation
				OBX.3.2	Observation Identifier
				   Second Component uniquely identifies this obsMod
				OBX.4	Sub-Id
				  Sub-Id is used to link this obsMod back to Parent ClinicalObservation
   obsValue	OBX.5   Observation ValuE
   obsValue OBX.5      Observation ValuE

PerformingLabIENObs:

DEFINITION:
 Information about the actual lab performing the test
HL7 MAPPING:
   setId		OBX.1	Set Id
   "CE"        OBX.2   ValuE Type
   obsId		OBX.3.1	Observation Identifier
				   First Component is used to link this obsMod back to Parent ClinicalObservation
				OBX.3.2	Observation Identifier
				   Second Component uniquely identifies this obsMod
				OBX.4	Sub-Id
				  Sub-Id is used to link this obsMod back to Parent ClinicalObservation
   obsValue	OBX.5   Observation ValuE
   obsValue OBX.5      Observation ValuE

PerformingLabDisclosureObs:

DEFINITION:
 Information about the actual lab performing the test
HL7 MAPPING:
   setId      OBX.1   Set Id
   "CE"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue OBX.5     Observation ValuE

BloodGroupObs:

DEFINITION:
 A blood group is an classification of blood based on the presence
 or absence of inherited antigenic substances on the surface of red blood cells (RBCs).
 These antigens may be proteins, carbohydrates, glycoproteins or glycolipids,
 depending on the blood group system, and some of these antigens are also present on the surface
 of other types of cells of various tissues.
 NOT USED - Included for completeness and/or future use
HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Universal Service Identifier
   obsValue    OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

BloodRhObs:

DEFINITION:
 Rhesus blood group system refers to the five main Rhesus antigens
 (C, c, D, E and e) as well as the many other less frequent Rhesus antigens
 NOT USED - Included for completeness and/or future use
HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

BloodGroupAndRhObs:

DEFINITION:
 Combination of Rh and Blood Group; stored as combination when not possible
 to deconstruct incoming data
HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

AntibodyScreenObs:

DEFINITION:
 Antibody screening tests are done to detect antibodies against red blood cells.
HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

AntibodyTiterResultObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "NM"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   comments    OBX NTE's Comments 

AntibodyTiterObs:

DEFINITION:
 Antibody titers are done to detect quatities of antibodies present
HL7 MAPPING:
   setId      OBX.1   Set Id
   "CE"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue OBX.5     Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

AutologousDonationObs:

DEFINITION:
 Was the donation by the patient to be given to himself/herself?
HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

DirectCoombsObs:

HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   abnFlag     OBX.8   Abnormal Flag
   refRange    OBX.7   Reference Range
   status      OBX.11  Status
   comments    OBX NTE's Comments 

RequiredBBOrderDataObs:

DEFINITION:
 Information gathered at Order time necessary to process BloodBank request
HL7 MAPPING:
   setId      OBX.1   Set Id
   "ST"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

CollectSampleObs:

DEFINITION:
 Information about the actual specimen being tested
HL7 MAPPING:
   setId		OBX.1	Set Id
   "CE"        OBX.2   ValuE Type
   obsId		OBX.3.1	Observation Identifier
				   First Component is used to link this obsMod back to Parent ClinicalObservation
				OBX.3.2	Observation Identifier
				   Second Component uniquely identifies this obsMod
				OBX.4	Sub-Id
				  Sub-Id is used to link this obsMod back to Parent ClinicalObservation
   obsValue	OBX.5   Observation ValuE
   obsValue OBX.5      Observation ValuE

PerformedPriorityObs:

DEFINITION:
 Information about the priorty to perform the result
HL7 MAPPING:
   setId		OBX.1	Set Id
   "CE"        OBX.2   ValuE Type
   obsId		OBX.3.1	Observation Identifier
				   First Component is used to link this obsMod back to Parent ClinicalObservation
				OBX.3.2	Observation Identifier
				   Second Component uniquely identifies this obsMod
				OBX.4	Sub-Id
				  Sub-Id is used to link this obsMod back to Parent ClinicalObservation
   obsValue	OBX.5   Observation ValuE
   obsValue OBX.5      Observation ValuE

BloodProductTypeObs:

HL7 MAPPING:
   setId       OBX.1   Set Id
   "CE"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   comments    OBX NTE's Comments 

NumberOfUnitsOrderedObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "NM"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

NumberOfUnitsCollectedObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "NM"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

NumberOfUnitsAvailableObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "NM"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

NumberOfUnitsTransfusedObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "NM"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

UnitsCollectedDateTimeObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "TS"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

UnitStatusDateTimeObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "TS"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

ProductUpdateDateTimeObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "TS"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

NumberOfUnitsIssuedObs:

HL7 MAPPING:
   setId      OBX.1   Set Id
   "NM"       OBX.2   ValuE Type
   obsId      OBX.3.1 Observation Identifier
   obsValue   OBX.5   Observation ValuE

BloodProductOrderObs:

HL7 MAPPING:
   setId       OBX.1   Set Id
   "ST"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   status      OBX.11  Status
   comments    OBX NTE's Comments 

BloodProductHistoryObs:

HL7 MAPPING:
   setId       OBX.1   Set Id
   "ST"        OBX.2   ValuE Type
   obsId       OBX.3.1 Observation Identifier
   obsValue    OBX.5   Observation ValuE
   status      OBX.11  Status
   comments    OBX NTE's Comments 

DoDBloodBankEvent:

HL7 MAPPING:

 obsBatId             OBR.4.1 Universal Service Identifier
 fillerOrderNumber    OBR.2 Filler Order Number
 placerOrderNumber    OBR.3 Placer Order Number
 status               OBR.25 Result Status
 obsDateTime          OBR.7 Transaction Date 
 comments  OBR NTE's Comments 
 Specimen             OBR.15 Specimen Source