This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Code System Versioning"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
|||
| Line 1: | Line 1: | ||
Code system versioning - Many functions (e.g. isConceptIdValid) might benefit from including ReleaseVersion.release_id as a parameter. For instance, a concept introduced to SNOMED CT in the January 2005 release will return isConceptIdValue=FALSE if tested against the January 2004 release, but is valid nonetheless | Code system versioning - Many functions (e.g. isConceptIdValid) might benefit from including ReleaseVersion.release_id as a parameter. For instance, a concept introduced to SNOMED CT in the January 2005 release will return isConceptIdValue=FALSE if tested against the January 2004 release, but is valid nonetheless | ||
| + | |||
| + | == Use Case Name: Code System Version Enumeration == | ||
| + | * '''Description:''' The user needs to determine the what different versions of a code system exist on a specific instance of a CTS service. | ||
| + | * '''Who needs it and why?''' - General requirement for messaging and querying terminology services. | ||
| + | # A message may deliver data in a coded datatype. | ||
| + | ## To support interoperability when receiving messages from multiple different systems. Where only the code and code system/version is supplied then a query on terminology service would return the display name. This would also apply if using a version of the code system to manage different languages | ||
| + | ## Where code, code system/version, and display name is included in the message then a query on the terminology service would check the validity of the code against the version held in the receiving system. | ||
| + | * '''Why should this be standardized?''' - This needs to be standardized as code systems are standard HL7 vocabualry objects, and are frequently versioned for a variety of reasons. Where code system versioning not standardised then it will not be possible to achieve semantic interoperability for this type of data | ||
| + | <br/> | ||
| + | * '''Questions and issues:''' | ||
| + | ** HL7 Version 2 coded entry data type (CE) there is provision for the code,description,code system identifier, and code system version. | ||
| + | How do versions fit into the HL7 CD Data types? | ||
| + | ** Since HL7 assigns an OID and version number for a code system, does CTS1 allow the version to be queried? Does CTS1 (HL7 uses the OID only, and not the version number.) | ||
| + | ** CTS 2 should use the code system OID and Version number when regestering code systems. | ||
| + | <br/> | ||
| + | |||
| + | == Use Case Name: Code System Version History By Concept Code == | ||
| + | * '''Description:''' The user needs to determine the history of a concept code within a code system. | ||
| + | * '''Who needs it and why?''' - General requirement for messaging and querying terminology services. | ||
| + | # A message may deliver data in a coded datatype. | ||
| + | ## To support interoperability when receiving messages from multiple different systems. Where only the code and code system/version is supplied then a query on terminology service would return the display name. This would also apply if using a version of the code system to manage different languages | ||
| + | ## Where code, code system/version, and display name is included in the message then a query on the terminology service would check the validity of the code against the version held in the receiving system. | ||
| + | #The interface needs to support: | ||
| + | ## The ability to query version history by concept code - when it was introduced, when it was changed, when it was withdrawn, what happened to it, etc. | ||
| + | * '''Why should this be standardized?''' - This needs to be standardized as value sets are standard HL7 vocabualry objects. Where code system versioning not standardised then it will not be possible to achieve semantic interoperability for this type of data | ||
| + | <br/> | ||
| + | * '''Questions and issues:''' | ||
| + | ** HL7 Version 2 coded entry data type (CE) there is provision for the code,description,code system identifier, and code system version. | ||
| + | How do versions fit into the HL7 CD Data types? | ||
| + | ** Since HL7 assigns an OID and version number for a code system, does CTS1 allow the version to be queried? Does CTS1 (HL7 uses the OID only, and not the version number.) | ||
| + | ** CTS 2 should use the code system OID and Version number when regestering code systems. | ||
| + | <br/> | ||
| + | |||
| + | |||
| + | == Use Case Name: Code System Version Selection/Query == | ||
| + | * '''Description:''' The user needs to select a specific version of a terminology and make queries relative to that version. | ||
| + | * '''Who needs it and why?''' - General requirement for messaging and querying terminology services. | ||
| + | # A message may deliver data in a coded datatype. | ||
| + | ## To support interoperability when receiving messages from multiple different systems. Where only the code and code system/version is supplied then a query on terminology service would return the display name. This would also apply if using a version of the code system to manage different languages. | ||
| + | ## Where code, code system/version, and display name is included in the message then a query on the terminology service would check the validity of the code against the version held in the receiving system. | ||
| + | #The interface needs to support: | ||
| + | ## The ability to select a specific version of a terminology and make queries relative to that version | ||
| + | * '''Why should this be standardized?''' - This needs to be standardized as value sets are standard HL7 vocabualry objects. Where code system versioning not standardised then it will not be possible to achieve semantic interoperability for this type of data | ||
| + | <br/> | ||
| + | * '''Questions and issues:''' | ||
| + | ** HL7 Version 2 coded entry data type (CE) there is provision for the code,description,code system identifier, and code system version. | ||
| + | How do versions fit into the HL7 CD Data types? | ||
| + | ** Since HL7 assigns an OID and version number for a code system, does CTS1 allow the version to be queried? Does CTS1 (HL7 uses the OID only, and not the version number.) | ||
| + | ** CTS 2 should use the code system OID and Version number when regestering code systems. | ||
| + | <br/> | ||
Latest revision as of 11:26, 30 April 2006
Code system versioning - Many functions (e.g. isConceptIdValid) might benefit from including ReleaseVersion.release_id as a parameter. For instance, a concept introduced to SNOMED CT in the January 2005 release will return isConceptIdValue=FALSE if tested against the January 2004 release, but is valid nonetheless
Use Case Name: Code System Version Enumeration
- Description: The user needs to determine the what different versions of a code system exist on a specific instance of a CTS service.
- Who needs it and why? - General requirement for messaging and querying terminology services.
- A message may deliver data in a coded datatype.
- To support interoperability when receiving messages from multiple different systems. Where only the code and code system/version is supplied then a query on terminology service would return the display name. This would also apply if using a version of the code system to manage different languages
- Where code, code system/version, and display name is included in the message then a query on the terminology service would check the validity of the code against the version held in the receiving system.
- Why should this be standardized? - This needs to be standardized as code systems are standard HL7 vocabualry objects, and are frequently versioned for a variety of reasons. Where code system versioning not standardised then it will not be possible to achieve semantic interoperability for this type of data
- Questions and issues:
- HL7 Version 2 coded entry data type (CE) there is provision for the code,description,code system identifier, and code system version.
How do versions fit into the HL7 CD Data types?
- Since HL7 assigns an OID and version number for a code system, does CTS1 allow the version to be queried? Does CTS1 (HL7 uses the OID only, and not the version number.)
- CTS 2 should use the code system OID and Version number when regestering code systems.
Use Case Name: Code System Version History By Concept Code
- Description: The user needs to determine the history of a concept code within a code system.
- Who needs it and why? - General requirement for messaging and querying terminology services.
- A message may deliver data in a coded datatype.
- To support interoperability when receiving messages from multiple different systems. Where only the code and code system/version is supplied then a query on terminology service would return the display name. This would also apply if using a version of the code system to manage different languages
- Where code, code system/version, and display name is included in the message then a query on the terminology service would check the validity of the code against the version held in the receiving system.
- The interface needs to support:
- The ability to query version history by concept code - when it was introduced, when it was changed, when it was withdrawn, what happened to it, etc.
- Why should this be standardized? - This needs to be standardized as value sets are standard HL7 vocabualry objects. Where code system versioning not standardised then it will not be possible to achieve semantic interoperability for this type of data
- Questions and issues:
- HL7 Version 2 coded entry data type (CE) there is provision for the code,description,code system identifier, and code system version.
How do versions fit into the HL7 CD Data types?
- Since HL7 assigns an OID and version number for a code system, does CTS1 allow the version to be queried? Does CTS1 (HL7 uses the OID only, and not the version number.)
- CTS 2 should use the code system OID and Version number when regestering code systems.
Use Case Name: Code System Version Selection/Query
- Description: The user needs to select a specific version of a terminology and make queries relative to that version.
- Who needs it and why? - General requirement for messaging and querying terminology services.
- A message may deliver data in a coded datatype.
- To support interoperability when receiving messages from multiple different systems. Where only the code and code system/version is supplied then a query on terminology service would return the display name. This would also apply if using a version of the code system to manage different languages.
- Where code, code system/version, and display name is included in the message then a query on the terminology service would check the validity of the code against the version held in the receiving system.
- The interface needs to support:
- The ability to select a specific version of a terminology and make queries relative to that version
- Why should this be standardized? - This needs to be standardized as value sets are standard HL7 vocabualry objects. Where code system versioning not standardised then it will not be possible to achieve semantic interoperability for this type of data
- Questions and issues:
- HL7 Version 2 coded entry data type (CE) there is provision for the code,description,code system identifier, and code system version.
How do versions fit into the HL7 CD Data types?
- Since HL7 assigns an OID and version number for a code system, does CTS1 allow the version to be queried? Does CTS1 (HL7 uses the OID only, and not the version number.)
- CTS 2 should use the code system OID and Version number when regestering code systems.
