V3DT conference call notes for Mon, Feb 8, 1999.

The HL7 version 3 data type task group has had its fifteenth conference call on Monday, February 8, 1999, 11:00 to 12:30 EST.

Attendees were:

Agenda items were:

  1. The Orlando aftermath - new ideas, new directions ...

    ... you name it. This will be timeboxed to 30 minutes. We go in two rounds:

    1. Brainstorming: people will name key words and short descriptions of their issues
    2. Sweeping: we will sort things into bundles, and clarify, resolve, or assign for further work.

  2. Real World Instances - what, whether, and, if so, how?

Agenda Item 1: The Aftermath ... new ideas, new directions, etc.

First Round: Brainstorming

Stan Huff

1. We need to be more clear on how such constructs as implicit type conversion or the No Information data type are actually implemented. This means both

2. We need to specify how we express constraints (syntax and semantics of constraint expressions.) Probably, we'll have special constraint expressions for primitive data types and generic expressions for the various composites or collection types.

3. We need more intuitive representations of many of the composite types, e.g. forms to express an Interval simply as, e.g., "<3.4".

GS: This is going to be handled by character string literals. We want intuitive string literals to be available (independently from the ITS). String literals make most sense for XML ITS, since one of the benefits of XML are the alleged "human readability" of the raw XML source. This readability would be enhanced by literals that are friendly to the human eye, rather than composite structures that just reflect the abstract syntax or semantic components.

Clarifying question by Mark Shafarman: those literals would be defined for all ITSs alike. An ITS may or may not choose to deploy a literal form for a fine grained composite element.

4. Annotation should include codes. With this, Stan points out that in the notes and the Orlando Report some conclusions not actually reflect the consensus of the respective phone conference.

GS: I admit that in some places I diverted from what we settled in the calls. Those areas are:

We will of course have to come back to those issues to make sure the proposal reflects the consensus of the task force. I invite everyone to stand and write down a consistent argument that would defeat my choice.

The question of the two data types for physical and monetary quantities was also addressed in my recent public e-mail discussion with Woody Beeler. What it boils down to in part is: when do we deploy domain constraint and when do we define a new data type.

Stan Huff put it this way (and I very much agree): When a data type with a certain constraint is reused in many places, this would suggest to define a top-level type name for the data type with this particular constraint. The advantages are consistency and maintenance. a type name would guarrantee consistency in the way the constraint is expressed, since the same constraint is just reused not rewritten. If a change needs to be made to the constraint, it can be made in just one place and take effect at all points of use.

GS: However, this maintenance issue has a straight flip side: if the same type was used in different places with different intentions and assumptions, and the modification renders any of those assumptions questionable or invalid, then it would have been better to not subsume the particular type-constraint-configuration unto one data type name. This is what I mean that types ought to be clearly defined semantic entities so that you can be sure that they used everywhere with the same intentions and assumptions.

4. Stan believes that the data type models are exactly the way they should be from a semantic point of view. However, practical simplicity in the use of those types could be reached by flattening the models For example, number - interval - measurements - ... - are now expressed through nested generic types, but those structures may suffer difficulty in use.

Namely, the access paths of deeply nested types are quite long, which Stan regards as being a problem. For instance, suppose we defined type T nesting types U and V. The accessor path would be t.u.v insetead of simply t.v if the U-level would be flattened away.

However, Stan agrees that flattening is only possible if multiplicities are 1 to 1.

5. Do we understand the TII now? How do we support the use cases people associated with the "assiging authority" information. E.g., how can I call somebody to ask whether the specimen of my order was good? How can I contact a person in charge of some object? How can I contact a system that hosts a given object?

Woody Beeler

From the e-mail discussion, Woody likes to follow up on two central issues:

1. Representation of DTs as an HMD. Woody accepts my concern about abstract syntax being the normative part of the high level HL7 specification. But he does not consider HMDs to be just abstract syntax definition either. Thus an ITS could use a different abstract syntax than the one suggested by a naive interpretation of an HMD.

An ITS specification of a data type (or any other part of an HMD) could use less components than the HMD specification suggests.

However, conformance and interoperability would require this mapping between different abstract syntaxes to be semantically isomorphic. This means that all the semantic components that we identify in the data type specification (or the HMD) must be recoverable in any of the representations.

With this corrected understanding of the HMD, type definition boxes used in our DT proposal are very similar, if not the same, as HMD tables.

GS: Cool! This means I can safely withdraw my concerns about the HMD being too specific about abstract syntax.

2. The generality of nested generic types and collections should somoehow be constrained, so that we have a bounded set of data types that commitees will use.

For this he likes to subtype the class of generic types into those generic types that apply to all vs. those that only apply to some base data types.

We will follow up on the channel definition example.

R. Woody now believes that the issue titled "once a list, always a list" would be accepted affirmative. And placed as a call for challenging examples. This means, we would assume that the same RIM attribute could not swich between elementary type and collection thereof. Once a collection, always a collection.

Mark Shafarman

1. When domain TCs define composite data types, they should review their approach with Control Query. Control Query's task is it to make sure the new types are consistent with what is already there and that it follows certain technical and style requirements. (GS: yes, however, we need to objectify the style requirements to keep ourselves (i.e. CQ) from making arbitrary decisions on what does and does not go).

2. Constraints on data types can leverage initial field review that occured in the templates group. Some available alternatives are a tabular form vs. language-like expressions of constraints.

Joann Larson

Joann and Mike remembered well the consternations they stired up by pointing out that PAFM actually consider's "mother's maiden name" to be a Stakeholder_identifier. Woody puts it this way: "is stakeholder id a generic attribute for stakeholder or a identifier?"

Second Round: Clustering the issues.

Agenda Item 2: Real World Instances - what, whether, and, if so, how?

My next agenda item would be what we are going to do about real world instances:

PN, XON, AD, PL, DLN, ...

My take on it is this:

do not define data types for: PN, XON, AD, PL, since those appear only once in the RIM and are already modeled (XON, PL) or are being modeled (AD). We should come up with a class definition for person name that is truly international, including all ramifications.

The only thing I am not sure about is DLN et. al. I am almost inclined to recommend making Stakeholder_id a data type. SSN, DLN, Passport-Number, Inventory-Number, etc. are identifiers not only used for stakeholders. For example, the Animal proposal will need an animal identifier ... and Animal would not be a stakeholder.

The other way to go would be to generalize stakeholder id to

class RealWorldInstanceId { type_cd : CodeValue; id_txt : CharacterString; has_issuing_authority :: Stakeholder; }

This would be the ultimate choice, if we need that real association to real stakeholders. In my world, it is not allowed to associate with any RIM class instance from within a data type. In other words, there should be no hidden forreign keys to RIM classes within data types. This would prevent us from doing issuing_authority in the OID way. Since, in real world identifiers, issuing authority is also a real world authority, and I am very interested which one it is.

However, we have a dilemma. We need to pursue PAFM to step back from their idea that "mother's maiden name" is a stakeholder identifier. May be not. But we have to rename that class and make it useful for other kinds of real world instances, like devices, things, animals.

The location stuff will be attacked by the Animal/PublicHealth/Epidemiology proposal. PL is already in the RIM as Patient_location. AD will be part of a generalized location class. So, I see no need for an AD data type. Sounds strange, I know, but it the reasonable thing to do.

Woody Beeler reports that Mark Tucker and Jack Harrington hold that data types are classes where we are not worried about their idetity. If we make classes from these former data types, we could create a set of CMETs for those data type-like classes and it becomes functionally the same as data types.

Woody also suggests that if we make PN and AD classes we should put it into CQ domain instead of PAFM. PAFM is already overloaded with a lot of stuff, and CQ could concentrate better on the internationalization issues.

Mark Shafarman sais that we want to control the numbers of different forms of data types. We want to handle Internationalization right. Whatever we do on those types should remain in the realm of CQ.

Woody suggests (but is usure about this) we could use OIDs for stakeholders that only act as identifier issueing authorities. Every user/organization will have an OID name space anyway, so the real world instance identifier would look similar to a TII, just that the "extension" field would be named identifier_text (or the like) and be required rather than optional. A couple of well known OIDs would be used for assigning authorities that everyone knows of (e.g. Social Sec. Authority, or the like). HL7 could allocate OIDs for those in its own name space.

Joann and Mike will find a specification of postal address forms from the "internatiunal postal union" (IPU). ... They did their homework promptly and reported this very informative publication. However, it seems like the model address cheat sometimes, since they use trivial post box addresses when you would really like to see how a streat address looks like. It leaves a lot to further research or guess. Strawman proposal on external id numbers --- PAFM? CFP to ... next:

Issues to tackle in the next calls are:

  1. Person name
  2. Postal address
  3. Real World Instance identifier

Next conference call is next Monday, Feb 15, 1999, 11:00 AM EST.

Agenda items are:

  1. External Identifier


-Gunther Schadow