Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| Readme file | n/a | Updated with Production naming convention as expected | |
| MRCM Attribute Domain files | 0 | NO records had their UUID's refreshed as expected, as we added the Member UUID's back into the master MRCM spreadsheet in order to keep them consistent between the Member release and public Production release | |
| Relationship files | 8 | 1 record replaced as follows - Kai confirmed this is fine due to reconciliation code: < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 Finally 7 role group changes which Kai already confirmed are valid. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| MRCM Attribute Domain files | 5 | 5 new records had their UUID's refreshed as expected | |
| Relationship files | 19 | 1 record replaced (back to how it was in the Beta!) as follows - Kai confirmed this is fine due to reconciliation code: < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 Finally 17 role group changes which Kai already confirmed are valid. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| MRCM Attribute Domain files | 5 | 5 new records had their UUID's refreshed as expected | |
| Readme | n/a | Beta wording updated to Member as expected | |
| Relationship files | 19 | 1 record replaced (back to how it was in the Alpha?!) as follows - Kai confirmed this is fine due to reconciliation code: < 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Plus 1 record had it's ID updated, as expected in ISRS-587: < 6573891021 20190731 1 900000000000207008 716092007 91431006 5 116676008 900000000000011006 900000000000451002 Finally 17 role group changes which Kai already confirmed are valid. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| RefsetDescriptor files | 1 | 1 record updated with the new attributeType ("URL" instead of "parsable string), as expected in ISRS-583: < a87a81a3-b10c-490b-9cc1-d94fafc5dc27 20170731 1 900000000000012004 900000000000456007 723560006 723570008 707000009 7 | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| MRCM Attribute Domain files | 10 | 5 July 2019 Alpha records (for Domain 781405001) removed completely (as never published), plus 5 Jan 2019 Published records (for Domain 373873005) inactivated, plus 5 July 2019 Beta records newly added (for Domain 781405001) to replace them, as expected in ISRS-564: < 03b4720d-5840-41d5-bcf4-884c603acc28 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 < 16965a9c-e4ba-4348-9b45-03150f74986c 20190731 1 900000000000012004 723561005 774161007 781405001 1 0..* 0..1 723597001 723596005 < b1bfe4c7-b443-45fa-9653-108093235e5a 20190731 1 900000000000012004 723561005 774160008 781405001 1 1..* 1..1 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 < be279b7b-2331-496c-b3e6-51b94df106fc 20190731 1 900000000000012004 723561005 774163005 781405001 1 0..* 0..1 723597001 723596005 > 391f932e-3158-47bb-a95e-a2b1c19e864d 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 | |
| MRCM Attribute Range files | 5 | ISRS-564 | 5 records had the DomainID changed, as expected in ISRS-564 + "OR Medicinal product package (product)" clause removed from all records to correct erroneous Beta Version 1: < 2affaf44-9365-4d6d-84d3-31409206a77a 20190131 1 900000000000012004 723562003 774158006 << 774167006 | Product name (product name)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774158006 |Has product name| = << 774167006 | Product name (product name)| 723597001 723596005 < 355c9063-7238-4409-81a8-13f22b2a8bff 20190131 1 900000000000012004 723562003 774161007 < 260299005 |Number (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774161007 |Has pack size| = < 260299005 |Number (qualifier value)| } 723597001 723596005 < 608ab6f5-6830-4294-926a-5c3a20b62060 20190131 1 900000000000012004 723562003 774159003 << 774164004 | Supplier (supplier)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774159003 |Has supplier| = << 774164004 | Supplier (supplier)| 723597001 723596005 < e491647d-1793-4b20-b92d-c1180a96b00f 20190131 1 900000000000012004 723562003 774163005 << 767524001 |Unit of measure (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774163005 |Has pack size unit| = << 767524001 |Unit of measure (qualifier value)| } 723597001 723596005 < e5945adf-c075-4fb7-8f1b-515a124326cf 20190131 1 900000000000012004 723562003 774160008 << 763158003 |Medicinal product (product)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774160008 |Contains clinical drug| = << 763158003 |Medicinal product (product)| } 723597001 723596005 |
| Relationship files | 19 | The only changes were Role Group changes, which Kai has already confirmed are valid (plus Yong also confirmed that all role group only changes are valid, as long as they're not Group 0): < 2254342027 20190731 1 900000000000207008 238756007 2789006 2 363698007 900000000000011006 900000000000451002 < 2868308023 20190731 1 900000000000207008 162723006 420158005 2 419066007 900000000000011006 900000000000451002 < 2868309026 20190731 1 900000000000207008 162723006 5880005 1 418775008 900000000000011006 900000000000451002 < 2886522022 20190731 1 900000000000207008 417676004 420158005 2 419066007 900000000000011006 900000000000451002 < 2951141021 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 2952977026 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 3050044026 20190731 1 900000000000207008 73475009 90734009 2 263502005 900000000000011006 900000000000451002 < 3819331025 20190731 1 900000000000207008 449240007 412375000 2 127489000 900000000000011006 900000000000451002 < 3819332021 20190731 1 900000000000207008 449240007 396435000 4 127489000 900000000000011006 900000000000451002 < 3819333027 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 3819334022 20190731 1 900000000000207008 449240007 428126001 3 127489000 900000000000011006 900000000000451002 < 529646020 20190731 1 900000000000207008 238756007 10410005 1 363698007 900000000000011006 900000000000451002 < 6407173026 20190731 1 900000000000207008 87242005 129006008 4 363714003 900000000000011006 900000000000451002 < 6407174021 20190731 1 900000000000207008 87242005 363836006 3 363714003 900000000000011006 900000000000451002 < 857174020 20190731 1 900000000000207008 73475009 10200004 1 363698007 900000000000011006 900000000000451002 < 857175021 20190731 1 900000000000207008 73475009 66925006 3 246075003 900000000000011006 900000000000451002 < 892916029 20190731 1 900000000000207008 87242005 249971006 2 363714003 900000000000011006 900000000000451002 < 9279742024 20190731 1 900000000000207008 80660001 363808001 4 363714003 900000000000011006 900000000000451002 As long as Kai confirms that all Role Group changes above are valid and expected, then there is only one other potential issue: Yong's also queried the one record where the ID is also still changing for no apparent reason - the relationship itself is valid so not a huge concern, just wondered if you identified the reason for the ID change when you looked at this a few days ago? Would be good to confirm that this is an expected change rather than a potential indicator of a deeper issue: < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 > 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Kai confirmed (in ISRS-581) all changes are valid and expected. | |
| Relationship files | 0 | Zero substantive changes to the inferred file, as expected from ISRS-573. | |
| OWLExpression files | 2 | ISRS-573 | 2 new records as expected in ISRS-573: > 20190731 1 900000000000012004 733073007 762705008 SubClassOf(:762705008 :410662002) Other than that, every single new record for July 2019 (350,827) has had its UUID replaced - as expected because I had to regenerate the entire OWLExpression Delta file (using the SNOMED OWL Toolkit) in order to include the 2 records above. |
| Readme | n/a | Alpha wording updated to Beta as expected |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| MRCM Attribute Domain files | 10 | 5 July 2019 Alpha records (for Domain 781405001) removed completely (as never published), plus 5 Jan 2019 Published records (for Domain 373873005) inactivated, plus 5 July 2019 Beta records newly added (for Domain 781405001) to replace them, as expected in ISRS-564: < 03b4720d-5840-41d5-bcf4-884c603acc28 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 < 16965a9c-e4ba-4348-9b45-03150f74986c 20190731 1 900000000000012004 723561005 774161007 781405001 1 0..* 0..1 723597001 723596005 < b1bfe4c7-b443-45fa-9653-108093235e5a 20190731 1 900000000000012004 723561005 774160008 781405001 1 1..* 1..1 723597001 723596005 < be279b7b-2331-496c-b3e6-51b94df106fc 20190731 1 900000000000012004 723561005 774163005 781405001 1 0..* 0..1 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 > b83c07c4-16ce-4659-b6b5-41f103563719 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 | |
| MRCM Attribute Range files | 5 | ISRS-564 | 5 records had the DomainID changed + "OR Medicinal product package (product)" clause added - CHECKING WITH LINDA TO CONFIRM THIS IS AS EXPECTED... NO - Linda confirmed that this is a mistake due to an issue with the formulae in the MRCM Google Sheet - she will fix now so that we can rebuild... < 2affaf44-9365-4d6d-84d3-31409206a77a 20190131 1 900000000000012004 723562003 774158006 << 774167006 | Product name (product name)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774158006 |Has product name| = << 774167006 | Product name (product name)| 723597001 723596005 < 355c9063-7238-4409-81a8-13f22b2a8bff 20190131 1 900000000000012004 723562003 774161007 < 260299005 |Number (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774161007 |Has pack size| = < 260299005 |Number (qualifier value)| } 723597001 723596005 < 608ab6f5-6830-4294-926a-5c3a20b62060 20190131 1 900000000000012004 723562003 774159003 << 774164004 | Supplier (supplier)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774159003 |Has supplier| = << 774164004 | Supplier (supplier)| 723597001 723596005 < e491647d-1793-4b20-b92d-c1180a96b00f 20190131 1 900000000000012004 723562003 774163005 << 767524001 |Unit of measure (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774163005 |Has pack size unit| = << 767524001 |Unit of measure (qualifier value)| } 723597001 723596005 < e5945adf-c075-4fb7-8f1b-515a124326cf 20190131 1 900000000000012004 723562003 774160008 << 763158003 |Medicinal product (product)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774160008 |Contains clinical drug| = << 763158003 |Medicinal product (product)| } 723597001 723596005 |
| Relationship files | 13 | The only changes were Role Group changes, which Kai has already confirmed are valid: < 6407173026 20190731 1 900000000000207008 87242005 129006008 4 363714003 900000000000011006 900000000000451002 > 6407174021 20190731 1 900000000000207008 87242005 363836006 2 363714003 900000000000011006 900000000000451002 > 6407173026 20190731 1 900000000000207008 87242005 129006008 3 363714003 900000000000011006 900000000000451002 > 892916029 20190731 1 900000000000207008 87242005 249971006 4 363714003 900000000000011006 900000000000451002 > 9279742024 20190731 1 900000000000207008 80660001 363808001 1 363714003 900000000000011006 900000000000451002 As long as Kai confirms that all Role Group changes above are valid and expected, then there is only one other potential issue: Yong's also queried the one record where the ID is also still changing for no apparent reason - the relationship itself is valid so not a huge concern, just wondered if you identified the reason for the ID change when you looked at this a few days ago? Would be good to confirm that this is an expected change rather than a potential indicator of a deeper issue: < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 > 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Kai confirmed (in ISRS-581) all changes are valid and expected. | |
| Relationship files | 0 | Zero substantive changes to the inferred file, as expected from ISRS-573. | |
| OWLExpression files | 2 | ISRS-573 | 2 new records as expected in ISRS-573: > 20190731 1 900000000000012004 733073007 762705008 SubClassOf(:762705008 :410662002) Other than that, every single new record for July 2019 (350,827) has had its UUID replaced - as expected because I had to regenerate the entire OWLExpression Delta file (using the SNOMED OWL Toolkit) in order to include the 2 records above. |
| Readme | n/a | Alpha wording updated to Beta as expected |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| Relationship files | 13 | 13 records with role group changes - ********** NEED TO ASK KAI TO RECONFIRM THESE NEW CHANGES IN FINAL BETA PACKAGE *********** ??????????????Kai confirmed that this is expected behaviour, due to the automatic self-grouping coming out slightly differently in subsequent builds. He confirmed that every relationship is the only relationship in its group in both builds, and so whilst the group numbers have changed this has no effect on the inferred form. In the specific examples below:
< 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 < 2254342027 20190731 1 900000000000207008 238756007 2789006 2 363698007 900000000000011006 900000000000451002 < 3050044026 20190731 1 900000000000207008 73475009 90734009 2 263502005 900000000000011006 900000000000451002 < 3819331025 20190731 1 900000000000207008 449240007 412375000 2 127489000 900000000000011006 900000000000451002 < 3819332021 20190731 1 900000000000207008 449240007 396435000 4 127489000 900000000000011006 900000000000451002 < 3819333027 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 3819334022 20190731 1 900000000000207008 449240007 428126001 3 127489000 900000000000011006 900000000000451002 < 529646020 20190731 1 900000000000207008 238756007 10410005 1 363698007 900000000000011006 900000000000451002 < 6777054028 20190731 1 900000000000207008 722095005 385315009 5 263502005 900000000000011006 900000000000451002 < 6777055027 20190731 1 900000000000207008 722095005 80891009 1 363698007 900000000000011006 900000000000451002 < 857174020 20190731 1 900000000000207008 73475009 10200004 1 363698007 900000000000011006 900000000000451002 < 857175021 20190731 1 900000000000207008 73475009 66925006 3 246075003 900000000000011006 900000000000451002 < 9279742024 20190731 1 900000000000207008 80660001 363808001 4 363714003 900000000000011006 900000000000451002 | |
| Relationship files | 0 | As long as Kai confirms that all Role Group changes above are valid and expected, then there are zero substantive changes to the inferred file, as expected from ISRS-573. This unexpected inactivation (from Version 6) has been reversed which is good, as it was not the intended effect of ISRS-573 as far as I can tell? < 9059580020 20180131 1 900000000000012004 762705008 410662002 0 116680003 900000000000011006 900000000000451002 | |
| OWLExpression files | 2 | ISRS-573 | 2 new records as expected in ISRS-573: > 20190731 1 900000000000012004 733073007 762705008 SubClassOf(:762705008 :410662002) Other than that, every single new record for July 2019 (350,827) has had its UUID replaced - as expected because I had to regenerate the entire OWLExpression Delta file (using the SNOMED OWL Toolkit) in order to include the 2 records above. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| Relationship files | 11 | 11 records with role group changes - ??????????????Kai confirmed that this is expected behaviour, due to the automatic self-grouping coming out slightly differently in subsequent builds. He confirmed that every relationship is the only relationship in its group in both builds, and so whilst the group numbers have changed this has no effect on the inferred form. In the specific examples below:
< 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 < 2254342027 20190731 1 900000000000207008 238756007 2789006 2 363698007 900000000000011006 900000000000451002 < 2868308023 20190731 1 900000000000207008 162723006 420158005 2 419066007 900000000000011006 900000000000451002 < 2868309026 20190731 1 900000000000207008 162723006 5880005 1 418775008 900000000000011006 900000000000451002 < 2886522022 20190731 1 900000000000207008 417676004 420158005 2 419066007 900000000000011006 900000000000451002 < 2951141021 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 2952977026 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 529646020 20190731 1 900000000000207008 238756007 10410005 1 363698007 900000000000011006 900000000000451002 < 6777054028 20190731 1 900000000000207008 722095005 385315009 5 263502005 900000000000011006 900000000000451002 < 6777055027 20190731 1 900000000000207008 722095005 80891009 1 363698007 900000000000011006 900000000000451002 < 9059580020 20180131 1 900000000000012004 762705008 410662002 0 116680003 900000000000011006 900000000000451002 < 9279742024 20190731 1 900000000000207008 80660001 363808001 4 363714003 900000000000011006 900000000000451002 | |
| Relationship files | 11 | ??????? | This record has also been inactivated, which was not the intended effect of ISRS-573 as far as I can tell? < 9059580020 20180131 1 900000000000012004 762705008 410662002 0 116680003 900000000000011006 900000000000451002 |
| OWLExpression files | 0 | ISRS-573 | Should have been 2 changes to records here - nothing here! Need to check input files and ensure that the SRS is overwriting with new ones and not just pickling up the old ones.... |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| Relationship files | 11 | 11 records with role group changes - Kai confirmed that this is expected behaviour, due to the automatic self-grouping coming out slightly differently in subsequent builds. He confirmed that every relationship is the only relationship in its group in both builds, and so whilst the group numbers have changed this has no effect on the inferred form. In the specific examples below:
< 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records removed, but none replaced as expected?: < 05bb3b23-6b0f-4e71-a88a-7246ed98fe04 20190731 1 900000000000207008 900000000000509007 739681000124113 900000000000548007 | |
| Relationship files | 11 | 11 records with role group changes - Expected???: < 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| OWLExpression files | 7 | 7 new records added as expected (due to missing records in first OWL Conversion): > 0c554fdd-84ef-4f47-993a-fd42d2e92c5d 20190731 1 900000000000207008 733073007 23892008 SubClassOf(ObjectIntersectionOf(:64572001 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:246075003 :28794003) ObjectSomeValuesFrom(:370135005 :441862004)))) :23892008) Plus UUID's refreshed for latest new records as expected. | |
| Relationship files | 12 | ISRS-559 | 4 records removed, and 8 records added back in: < 20030131 0 900000000000207008 65102004 23892008 116680003 900000000000011006 900000000000451002 > 20160131 1 900000000000207008 9095002 23892008 116680003 900000000000011006 900000000000451002 The vast majority of these are directly linked to the 7 new OWL Axioms included in this new build, and so these changes seem reasonable. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| Concept files | 10029 | 2476 records updated, plus 3142, records inactivated, plus 4411 records added, as expected as matches exactly with cut off QA report: https://dailybuild.ihtsdotools.org/qa-beta/ (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) | |
| Description files | 19546 | 136 records updated, plus 4048 records inactivated, plus 15362 records added (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on ) | |
| Relationship files | 259183 | 147216 records updated, plus 45783 records inactivated, plus 57019 records added (no data on this from qa.snomed.org) - Andrew Atkinson , there are some differences for inactivated relationships (45,295) and new additions (65,633) and I am not sure about total number for updated records. Yong - comments on ) | |
| OwlExpression files | 350827 | 0 records updated, plus 0 records inactivated, plus 350834 records added Andrew Atkinson The total number of axioms would be at least 351038. There are 4411 new axioms and inactivations of 3142 axioms in the July 2019 release. It means that there are 1269 additional axioms comparing to 349769 in the last demo release. There were 224 axioms in the January release. The new axioms would be 350814. I guess those 20 axioms (350834-350814) would be GCIs and 'additional axioms'. I do not have access to the Alpha file to confirm. Why the number of impact is different to the new records? Yong - comments on | |
| Stated Relationship files | 814884 | 0 records updated, plus 814884 records inactivated, plus 0 records added (no data on this from qa.snomed.org) - Yong confirmed that this is the expected amount on | |
| TextDefinition files | 688 | 0 records updated, plus 25 records inactivated, plus 663 records added (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on | |
| SimpleMap files | 4442 | 0 records updated, plus 2 records inactivated, plus 4440 records added, as expected as: 4411 added for CTV3 (as part of the normal authoring cycle updates, exported from the termServer - this is the exact expected amount as it matches exactly the number of new concepts created in the latest authoring cycle) + 31 new/updated records for ICD-0 as expected, matching the 31 records in the Delta from mapping tool. | |
| ExtendedMap files | 2056 | 25 records updated, plus 626 records inactivated, plus 1405 records added, as expected from the 2056 changes in the ICD-10 map Delta file that WCI sent us from the mapping tool export | |
| Simple Refset files | 104 | 0 records updated, plus 20 records inactivated, plus 84 records added, as expected from the Lateralizable Refset changes that Yong made in this cycle, exported in a Delta file from the Refset tool (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) | |
| ModuleDependency files | 3 | 3 records updated, as expected for July 2019 effectiveTimes | |
| Readme file | July 2019 dates updated + Alpha "x" prefixes added, as expected | ||
| MRCM AttributeDomain files | 6 | 1 new record added, plus 5 records updated ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the July 2019 cycle: ??????? (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) > 07805dc4-f785-48f1-a7b0-b089b29f1c4e 20190731 1 900000000000012004 723561005 784276002 781405001 0 1..1 0..0 723597001 723596005 < 16965a9c-e4ba-4348-9b45-03150f74986c 20190131 1 900000000000012004 723561005 774161007 373873005 1 0..* 0..1 723597001 723596005 < b1bfe4c7-b443-45fa-9653-108093235e5a 20190131 1 900000000000012004 723561005 774160008 373873005 1 0..* 0..1 723597001 723596005 < be279b7b-2331-496c-b3e6-51b94df106fc 20190131 1 900000000000012004 723561005 774163005 373873005 1 0..* 0..1 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190131 1 900000000000012004 723561005 774159003 373873005 0 0..1 0..0 723597001 723596005 < 03b4720d-5840-41d5-bcf4-884c603acc28 20190131 1 900000000000012004 723561005 774158006 373873005 0 0..1 0..0 723597001 723596005 | |
| MRCM AttributeRange files | 6 | 2 records inactivated, plus 0 updated, plus 6 new records added, ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the July 2019 cycle: ??????? (plus confirmed by Maria to be as expected in her email at ??????????) | |
| MRCM Domain files | 11 | 9 records updated, plus 1 inactivated, plus 1 new record added ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the July 2019 cycle: ??????? (plus confirmed by Maria to be as expected in her email at ??????????) | |
| Association Reference files | 6892 | 521 records updated, plus 1630 records inactivated, plus 4741 records added Yong confirmed that this is approximately the expected amount on There are 126 new additions and 24 inactivation for the 734138000|Anatomy structure and entire association reference set (foundation metadata concept)| | |
| Attribute Value files | 16375 | 1318 records updated, plus 78 records inactivated, 14979 records added because of a large number of description changes in product and disease hierarchies. (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on . | |
| Language refset files | 39699 | 1004 records updated, plus 7815 records inactivated, plus 30880 records added because of a large number of description changes in product and disease hierarchies. (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on . |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| MRCM Attribute Domain files | 5 | 5 new records had their UUID's refreshed as expected | |
| Relationship files | 19 | 1 record replaced (back to how it was in the Alpha?!) as follows - Kai confirmed this is fine due to reconciliation code: < 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Plus 1 record had it's ID updated, as expected in ISRS-587: < 6573891021 20190731 1 900000000000207008 716092007 91431006 5 116676008 900000000000011006 900000000000451002 < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 Finally 17 role group changes which Kai already confirmed are valid. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| MRCM Attribute Domain files | 5 | 5 new records had their UUID's refreshed as expected | |
| Readme | n/a | Beta wording updated to Member as expected | |
| Relationship files | 19 | 1 record replaced (back to how it was in the Alpha?!) as follows - Kai confirmed this is fine due to reconciliation code: < 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Plus 1 record had it's ID updated, as expected in ISRS-587: < 6573891021 20190731 1 900000000000207008 716092007 91431006 5 116676008 900000000000011006 900000000000451002 Finally 17 role group changes which Kai already confirmed are valid. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| RefsetDescriptor files | 1 | 1 record updated with the new attributeType ("URL" instead of "parsable string), as expected in ISRS-583: < a87a81a3-b10c-490b-9cc1-d94fafc5dc27 20170731 1 900000000000012004 900000000000456007 723560006 723570008 707000009 7 | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| MRCM Attribute Domain files | 10 | 5 July 2019 Alpha records (for Domain 781405001) removed completely (as never published), plus 5 Jan 2019 Published records (for Domain 373873005) inactivated, plus 5 July 2019 Beta records newly added (for Domain 781405001) to replace them, as expected in ISRS-564: < 03b4720d-5840-41d5-bcf4-884c603acc28 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 < 16965a9c-e4ba-4348-9b45-03150f74986c 20190731 1 900000000000012004 723561005 774161007 781405001 1 0..* 0..1 723597001 723596005 < b1bfe4c7-b443-45fa-9653-108093235e5a 20190731 1 900000000000012004 723561005 774160008 781405001 1 1..* 1..1 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 < be279b7b-2331-496c-b3e6-51b94df106fc 20190731 1 900000000000012004 723561005 774163005 781405001 1 0..* 0..1 723597001 723596005 > 391f932e-3158-47bb-a95e-a2b1c19e864d 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 | |
| MRCM Attribute Range files | 5 | ISRS-564 | 5 records had the DomainID changed, as expected in ISRS-564 + "OR Medicinal product package (product)" clause removed from all records to correct erroneous Beta Version 1: < 2affaf44-9365-4d6d-84d3-31409206a77a 20190131 1 900000000000012004 723562003 774158006 << 774167006 | Product name (product name)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774158006 |Has product name| = << 774167006 | Product name (product name)| 723597001 723596005 < 355c9063-7238-4409-81a8-13f22b2a8bff 20190131 1 900000000000012004 723562003 774161007 < 260299005 |Number (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774161007 |Has pack size| = < 260299005 |Number (qualifier value)| } 723597001 723596005 < 608ab6f5-6830-4294-926a-5c3a20b62060 20190131 1 900000000000012004 723562003 774159003 << 774164004 | Supplier (supplier)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774159003 |Has supplier| = << 774164004 | Supplier (supplier)| 723597001 723596005 < e491647d-1793-4b20-b92d-c1180a96b00f 20190131 1 900000000000012004 723562003 774163005 << 767524001 |Unit of measure (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774163005 |Has pack size unit| = << 767524001 |Unit of measure (qualifier value)| } 723597001 723596005 < e5945adf-c075-4fb7-8f1b-515a124326cf 20190131 1 900000000000012004 723562003 774160008 << 763158003 |Medicinal product (product)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774160008 |Contains clinical drug| = << 763158003 |Medicinal product (product)| } 723597001 723596005 |
| Relationship files | 19 | The only changes were Role Group changes, which Kai has already confirmed are valid (plus Yong also confirmed that all role group only changes are valid, as long as they're not Group 0): < 2254342027 20190731 1 900000000000207008 238756007 2789006 2 363698007 900000000000011006 900000000000451002 < 2868308023 20190731 1 900000000000207008 162723006 420158005 2 419066007 900000000000011006 900000000000451002 < 2868309026 20190731 1 900000000000207008 162723006 5880005 1 418775008 900000000000011006 900000000000451002 < 2886522022 20190731 1 900000000000207008 417676004 420158005 2 419066007 900000000000011006 900000000000451002 < 2951141021 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 2952977026 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 3050044026 20190731 1 900000000000207008 73475009 90734009 2 263502005 900000000000011006 900000000000451002 < 3819331025 20190731 1 900000000000207008 449240007 412375000 2 127489000 900000000000011006 900000000000451002 < 3819332021 20190731 1 900000000000207008 449240007 396435000 4 127489000 900000000000011006 900000000000451002 < 3819333027 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 3819334022 20190731 1 900000000000207008 449240007 428126001 3 127489000 900000000000011006 900000000000451002 < 529646020 20190731 1 900000000000207008 238756007 10410005 1 363698007 900000000000011006 900000000000451002 < 6407173026 20190731 1 900000000000207008 87242005 129006008 4 363714003 900000000000011006 900000000000451002 < 6407174021 20190731 1 900000000000207008 87242005 363836006 3 363714003 900000000000011006 900000000000451002 < 857174020 20190731 1 900000000000207008 73475009 10200004 1 363698007 900000000000011006 900000000000451002 < 857175021 20190731 1 900000000000207008 73475009 66925006 3 246075003 900000000000011006 900000000000451002 < 892916029 20190731 1 900000000000207008 87242005 249971006 2 363714003 900000000000011006 900000000000451002 < 9279742024 20190731 1 900000000000207008 80660001 363808001 4 363714003 900000000000011006 900000000000451002 As long as Kai confirms that all Role Group changes above are valid and expected, then there is only one other potential issue: Yong's also queried the one record where the ID is also still changing for no apparent reason - the relationship itself is valid so not a huge concern, just wondered if you identified the reason for the ID change when you looked at this a few days ago? Would be good to confirm that this is an expected change rather than a potential indicator of a deeper issue: < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 > 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Kai confirmed (in ISRS-581) all changes are valid and expected. | |
| Relationship files | 0 | Zero substantive changes to the inferred file, as expected from ISRS-573. | |
| OWLExpression files | 2 | ISRS-573 | 2 new records as expected in ISRS-573: > 20190731 1 900000000000012004 733073007 762705008 SubClassOf(:762705008 :410662002) Other than that, every single new record for July 2019 (350,827) has had its UUID replaced - as expected because I had to regenerate the entire OWLExpression Delta file (using the SNOMED OWL Toolkit) in order to include the 2 records above. |
| Readme | n/a | Alpha wording updated to Beta as expected |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | 4411 UUID's refreshed for latest new records as expected, as matches exactly the number of new CTV3 records added in this release as compared to January 2019. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| MRCM Attribute Domain files | 10 | 5 July 2019 Alpha records (for Domain 781405001) removed completely (as never published), plus 5 Jan 2019 Published records (for Domain 373873005) inactivated, plus 5 July 2019 Beta records newly added (for Domain 781405001) to replace them, as expected in ISRS-564: < 03b4720d-5840-41d5-bcf4-884c603acc28 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 < 16965a9c-e4ba-4348-9b45-03150f74986c 20190731 1 900000000000012004 723561005 774161007 781405001 1 0..* 0..1 723597001 723596005 < b1bfe4c7-b443-45fa-9653-108093235e5a 20190731 1 900000000000012004 723561005 774160008 781405001 1 1..* 1..1 723597001 723596005 < be279b7b-2331-496c-b3e6-51b94df106fc 20190731 1 900000000000012004 723561005 774163005 781405001 1 0..* 0..1 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 > b83c07c4-16ce-4659-b6b5-41f103563719 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 | |
| MRCM Attribute Range files | 5 | ISRS-564 | 5 records had the DomainID changed + "OR Medicinal product package (product)" clause added - CHECKING WITH LINDA TO CONFIRM THIS IS AS EXPECTED... NO - Linda confirmed that this is a mistake due to an issue with the formulae in the MRCM Google Sheet - she will fix now so that we can rebuild... < 2affaf44-9365-4d6d-84d3-31409206a77a 20190131 1 900000000000012004 723562003 774158006 << 774167006 | Product name (product name)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774158006 |Has product name| = << 774167006 | Product name (product name)| 723597001 723596005 < 355c9063-7238-4409-81a8-13f22b2a8bff 20190131 1 900000000000012004 723562003 774161007 < 260299005 |Number (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774161007 |Has pack size| = < 260299005 |Number (qualifier value)| } 723597001 723596005 < 608ab6f5-6830-4294-926a-5c3a20b62060 20190131 1 900000000000012004 723562003 774159003 << 774164004 | Supplier (supplier)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..1] 774159003 |Has supplier| = << 774164004 | Supplier (supplier)| 723597001 723596005 < e491647d-1793-4b20-b92d-c1180a96b00f 20190131 1 900000000000012004 723562003 774163005 << 767524001 |Unit of measure (qualifier value)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774163005 |Has pack size unit| = << 767524001 |Unit of measure (qualifier value)| } 723597001 723596005 < e5945adf-c075-4fb7-8f1b-515a124326cf 20190131 1 900000000000012004 723562003 774160008 << 763158003 |Medicinal product (product)| << 373873005 |Pharmaceutical / biologic product (product)|: [0..*] { [0..1] 774160008 |Contains clinical drug| = << 763158003 |Medicinal product (product)| } 723597001 723596005 |
| Relationship files | 13 | The only changes were Role Group changes, which Kai has already confirmed are valid: < 6407173026 20190731 1 900000000000207008 87242005 129006008 4 363714003 900000000000011006 900000000000451002 > 6407174021 20190731 1 900000000000207008 87242005 363836006 2 363714003 900000000000011006 900000000000451002 > 6407173026 20190731 1 900000000000207008 87242005 129006008 3 363714003 900000000000011006 900000000000451002 > 892916029 20190731 1 900000000000207008 87242005 249971006 4 363714003 900000000000011006 900000000000451002 > 9279742024 20190731 1 900000000000207008 80660001 363808001 1 363714003 900000000000011006 900000000000451002 As long as Kai confirms that all Role Group changes above are valid and expected, then there is only one other potential issue: Yong's also queried the one record where the ID is also still changing for no apparent reason - the relationship itself is valid so not a huge concern, just wondered if you identified the reason for the ID change when you looked at this a few days ago? Would be good to confirm that this is an expected change rather than a potential indicator of a deeper issue: < 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 > 11583041026 20190731 1 900000000000207008 80660001 308490002 4 370135005 900000000000011006 900000000000451002 Kai confirmed (in ISRS-581) all changes are valid and expected. | |
| Relationship files | 0 | Zero substantive changes to the inferred file, as expected from ISRS-573. | |
| OWLExpression files | 2 | ISRS-573 | 2 new records as expected in ISRS-573: > 20190731 1 900000000000012004 733073007 762705008 SubClassOf(:762705008 :410662002) Other than that, every single new record for July 2019 (350,827) has had its UUID replaced - as expected because I had to regenerate the entire OWLExpression Delta file (using the SNOMED OWL Toolkit) in order to include the 2 records above. |
| Readme | n/a | Alpha wording updated to Beta as expected |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| Relationship files | 13 | 13 records with role group changes - ********** NEED TO ASK KAI TO RECONFIRM THESE NEW CHANGES IN FINAL BETA PACKAGE *********** ??????????????Kai confirmed that this is expected behaviour, due to the automatic self-grouping coming out slightly differently in subsequent builds. He confirmed that every relationship is the only relationship in its group in both builds, and so whilst the group numbers have changed this has no effect on the inferred form. In the specific examples below:
< 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 < 2254342027 20190731 1 900000000000207008 238756007 2789006 2 363698007 900000000000011006 900000000000451002 < 3050044026 20190731 1 900000000000207008 73475009 90734009 2 263502005 900000000000011006 900000000000451002 < 3819331025 20190731 1 900000000000207008 449240007 412375000 2 127489000 900000000000011006 900000000000451002 < 3819332021 20190731 1 900000000000207008 449240007 396435000 4 127489000 900000000000011006 900000000000451002 < 3819333027 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 3819334022 20190731 1 900000000000207008 449240007 428126001 3 127489000 900000000000011006 900000000000451002 < 529646020 20190731 1 900000000000207008 238756007 10410005 1 363698007 900000000000011006 900000000000451002 < 6777054028 20190731 1 900000000000207008 722095005 385315009 5 263502005 900000000000011006 900000000000451002 < 6777055027 20190731 1 900000000000207008 722095005 80891009 1 363698007 900000000000011006 900000000000451002 < 857174020 20190731 1 900000000000207008 73475009 10200004 1 363698007 900000000000011006 900000000000451002 < 857175021 20190731 1 900000000000207008 73475009 66925006 3 246075003 900000000000011006 900000000000451002 < 9279742024 20190731 1 900000000000207008 80660001 363808001 4 363714003 900000000000011006 900000000000451002 | |
| Relationship files | 0 | As long as Kai confirms that all Role Group changes above are valid and expected, then there are zero substantive changes to the inferred file, as expected from ISRS-573. This unexpected inactivation (from Version 6) has been reversed which is good, as it was not the intended effect of ISRS-573 as far as I can tell? < 9059580020 20180131 1 900000000000012004 762705008 410662002 0 116680003 900000000000011006 900000000000451002 | |
| OWLExpression files | 2 | ISRS-573 | 2 new records as expected in ISRS-573: > 20190731 1 900000000000012004 733073007 762705008 SubClassOf(:762705008 :410662002) Other than that, every single new record for July 2019 (350,827) has had its UUID replaced - as expected because I had to regenerate the entire OWLExpression Delta file (using the SNOMED OWL Toolkit) in order to include the 2 records above. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| Relationship files | 11 | 11 records with role group changes - ??????????????Kai confirmed that this is expected behaviour, due to the automatic self-grouping coming out slightly differently in subsequent builds. He confirmed that every relationship is the only relationship in its group in both builds, and so whilst the group numbers have changed this has no effect on the inferred form. In the specific examples below:
< 11576335029 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 < 2254342027 20190731 1 900000000000207008 238756007 2789006 2 363698007 900000000000011006 900000000000451002 < 2868308023 20190731 1 900000000000207008 162723006 420158005 2 419066007 900000000000011006 900000000000451002 < 2868309026 20190731 1 900000000000207008 162723006 5880005 1 418775008 900000000000011006 900000000000451002 < 2886522022 20190731 1 900000000000207008 417676004 420158005 2 419066007 900000000000011006 900000000000451002 < 2951141021 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 2952977026 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 529646020 20190731 1 900000000000207008 238756007 10410005 1 363698007 900000000000011006 900000000000451002 < 6777054028 20190731 1 900000000000207008 722095005 385315009 5 263502005 900000000000011006 900000000000451002 < 6777055027 20190731 1 900000000000207008 722095005 80891009 1 363698007 900000000000011006 900000000000451002 < 9059580020 20180131 1 900000000000012004 762705008 410662002 0 116680003 900000000000011006 900000000000451002 < 9279742024 20190731 1 900000000000207008 80660001 363808001 4 363714003 900000000000011006 900000000000451002 | |
| Relationship files | 11 | ??????? | This record has also been inactivated, which was not the intended effect of ISRS-573 as far as I can tell? < 9059580020 20180131 1 900000000000012004 762705008 410662002 0 116680003 900000000000011006 900000000000451002 |
| OWLExpression files | 0 | ISRS-573 | Should have been 2 changes to records here - nothing here! Need to check input files and ensure that the SRS is overwriting with new ones and not just pickling up the old ones.... |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records had their UUID's replaced, no substantive changes as expected in ISRS-580 Also spot checked the example Rory sent (a5f66441-9de9-53aa-89ab-8fe95badf6ab) and this now exists as expected | |
| Relationship files | 11 | 11 records with role group changes - Kai confirmed that this is expected behaviour, due to the automatic self-grouping coming out slightly differently in subsequent builds. He confirmed that every relationship is the only relationship in its group in both builds, and so whilst the group numbers have changed this has no effect on the inferred form. In the specific examples below:
< 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| Language Refset files | 64 | 64 records removed, but none replaced as expected?: < 05bb3b23-6b0f-4e71-a88a-7246ed98fe04 20190731 1 900000000000207008 900000000000509007 739681000124113 900000000000548007 | |
| Relationship files | 11 | 11 records with role group changes - Expected???: < 20190731 1 900000000000207008 162723006 285854004 3 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 417676004 285854004 1 363714003 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 449240007 396433007 1 127489000 900000000000011006 900000000000451002 < 20190731 1 900000000000207008 80660001 308490002 1 370135005 900000000000011006 900000000000451002 |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | n/a | UUID's refreshed for latest new records as expected. | |
| OWLExpression files | 7 | 7 new records added as expected (due to missing records in first OWL Conversion): > 0c554fdd-84ef-4f47-993a-fd42d2e92c5d 20190731 1 900000000000207008 733073007 23892008 SubClassOf(ObjectIntersectionOf(:64572001 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:246075003 :28794003) ObjectSomeValuesFrom(:370135005 :441862004)))) :23892008) Plus UUID's refreshed for latest new records as expected. | |
| Relationship files | 12 | ISRS-559 | 4 records removed, and 8 records added back in: < 20030131 0 900000000000207008 65102004 23892008 116680003 900000000000011006 900000000000451002 > 20160131 1 900000000000207008 9095002 23892008 116680003 900000000000011006 900000000000451002 The vast majority of these are directly linked to the 7 new OWL Axioms included in this new build, and so these changes seem reasonable. |
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| Concept files | 10029 | 2476 records updated, plus 3142, records inactivated, plus 4411 records added, as expected as matches exactly with cut off QA report: https://dailybuild.ihtsdotools.org/qa-beta/ (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) | |
| Description files | 19546 | 136 records updated, plus 4048 records inactivated, plus 15362 records added (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on ) | |
| Relationship files | 259183 | 147216 records updated, plus 45783 records inactivated, plus 57019 records added (no data on this from qa.snomed.org) - Andrew Atkinson , there are some differences for inactivated relationships (45,295) and new additions (65,633) and I am not sure about total number for updated records. Yong - comments on ) | |
| OwlExpression files | 350827 | 0 records updated, plus 0 records inactivated, plus 350834 records added Andrew Atkinson The total number of axioms would be at least 351038. There are 4411 new axioms and inactivations of 3142 axioms in the July 2019 release. It means that there are 1269 additional axioms comparing to 349769 in the last demo release. There were 224 axioms in the January release. The new axioms would be 350814. I guess those 20 axioms (350834-350814) would be GCIs and 'additional axioms'. I do not have access to the Alpha file to confirm. Why the number of impact is different to the new records? Yong - comments on | |
| Stated Relationship files | 814884 | 0 records updated, plus 814884 records inactivated, plus 0 records added (no data on this from qa.snomed.org) - Yong confirmed that this is the expected amount on | |
| TextDefinition files | 688 | 0 records updated, plus 25 records inactivated, plus 663 records added (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on | |
| SimpleMap files | 4442 | 0 records updated, plus 2 records inactivated, plus 4440 records added, as expected as: 4411 added for CTV3 (as part of the normal authoring cycle updates, exported from the termServer - this is the exact expected amount as it matches exactly the number of new concepts created in the latest authoring cycle) + 31 new/updated records for ICD-0 as expected, matching the 31 records in the Delta from mapping tool. | |
| ExtendedMap files | 2056 | 25 records updated, plus 626 records inactivated, plus 1405 records added, as expected from the 2056 changes in the ICD-10 map Delta file that WCI sent us from the mapping tool export | |
| Simple Refset files | 104 | 0 records updated, plus 20 records inactivated, plus 84 records added, as expected from the Lateralizable Refset changes that Yong made in this cycle, exported in a Delta file from the Refset tool (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) | |
| ModuleDependency files | 3 | 3 records updated, as expected for July 2019 effectiveTimes | |
| Readme file | July 2019 dates updated + Alpha "x" prefixes added, as expected | ||
| MRCM AttributeDomain files | 6 | 1 new record added, plus 5 records updated ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the July 2019 cycle: ??????? (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) > 07805dc4-f785-48f1-a7b0-b089b29f1c4e 20190731 1 900000000000012004 723561005 784276002 781405001 0 1..1 0..0 723597001 723596005 < 16965a9c-e4ba-4348-9b45-03150f74986c 20190131 1 900000000000012004 723561005 774161007 373873005 1 0..* 0..1 723597001 723596005 < b1bfe4c7-b443-45fa-9653-108093235e5a 20190131 1 900000000000012004 723561005 774160008 373873005 1 0..* 0..1 723597001 723596005 < be279b7b-2331-496c-b3e6-51b94df106fc 20190131 1 900000000000012004 723561005 774163005 373873005 1 0..* 0..1 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190131 1 900000000000012004 723561005 774159003 373873005 0 0..1 0..0 723597001 723596005 < 03b4720d-5840-41d5-bcf4-884c603acc28 20190131 1 900000000000012004 723561005 774158006 373873005 0 0..1 0..0 723597001 723596005 | |
| MRCM AttributeRange files | 6 | 2 records inactivated, plus 0 updated, plus 6 new records added, ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the July 2019 cycle: ??????? (plus confirmed by Maria to be as expected in her email at ??????????) | |
| MRCM Domain files | 11 | 9 records updated, plus 1 inactivated, plus 1 new record added ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the July 2019 cycle: ??????? (plus confirmed by Maria to be as expected in her email at ??????????) | |
| Association Reference files | 6892 | 521 records updated, plus 1630 records inactivated, plus 4741 records added Yong confirmed that this is approximately the expected amount on There are 126 new additions and 24 inactivation for the 734138000|Anatomy structure and entire association reference set (foundation metadata concept)| | |
| Attribute Value files | 16375 | 1318 records updated, plus 78 records inactivated, 14979 records added because of a large number of description changes in product and disease hierarchies. (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on . | |
| Language refset files | 39699 | 1004 records updated, plus 7815 records inactivated, plus 30880 records added because of a large number of description changes in product and disease hierarchies. (no data on this from qa.snomed.org) - Yong confirmed that this is approximately the expected amount on . |