This wiki has undergone a migration to Confluence found Here

Proposal For Data Type Vocabulary Management

From HL7Wiki
Revision as of 20:13, 14 August 2006 by GrahameGrieve (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Vocabularies in Data Type Ballot

  • NullFlavor
  • MediaType
  • Charset
  • CompressionAlgorithm
  • IntegrityCheckAlgorithm
  • URLScheme
  • TelecommunicationAddressUse
  • AddressPartType
  • PostalAddressUse
  • EntityNamePartType
  • EntityNamePartQualifier
  • EntityNameUse
  • Currency
  • CalendarCycle
  • Calendar
  • TimingEvent
  • GTSAbbreviation
  • ProbabilityDistributionType

Categories

Overall, there is 4 categories for how to manage the terminologies. A number of these terminologies are managed by some other SDO, so there is no management involved. Some of the terminologies are explicitly bound to the xml representation (in element names) so can only be changed through balloting the XML data types ITS. Also there is some domains that are explicitly involved in the interpretation of the wire format, and these should only change with the ballot. Finally, there is 4th group of terminologies that are only relevant for the interpretation of the data, and these can change at harmonization like other terminologies.

Externally Managed Terminologies

HL7 does not manage these terminologies, so we do not need to make changes.

  • MediaType
  • Charset
  • Currency
  • URLScheme

We do make some recommendations on which of these should or should not be supported, but there appears to be no strong desire to change these in any hurry, so it's ok to do this with the ballot cycle.

Domains that are bound the XML Element Names

These domains lead directly to XML element names. They should only be changed in association with the ballot

  • AddressPartType
  • EntityNamePartType

Domains that are required to understand the XML

Changes to these affect the reading of the wire format directly, or are part of the internal infrastructure of the data types concepts, and changes should only be made through the ballot process.

  • CompressionAlgorithm
  • IntegrityCheckAlgorithm
  • CalendarCycle
  • Calendar

Domains that can be changed through harmonization

These domains have no infrastructural consequences, and can be changed through harmonisation like other HL7 vocabularies

  • TelecommunicationAddressUse
  • PostalAddressUse
  • EntityNamePartQualifier
  • EntityNameUse
  • TimingEvent
  • GTSAbbreviation
  • ProbabilityDistributionType


Special Case

It's unclear what to do with NullFlavor. In theory, it's just a standard domain, but in practice there is some special rules about nullFlavor implications that mean that there is some very structural implications for interpretation of data, and these kind of items should not be introduced except through a ballot cycle.

Special cases:

  • NINF & PINF: change the implication of a partially populated IVL<T>
  • TRC & QS: changes the interpretation of other data

Note that these are special because if you collapse these to NI, not only do you lose information about why the data is null, you lose other derived information - this is different to other nullFlavors

Note that QS has been added through harmonisation since the last ballot.


  • NullFlavor