Difference between revisions of "Proposal For Data Type Vocabulary Management"
Rene spronk (talk | contribs) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 88: | Line 88: | ||
== Special Case == | == Special Case == | ||
| − | It's unclear what to do with NullFlavor. In theory, it's just a | + | It's unclear what to do with [[NullFlavor]]. In theory, it's just a |
standard domain, but in practice there is some special rules | standard domain, but in practice there is some special rules | ||
about nullFlavor implications that mean that there is some | about nullFlavor implications that mean that there is some | ||
| 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. | ||
| − | |||
| − | |||
| − | |||
Latest revision as of 08:42, 22 December 2006
Contents
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.
