V3DT conference call notes for Mon, Dec 21, 1998.

The HL7 version 3 data type task group has had its tenth conference call on Monday, December 21, 1998, 11:00 to 12:30 EST.

Attendees were:

Agenda items were:

  1. review of the uncertainty debate time boxed to 10 minutes.
  2. review of the concepts of generic types and the extensive use of implicit type conversion
  3. generic data type for historic information [slide]
  4. generic data type for annotated information (This has been an idea of Mark Tucker that seems to be very useful and straight forward. It would be the v3 counterpart of the NTE segment.)

AGENDA ITEM 1: review of the uncertainty debate

time boxed to 10 minutes.

The issues of the uncertainty debate are captured in the last notes.

We eventually cancelled this agenda item because of lack of preparation.

AGENDA ITEM 2: review of the concepts of generic types and the extensive use of implicit type conversion

During the last conferences I kind of "creeped" in the concept of (1) generic data types and we mumbled about using (2) implicit type conversion to provide for more flexible interoperability.

GENERIC DATA TYPES

Generic data types are incomplete type definitions.

This incompleteness is signified by one or more parameters to the type definition. Usually paramters stand for other types. Using parameters, a generic type might declare components (fields) of other not fully specified data types. For example, the generic data type Interval is declared with a parameter T. In this example, T can stand for any OrderedType. The components low and high are declared as being of type T.

Before you can instantiate a generic type, you must complete its definition.

For example, if you want to use the an Interval, you have to say of what base data type the interval should be, i.e. you have to bind the parameter T. Say, you want an interval of Integer Numbers, you bind the parameter T to the type Integer Number through which the incomplete data type Interval becomes completed as a data type Interval of IntegerNumber.

You can complete the definition of a generic data type right at the point of instantiation.

This means, that you do not have to define all possible types generated by the generic type in advance. For instance, given generic type Interval and the ordered types Integer Number , Floating Point Number , Measurement with Unit , Ratio of Quantities , Point in Time , and Calendar Modulus Expressions , you can use intervals of all those base types without having an actual specification of all the specific types. The specification, what an Interval is, is given only once, generically. Whenever you have a new ordered type, you can build an interval from it and use that new special interval, without having to define the new interval type explicitly. Generic types are thus a more efficient way of type specification.

Generic types became most popular in C++, where they are called class templates. The C++ notation the Interval type would be defined as:

template <class T> class Interval { T low; T high; ... };
this interval generic type can then be used as follows:
Interval<int> foo; Interval<float> bar; Interval<Date> effectivePeriod;

Generic data types may have more than one parameters. E.g. a type could be defined as

template <class N, class D> class Ratio { N numerator; D denominator; ... }
which is actually one way of making constraints: with this generic type ratio, is would be clear that Ratio would be a ratio of two integers (a rational number), Ratio would be a ratio of two floating boint numbers, and Ratio would be a ratio of a float and an int.

Please note that our data type Ratio of Quantities , is currently not defined as a generic type.

Generic data types can be used in a nested way. Suppose you want an Interval of Ratios of floats by ints:

Interval<Ratio<float, int>> foo;
would be all you needed to do to instantiate that new type.

Note: We did not decide on using the C++ notation of generic types, I just use it here to exemplify how generic types work.

IMPLICIT TYPE CONVERSION

In HL7 v2.x implicit type conversion was an integral part of the technology and it proved to be quite flexible, expecially for inter-version compatibility or localizations. For instance, you could promote a single data element to a "repeating" element (i.e. a list of the base element) and vice versa without causing interoperability trouble with prior versions. Likewise, you could make an data element declared as a primitive data type in one version a composite data type in another version. And you could "append" components "at the end" of a type definition, all without causing HL7 agents of different versions to reject each other messages.

However, in HL7 v2.x, implicit type conversion was not a stated rule, it was sort of a by-product of the way HL7 messages used to be encoded. Transfer to other technologies, like C++ classes in ProtoGen/HL7 and IDL interfaces in SIGOBT's work lost this convenience of the implicit type conversion. It is therefore necessary to state the rules of implicit type conversion precisely.

Type conversion is also called "type casting". If a more primitive type is cast to a more complex type we can call this "up-casting" or "promoting" the lower to the higher level type. If a higher level type is being cast to a lower level type we call that "down-casting".

Type conversion must be clearly defined by reasonable rules. The rules should transfer the semantics of the data as good as possible. Especially the rules should not merely be driven by the coincidence of representations. For instance, it makes no sense to cast an ICD-9 code 100.1 to a floating point number 100.1 just because their representation happens to be the same.

The easiest way to state the rule for type conversion is by using a conversion matrix such as exemplified in the following table. The rows show the type you have and the columns show the type you need and thus need to convert to.

  String FreeText CodeValue CodePhrase CodeTranslation ConceptDescriptor Integer Float Measurement Ratio
String N/A promote to text/plain if code system is known and string is a valid code in the system promote to CodeValue first promote to CodeValue first promote to CodeValue first if string is a valid integer literal if string is a valid floating point literal if string is a valid measurement literal is string is a valid ratio literal
FreeText if media type is text/plain N/A try conversion to string first try conversion to string first try conversion to string first try conversion to string first try conversion to string first try conversion to string first try conversion to string first try conversion to string first
CodeValue use the code or other rule for creating literals convert to string first N/A make a phrase with just one CodeValue promote to a CodePhrase first promote to a CodePhrase first none none none none
CodePhrase make a literal? convert to string first take first CodeValue in phrase (cave!) N/A new translation with origin set to NIL promote to CodeTransaltion first none none none none
CodeTranslation make a literal? convert to string first convert to CodePhrase first use the term component N/A make new ConceptDescriptor none none none none
ConceptDescriptor use "orignial text"? make a literal? use "original text" or convert to string first if a specific code system is needed, see whether it is in the set of translations down-cast to CodeTransaltion first if a specific code system is needed, see whether it is in the set of translations N/A none none none none
Integer use integer literal convert to string first none none none none N/A make a float from an int, precision is number of all digits in the integer make a float first use as the numerator, set denominator to 1
Float use floating point literal convert to string first none none none none round the float to an int, cave: this may create pseudo-precision N/A use "1" (the unity) for unit use as the numerator, set denominator to 1
Measurement use floating point literal convert to string first none none none none down-cast to float first return the value, may throw exception if unit is not "1" N/A use as the numerator, set denominator to 1
Ratio use ratio literal convert to string first none none none none down-cast to float first convert numerator and denominator to floats and the build the quotient cast the ratio values to a float, make a new unit as the ratio of units (if any) N/A

As can be seen the conversion matrix is sizeable, even on a subset of our types.

Conversions can be concatenated to eventually convert between "distant" types. This process is guided by pre-formulated strategy rules of the form "convert to T first".

Many special converisons exist between character string and any other type because we want to define concise and nice looking string literals for many of the more complex types. String literals can be used in XML for instance to make the message more compact and readable.

Type conversion matrices can be interpreted by computers quite easily. In C, for instance, the matrix would be stored as a two dimensional array of function pointers:

typedef (*conv_func)(void*, void**); conv_func conv_matrix[MAXTYPE, MAXTYPE] { { NULL, t1tot2, ..., t1totN }, { t2tot1, NULL, ..., t2totN }, ... { tMtot1, tMtot2, ..., NULL }, }; convert(int ti1, void *vi1, int ti2, void **vi2) { conv_func cnv = conv_matrix[ti1, ti2]; if(cnv != NULL) cnv(vi1, vi2); }

In C++ one can do the same or one can use polymorphism to make the process more obvious. C++ even has its own rules of implicit type conversion using cast operators, which could be used to some extent. In Java the process is mostly the same but function pointers are not available. The above example does not show how concatenation and strategic steps can be used to convert between distant types.

Discussions

We examined this approach by asking several quiestions:

Without having taken minutes on how we solved all of those questions (I am sorry) it we were assured that this system could work. Mark Tucker had a good answer to the combinatorial explosion. Mark Shafarman asked the question about XML encoding.

The XML encoding as of last summer uses an XML attribute TY and mentions the data type as the value to the TY attribute. For instance:

<foo ty="integer">100</foo> <foo ty="ratio"> <numerator ty="float">10.23</numerator> <denominator ty="integer>5</denominator> </foo>
might all be sent even though foo might initially have been declared as a floating point value.

Mark Tucker's rule of minimal explicitness is that you only need TY attributes at a place where the actual type used diverts from the specification.

When generic types are used, the TY value only specifies the generic type, the parameter type is found where the value of that type is expected to be. Thus, TY attributes are always required for the parameterized components of generic types.

AGENDA ITEM 3: generic data type for historic information

In the recent years we have experienced a need for data elements to be communicated with a history. I.e. the National Immunization Program (CDC, State Departments of Health) needed to communicate historic address information. Other examples for history are "effective date" and "end date" of identifiers or other data. The traditional approach to this problem was to extend a preexisiting data type T or to create a new data type XT. Using generic types as described above, we no longer need to take care of history information for every existing type. INstead we can define the following set of generic types:

GENERIC DATA TYPE FOR INFORMATION HISTORY

History
Generic data type to give the history of some information. This is an ordered list of data of the same type along with the time interval giving the time the information was (or is) valid. The order of history items in the lists should be backwards in time. The hisotry information is not limited to the past history, expected future values can also appear.
GENERIC TYPE
parameter name allowed types description
T ANY Any data type can be used here.
ORDERED LIST OF History Item<T>

GENERIC DATA TYPE "HISTORY ITEM"

History Item
Generic data to give the time range in which some information was, is, or is expected to be valid.
GENERIC TYPE
parameter name allowed types description
T ANY Any data type can be used here.
component name type/domain optionality description
value T required The information itself.
validity period Interval<Point in Time> required The time interval the given information was, is, or is expected to be valid. The interval can be open or closed infinite or undefined on either side.

NOTES

When no validity period is known, it doesn't make sense to send a history item for the information, therefore, both components are required. However, an interval can be defined open and undefined or infinite on both sides. This should not be done unless in a case where infinite or undefined validity periods are semantically justified.

AGENDA ITEM 4: generic data type for annotated information

HL7 v2.x had the NTE segment to add arbitrary free text annotations to messages. There is no plan yet how to implment the NTE feature with v3.0 messages. A consistent way of doing so is to define a generic type for annotated information. Thus any message element instance can be annotated, with the advantage that annotations can be matched to precisely to the message element instance for which they apply. Conversely NTE segments had no way to make associations of the notes and comments to one particular field or component.

GENERIC DATA TYPE "ANNOTATED INFORMATION"

Annotated Information
Generic data to give allow arbitrary free text annotations for any message element instance.
GENERIC TYPE
parameter name allowed types description
T ANY Any message element type can be annotated.
component name type/domain optionality description
value T required The information itself.
note Free Text required The annotation as free text to be eventually displayed to a user or administrator.

Stan Huff reported that annotations in NTEs are frequently of a coded nature, which means that we might want to have not only free text annotations but also coded annotations. It also seems like codes and text (may be even other data types) may be mixed.

The question is, should we allow data of any types to be sent as the annotation? Does it make sense to send the number 5 as an annotation to the number 6? Does it make sense to send code A to annotate code B? It certainly may make some sense, but the difficulty is that it is not clear and not standardized what new information is constructed through annotations.

Everyone agreed that annotations are primarily used to display the annotation to human users. For instance, a lab value might be sent annotated, in which case the EMR GUI program shows a little exclamation point where in the flowsheet cell. When the user clicks on that mark, a text box pops up that displays the free text annotation.

If different types of annotations are permissible, then it becomes useful to have multipart annotations where different types can be mixed all in one annotation. This could be very very powerful but not standardized at all. Wes Rishel would call such a construct a "polyglot" data type and he sure would not like it. Such unstandardized structures of information are "a powerful mess" of doubtful use. We may still want to go ahead allowing such constructs.

Stan Huff provided a list of coded annotations he has compiled to reflect what is actually done at his institution. This table is descriptive rather then normative. Neither Stan Huff nor we intend to use those annotations. Stan just provided the list to show what people actually do.

CODEDESCRIPTION
AANORM No clinical significant abnormality detected
AAU241 AAU24 GROUPING CODE
AAUR1 "The presence of protein, glucose, ketones or blood may interfere with"
AAUR2 "CTAB, acid albumin and berry spot are screening procedures for mucopo"
ABA CDC ANAEROBIC BLOOD AGAR
ABB12H Abbott B12 Control High
ABB12L Abbott B12 Control Low
ABB12M Abbott B12 Control Medium
ABBH ABBOTT CONTROL HIGH
ABBL ABBOTT CONTROL LOW
ABBM ABBOTT CONTROL MEDIUM
ABOR4 ARUP REF LAB IF SPECIMEN
ABYPOS Interpretative comment: Positive or discrepant results to be confir
ACC NO CORRECIVE ACTION NEEDED
ACETAM Toxic Level: >200 ug/mL 4 hours after ingestion or >50 ug/mL 12 hou
ACI Abnormal cells seen. Sent to pathologist for identification.
ACTHS "Ref Range for ACTH Stim Test, from Tietz, Clinical Guide to Laborator"
ACTHS1 Ranges for ACTH Stimulation Test:
ACTHS2 Baseline cortisol: >5 ug/dL
ACTHS3 Peak cortisol: >20 ug/dL
ACUTE1 Acute infection is diagnosed by a fourfold or
ACUTE2 greater rise in titer 1421 days after onset.
AD Air drying artifact
ADD Specimen in Lab
ADDACC ADDITIONAL ACCESSION
ADDPIE ADDITIONAL PIECES
ADDRDG ADDL READINGS
ADEQ SPECIMEN APPEARS TO BE ADEQUATE FOR REQUESTED ANALYSIS
ADET Enzyme activity detected.
ADIFF "No automated differential available, see manual differential."
ADJ "Adjusted WBC (eg: NRBC, Giant platelets, nonhematopoietic nucleated ce"
ADM ADMINISTRATIVE
AFPWNL "Assuming the patient information is correct, this patient's AFP is w"
AG AGREE
AGNBFG Anaerobic gram negative bacillus NOT Bacteroides fragilis group
AGR Growth in routine aerobic bottle
ALK1 Residual activity of 20% or less suggests the predominant isoenzyme is
ALK2 Residual activity between 25 and 55% suggests the predominant isoenzym
ALK3 Residual activity greater than 60% suggests the predominant isoenzyme
ALKF1 Residual activity <
ALKF2 isoenzyme is bone.
ALKF3 Residual activity >
ALKF4 predominant isoenzyme is liver and/or intestinal.
ALKF5 Residual activity > 60% suggests predominant
ALKF6 isoenzyme is placental or neoplasia associated.
ALTA Test performed at Alta View Hospital
AMDA1 All of the nongestational Oral Glucose Tolerance Tests currently in
AMDA2 will be replaced by the American Diabetes Association recommended
AMDA3 "OGTT on June 15, 1998. This new OGTT consists of a fasting specimen"
AMDA4 and a specimen collected 2 hours after a 75g oral glucose dose.
AMITA Possible antimitochondrial antibody present
AMTRC Amitriptyline levels <10 ng/mL and Nortriptyline levels <20 ng/mL can
AMTRC1 Amitriptyline <10 ng/mL / Nortriptyline <20 ng/mL
AMTRC2 cannot be distinguished statistically from 0 ng/mL
AMTRIP Amitriptyline
AN Growth in routine aerobic and aneaerobic bottles
AN1 Approximate reference ranges for serum AFP in
AN10 "Gitlin D., Normal Biology of alphaFetoprotein,"
AN11 Ann NY Acad Sci 1975; 259: 716.
AN2 neonates:
AN3 Weeks Gestation Range (ng/mL)
AN4 "1323 1,000,000 2,500,000"
AN5 "2333 100,000 1,000,000"
AN6 "3342 5,000 200,000"
AN7 The plasma AFP level in the newborn normally
AN8 declines rapidly with an average halflife of 3.5
AN9 days during the first weeks of life. Source:
ANACM1 Antinuclear antibodies are seen in a variety of systemic rheumatic
ANACM2 "When cell culture substrates (HEp2 cells) are used, the ANA inciden"
ANACM4 UVRMC screens all ANA samples using an EIA assay. All samples that s
ANACMU ANA EIA COMMENT
ANACOM Acceptable specimens are aspirated fluids or biopsy.
ANAG ANAEROBE WORKUP GROUP
ANANEG "ANA NEGATIVE, POSSIBLE AMA OR ANTISMA, SPEICMEN ON HOLD X8155"
ANATFL ANA titer on fluid group comment
ANATR Reference range for ANAT
ANATR1 Normal Values:
ANATR2 <1:200 Homogeneous and Speckled Patterns
ANATR3 <1:50 Nucleolar and Centromere
ANAX Not cultured for anaerobes due to presence of normal anaerobic flora.
AOGP All organisms are Gram Positive
APPLE Test performed at British Columbia Children's Hospital (Dr. Applegart
AQNS QNS for Antibody ID
ARHEM ACUTE AND REMOTE HEMORRHAGE
ARR16A SL CLINIC MAIN ARRAY 360
ARRAY2 "Specimen unacceptable for nephelometric assay due to lipemia, sugges"
ARRIVE On arrival
ARSP Arachnia species
ART ARTERY
ARUP Test performed by ARUP Laboratories
ARUPAD "500 Chipeta Way, Salt Lake City, UT 84108"
ARUPCM Testing performed at ARUP laboratories.
ARUPWB Specimen sent to ARUP laboratories for confirmation. Results to foll
ARYLA1 ARYLA GROUPING CODE
ASAP As soon as possible
ASO4 166250:School age children and young adults
ASO5 "A twofold increase in the ASO value, using serial analysis, within on"
ASUP Run accepted with supervisory review
AT7 "If T7 is abnormal, run TSH."
ATNS ANA test not standardized for fluids other than serum.
B12V B12 VIAL RUN WITH NAP
BA SPECIMEN NOT ADEQUATE DUE TO PRESENCE OF BARIUMLIKE SUBSTANCE. PLEASE
BAREA Height and weight not provided. Result not corrected for body surfac
BBDAM A PLOT OF THE ABOVE VALUES SUGGESTS: BLOODBRAIN BARRIER DAMAGE
BBE BLOOD BANK ERROR IN ENTRY.
BCC Benign cellular changes: See descriptive diagnosis
BCI1 Interpret as you would direct bilirubin. Does not
BCI2 include delta bilirubin (conjugated to albumin).
BCI3 Total includes delta.
BCPR "No human DNA recovered, possible inadequate sample."
BD "I have reviewed this case. Bashar Dabbas, M.D."
BDUP Blind Duplicate
BENNET "Reviewed by Dr. Sterling Bennett, M.D."
BFAB SPECIMEN QUALITY: SPECIMEN APPEARS TO BE INADEQUATE. INSUFFICIENT NUM
BFCT BUFFY COAT (MICRO WU) (BUF for spec)
BG BORDET GENGOU
BILL Billed for Services Performed
BIOL Specimen sent to Bioscience Laboratories
BIOTR "Test performed by BioTrace Laboratories, Salt Lake City, Utah."
BJLO Bence Jones Protein undetectable due to low protein
BLDSMR See Blood Smear survey report sheet
BMASS Height and weight not provided. Clearance NOT corrected for body mass
BMS Bone marrow surveillance
BMTCL BMT Clinician
BORDER If Indeterminate or Borderline: Suggest repeat test in 24 48 hours
BPCR "No human DNA recovered, possible inadequate sample."
BUCOM Interpret as you would indirect bilirubin.
BWPP Plt Pheresis Leukoreduced/Irradiated/Washed
BXHX History of biopsy
BY Result taken by:
CANP CANCELED PER PATHOLOGIST
CANRN CANCELED PER NURSE
CANTR Transfusion Cancelled
CAPSRV CAP SURVEY
CDLCOM "For this method, the bactericidal effects of serum diluted 1:8 to 1:"
CEACM1 "When serial samples are being evaluated, the same"
CEACM2 type of specimen should be used throughout the study.
CFN Patient will be contacted
CHAN "Test performed by Dr. Gary Chan, University of Utah Medical Center."
CHCD Please fax results to Columbia Home Care at 274-0874
CHEM1 A HIGH POTASSIUM CAN BE CAUSED BY HEMOLYSIS OR BY ALLOWING THE BLOOD
CHEM2 LOW GLUCOSE CAN BE CAUSED BY ALLOWING THE BLOOD TO SIT FOR SEVERAL HO
CK100 "The Total CPK is below 100 U PER L, so the CKMB is not performed or c"
CK500 Relative Index does not apply when Total CK is less than 500 U PER L.
CMGCO1 The absence of CMV antibody (<1:2) indicates no
CMGCO2 exposure to the virus. The presence of CMV
CMGCO3 "antibody indicates previous exposure, but does"
CMGCO4 not indicate immunity from reinfection.
CMMCO1 IgM may remain negative in immunosuppressed
CMMCO2 "individuals, and is occasionally presistently"
CMMCO3 positive in asymptomatic individuals after acute
CMMCO4 infection.
CMMCOM A positive result indicates active CMV infection.
CMPTST COMPETENCY TESTING
CMS Catheter Monitoring Specimen
CMT10 RADIOMETER CMT10 CHORIDE TITRATOR
CMV24 CMV Negative by Early Antigen at 24 hours
CMV48 CMV Negative at 48 hours by Early Antigen. Culture will be held 15 d
CMVB CMV antigenemia intrep:
CMVB1 A single positive cell per slide is considered a positive specimen.
CMVB2 Interpretation:
CMVB3 110 positive cells is a low level CMV antigenemia. This level usual
CMVB4 1150 positive cells is an intermediate level of CMV antigenemia. Us
CMVB5 >50 positive cells is a high level of CMV antigenemia. Usually sugge
CNDPDR Test cancelled per physician
CNSNS Coagulase negative Staphylococcus species. Unable to speciate.
CNSNSE "Coagulase negative Staphylococcus species, NOT S. epidermidis"
CNT50 50 CELLS COUNTED ON SMEAR
CNTM Contaminated
CONSEN Sensitivities confirmed by repeat analysis.
CONT The submitted specimen is contaminated. No further testing is possibl
CONTVE Contaminated with vaginal squamous epithelial cells
COR1 "To screen for all inhibitors, a one hour incuba"
COR10 1:1 correction >
COR2 tion at 37 degrees is necessary on all 1:1
COR3 correction studies.
COR4 If 1:1 correction result is within 2 seconds of
COR4A If 1:1 correction result is within 4 seconds of
COR5 "normal plasma result, it is consistent with a"
COR6 factor deficiency.
COR7 If 1:1 correction result is 3 or more seconds
COR7A If 1:1 correction result is 5 or more seconds
COR8 "longer than normal plasma result, it is consistent"
COR9 with an inhibitor.
CPM IHC HYPERLIPIDEMIA CAD PREVENTION
CPM1 "IF...CAD THEN...ASA, beta blocker, LDLC<100"
CPM10 IF...Obese THEN...Diet
CPM2 IF...CAD risk THEN...LDLC<130
CPM3 IF...Diabetes THEN...LDLC<100
CPM4 IF...LDLC > 100 THEN...
CPM5 Need 26% reduction Simvastatin 10 mg qd
CPM6 Need 32% reduction Simvastatin 20 mg qd
CPM7 Need 38% reduction Simvastatin 40 mg qd
CPM8 IF...Female THEN...Premarin
CPM9 IF...Smoker THEN...Quit
CPMG IHC Hyperlipidemia CPM Recommendation
CRCLC "Clearance calculated from serum creatinine, patient age, and patient"
CRDHOT UNABLE TO INTERPRET FOR OCCULT BLOOD. CARDS APPEAR TO HAVE BEEN EXPO
CREEKF Please fax results to Creekside Home Health at 2780597
CREFFL CHANGED REFERENCE FLUID
CRITV Critical value. Phone report immediately.
CRSMD CYTOCHEM REACTION SUGGESTS MYELOPEROX. DEFICIENCY
CT VERIFIED WITH CLINITEST TABLET
CTC CHLAMYDIA CULTURE CONFIRMATION
CTM CONTAMINANT
CU5WBC "CC, Culture if >5 WBC's per HPF"
CWAH Hormonal pattern compatible with age and history
CXIF Culture if indicated
CXO Culture ordered. Hold charge cancelled
CYC Reference range disclaimer for Cyclosproine A
CYCL CYC + LDS
CYCL1 Therapeutic range for Cyclosporine A should be
CYCL2 individualized for each patient.
CYCL3 > 180 100200 ng/mL
CYCL4 Hepatic Unstated 250450 ng/mL
CYCL5 Cardiac 090 250350 ng/mL
CYCL6 > 90 100200 ng/mL
CYCL7 Bone Marrow Unstated 150250 ng/mL
CYCL8
CYCL9 The above table is offered as a tentative guideline. The ranges are
CYTO Specimen sent to University of Utah Cytogenetics Laboratory
D Duplicate Order
DAU2 Sympathomimetic Amines include Amphetamine/Methamphetamine and other m
DFACO1 Results should be interpreted in light of
DFACO2 culture results as well as clinical information
DHEAS6 Reference Range for postmenopausal women is 10190 ug/dL.
DHEASL DHEAS6 + LDS
DHTS1 Dihydrotestosterone Reference Ranges (ng/dL):
DHTS3 1 <3 <3
DHTS4 2 317 512
DHTS5 3 833 719
DHTS6 4 2252 413
DHTS7 5 2465 318
DHTS8 Adult 3085 422
DIFBAD INADEQUATELY PREPARED DIFFERENTIAL SLIDE
DIFREF Manual Differential referred to Special Hematology
DIFSCN Manual Differential scanned to verify autodiff
DIP DIPSTICK MAY BE INACCURATE DUE TO COLOR OF URINE
DIPPOS Unable to do microalbumin due to pos. urine protein dipstick
DNARPT Verified by repeat analysis with blocking probe.
DOCS Do Culture and Sensitivity testing.
DOCTOR Test will be read by requesting physician
DOWN Instrument or assay requires service no patients run until issue is
DOXCO1 Toxicity can occur at levels > the therapeutic ranges.
DOXCO2 Some patients may exhibit satisfactory clinical
DOXCO3 responses with < the therapeutic range. Clinical
DOXCO4 evaluation is essential in interpreting these levels.
DOXCOM Toxicity occurs with increasing frequency at levels exceeding the up
HELD Held for possible culture
UAM1C Urine sample sent to Microbiology for culture
UCOM10 Urine specimen held for 48 hrs. Contact Lab ASAP for culture
UCOM11 Spun microscopic analysis performed on <12 ml of urine
UCOM12 Possible false positive(s) on dipstick due to color and/or medication
UCOM13 Bilirubin negative by ictotest. Possible false positive on dipstick due to color and/or medication.
UCOM15 QNS for spun microscopic
UCOM16 Glitter cells seen
UCOM26 Not Sufficient WBC's for culture
UCOM27 Culture ordered with Urinalysis
UCOM3 Blood confirmed by repeat analysis
UCOM8 Cultured per Doctor or Nurse request
UCOM9 Cultured per Doctor's standing order

As expected, it seems to me that most of those annotations could better be communicated in RIM-standardized information structures. For some of those annotations there are existing information structures that sould be used instead of those annotations. For instance DOCS meaning "Do Culture and Sensitivity testing" is either an order or a reflex test order notification. CYCLn should be one free text note rather than multiple codes for the arbitrarily broken lines of text. This note sould appear as part of the Master_service description rather than as a free-floating annotation. Most of the free text notes should indeed appear as master service data.

It might have been reasonable in v2.x to use those coded NTE segments for this purpose, in v3 we definitely want to use the available stanardized information structure. If any significant amout of real existing annotation could not be accomodated in RIM data elements, we should drive a use case analysis from there suggesting improvements to the RIM.

I am pretty convinced that I do not want annotations to be used in any computer processable way. Stan Huff basically agreed that the information should be put elsewhere. However, it was felt that one might want to use annotations as interim solutions.

Conclusion: we could give the note component of the Anntotated Information a different data type, or just the type ANY. Thus one could burry in the note a list of lists of key value pairs. The group felt like they wanted to go that way. You are free to beat me up for not having given into that general thrust for the purpose of writing these notes. I don't believe we really want to provide an "anything goes" data type extension here. Sorry. I can't do that now...


Next conference call is next Monday, December 28, 1998, 11:00 AM EST.

Agenda items are:

  1. collections [slide]
  2. incomplete information (what Stan calls "exception") [slide] [slide] [slide]
  3. update semantics [slide]
  4. review of the uncertainty debate time boxed to 10 minutes.

regards

-Gunther Schadow