DEFINITION:
Labdata.a1 contains the data structure for standard laboratory data.
This is laboratory data that is non-Microbiology data. It is composed
of a header portion and the results portion. These are detailed in
the sections that describe header and results.
In general, laboratory data is acquired on the HEMS product through an
interface to a laboratory interface system.
EXAMPLES:
Examples of laboratory data that are use this data structure are hematology,
chemistry, coagulation, and serology. As stated before microbiology,
anatomic pathology, and blood bank are not handled within this structure.
DATABASE MAPPING:
Patient Event, Observation, Lab_Test, Specimen, Specimen_Descript
HL7 MAPPING:
OBX, OBR, ORC, Segments
OLE MAPPING:
Supported:
OLE data type: CLabData object
ALERT REQUIREMENTS:
Alerts use this data. See specific elements for their use.
DEFINITION:
The laboratory header contains management type data. This includes
information about the test that is done, the type of specimen, various
dates asscociated with the test, test status, who resulted, comments
about the entire test, and text comments about the entire test.
OLE MAPPING:
All supported labDataHeader information is exposed as properties of
the CLabData object
DEFINITION:
The results are a the set of observations,values, flags, normals,
comments, etc that are done as part of a test.
EXAMPLES:
For example the test SMA-7 or CHEM-7 are composed of 7 observations
and their accompanying flags and values : sodium, potassium,
chloride, CO2, blood urea nitrogen, glucose, and creatinine.
OLE MAPPING:
Supported: Get
Property: CLabData::Results
OLE data type: CObservations collection object
DEFINITION:
The test name is required. This is a coded value and represents the type of
of laboratory test that is to be performed. This must be coded
to be considered a valid laboratory test on our system.
EXAMPLES:
Examples of laboratory tests include CBC (complete blood count),
Blood Ammonia Level, Gentamycin Level, Chemistry Panel 7, PT, PTT,
etc.
DATABASE MAPPING:
Lab_Test:Test_Ncid
HL7 MAPPING:
OBR-4 Universal Service Id
OLE MAPPING:
Supported: Get
Property: CLabData::TestName
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Required. The test name (code) is one way that you can use to map data to an
alert object.
DEFINITION:
This is a set of specimen descriptors. See LabSpecimen for
detailed description.
OLE MAPPING:
Not Supported:
DEFINITION:
This is the date and time that the laboratory test as a whole
was "verified". In the clinical laboratory this is when the
technologist reviews the results and "blesses" them. This
step is similar to the verification that may be done by a
pharmacist to a pharmacy order.
This does not seem to be being used or sent to us at this
time.
EXAMPLES:
Once a lab test is received in the lab, say a Chem 7, the
specimen is prepared for analysis, it is then analyzed (the
test performed), the result posted preliminary (at which time
clinicians may have access to the data), then the results are
reviewed by a tech or pathologist, once reviewed they are
verified and the status is changed to final.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currenlty not used.
DEFINITION:
This is the date and time that the result was received on the
the HEMS system. This time is the date and time we store
the lab test.
EXAMPLES:
An example might be that a Chem-7 was collected 10/10/96.13:00,
the analysis done and the test verified 10/10/96.13:30 and received
on the HEMS side at 10/10/96.13:31.
DATABASE MAPPING:
HL7 MAPPING:
Not sent through HL7.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a unique number, which consists of a system ncid (coded) and
and the alphanumeric number. This is the service or facility
that "fills" the order. See clintype.a1 UniqueReferenceId.
EXAMPLES:
An example specific to lab would be the system number for the
clinical lab and their order number respective to the order
that was done.
DATABASE MAPPING:
Lab_Test:Filler_Number
HL7 MAPPING:
OBR-20 Filler Field 1+
OLE MAPPING:
Supported: Get/Set
Property: CLabData::FillerNumber maps to refNum (BSTR)
Property: CLabData::FillerSystem maps to system (CCodedCtrl)
ALERT REQUIREMENTS:
Currently not used specifically by the logic. However,
it is required that either this number or the placer number is
unique so that updates to data strings can be performed.
DEFINITION:
This is a unique number, which consists of a system ncid (coded)
and the alphanumeric number. This number is assigned by the
system responsible for "placing or requesting the order". See clintype.a1
UniqueReferenceId.
EXAMPLES:
An example would be on a legacy HIS a placer number of a Chem-7
would be assigned, the order sent to the lab, the lab assigns the
fillernumber, the results are passed to the LDR with both the
filler and placer numbers. This would link where the order occurred
and how the order was filled.
DATABASE MAPPING:
Lab_Test:Placer_Number
HL7 MAPPING:
OBR-18 Placer Field 1
OLE MAPPING:
Supported: Get/Set
Property: CLabData::PlacerNumber maps to refNum (BSTR)
Property: CLabData::PlacerSystem maps to system (CCodedCtrl)
ALERT REQUIREMENTS:
Currently not used specifically by the logic. However,
it is required that either this number or the placer number is
unique so that updates to data strings can be performed.
DEFINITION:
This is the status of the result as it is being processed by
the laboratory. In general, lab tests start as preliminary
which denotes that the test has not been verified or completed
and then progress to finalized.
EXAMPLES:
Examples of test status include : preliminary, pending, cancelled,
complete, finalized.
DATABASE MAPPING:
Lab_Test:Test_Status_Ncid
HL7 MAPPING:
OBR-25 Result Status +
OLE MAPPING:
Supported: Get
Property: CLabData::TestStatus
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Will be used by Infectious Disease.
DEFINITION:
This is the set of person or persons that are responsible for
either performing the test or verifying the results. This can be
either coded or represented by text.
EXAMPLES:
An example would be that R. Dupont student Tech performs a 24
hour Fecal Fat. S. Harada Pathologist verifies the results and
finalizes the test.
DATABASE MAPPING:
Coded - Resulting_Technician:Technician_Ncid
Not Coded - Resulting_Technician:Technician_Text ????? not in interface document
HL7 MAPPING:
OBR-34 Technician+
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used in logic ... however, if you want to route alert messages
back to persons who are responsible for the posting of values
you would want to code this field.
DEFINITION:
This is a set of comments that are associated with the entire
test.
EXAMPLES:
An example might be that the "Sample Hemolyzed" or
"Quantity Insufficient".
DATABASE MAPPING:
HL7 MAPPING:
NTE Segment ???? this says freetext but interface refers to this
OLE MAPPING:
Supported: Get
Property: CLabData::CodedComments
OLE data type: CCodedComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a set of comments that are not coded by the lab and
are, in general, free text comments regarding the test as
a whole.
EXAMPLES:
An example would be "Nurse Dupont was called and ask to
provide collection time for the sample".
DATABASE MAPPING:
HL7 MAPPING:
NTE ????
OLE MAPPING:
Supported: Get
Property: CLabData::TextComments
OLE data type: CTextComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
See resultingTechnicians.
DEFINITION:
See resultingTechnicians
DEFINITION:
This is a set of specimen descriptors. See LabSpecimen for
detailed description.
DEFINITION:
This is the set of information that describes the specimen.
The descriptors include the type of specimen, times asscociated
with the specimen, who collected the specimen, and comments
asscociated with the specimen.
EXAMPLES:
Examples of a specimen description is a pleural fluid, collected
10/10/96.13:02, received in the laboratory at 10/10/96.13:30,
collected by the physician Dr. D. Brown and R. Dupont RN. Collected
in Radiology with a text comment check for metastatic cells.
DATABASE MAPPING:
Specimen Specimen_Descript
HL7 MAPPING:
OBR
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Future alerts may need to look at specimen descriptors. We should
encourage sites where possible to at least code the sterile body
fluid locations.
DEFINITION:
The date and time that the specimen for testing was collected. This
should be the date and time the blood was drawn or the sample was obtained
from the patient.
EXAMPLES:
Chem-7 drawn 10/10/96.06:00
DATABASE MAPPING:
Specimen:Collection_Start_Gmtime
HL7 MAPPING:
OBR-7 Observation Date/Time
OLE MAPPING:
Supported: Get/Set
Property: CLabData::CollectionDateTime
OLE data type: DATE
ALERT REQUIREMENTS:
Required.
DEFINITION:
The date and time the specimen (sample) was received in the laboratory
for testing.
EXAMPLES:
Chem-7 collected 10/10/96.06:00 received in the laboratory 10/10/96.08:00.
DATABASE MAPPING:
Specimen:Specimen_Received_Gmtime
HL7 MAPPING:
OBR-14 Specimen Received Date/Time
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Required.
DEFINITION:
This is an Ncid that represents a full description of
a body site. This is for sites that cannot represent the parts
of a specimen in atomic representation.
EXAMPLES:
For example, right lower leg would be assigned an ncid instead
of assigning 3 ncids for right, lower, and leg.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Spported:
ALERT REQUIREMENTS:
Not used.
DEFINITION:
This is the set of information that describes a specimen. See
Specimen Descript.
DEFINITION:
This is the person or persons that were responsible for collecting the
specimen. Ideally this should be a coded person, however, the structure
supports text.
EXAMPLES:
specimen collected by R. Dupont, phlebotomist.
DATABASE MAPPING:
Specimen_Collector:Collector_Ncid
HL7 MAPPING:
OBR-10 Collector Identifer Note: in HL7 the collector
can be a person, department, or facility. We currently seem
to only support person. However, facilities seem to be handled
in the collectionLocation portion of this definition.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Not used.
DEFINITION:
CollectionLocation is where the specimen was obtained. This could a
physical location such as a room/bed, nursing Division, service area, buildFloor, or
facility. All of the above are coded. In addition a collection location can
also be a terminal location either coded or text.
EXAMPLES:
An example of this would be a pleural fluid, which might be collected in
the radiology department as a by product of a thoracentesis. This is then
sent to the laboratory for cell counts and culture and sensitivities.
DATABASE MAPPING:
Specimen_Collector:Collector_Ncid?
HL7 MAPPING:
? we think this is OBR-10 however we don't think we support locations?
OLE MAPPING:
Supported: Get
Property: CLabData::CollectionLocation
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
These are coded comments that are relative to the specimen collection.
EXAMPLES:
An example might be a coded comment that translated to "specimen was
difficult to obtain" or "venous draw" or "arterial draw".
DATABASE MAPPING:
Currently not stored in the relational tables.
HL7 MAPPING:
This is not supported in HL7. We have created what is termed a ZTE
which is a 3M segment that supports coded and text comments.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
These are text comments that are relative to the specimen collection.
EXAMPLES:
An example might be "Patient was argumentative during collection of
blood."
DATABASE MAPPING:
Currently not stored in the relational tables.
HL7 MAPPING:
OBR-13 Relevant Clinical Information
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
I don't know what this is
DEFINITION:
See collectors.
DEFINITION:
See collectors.
DEFINITION:
This is the set of data that describes the source of
of the specimen, the quantity, the qualitative, and
quantitative features of the source.
DEFINITION:
See clintype.a1 BodySite.
DEFINITION:
See clintype.a1
DEFINITION:
This is the type of specimen not necessarily related to body site. It should
be noted that the "common" specimen types are included in the LOINC definition of
the test or observation. Therefore, most of the time we will not receive specimen
types for the common lab tests. In situations where body fluids are being tested,
like cell counts etc these will usually have a specimen type.
EXAMPLES:
Examples of this include serum, whole blood, urine, peritoneal fluid, etc.
DATABASE MAPPING:
Specimen_Description:Description_Ncid
HL7 MAPPING:
OBR-15 Specimen Source
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is the method of collecting the specimen. It can be either
coded or represented as free text.
EXAMPLES:
For instance a urine might have been obtained via a suprapubic
catheter.
DATABASE MAPPING:
HL7 MAPPING:
OBR-15 Specimen Source free text portion of the specimen source.
Appears we support coded but not free text.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
The volume of the specimen that was sent to the laboratory for analysis.
EXAMPLES:
An example would be a CSF (Cerebral Spinal Fluid) which might have a volume
of 3 cc (milliliters).
DATABASE MAPPING:
HL7 MAPPING:
OBR-9 Collection Volume. Does not appear to be supported at this time.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a statement of the volume qualitatively NOT quantitatively.
EXAMPLES:
An example might be scant amount of CSF (Cereberal Spinal Fluid).
DATABASE MAPPING:
HL7 MAPPING:
Fuzzy volumes appear not to be supported in HL7 currently.
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
If a specimen is recovered or obtained via a device this area
allows for the recording of this device. Allows for the storage
of the device (coded or text), a model number, and a serial number.
EXAMPLES:
An example of a collection device might be Hickman Catheter.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
See clintype.a1 PathologicLesion
DEFINITION:
This is the color of the specimen that was sent
for analysis.
EXAMPLES:
Examples : urine yellow, peritoneal fluid amber.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is the odor of the sample. Although not commonly commented
on there are certain odors that can be clinically significant.
EXAMPLES:
Commonly when a patient is infected with Pseudomonas aeruginosa
there can be a faint odor of grapes. Also clinicians will often
comment if the specimen had a "foul" odor which might denote
a bacterial process.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currenlty not used.
DEFINITION:
This is a statement as to the viscosity or particulate matter
that may be present in a specimen.
EXAMPLES:
An example might be comments as to a body fluid be thick or
viscous with fine particulate matter.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a comment as to the position of the patient when the specimen
was obtained. There are lab test that are performed once while the
patient is supine (lying on their back) and sitting or standing.
EXAMPLES:
An example of this is serum aldosterone levels which are collected
supine before the patient gets up for the morning and then the
upright sample is collected at least 2 hours after they have been
sitting or standing.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currenlty not used.
DEFINITION:
Often times in laboratory testing a prosthetic device may be sent
for analysis. In general, this is most often done for microbiology
testing. However if the device has a captured level of fluid from
where it was placed the fluid might be extracted and tested.
EXAMPLES:
A penrose drain or shunt is sent to the laboratory for cell analysis.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a set of the valid types of values that may
be asscociated with an observation id.
DEFINITION:
An observation value can be represented as a numeric (decimal,
integer, range (1-5), titer (1:32), another coded (positive,
negative), or a date and time. See observation for primitive
types.
DATABASE MAPPING:
Observation
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Alerts expect valid numerics, ranges, titers, or coded results.
Alert logic cannot use text.
DEFINITION:
Negation is combined with the observation id to produce an
existance statement. See the example below. It is a coded
field.
EXAMPLES:
If you were testing for a serologic finding of Clostridia
difficile toxin you might use negation to make the finding
of NOT Clostridia difficile Toxin. To determine the complete
result you would need to use this node with the observation
id node.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used. Future releases of alerts would require
this node to be coded if logic were to run against a result
that had negation.
DEFINITION:
The numeric operator is a field that is used in conjuction
with a numeric value to denote quantities greater than or
less than some value. See the example below. This is used in
many cases where the testing produces a qualitative rather than
quantitative result.
EXAMPLES:
R. Dupont ICU nurse performs a glucose test on patient S. Schrank,
who is a fragile diabetic. R Dupont uses a glucometer.
Since the pesky glucometer looses sensitivity after 400 mg it
reports the glucose on Mr. Schrank as > 400 mg/dl. The '>' becomes
the numeric operator on our system. This is usually coded on the
Hems system.
DATABASE MAPPING:
Observation:Numeric_Operator_Ncid
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently the alerts only alert on numeric values that do not
have numeric operators. It is therefore very important that a
site always codes the set of numeric operators that will be used.
DEFINITION:
Uncertainty are those "weasel" words that are asscociated
with a lot of qualitative findings. Weasel words being
words like possible, probably, maybe, sort of kind of, etc.
EXAMPLES:
R. Dupont rooky med tech is working late one evening when through
the ER a new patient is seen. The patient has a very very low
white count, < 1.0 mmm/cu. He does a differential on the patient based
on only 25 cells. The cells don't look right...he knows he can't call it...
he needs to turf it to Dr. Huff to validate they are myeloblasts ...
to get the result to the ER he makes the statement on the differential
probable atypical myelocytes ...wah lah weasel word.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
Machine probility is a probability that is arrived at
by a machine. This could be a monitoring device or could
be a probability assigned by alert logic or decision support
software.
EXAMPLES:
?
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a probability that is stated by a person. This
would be paired with the observation id.
EXAMPLES:
An example might be if Dr. Huff, Pathologist was reviewing
a differential (cell count) and identified a myeloblast and
and placed a 95% confidence that it was a myeloblast.
(we try).....
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
Unlike fuzzy bears, fuzzy statements are superlatives. These
are statements like very, best, most, greatest, etc.
EXAMPLES:
Dr. Huff, the greatest Pathologist, is reviewing a differential
that night tech R. Dupont has ask him to review. He sees myeloblasts
they are not typical... he might comment as very atypical
myeloblasts seen.
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
Units are standard quantity used as a measure, such as milligrams for
every decaliter. This is required so that measurements can be
compared within patients and facilitites.
EXAMPLES:
Glucose results are measured in mg/dl (miligrams per decaliter).
DATABASE MAPPING:
Observation:Units_Ncid
HL7 MAPPING:
OBX-6 Units
OLE MAPPING:
Not Supported:
ALERT REQUIREMENTS:
Release 5x of the alerts will allow the matching of units.
Coding of units is required.
DEFINITION:
The results of a laboratory test. See StdLabObservation.
DEFINITION:
This is the set of the observations that constitute a test. It
includes the observaiton code, values, reference ranges,
abnormal flags, delta flags, reporting flags, and observation
specific comments and result status.
EXAMPLES:
A Chem 7 test consists of the following set of observations :
Sodium, Potassium, Chloride, CO2, Blood Urea Nitrogen,
Glucose, and Creatinine.
DATABASE MAPPING:
Observation
HL7 MAPPING:
OBX
OLE MAPPING:
Supported:
Property: ClabData::Results.item()
OLE data type: CObservation object
ALERT REQUIREMENTS:
Observations are used by Critical Lab, Medication Monitoring,
ADEs, and Infectious Disease, there will be more in the future.
They need to be coded and have coded, numeric, range, or titer values.
Text results are not supported.
DEFINITION:
The observation id is the coded (ncid) of the observation. This
represents the analyte that was being tested.
EXAMPLES:
Examples of observation id's include 6164-Creatinine, 6004-Calcium Total,
6343-Glucose, and 7585 Digoxin.
DATABASE MAPPING:
Observation:Observation_Ncid
HL7 MAPPING:
OBX-3 Observation Identifier
OLE MAPPING:
Supported: Get
Property: CObservation::ResultName
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Observations are used by Critical Lab, Medication Monitoring,
ADEs, and Infectious Disease, there will be more in the future.
They need to be coded and have coded, numeric, range, or titer values.
Text results are not supported.
DEFINITION:
This is the measurement of the observation. How much of thing
was there. See ObservationValue and observation.
EXAMPLES:
An example of 6164-Creatinine would be 1.2 mg/dl. The value 1.2
would be stored in value the units mg/dl would be stored in
the units area. See ObservationValue and observation.
DATABASE MAPPING:
Observation:Numeric, Titer_Low Titer_High, Range_Low Range_High, Text_Value,
Numeric_Operator_Ncid, Coded_Ncid
HL7 MAPPING:
OBX-5 Observation ValueX
OLE MAPPING:
Supported: Get
Property: CObservation::CodedValue
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Observations values are used by Critical Lab, Medication Monitoring,
ADEs, and Infectious Disease, there will be more in the future.
They need to be have coded, numeric, range, or titer values.
Text results are not supported. In some cases units may be needed.
DEFINITION:
This is the normal values as sent from the laboratory system. These
are the values that are considered within healthy limits for the person.
They can be based on age, sex, or race. They are usually set per
facility and are based on the patient population and the instrumentation
used to perform the tests. We usually get only free text in this area.
EXAMPLES:
An example would be the hematocrit reference range for a 32 year old female
is 36-42%.
DATABASE MAPPING:
Observation:References_Range
HL7 MAPPING:
OBX-7 References Range
OLE MAPPING:
Supported: Get/Set
Property: CObservation::ReferencesRange
OLE data type: BSTR
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a flag that is placed on a result and is used to communicate
to a clinician if a result is out of the normal reference range.
Usually the flag also trys to communicate the severity of the
difference between the result and the reference range of the result.
These flags should be coded. The flagging of the results is controlled
by the laboratory computer system and is part of clinical laboratories
internal quality control.
EXAMPLES:
A potassium of 2.1 would be flagged low critical. A potassium
of 5.5 might be flagged High. A potassium of 6.7 would be flagged
high critical.
DATABASE MAPPING:
Observation:Abnormal_Flag_Ncid
HL7 MAPPING:
OBX-8 Abnormal Flags
OLE MAPPING:
Supported: Get
Property: CObservation::AbnormalFlag
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Will be used by the Critical Labs Release 5x. Could be used by other
logic in the future.
DEFINITION:
This status is reflects the current completion status of the
results for one observationId. This differs from the testStatus
which defines the current completion for the entire test
which may have multiple observationIds.
EXAMPLES:
A chem-7 is resulted with Sodium 125, Potassium 5.8, Chloride 100,
Urea Nitrogen 32, glucose 92, and CO2 22. The chem-7 is sent again
with each result the same except the Potassium 3.5 with a result status
indicating that the result has been corrected.
DATABASE MAPPING:
Currently not used.
HL7 MAPPING:
OBX-11 Ovserv Result Status. It does not appear that it is supported
by the current interface.
OLE MAPPING:
Supported: Get
Property: CObservation::ResultStatus
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a flag that is placed on a result and is used to communicate
to a clinician if a result has changed significantly from the previous
value. These flags should be coded. The flagging of the results is
controlled by the laboratory computer system and is part of clinical
laboratories internal quality control.
EXAMPLES:
A glucose level has a result of 105; a period of time passes and another
glucose level is drawn with the result of 270. This result gets flagged
with a delta flag that indicates that is value has significantly changed
upward.
DATABASE MAPPING:
Observation:Delta_flag_ncid.
HL7 MAPPING:
OBX-8 Abnormal Flags. This same field is used for both abnormal and
delta flags. The interface specification appear to support delta flags.
OLE MAPPING:
Supported: Get
Property: Cobservation::DeltaFlag
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Currently not used in version 4x. Planned enhancement for version 5x.
will be the use of delta flag for critical labs.
DEFINITION:
This is a coded field that indicates whether a result or observation
should be available for reporting, alerting or display. The flag may indicate
that the result is not publically available due to research, patient
confidentiality, or a number of other reasons.
EXAMPLES:
Often times the result of an HIV test is not publically available and the
results are given person to person only.
DATABASE MAPPING:
Observation:Report_Flag_Ncid
HL7 MAPPING:
OBX-13 User Defined Access Checks But this doesn't look like it is supported
as it is not documented in our interface documentation.
OLE MAPPING:
Supported: Get
Property: CObservation::ReportingFlag
OLE data type: CCodedCtrl
ALERT REQUIREMENTS:
Required by critical labs, medication monitoring, ADEs, Infectious
Disease and possibly future packages. The alerting packages use the
reporting flag to determine whether the result is a candidate to be
used in the alert logic.
DEFINITION:
This is a free text comment that allows the entering of information
relative to the observation.
EXAMPLES:
For example, if a result could only be done once the tech might
post the following "Unable to repeat the result. To validate
send more sample".
DATABASE MAPPING:
HL7 MAPPING:
We believe this comes from the NTE segment maybe??
OLE MAPPING:
Supported: Get
Property: CObservation::TextComments
OLE data type: CTextComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
This is a coded comment. This allows the entering of "canned"
information about the observation.
EXAMPLES:
For example, if a result was done in error you might see a
coded comment of "Result posted in error".
DATABASE MAPPING:
HL7 MAPPING:
OLE MAPPING:
Supported: Get
Property: CObservation::CodedComments
OLE data type: CCodedComments
ALERT REQUIREMENTS:
Currently not used.
DEFINITION:
we don't know what this is
DEFINITION:
obsId has now been added back into this structure.
The 'id' in the INSTANCE-OF-SUBTYPE structure refers
to the ASN1 structure or subtype being used to store
and validate the data. The obsId Ncid identifies the
actual data being stored.
DEFINITION:
The value of the clinical Observation including a ranges, units, time of
observation and any error codes or text.
DATABASE MAPPING:
ClinicalObservation
DATABASE MAPPING:
ClinicalObservation:ReferenceRange
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ClinicalObservation:
DEFINITION:
An html text description of the complete observation. (Can also include other forms
of text such as sgml, rtf or regular text.)
DATABASE MAPPING:
CommentGroup:, CommentItem:, CommentDoc:
DATABASE MAPPING:
ClinicalObservation:Display
DEFINITION:
This is a coded data element that represents a complete representation of the
observation, including the observation name, the observation value, and any
observation modifier. For example: "Patient has coarse rales in the right
upper lobe."
DATABASE MAPPING:
Same as ClinObs.
DATABASE MAPPING:
ClinicalObservation:
DEFINITION:
Format is a Voser stored representation that allows runtime insertion of
variables into the display expression (similar to the "=" in PTXT. A schedule
for implementing this function has not been set, but it will be after
Version 5.0.
DATABASE MAPPING:
ClinicalObservation:
DATABASE MAPPING:
ActionInfo:
DATABASE MAPPING:
ClinicalObservation:HL7_SETID
DEFINITION:
The goal is to unify the representation of all clinical observations as much as
possible. ClinObsHeader is the parent type from which LabDataHeader and
PatObsHeader will be derived.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Should be implemented using semantic links in the future.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Should be implemented using semantic links in the future.
DATABASE MAPPING:
ClinicalEventHeader:
DATABASE MAPPING:
ClinicalEventHeader:
DATABASE MAPPING:
EventHeaderTimeInterval:
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Used for comments for version 5 and later.
DATABASE MAPPING:
CommentGroup:, CommentItem:, CommentDoc:
DEFINITION:
Used first in alerts to distinguish critical lab, meds monitoring
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
The severity of observation. See alert.a1 severity for a discussion
on the severity of alerts and their assigment.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
The value asscociated with a severity. See alert.a1 severityValue
for a discussion on the severity and severity value.
DATABASE MAPPING:
Currently not defined, will be defined in future releases.
DEFINITION:
Where in the install process an alert is, live or test. See
alert.a1 for a complete discussion on productionStatus.
DATABASE MAPPING:
Currently not defined, will be defined in future releases.
DEFINITION:
See AlertKey for a discussion of this field, found in alert.a1.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
See alert.a1 for further discussion of the alert object (AOE).
DATABASE MAPPING:
ClinicalEventHeader:AlertObject
DEFINITION:
Using original alert message as a trigger for other AOEs. See alert.a1
for a discussion on chaining.
DATABASE MAPPING:
ClinicalEventHeader:
DEFINITION:
Used for distribution of the alert messages. See alert.a1 for discussion
on notificaitons.
DATABASE MAPPING:
Notification
DATABASE MAPPING:
ClinicalEventHeader:Display
DATABASE MAPPING:
ClinicaleventHeader:
DATABASE MAPPING:
ClinicalEventHeader:
DATABASE MAPPING:
DisplayOrder:
DEFINITION:
This is a set of unique identifiers which are assigned by the
CAM to identify alert object executables with the triggering
event. It allows the logic that is fired (no matter the number
of aoes) to be linked to the transaction that triggered the
logic.
EXAMPLES:
For instance, a lab result for potassium is stored. This data
is then sent to the alert infrastructure for processing both
the Critical Labs and Medication Monitoring (lab->drug) logic
is executed. These two aoes will share transId (say 1) but have
sequential seq (1, 2). So Critical Labs has the Alert Key 1-1 and
Medication Monitoring Lab->Drug has Alert Key 1-2.
DEFINITION:
The transId is the number used to link the AOEs that are
executed as a result of one trigger event.
EXAMPLES:
If a lab result comes through the CAM it will be given a
transId incremented by one since the last data string that
came through the system.
DATABASE MAPPING:
State_Table:Tx_Id
HL7 MAPPING:
Currently not supported.
OLE MAPPING:
ALERT REQUIREMENTS:
Assigned by the CAM required to link data events to aoes.
DEFINITION:
The number assigned by the CAM to each executable object
that is executed.
EXAMPLES:
One piece of data may trigger several AOEs. The transId
is held steady while the seq is incremented for each AOE
that is executed against the data.
DATABASE MAPPING:
State_Table:Seq_Num
HL7 MAPPING:
Not Currently supported.
OLE MAPPING:
ALERT REQUIREMENTS:
Assigned by the CAM required to link data events to aoes.
DEFINITION:
The name of the AOE (alert object) that was responsible
for creating the alert message. See alert.a1 for complete
description of this item.
DEFINITION:
This is the set of alert destinations/notifications.
DEFINITION:
This is the distribution of the alert message. This set of
information is used to distribute messages to users. Currently
this is done as part of the Alert Management system.
DEFINITION:
desType describes how the DestinationValue was arrived at. For
instance, the DestinationValues may have been arrived at by using
a piece of code that determined the attending physician. It could
also specify that the destination was arrived at by picking a person or
place off a list.
EXAMPLES:
For example, when a Medication Monitoring alert fires and is positive
you may want to send the message to the Attending Doctor and the pharmacy
department. The attending doctor value was arrived at by running logic
that looked in the Encounter role tables for the patient and determined
the Ncid of the atttending doctor. The pharmacy department was arrived at
by picking the department off a list.
DATABASE MAPPING:
Notification:
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
ALERT REQUIREMENTS:
The Alert Management software will fill this field.
DEFINITION:
value (DestinationValue) is the value of the destination. This could be an Ncid
or could be an actual text representation of an e-mail address. In either case
it denotes who or what gets the alert message. It may be arrived at by running
logic that determines a notification list, such as the attending doctor, or
it might be arrived at by picking a place or person from a list.
EXAMPLES:
Examples of what might be in this field include : Ncid of a person or place,
an actual e-mail address.
DATABASE MAPPING:
Notification:
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
ALERT REQUIREMENTS:
The Alert Management software will fill this field.
DEFINITION:
id(NotificationId) is a unique identifier that ties a notification
back to a message. It is possible that a single message may have
multiple notifications.
EXAMPLES:
A patient has a critical high serum potassium, 6.8 meq/L. The
the Critical Lab alerts creates an alert message. The message
is sent to the attending physician, the nursing division, and
the QA department. Each of the notifications will have a unique
identifier that ties it back to the alert message.
DATABASE MAPPING:
Notification:ValueText
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
ALERT REQUIREMENTS:
Created by the Alert Management software.
DEFINITION:
deliverySystem defines how your organization delivers it messages. This, in general,
will be through the HEMS system, however it is possible that one enterprise may
select to use a product such as Groupwise to deliver messages.
DATABASE MAPPING:
Currenlty not defined, will be defined in future releases.
HL7 MAPPING:
Currently not defined.
OLE MAPPING:
Currently not defined, will be defined in future releases.
ALERT REQUIREMENTS:
This field will be filled by the Alert Management software.
DATABASE MAPPING:
Notification:ValueText
DATABASE MAPPING:
Notification:ValueCodedNcid
DATABASE MAPPING:
Notification:ValueText
DATABASE MAPPING:
DATABASE MAPPING:
DATABASE MAPPING:
DEFINITION:
Obsolete. This is the Rel04 style of body location.
LocationDescription stores body site information. This information
is usually collected in physical examination, radiological exams,
anatomic pathology and other information that details the location
of the findings.
EXAMPLES:
Breath sounds are diminished in the right upper quadrant of the lungs.
The leison was found on the left lower leg.
DATABASE MAPPING:
HL7 MAPPING:
????
OLE MAPPING:
ALERT REQUIREMENTS:
Currently not used.
DATABASE MAPPING:
C-1,9,10,11,12,13,14,15,16,18,19
DATABASE MAPPING:
C-11 will be one occurrence of this SET
C-12 will be one occurrence of this SET
C-19 will be one occurrence of this SET
DEFINITION:
The ID of the clinician who performed the action.
This may be the same as the 'enteredBy' persion.
DEFINITION:
Related to ORC-1 in HL7, also used to store
information about every action which happens
DEFINITION:
Corresponds to ORC-10
This identifies who actually entered the data into
the system.
DEFINITION:
Corresponds to ORC-9
DEFINITION:
Corresponds to ORC-15
DEFINITION:
Corresponds to ORC-13, ORC-18
The location where data was entered into the system.
DEFINITION:
The location where care was provided.
DEFINITION:
Obsolete. Should only use prior to version 5.
DEFINITION:
Obsolete. Should only use prior to version 5.
DEFINITION:
Used for counterSignatures, etc.
DEFINITION:
Used when the action only applies to a subpart of the
patient Event. XXX Probably not needed because old and new could
be compared in audit file, redundant when used in conjunction with
semantic links.
DEFINITION:
This is filled in by DSS to indicate what editVersion of
the event the EventActionInfo was originally stored with.
DEFINITION:
This is filled by a client program when the clinician
electronically signs the document
DEFINITION:
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.
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.
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
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
DEFINITION:
Time the ADE Occurred
DEFINITION:
When the ADE was resolved
DEFINITION:
PatientObservation is mostly a template to follow when
creating ClinicalObservation subtypes for the WITH TYPES
clause of the clinObs in a subtype of PatientEvent.
OTHER NOTES:
Concept 'NormalizedObsId': Ncid is 114021UL2 , Rsid is 3859448UL2
OTHER NOTES:
Concept 'Centimeters': Ncid is 1617UL2 , Rsid is 1407UL2
OTHER NOTES:
Concept 'HeightMeasurementMethod': Ncid is 2059UL2 , Rsid is 68357UL2
OTHER NOTES:
Concept 'PatientObsCondition': Ncid is 2060UL2 , Rsid is 68358UL2
OTHER NOTES:
Concept 'PatientObsTiming': Ncid is 2128UL2 , Rsid is 68426UL2
OTHER NOTES:
Concept 'HeightMeasurementInstrument': Ncid is 114025UL2 , Rsid is 3859462UL2
OTHER NOTES:
Concept 'PatientPosition': Ncid is 1439UL2 , Rsid is 174UL2
OTHER NOTES:
Concept 'HeightId': Ncid is 110675UL2 , Rsid is 3000230069UL2
OTHER NOTES:
Concept 'Grams': Ncid is 1630UL2 , Rsid is 1420UL2
OTHER NOTES:
Concept 'WeightMeasurementInstrument': Ncid is 114027UL2 , Rsid is 3859463UL2
OTHER NOTES:
Concept 'WeightMeasurementMethod': Ncid is 2183UL2 , Rsid is 68481UL2
OTHER NOTES:
Concept 'WeightId': Ncid is 2178UL2 , Rsid is 68476UL2
OTHER NOTES:
Concept 'EffectiveAge': Ncid is 119304UL2 , Rsid is 3886581UL2
DEFINITION:
Any patient location that does not resolve to Facility, NursingDivsion, Room or Bed
DEFINITION:
Patient's location (NursingDivision/Room/Bed) when the adverse event occurred
Make use of existing domains for Facility, NursingDivision, Room and Bed
DEFINITION:
Diagnostic Serv Sect Id (OBR-24)
HospitalServiceObs taken from advserse.a1
OTHER NOTES:
Use existing domain, ncid 372
DEFINITION:
Domain of questions
Allergies documented on MAR?
Allergies documented on FrontofChart?
Allergies documented InChart?
YesNoNA (Yes 1022, or No 1023, or NA(NotApplicable))
DEFINITION:
Allows specifying if the allergies were documented at the time the ADE occurred
OTHER NOTES:
Concept 'BodyAnatomy': Ncid is 1134UL2 , Rsid is 31091UL2
BodySiteMod is new as of July 1998. It replaces the following
types: BodySide, BodyLaterality, Depth, RelativeDepth, Level
RelativeLevel, RelSideOrLaterality
OTHER NOTES:
Concept 'ModelNum': Ncid is 114038UL2 , Rsid is 3859477UL2
OTHER NOTES:
Concept 'SerialNum': Ncid is 114039UL2 , Rsid is 3859480UL2
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
OTHER NOTES:
Concept 'ProstheticDevice': Ncid is 114040UL2 , Rsid is 3859484UL2
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
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.
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
OTHER NOTES:
terminal ncid, DosesGiven
Should also belong to the domain ObservationIdenifier
DEFINITION:
coded frequency, all others can go in err_text for now
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
DEFINITION:
DateTime the started
DEFINITION:
DateTime stopped
DEFINITION:
DateTime given
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'
DEFINITION:
records the drug(s) suspected of causing the reaction
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
DEFINITION:
Text description of event
DEFINITION:
Domain of questions
Reaction documented in Chart?
Reaction documented in NursingNotes?
YesNoNA (Yes 1022, or No 1023, or NA(NotApplicable))
DEFINITION:
Domain listing locations site wants to check off indicating where reactions
were documented following it's occurrence
DEFINITION:
ADEAdmitFlag=Yes means the ADE was the reason for admission, No means it was not
DEFINITION:
terminal ncid Reaction, 68230
Obsolete - use ADEReactionObs
DEFINITION:
terminal ncid
Coded values such as: drug discontinued, antidote given, dose held
DEFINITION:
Outcomes records consequences to patient such as:
hospitalization required or prolonged
disability
life-threatening
death
Should also belong to the domain ObservationIdentifier
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
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
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
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
OTHER NOTES:
Concept 'Trend': Ncid is 31097UL2 , Rsid is 160275UL2
OTHER NOTES:
Concept 'Severity': Ncid is 30920UL2 , Rsid is 160136UL2
OTHER NOTES:
Concept 'Chronicity': Ncid is 84293UL2 , Rsid is 1055783UL2
OTHER NOTES:
Concept 'GeneralObservationModifier': Ncid is 83858UL2 , Rsid is 1055313UL2
OTHER NOTES:
Terminal Concept 'ApplicationId', Ncid is 14707639UL2 , Rsid is 15559203UL2
OTHER NOTES:
Concept 'ExacerbatingFactors': Ncid is 119305UL2 , Rsid is 3886584UL2
OTHER NOTES:
Concept 'AlleviatingFactors': Ncid is 119306UL2 , Rsid is 3886566UL2
OTHER NOTES:
Concept 'ObservationMethod': Ncid is 30692UL2 , Rsid is 159908UL2
OTHER NOTES:
Concept 'Uncertainty': Ncid is 1482UL2 , Rsid is 239UL2
HL7 MAPPING:
DG1.3.3 Diagnosis Coding Method
PR1.3.3 Procedure Coding Method
HL7 MAPPING:
DG1.17 DiagnosisClassification
HL7 MAPPING:
DG1.6 DiagnosisType
HL7 MAPPING:
DG1.18 Confidential Indicator
OTHER NOTES:
Terminal Concept 'ClinicianRole', Ncid is 1365UL2 , Rsid is 82UL2
ClinicianRole is a domain, ncid 1365 - new memebers for Procedure Practioner, Anesthesiologist,
Diagnosing Clinician are needed in this domain
OTHER NOTES:
Terminal Concept 'AssociatedClinician', Ncid is 14707640UL2 , Rsid is
15559205UL2
OTHER NOTES:
Concept 'Diagnosis': Ncid is 105328UL2 , Rsid is 3859412UL2
DEFINITION:
Contributing factors related to the patient's condition
race, pregnancy, smoking & alcohol use, hepatic/renal dysfunction
if other - store text comments
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))
DEFINITION:
Preventablility is the investigator's opinion concerning if the incident
could have been avoided
DEFINITION:
Number of other drugs the patient was on at the time
DEFINITION:
Number of other drugs patient is taking by a category (0-1, 2-4, 5-7, >7)
DEFINITION:
Who should get this ADE report
ReportTo domain, members such as FDA, P&T Committee
DEFINITION:
Who did the reporting
DEFINITION:
Role of person who reported the ADE to pharmacy
DEFINITION:
Date/Time the report was made
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
DEFINITION:
Time spent preparing form and collecting data for it
Terminal concept
DEFINITION:
terminal ncid ADEReactions, 154675
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
OTHER NOTES:
Concept 'Side': Ncid is 91046UL2 , Rsid is 20722UL2
OTHER NOTES:
Concept 'Laterality': Ncid is 1412UL2 , Rsid is 140UL2
OTHER NOTES:
Concept 'BodyDepth': Ncid is 1356UL2 , Rsid is 73UL2
OTHER NOTES:
Concept 'BodyRelativeDepth': Ncid is 1358UL2 , Rsid is 75UL2
OTHER NOTES:
Concept 'BodyLevel': Ncid is 1357UL2 , Rsid is 74UL2
OTHER NOTES:
Concept 'BodyRelativeLevel': Ncid is 1359UL2 , Rsid is 76UL2
OTHER NOTES:
Concept 'RelativeSideOrLaterality': Ncid is 1453UL2 , Rsid is 189UL2
OTHER NOTES:
Concept 'SpecimenReceivedTimeId': Ncid is 114034UL2 , Rsid is 3860878UL2
OTHER NOTES:
Concept 'SpecimenType': Ncid is 114035UL2 , Rsid is 3860884UL2
OTHER NOTES:
Concept 'DecimalVolumeId': Ncid is 114042UL2 , Rsid is 3859485UL2
OTHER NOTES:
Concept 'FuzzyVolume': Ncid is 1396UL2 , Rsid is 117UL2
OTHER NOTES:
Concept 'SpecimenModifiers': Ncid is 114043UL2 , Rsid is 3859486UL2
OTHER NOTES:
Concept 'ClinicalSpecimen': Ncid is 10446UL2 , Rsid is 34300UL2
OTHER NOTES:
Concept 'PathoLesionModifier': Ncid is 114036UL2 , Rsid is 3858268UL2
OTHER NOTES:
Concept 'PathologicStructure': Ncid is 1437UL2 , Rsid is 172UL2
OTHER NOTES:
Concept 'SpecimenCollectionMethod': Ncid is 1148UL2 , Rsid is 35988UL2
OTHER NOTES:
Concept 'CollectionDevice': Ncid is 114037UL2 , Rsid is 3859467UL2
OTHER NOTES:
Concept 'DegreeCelsius': Ncid is 1639UL2 , Rsid is 1429UL2
OTHER NOTES:
Concept 'SquareCentimeters': Ncid is 1655UL2 , Rsid is 1519UL2
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.
DEFINITION:
Revlevant Clinical Information from (OBR-13)
OTHER NOTES:
Domain PatObsId, not created yet
Domain PatObsComment, ncid 90781
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.
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
DEFINITION:
Probability (OBX-9)
DEFINITION:
User Defined Access Checks (OBX-13)
OTHER NOTES:
New domain
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)
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 ??
HL7 MAPPING:
PR1.13 Consent Code
OTHER NOTES:
Terminal Concept 'ConsentCode', Ncid is cidConcentCode, Rsid is 15559207UL2
ConsentCode is a domain, ncid
OTHER NOTES:
Terminal Concept 'ProcedureType', Ncid is 14707647UL2 , Rsid is 15559219UL2
ProceedureType is a domain, ncid ??
HL7 PR1.14 Procedure Priority
OTHER NOTES:
Terminal Concept 'ProcedureDuration',Ncid is 14707644UL2 ,Rsid is 15559213UL2
HL7 PR1.7 Procedure Minutes
OTHER NOTES:
Terminal Concept 'ProcedureCodeModifier', Ncid is 14707643UL2 , Rsid is rsidProcedureCodemodifier
ProceedureCodeModifier is a domain, ncid ??
HL7 PR1.16 Procedure Code Modifier
OTHER NOTES:
Terminal Concept 'DRGProcedureRank', Ncid is 14707642UL2 , Rsid is 15559209UL2
ProceedureDRGType is a domain, ncid ??
HL7 PR1.17 Procedure DRG Type
OTHER NOTES:
Terminal Concept 'ProcedureTissueType', Ncid is 14707646UL2 , Rsid is 15559217UL2
ProceedureTissueType is a domain, ncid ??
HL7 PR1.18 Tissue Type
OTHER NOTES:
Terminal Concept 'AnesthesiaDuration', Ncid is cidAnesthesiaDuration, Rsid is rsidAnesthesiaDuration
HL7 PR1.10 Anesthesia Minutes
OTHER NOTES:
Terminal Concept 'AnesthesiaCode', Ncid is cidAnesthesiaCode, Rsid is rsidAnesthesiaCode
AnesthesiaCode is a domain, ncid
HL7 PR1.9 Anesthesia Code
OTHER NOTES:
Concept 'MedicalProcedure': Ncid is 82750UL2 , Rsid is 1055156UL2
OTHER NOTES:
Concept 'MmiNumber': Ncid is 119307UL2 , Rsid is 3886614UL2
OTHER NOTES:
New concept NameIndexId: cid is 154816UL2 , rsid is 8035571UL2
OTHER NOTES:
New concept NameTypeId: cid is cidNameTypeId, rsid is rsidNameTypeId
OTHER NOTES:
New concept LastNameId: cid is 154817UL2 , rsid is 8035559UL2
OTHER NOTES:
New concept LastName2Id: cid is 154818UL2 , rsid is 8035576UL2
OTHER NOTES:
New concept FirstNameId: cid is 154819UL2 , rsid is 8035552UL2
OTHER NOTES:
New concept MiddleNameId: cid is 154820UL2 , rsid is 8035567UL2
OTHER NOTES:
New concept MiddleName2Id: cid is 154821UL2 , rsid is 8035577UL2
OTHER NOTES:
New concept NameSuffix: cid is 154822UL2 , rsid is 8035572UL2
OTHER NOTES:
New concept NameTitle: cid is 154823UL2 , rsid is 8035573UL2
OTHER NOTES:
New concept NameDegree: cid is 154824UL2 , rsid is 8035569UL2
OTHER NOTES:
New concept FullNameId: cid is 154825UL2 , rsid is 8035553UL2
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
OTHER NOTES:
Concept 'ToPatientRelationship': Ncid is 1012UL2 , Rsid is 10980UL2
OTHER NOTES:
Concept 'FamilyHistory': Ncid is 105329UL2 , Rsid is 3858183UL2
DEFINITION:
means 0 to many
HL7 MAPPING:
PR1.5 Attestation Date/Time
OTHER NOTES:
means 1 to many
HL7 MAPPING:
DG1.5 DiagnosisDate/Time
HL7 MAPPING:
DG1.19 Attestation Date/Time
HL7 MAPPING:
DG1.3 DiagnosisCode
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.
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.
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.
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
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
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
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
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
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.
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.
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
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
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.
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
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
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
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.
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.
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.
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'.
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
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.
DEFINITION:
The beginning of the recommended time range.
OTHER NOTES:
Terminal concept 'EarliestRecommendedDate': Ncid is 162168UL2 , Rsid is 8095827UL2
DEFINITION:
The end point of the recommended time range.
OTHER NOTES:
Terminal concept 'LatestRecommendedDate': Ncid is 162173UL2 , Rsid is 8095832UL2
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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
OTHER NOTES:
Concept 'NumericQuantGrowthObsId': Ncid is 119267UL2 , Rsid is 3886625UL2
Domain QuantitativeGrowthUnits is new,
should contain members like CFU (Colony Forming Units), CFU/ml
OTHER NOTES:
Concept 'RangeQuantGrowthObsId': Ncid is 119268UL2 , Rsid is 3886636UL2
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)
OTHER NOTES:
New domain, should contain qualitative terms like clumps
Concept 'QualitativeLabCodedValues': Ncid is 119266UL2 , Rsid is 3886629UL2
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
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
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
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
OTHER NOTES:
Concept 'NumericDrugConcentrationId': Ncid is 119279UL2 , Rsid is 3886623UL2
Domain ConcentrationUnits is ncid 1580
OTHER NOTES:
Concept 'StringDrugConcentrationId': Ncid is 119280UL2 , Rsid is 3886644UL2
OTHER NOTES:
New terminal concept 'DiameterSuppressedGrowthId'
Concept 'DiameterSuppressedGrowthId': Ncid is 119278UL2 , Rsid is 3886576UL2
Domain LengthUnits is ncid 1571
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
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
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
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
OTHER NOTES:
New terminal concept 'MinInhibitorySusceptGroup'
Concept 'MinInhibitorySusceptGroup': Ncid is 119270UL2 , Rsid is 3886611UL2
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
OTHER NOTES:
New terminal concept 'MinBactericidalSusceptGroup'
Concept 'MinBactericidalSusceptGroup': Ncid is 119271UL2 , Rsid is 3886608UL2
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
OTHER NOTES:
New terminal concept 'SynergySusceptGroup'
Concept 'SynergySusceptGroup': Ncid is 119272UL2 , Rsid is 3886653UL2
DEFINITION:
OTHER NOTES:
Concept 'HL7SubIdObsId': When there are both preliminary and final results
This is the HL7 subId
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
OTHER NOTES:
I have no idea what domain this is really supposed to be,
Values are Internal, External, specific relSFormNumId Domain?
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
OTHER NOTES:
New ObsMod
Orgination Date is the date the image was created.
OTHER NOTES:
New ObsMod
Received Date is the date the image was scanned and entered into
this system
OTHER NOTES:
Existing observation NameObs
Will not change the definition
Will fit the author name into the current definition
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
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.
DEFINITION:
means 0 to many
means 0 to many
HL7 MAPPING:
ORC.1 Order Control
HL7 MAPPING:
ORC.4 Placer Goup Number
HL7 MAPPING:
ORC.6 Response Flag
HL7 MAPPING:
ORC.8.1.1 Parent
HL7 MAPPING:
ORC.8.2.1 Parent
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
HL7 MAPPING:
ORC.7 QuantityTiming
HL7 MAPPING:
ORC.8 Parent
HL7 MAPPING:
ORC.14 Call Back Phone Number
OBR 17 Call Back Phone Number
HL7 MAPPING:
ORC.15 OrderEffectiveTime
HL7 MAPPING:
ORC.16.1 Order Control Reason
HL7 MAPPING:
OBR.11 Specimen Action Code
HL7 MAPPING:
OBR.12.1 Danger Code
HL7 MAPPING:
OBR.13 Relevant Clinical Info
HL7 MAPPING:
OBR 30 TransportationMode
HL7 MAPPING:
OBR 31.1 Reason for Study
HL7 MAPPING:
OBR 40.1 Transport Arrangement Responsibility
HL7 MAPPING:
OBR 41 Transport Arranged
HL7 MAPPING:
OBR 42 Escort Required
HL7 MAPPING:
OBR 43.1 Planned Patient Transport Comment
HL7 MAPPING:
obsId OBR.4.1 Universal Service Identifier
status OBR.25 Result Status
comments OBR NTE's Comments
OBR 27.1 Quantity/Timings
HL7 MAPPING:
ODS.2 Service Period
HL7 MAPPING:
ODS.3 Diet, Supplement, or Preference Code
HL7 MAPPING:
obsId ODS.1 Type
comments Comment Text Comment Text
comments ODS Text ODS Text
HL7 MAPPING:
obsId ODT.1 Tray Type
comments Comment Text Comment Text
comments ODT Text ODT Comments
HL7 MAPPING:
RQD.1 Requisition Line Number
HL7 MAPPING:
RQD.7 Dept. Cost Center
HL7 MAPPING:
RQD.8 Item Natural Account Code
HL7 MAPPING:
RQD.9 Deliver To ID
HL7 MAPPING:
RQD.10 Date Needed
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
HL7 MAPPING:
RQ1.1 Anticipated Price
HL7 MAPPING:
RQ1.2 Manufactured ID
HL7 MAPPING:
RQ1.3 Manufacturer's Catalog
HL7 MAPPING:
RQ1.4 Vendor ID
HL7 MAPPING:
RQ1.5 Vendor's Catalog
HL7 MAPPING:
RQ1.6 Taxable
HL7 MAPPING:
RQ1.7 Substitute Allowed
HL7 MAPPING:
comments Comments Comments
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)
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
DEFINITION:
means 0 to many
means 0 to many
OTHER NOTES:
means 1 to many
means 1 to many
DEFINITION:
means 0 to many
OTHER NOTES:
means 1 to many
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
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"!
DEFINITION:
means 0 to many
OTHER NOTES:
means 1 to many
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.
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.
DEFINITION:
means 0 to many
OTHER NOTES:
Concept 'BloodPressureMeasureInstrument': Ncid is 114020UL2 , Rsid is 3859446UL2
OTHER NOTES:
Concept 'BloodPressureMeasureMethod': Ncid is 1981UL2 , Rsid is 68282UL2
OTHER NOTES:
Concept 'PatientBreathingPhase': Ncid is 1982UL2 , Rsid is 68283UL2
OTHER NOTES:
Concept 'HeartRateCharacteristicsRhythm': Ncid is 2052UL2 , Rsid is 68350UL2
OTHER NOTES:
Concept 'HeartRateMeasureInstrument': Ncid is 114022UL2 , Rsid is 3859458UL2
OTHER NOTES:
Concept 'RespRateMeasureMethod': Ncid is 2127UL2 , Rsid is 68425UL2
OTHER NOTES:
Concept 'RespRateMeasureInstrument': Ncid is 114023UL2 , Rsid is 3859460UL2
OTHER NOTES:
Concept 'TemperatureMeasureInstrument': Ncid is 2156UL2 , Rsid is 68454UL2
OTHER NOTES:
Concept 'TemperatureMeasureMethod': Ncid is 2157UL2 , Rsid is 68455UL2
OTHER NOTES:
Concept 'TemperatureId': Ncid is 2154UL2 , Rsid is 68452UL2
OTHER NOTES:
Concept 'SystolicBPId': Ncid is 1985UL2 , Rsid is 68286UL2
Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2
OTHER NOTES:
Concept 'DiastolicBPId': Ncid is 1976UL2 , Rsid is 68277UL2
Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2
OTHER NOTES:
Concept 'HeartRateId': Ncid is 2051UL2 , Rsid is 68349UL2
Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2
OTHER NOTES:
Concept 'RespiratoryRateId': Ncid is 2124UL2 , Rsid is 68422UL2
Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2
OTHER NOTES:
Concept 'VitalSignsBatteryId': Ncid is 110669UL2 , Rsid is 3000230065UL2
DEFINITION:
means 0 to many
OTHER NOTES:
Concept 'BSAMeasurementMethod': Ncid is 2151UL2 , Rsid is 68449UL2
OTHER NOTES:
Concept 'BSAId': Ncid is 114028UL2 , Rsid is 3860872UL2
OTHER NOTES:
Concept 'HeightWeightId': Ncid is 110670UL2 , Rsid is 3000230067UL2
DEFINITION:
means 0 to many
OTHER NOTES:
means 1 to many
OTHER NOTES:
Concept 'SystolicBPId': Ncid is 1985UL2 , Rsid is 68286UL2
Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2
OTHER NOTES:
Concept 'DiastolicBPId': Ncid is 1976UL2 , Rsid is 68277UL2
Concept 'MillimetersOfMercury': Ncid is 1788UL2 , Rsid is 5468UL2
OTHER NOTES:
Concept 'HeartRateId': Ncid is 2051UL2 , Rsid is 68349UL2
Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2
OTHER NOTES:
Concept 'RespiratoryRateId': Ncid is 2124UL2 , Rsid is 68422UL2
Concept 'PerMinute': Ncid is 1762UL2 , Rsid is 5442UL2
OTHER NOTES:
Concept 'OrthostaticVitalsId': Ncid is 110676UL2 , Rsid is 3000230071UL2
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
HL7 MAPPING:
setId OBX.1 Set Id
"NM" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"NM" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"NM" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"NM" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"TS" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"TS" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"TS" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
HL7 MAPPING:
setId OBX.1 Set Id
"NM" OBX.2 ValuE Type
obsId OBX.3.1 Observation Identifier
obsValue OBX.5 Observation ValuE
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
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
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