PDF: Force Page Break

1 Introduccio?n 

1.1 Generalidades 

1.2 Propo?sito 

1.3 Alcance 

1.4 A quie?n se dirige este documento 

• Se agregaron 100 nuevos conceptos anato?micos que representan los diferentes cortes de la pro?stata para apoyar las anotaciones para procedimientos de diagno?stico por ima?genes. Los nuevos co?digos esta?n incluidos en el subconjunto de DICOM para informes estructurados. 

2.2.2 Escala de evaluacio?n 

• Se agregaron 750 conceptos nuevos solicitados para la representacio?n de escalas de evaluacio?n y conceptos asociados, como procedimientos y entidades observables relacionadas con el registro de dichas escalas. 

2.2.3 Terminologi?a Me?dica Convergente (CMT) 

• Continuamente se agregan nuevos conceptos. 

2.2.4 Odontologi?a 

• Para continuar con las mejoras en la cobertura del dominio de la periodontologi?a, se agregaron ma?s de 90 conceptos asociados a el subconjunto de Odontologi?a. 

  2.2.4.1 Cephalometry

• Se agregaron 23 nuevos conceptos relacionados con la cefalometri?a, un dominio especializado de la odontologi?a, como subtipos de 698965000 |entidad anato?mica inmaterial (estructura corporal)| 

2.2.5 Procedimientos de diagno?stico por ima?genes 

• Se agregaron 23 nuevos conceptos para representar subtipos de 430447002 |tomografi?a computarizada para planificacio?n de radioterapia (procedimiento)| en localizaciones especi?ficas 

2.2.6  LOINC

2.2.7  Dispositivos me?dicos 

• Se actualizo? el contenido correspondiente a dispositivos me?dicos para alinearlo con la publicacio?n mensual de GMDN hasta abril de 2016, inclusive. Esto dio lugar a la incorporacio?n de 208 conceptos nuevos. El vi?nculo con GMDN se representa en un fichero de referencias cruzadas simples y tambie?n es congruente con la actualizacio?n mensual de GMDN hasta abril de 2016. El trabajo futuro incluira? la resolucio?n de conceptos duplicados. 

2.2.8 Organismos 

• Se agregaron 205 conceptos nuevos para facilitar la realizacio?n de informes de resultados microbiolo?gicos (en las jerarqui?as Organismo y Hallazgo). Este cambio se produjo como resultado de las peticiones de cambio del SIRS, el ana?lisis de las deficiencias de la cobertura del contenido identificadas en el NRC Refset (como componente del ana?lisis retrospectivo luego del cierre del proyecto de informes microbiolo?gicos) y recomendaciones realizadas por el proyecto Redisen?o del a?rea sema?ntica de Organismos y de Enfermedades Infecciosas. 

2.2.9 Productos farmace?uticos/biolo?gicos 

• Tareas menores de mantenimiento. 

   

PDF: Force Page Break

3 Technical notes

3.1 Known Issues

Known Issues are content or technical issues where the root cause is understood, and the resolution has been discussed and agreed but has yet to be implemented.  This can be due to a number of reasons, from lack of capacity within the current editing cycle, to the risk of impact to the stability of SNOMED CT if the fix were to be deployed at that stage in the Product lifecycle.  

For the Snomed CT July 2016 International edition, the following Known Issues were identified, and agreed to be resolved in the next editing cycle (to be published in January 2017):

PDF: Force Page Break

3.2 Resolved Issues

Resolved issues are Known Issues which were not fixed as part of the previous release lifecycle, but which have now been resolved in the latest release - in this case the July 2016 International Edition.  They can also be issues found during the Alpha and Beta testing of the current release, which were resolved before the final deployment of the associated Member release.  Finally they can be issues which were reported or found during the testing phase, but which have been closed without any action taken.  

The Resolved Issues for the Snomed CT July 2016 International edition can be found here:

PDF: Force Page Break

3.3 Technical updates

Complex map files

In line with the ICD-9-CM deprecation process described in section 2.4.2 above, the complex map files have been removed from the RF2 release package.  This is because the ICD-9-CM map constituted the entirety of the complex map files, and as this map has now been deprecated, there is no longer a use case to include the complex map files.  The same applies to the ICD9 CrossMaps files in the RF1 package, which have been removed for the same reason.

RF1 package

In line with the RF1 deprecation plan approved by the General Assembly in October 2015, IHTSDO will take a new approach to generating qualifying relationships in the RF1 distribution of the SNOMED CT International Edition.

The scope of qualifying relationships in the July 2016 International Edition will be limited to Lateralization Qualifying Relationships in the Body Structure hierarchy. The conversion utility will take a RF2 Laterality reference set as its input.  The RF2 Laterality reference set will be available from the IHTSDO Licensing and Distribution system (MLDS). The approach also removes qualifiers not related to body structures because these cannot be reproduced algorithmically. This approach is required so that the new algorithmic derivation of RF1 files from the authoritative RF2 distribution can be run independently of IHTSDO from 2017 onwards.

File types now removed from the RF1 package

The following files will be removed from the RF1 package, as they are incompatible with the new algorithmic RF1 conversion process, which (as detailed above) needs to be self-contained going forward:

• res1_DualKeyIndex_Concepts-en-US_INT_[date].txt
• res1_DualKeyIndex_Descriptions-en-US_INT_[date].txt
• res1_WordKeyIndex_Concepts-en-US_INT_[date].txt
• res1_WordKeyIndex_Descriptions-en-US_INT_[date].txt
• res1_Canonical_Core_INT_[date].txt
• der1_CrossMaps_ICDO_INT_[date].txt
• der1_CrossMapSets_ICDO_INT_[date].txt
• der1_CrossMapTargets_ICDO_INT_[date].txt

Resource Filename update

The naming convention for the Stated Relationship to OWL resource file has been updated from “tls2_StatedRelationshipsToOwlKRSS_INT_[date].pl” to “tls2_StatedRelationshipsToOwlKRSS_Script_INT_[date].pl”

RF2 package format

For future reference, the RF2 package convention dictates that it contains all relevant files, regardless of whether or not there is content to be included in each particular release.  Therefore, the package contains a mixture of files which contain both header rows and content data, and also files that are intentionally left blank (including only a header record).  The reason that these files are not removed from the package is to draw a clear distinction between

1. ...files that have been deprecated (and therefore removed from the package completely), due to the content no longer being relevant to RF2 in this or future releases, and 
2. ...files that just happen to contain no data in this particular release (and are therefore included in the package but left blank, with only a header record), but are still relevant to RF2, and could therefore potentially contain data in future releases.

This allows users to easily distinguish between files that have purposefully been removed or not, as otherwise if files in option 2 above were left out of the package it could be interpreted as an error, rather than an intentional lack of content in that release.