TECHNICAL REVIEW
| Issue | Resolution actions |
|---|---|
Born inactive stated relationships found for PreAlpha20170131 release RESOLUTION: Relevant born inactive relationships deleted. | MCH - These born inactive concepts and stated relationships were not identified during authoring validation due to we don't run these type of assertions as they compare against previous release package which slows down the validation process. Maybe we should consider to update existing assertions so that they can be run at task/project level validations as well. These assertions are run during the daily release build. AAT - we therefore asked Monica/Donna whether or not we have scope to have the RVF slightly in order to cover these issues as part of the authoring task validation. Monica confirmed this would not be possible if these do slow down the validation process.
|
Born inactive concepts found for preAlpha 20170131 release 717739000 20170131 0 900000000000207008 900000000000074008 RESOLUTION: Relevant born inactive concepts deleted. | Same as above |
The following new RVF failure appeared after applying the Alpha feedback fixes that the Content Team implemented: testCategory: "release-type-validation", RESOLUTION: 12 Relationships deleted completely, as they were new to the 20170131 Release cycle, and therefore not previously published. | Same as above |
The following RVF failure was newly added after the Alpha fixes that the Content Team implemented: testCategory: "release-type-validation", RESOLUTION: Concept 723067001 deleted completely, as it was new to the 20170131 Release cycle, and therefore not previously published. | Same as above |
Six concepts are in the 'SNOMED CT model component module (core metadata concept)' module but the relationships in question here are in the 'SNOMED CT core module (core metadata concept)' module. The associated descriptions are all in the same module as the concept entries. 718291003 RESOLUTION: 5 Inferred relationships have been inactivated, and 5 new ones activated with the correct module ID, in order to align the Concept moduleID with the related Relationship moduleID's. The final concept (900000000000441003) is the Model Component concept, and therefore has its Relationship in the Core module and not the Model Component module for a valid reason, as follows: • The 2 root modules (Core and Model Component) were setup in the first place so that the Core was dependent on the Model Component module The only action taken for this concept, therefore, was to update the comments in the code to ensure that this valid state is retained going forward. | This was a defect in the classifier wrapper, which MCH has now resolved. |
ISRS-103, ISRS-104, ISRS-106, ISRS-107, ISRS-108, ISRS-109 and ISRS-110 | These are all to be ignored as warnings - do we need to whitelist these? (especially as we've now open-sourced the RVF) Some of these can be fixed by whitelisting, but some are restraints in the assertions - so we need to fix them. The whitelisting framework is still a reasonably long way away due to capacity - most likely Q3/Q4 2017. |
| The Release Feedback process is labour intensive and could be refined |
|
CONTENT REVIEW
| Issue | Resolution actions |
|---|---|
Three retired concepts have a historical relationship of an inappropriate type: RESOLUTION: IHTSDO Content Team resolved as follows: 139521000: Tingling: [sensation] or [has sensation] (finding) now retired as ambiguous The third concept (700043003) was found to be valid, and therefore no action required | Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward. |
Ten RF1 descriptions for active concepts are status 10 (MOVED_TO), alongside descriptions with active status: RESOLUTION: IHTSDO Content team have inactivated all of the descriptions in question with reason "moved elsewhere" | The Task originally created to resolve this issue somehow got deleted as part of the process, and so never made it into the Jan 2017 Release.
|
Three concepts in RF1 have more than one historical relationship (except MAY_BE_As, MOVED_TOs OR WAS_As): RESOLUTION: IHTSDO Content Team remodelled so that the three concepts now have one reason for inactivation and one historical relationship each as appropriate. | Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward. |
As part of the previous editing cycle, a minor issue was found with several relationships, which had targets with different semantic tags to their sources. In discussion with the Content Team at the time, we agreed to fix all but one, which was seen to be an example of the exception to the rule, and therefore a valid relationship to retain: id effectiveTime active moduleId sourceId destinationId relationshipGroup typeId characteristicTypeId modifierId RULEID SCTID DETAILS TERMLIST RESOLUTION: IHTSDO Content Team remodelled this concept and removed the disorder parent. | Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward. |
The following 3 concepts had the Core module assigned to them during authoring, instead of the Concept Model module: 719367001 RESOLUTION: 3 records updated to the correct ModuleID in the Concept Delta file in the Beta release | These were not assigned, the tool defaulted to the incorrect module ID even when a concept was cloned. Core module vs Model component. This should be default as per hierarchy selected. This was a new item introduced by SCA. Previously it was not a choice for an author to make. Now the team are aware and guidance has been written into the Ed. guide.
|
| ISRS-90 The concept 722541007 has concept modeling of Causative agent (attribute) = Infectious process (qualifier value). The value "infectious process" should not be allowed because it is not in the range for causative agent. RESOLUTION: Relationship record deleted, to remove the erroneous attribute Causative agent (attribute) | This was identified by the new MRCM validation, and therefore the long term solution for this is to get the MRCM rules into both the SCA input validation, and the RVF, so that these issues can be resolved as part of the editing cycle going forward. |
The concept 723017008 has After (attribute) = Intraocular lens implant (physical object). This violated the range for After attribute that should only take values from clinical finding hierarchy or procedure hierarchy. RESOLUTION: Relationship record updated, to change the erroneous attribute Intraocular lens implant (physical object) (313236002), and add in the new attribute 69724002|Insertion of prosthetic intraocular lens (procedure)| | MRCM rules ought to pick this up or not allow improper selection. Batch uploads bypass the MRCM rules therefore these can slip through. Since this occurred, the validation of ICD-11 has been changed from small amounts of spot checks to thorough checking by the ICD-11 authors. |
A new concept - 723067001 | Transcatheter aortic valve replacement (procedure) | - is a duplicate and so has been inactivated within the same authoring cycle. RESOLUTION: Concept deleted completely, as it was new to the 20170131 Release cycle, and therefore not previously published. | This was not a duplicate in fact but in as much as it was questioned by an member from a clinical perspective so the right thing to do was to pull it back till further investigation of meaning was carried out. Therefore this was a one off and will not re-occur. |
ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations.. · AFTER(255234002) - only modelled with valid destination concepts RESOLUTION: 1 Relationship deleted completely, as it was new to the 20170131 Release cycle, and therefore not previously published. | Same as ISRS 91: Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF? |
ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations.. · CAUSATIVE AGENT(246075003) - only modelled with valid destination concepts RESOLUTION: 1 Relationship record updated, in order to replace the Causative agent attribute with Pathological process. | Same as ISRS 90: Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF? |
ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations... · HAS INTERPRETATION(363713009) - only modelled with valid destination concepts RESOLUTION: 3 records removed, plus 3 records added in the Relationship and Stated Relationship Delta files in the Beta release, in order to change the attribute to "Interprets". | Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF? ICD-11 batch allows incorrect attributes to be selected. |
ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations.. · OCCURRENCE(246454002) - only modelled with valid destination concepts RESOLUTION: 2 Relationships deleted completely, as they were new to the 20170131 Release cycle, and therefore not previously published. | Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF? ICD-11 batch allows incorrect attributes to be selected. This is partly due to the fact that an allowable value for this attribute is CONGENITAL so it is easy to presume that ACQUIRED would belong here too. Guidance has been clarified in the Ed. guide. |
ADHA ran the alpha package through their validation routines. Technically, it passed – from a content perspective there looks like a number of concept model violations.. I’ve got almost 700 observable entity concepts failing the tests below… but… · observable entity(363787002) only approved defining attributes used RESOLVED: This was traced back to a change that was made to the Concept model for Observables, that was implemented in September 2016. The editorial guide was updated accordingly, but has not been published since the update was made, and so ADHA did not have visibility of the updates. IHTSDO therefore provided them with the information on the new Concept model, and they will update their validation rules accordingly. This is therefore a non-issue and no action is required. | Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF? Publish the updated editorial guidance along with the Alpha release. |
The following RVF failure is now reporting 7 Active Descriptions that have Inactivation reasons assigned to them: assertionText: "Active descriptions do not have active inactivation indicators", Either the Descriptions need to be inactivated accordingly, or the reasons updated/removed as the Descriptions should remain Active. RESOLUTION: 6 Inactivation reasons were inactivated (as they were previously published), and 1 was deleted (as it was new to this release cycle). |
|
The new refset being added to the January 2017 International Edition (723264001 - Lateralizable body structure reference set (foundation metadata concept)) needs a new record added to the International edition refsetDescriptor files. RESOLUTION: The following refsetDescriptor record has been added accordingly: bbdcc9fc-5bc6-415a-a5ee-c5adfc569bd5 20170131 1 900000000000207008 900000000000456007 723264001 449608002 900000000000461009 0 | This kind of issue is now being addressed by the new Service Acceptance process, which will prevent these kind of pre-dependencies from being missed at the start of projects. |
5251000119108 |Acquired arteriovenous malformation (disorder)| incorrectly uses 255396000 |Acquired (qualifier value)| as the value of |Occurrence| IHTSDO removed attribute value pair of Occurrence - Acquired. Concept therefore needs to be changed to primitive. The related concept, 402847002 |Acquired arteriovenous malformation of the skin (disorder)| was also identified to have an invalid attribute. RESOLUTION: Both concepts have been remodelled accordingly. | Same as ISRS-96 |
Three retired metadata concepts were erroneously moved into the Core module: CONCEPTID CONCEPTSTATUS FULLYSPECIFIEDNAME These metadata concepts were transferred into the core module when they became inactive, so the RF1 conversion tool thinks they're relevant. The RF1 conversion filters out concepts with a metadata semantic tag, but only if they're also in the model module. RESOLUTION: ModuleID for all three concepts assigned to the Model Component module (900000000000012004). | Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward. |
There are 21 Historical Associations that are active, but which have been found to have inactive concepts for their targetComponentID: id effectivetime active moduleid refsetid referencedcomponentid targetcomponentid RESOLUTION: It was discovered that 2 of the above source concepts actually had 2 concepts referenced, and so 23 associationReference records were updated in order to replace the inactive targetComponentID's with the relevant active concepts. In addition to this, the system then automatically inactivated 12 additional associationReference records, where the source concept was also associated to "Limited components" ([900000000000486000|limited]): 95d6b955-adb9-59fc-a011-93ee592153b1 20170131 0 900000000000207008 900000000000527005 149532003 287840006 | This issue needs particular attention, as one of our members is asking why the fix for this changed history? The issue here is that when the targetComponentID has been changed in the past, the record was inactivated and re-created with the new targetComponentID. However, the termServer considered this a mutable field, and therefore since we moved to the termServer if we change the targetComponentID field it will simply update the record instead of inactivating and re-creating.
Both David and Linda agreed the following:
"As far as I can tell there is nothing in the documents that these fields to be immutable. However, there are some reasons that suggest to me it might be better for them to be immutable.
For example:
Arguably the only case where it would "reasonable" to treat the target as mutable would be where
A(inactive)=B(active)
Then B is inactivated and a new historical relationship is added:
B(inactive)=C(active)
in this case one could argue that the transitive result represents an update of the existing association.
A(inactive)=C(active)
However, overall I would suggest that immutability is clearer and safer in all cases. We therefore need to take a look at the termServer functionality and update it accordingly...
|
| Mapping Release Notes - They were questioned by our members due to some inaccuracies in the ICD10 map wording. |
|