DataTypes Comments Section 5

From HL7Wiki
Revision as of 02:03, 10 March 2008 by Hsolbrig (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

5 Quantities

  • 5.1 Abstract Type Quantity (QTY) specializes ANY
    1. 5.1.2 - To the best of my knowledge, a partial ordering relation is antisymmetric , not asymmetric . While this is undoubtedly a trivial point, asymmetry is often defined as antisymmetric and irreflexive, and <= is clearly reflexive. This understanding is supported in this document by 5.1.3, where the less than relation is defined as asymmetric and transitive. As we know that it is irreflexive, it is unstated because it is part of the asymmetric definition.
    2. 5.1.5 - same as 5.1.2. antisymmetric
    3. 5.1.7 - Definition 183 - should the data types of 'x' and 'y' in the invariants be QTY or QTZ? If it needs to be a QTZ, then the description needs to say why.
  • 5.2 Abstract Type Zeroed Quantity (QTZ) specializes QTY
  • 5.3 Integer Number (INT) specializes QTZ
  • 5.4 Real Number (REAL) specializes QTZ
  • 5.5 Ratio (RTO) specializes QTY
  • 5.6 Physical Quantity (PQ) specializes QTZ
    1. While the coloring is not a bad idea, it is kind of introduced fairly late in the game, so it might behoove us to add a short section to say, "In the paragraphs that follow, blue signifies Thing, ...".
    2. P4 - if the form is value unit of Thing, shouldn't an attempt be made to make the first example match the format? It isn't obvious how, but, following the rule laid out, it should be 37 Celsius of Patient Body Temperature. If the first example doesn't fit the rule, perhaps the rule needs to be rethought?
    3. P5 - There needs to be some indicator in the color labels aren't correct in this paragraph. While it is fairly obvious, it is always good form to use asterisks (linguistic tradition) or some other notation to make it absolutely clear that this is misuse.
    4. P5 - Units are pink, so the final sentence should say that "UCUM does not support units of "beer" "drinks" ...
    5. P6 - Don't know how "scoops" got introduced, but we need to stick with "drinks" and "tablets" if they were our primary examples.
    6. P6 - Why would "Patient Body Temperature" be a "thing" and "Acetaminophen Tablets" be a thing and a qualifier?
    7. CodingRationale - same argument as w/ CD
    8. "However, for the semantic specification it doesn't matter how the canonical form is built, nor what specific canonical form is chosen, only that some canonical form could be defined." - Does this statement mean that an implementation SHALL produce a canonical form or is it implying that it simply has to have a certificate filed away somewhere that says that it is possible to do as much? (i.e. does a compliant application have to generate canonical forms on demand?).
  • 5.7 Physical Quantity Representation (PQR) specializes CV
    1. This kind of looks like a last minute addition. 5.7.7 is kind of late in the game to say that PQR is a translation of a PQ which has an originalText...' How is a PQR generated from a PQ? How do I get back to the PQ to get the originalText? Can a PQR be promoted (demoted?) (transformed?) to a PQ?
  • 5.8 Monetary Amount (MO) specializes QTZ
    1. "For large amounts, it is important not to store MO values in floating point registers, since this may lose precision. " - useful advice, but strangely out of place in an abstract specification
    2. A line in front of the table saying that the following table lists some of the more common currency codes would make the reading smoother.(and they, you might want to make sure that you indeed have the more common ones...)
  • 5.9 Calendar (CAL) specializes DSET<CLCY>
    1. Figure 11 is really fun!
  • 5.10 Calendar Cycle (CLCY) specializes ANY
  • 5.11 Point in Time (TS) specializes QTY
  • 5.12 Expression (EXPR) specializes T
    1. There appears to be a typo in table 50 - the links need to be "ED" and "EXPR<T>" rather than "dt-ED" and "dt-EXPR<T>"
    2. 5.12.1 and 5.12.2 same - dt- in both
    3. 5.12.3 - "This is a very simple language to support common dosage formulas..." - what is the scope of this language (i.e. is it a common language used in pharmacy applications, a language used in HL7 apps or a language that was developed just for this data type?) If the latter, it seems a bit presumptuous (and confusing) to give it a first class name.