This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Proposal For Data Type Vocabulary Management"

From HL7Wiki
Jump to navigation Jump to search
m
Line 104: Line 104:
  
 
Note that QS has been added through harmonisation since the last ballot.
 
Note that QS has been added through harmonisation since the last ballot.
 
 
* NullFlavor
 

Revision as of 20:16, 14 August 2006

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.

For those domains that can only be changed by ballot, INM is happy to receive change proposals from the harmonisation process, and these will be treated favorably.

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.