Peter, It means "Physical Quantity" and is one of the basic datatypes.
I think it is supposed to be used for measures, but I need to look at more
examples of usage. (01)
Pat (02)
Patrick Cassidy
MITRE Corporation
W903 Information Discovery & Understanding
7515 Colshire Drive
McLean, VA 22102-7508
Phone: 703-883-8976
(Eatontown: 732-578-6340)
Fax: 703-883-1379
Email: pcassidy@xxxxxxxxx
Mail Stop: MNJE (03)
-----Original Message-----
From: health-ont-bounces@xxxxxxxxxxxxxxxx
[mailto:health-ont-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Peter Yim
Sent: Thursday, February 10, 2005 8:48 PM
To: [health-ont]
Subject: Re: [health-ont] Comments on Time concepts in HL7 (04)
Great work, Pat. (05)
A small question ... under the last section:
"DataTypePointInTime", the "PQ" you have there on the first and
last line, what does it stand for? (06)
Tx. -ppy
-- (07)
Patrick Cassidy wrote Thu, 10 Feb 2005 13:47:58 -0500:
> An initial attempt was made to review time-related concepts in HL7 to
> determine how they might map to concepts in an upper ontology.
> Some initial comments are attached as a WinWord file and also appended as
> text. There are additional time-related concepts in HL7, and in
particular
> relations of time to other concepts. These will be reviewed as time
> permits, or if others request further discussion.
>
> Pat (08)
> Patrick Cassidy
> MITRE Corporation
> W903 Information Discovery & Understanding
> 7515 Colshire Drive
> McLean, VA 22102-7508
> Phone: 703-883-8976
> (Eatontown: 732-578-6340)
> Fax: 703-883-1379
> Email: pcassidy@xxxxxxxxx
> Mail Stop: MNJE
>
>
> ===================================== (09)
> Considerations for aligning HL7 Time concepts with an upper ontology (010)
> As part of the Ontolog group participation in discussion of the National
> Health Information Network RFI, we are providing information on how
> ontologies can assist in enabling the interoperability of patient health
> records. At this point, we are focused on how existing and prospective
> health domain ontologies and taxonomies can be aligned with upper
ontologies
> to improve the accuracy of conceptual information transfer among systems
> using different domain knowledge representations. (011)
> For this facet of that task, my immediate focus will be to determine how
the
> representations of time in the HL7 terminology may be related to similar
> concepts in an upper ontology. (012)
> HL7 Information Request (013)
> I have looked at the lists of data types in the html files of the current
> HL7 Reference Model. I also found some definitions of the types in the
XML
> files. However, I have found only a few files related to the relations
> between concepts. I would appreciate help from anyone who can point me to
> the locations of a comprehensive list of the relations that are defined
> between concepts within the HL7 system. In particular, I can't find
> anything describing the relations between time intervals, time points, or
> events that may be specified as taking place at a particular time. (014)
> There are a few additional questions I have: (015)
> Regarding the term "DataType": is this intended to mean that the Type
labels
> used here may be attached to field designators in documents, such as in
> XML-tagged documents? Or are these intended merely as general terms for
> concepts? Or both? (016)
> DataValue: can a data value be qualitative (e.g. color)? I could not find
> color in the classification. Where is that located? (017)
> In examining the files I can find in HL7, there is one issue regarding the
> classification of Time data types that can be discussed with the
information
> I currently have. That issue is discussed below. If anyone has
additional
> information relating to there concepts in HL7, or if I have misinterpreted
> the intended meanings of these concepts, please send me a note
> (cassidy@xxxxxxxxx) or send a note to this list. (018)
> Time Representation
> ------------------------- (019)
> General comments on time representation:
> In order to represent time so as to be broadly compatible with many
> different databases, it is necessary to make at least the following
> distinctions: (020)
> (1) Specific calendar times such as 12:00 Noon GMT on Feb. 5, 2005 need to
> be distinguished from a specific quantity of time, such as 20 minutes. (021)
> (2) A relation between time points of before and after needs to be
defined. (022)
> (3) Relations between specific time intervals, such as coinciding,
> overlapping, or before/after, need to be defined. (023)
> (4) Recurring time intervals, such as days of the week or months of the
> year, need to be distinguished from time points, specific time intervals,
> and quantities of time. (024)
> Time Representation in HL7 (025)
> Within the HL7 data types the following (selected) portion of the taxonomy
> was noted: (026)
> DataTypeDataValue
> DataTypeInterval
> DataTypeIntervalOfPhysicalQuantities
> DataTypeIntervalOfPointsInTime
> DataTypeEventRelatedInterval
> DataTypeGeneralTimingSpecification
> DataTypePeriodicIntervalOfTime (027)
> DataTypeQuantity
> DataTypePhysicalQuantity
> DataTypeParametricProbabilityDistributionOfPhysicalQuantities
> DataTypePointInTime (028)
> It appears that DataTypePointInTime is intended to refer to a specific
point
> in time on the calendar - a specific time location. (029)
>>>A quantity specifying a point on the axis of natural time. A point in (030)
> time is most often represented as a calendar expression (031)
> An interval of time points (DataTypeIntervalOfPointsInTime) would then
> also be a specific time location. (032)
> DataTypeGeneralTimingSpecification is defined as: (033)
>>>A set of points in time, specifying the timing of events and actions (034)
> and the cyclical validity-patterns that may exist for certain kinds of
> information, such as phone numbers (evening, daytime), addresses (so
> called "snowbirds," residing in the south during winter and north
> during summer) and office hours. (035)
> There is a problem with this arrangement: The instances of the parent
class
> (Type) DataTypeIntervalOfPointsInTime are each a single interval of time,
> but the suggested instances of this class (evening, wintertime), are
> conceptually each themselves not single time intervals, rather they are
> classes of time intervals (i.e., all evenings, etc.). For example, in the
> SUMO ontology, Monday is a subclass of TimeInterval, not an instance.
Thus
> this class (Type) would not fit into a schema where instances are intended
> to be individuals. This schema above can work for its intended purpose if
> users did not attempt to draw logical inferences from the subclass
structure
> that is given here, but merely used the terms in a single restricted
manner. (036)
> If this conceptual classification is intended to at some point map
to
> other classifications, however, it will be important to keep the logical
> meanings consistent for all inherited instances within a subclass
structure.
> In this case, there are two possibilities to modify the existing
> arrangement: (037)
> (1) the class (Type) DataTypeGeneralTimingSpecification can be left in
its
> present position, but the types of recurrent time interval which are
> intended to be used (evening, Winter, Mondays from 9 to 5) should each be
> entered as a subclass (subtype) of that class, rather than as instances.
> Such subtypes will themselves have instances which are specific time
> intervals (e.g., Monday, Feb. 7, 20005, GMT would be an instance of the
> class Monday), but perhaps more commonly the classes (e.g. Monday) would
be
> the individual data elements that are used in medical records or other
> communications. (038)
> (2) If it is desired that all data elements used in data communications be
> instances of a designated data type, and must not be subclasses, the
class
> of DataTypeGeneralTimingSpecification should be moved from its present
> position to a higher level in the DataType hierarchy, at the same level as
> DataTypeIntervalOfPointsInTime. Then each instance of this class , though
> it is also conceptually a class, could be used as a data value while
> conforming both to the general schema, and to a strict logical inheritance
> rule that will enhance interoperability. (039)
> On the related Type DataTypePeriodicIntervalOfTime, I could not find the
> notes describing its intended meaning, and it is not clear how this
differs
> from DataTypeGeneralTimingSpecification. Perhaps this is intended to
> represent strictly periodic intervals? or blocks of time, such as one
week?
> The definition or a pointer to the definition of this concept would be
> helpful.
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/health-ont/
Community Files: http://ontolog.cim3.net/file/work/health-ont/NHIN-RFI/
To Post: mailto:health-ont@xxxxxxxxxxxxxxxx
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?NhinRfi (040)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/health-ont/
Community Files: http://ontolog.cim3.net/file/work/health-ont/NHIN-RFI/
To Post: mailto:health-ont@xxxxxxxxxxxxxxxx
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?NhinRfi (041)
|