January 2019 Member (Version 1) vs January 2019 Member (Version 2) traceability
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
July 2019 Beta (Version 3 - PUBLISHED) to July 2019 Member (Version 1) traceability
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: < 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. |
July 2019 Alpha (Version 3 - PUBLISHED) vs July 2019 Beta (Version 3 - PUBLISHED) traceability
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 |
July 2019 Alpha (Version 3 - PUBLISHED) vs July 2019 Beta (Version 1) traceability
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 |
July 2019 Alpha (Version 3 - PUBLISHED) vs July 2019 Alpha (Version 7 - US Language + Classifier Fix test) traceability
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. |
July 2019 Alpha (Version 3 - PUBLISHED) vs July 2019 Alpha (Version 6 - US Language + Classifier Fix test) traceability
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.... |
July 2019 Alpha (Version 3 - PUBLISHED) vs July 2019 Alpha (Version 5 - US Language Fix test) traceability
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 |
July 2019 Alpha (Version 3 - PUBLISHED) vs July 2019 Alpha (Version 4 - US Language Fix test) traceability
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| Simple Refset files | 2 | ISRS-669 | 2 (now inactive) records inactivated as expected due to manual fixes in ISRS-669 < 44e2c896-a1de-4c62-a18c-175ed1daefce 20190131 1 900000000000207008 723264001 771410009 < 94b62cea-42c5-4a65-8e06-242fbdcee14f 20190131 1 900000000000207008 723264001 771409004 |
| SimpleMap files | 3044 | UUID's refreshed for latest new records as expected. |
January 2020 PreAlpha (Version 1) vs January 2020 Alpha (Version 1) traceability
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| SimpleMap files | 3044 | UUID's refreshed for latest new records as expected. | |
| Concept files | 1 | 1 record removed, reinstating the original record from 2018 as expected: < 209401004 20200131 1 900000000000207008 900000000000073002 |
July 2019 PRODUCTION (PUBLISHED) to January 2020 PreAlpha (Version 1) traceability
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
|---|---|---|---|
| Concept files | 6030 | 1657 records updated, plus 1329 records inactivated, plus 3044 records added, ??????????????as expected as matches exactly with ?????????????? report: (plus confirmed by Maria/Yong to be as expected in email at ??????????????) | |
| Description files | 20724 | 5601 records updated, plus 2836 records inactivated, plus 12287 records added (no data on this from reports) - Yong confirmed that this is approximately the expected amount on ???????????) | |
| Relationship files | 98612 | 4115 records updated, plus 41159 records inactivated, plus 43338 records added (no data on this from reports) - Yong confirmed that this is approximately the expected amount on ???????????) | |
| OwlExpression files | 19175 | 14365 records updated, plus 1329 records inactivated, plus 3481 records added (no data on this from reports) - Yong confirmed that this is approximately the expected amount on ???????????) | |
| Stated Relationship files | 0 | 0 records updated, plus 0 records inactivated, plus 0 records added As expected due to full migration to OWLExpression file in the last July 2019 International Edition | |
| TextDefinition files | 483 | 0 records updated, plus 65 records inactivated, plus 418 records added (no data on this from reports) - Yong confirmed that this is approximately the expected amount on ???????????) | |
| SimpleMap files | 3115 | 0 records updated, plus 43 records inactivated, plus 3072 records added, as expected as: ????????/ 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) + ??????? new/updated records for ICD-0 as expected, matching the 31 records in the Delta from mapping tool. | |
| ExtendedMap files | 2762 | 37 records updated, plus 885 records inactivated, plus 1840 records added, as expected from the ???????? changes in the ICD-10 map Delta file that WCI sent us from the mapping tool export | |
| Simple Refset files | 172 | 0 records updated, plus 32 records inactivated, plus ?????? 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 ??????????) | |
| ModuleDependency files | 3 | 3 records updated, as expected for January 2020 effectiveTimes | |
| Readme file | January 2020 dates updated + Alpha "x" prefixes added, as expected | ||
| MRCM AttributeDomain files | 4 | 4 records updated ?????????? as confirmed by Linda's in line with the changes she made to master sheet for the January 2020 cycle: ??????? (plus confirmed by Maria to be as expected in her email at 08:40 on 23/05/2019) 2 records re-activated: < 03b4720d-5840-41d5-bcf4-884c603acc28 20190731 0 900000000000012004 723561005 774158006 373873005 0 0..1 0..0 723597001 723596005 < f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20190731 0 900000000000012004 723561005 774159003 373873005 0 0..1 0..0 723597001 723596005 > f3a97490-6c74-404e-a3e9-436b7d4ca2a1 20200131 1 900000000000012004 723561005 774159003 373873005 0 0..1 0..0 723597001 723596005 Plus 2 records inactivated: < 0c13203d-fddb-43eb-841b-0851b1dff64e 20190731 1 900000000000012004 723561005 774159003 781405001 0 0..1 0..0 723597001 723596005 < baea9566-e726-4403-bafa-59944e056d74 20190731 1 900000000000012004 723561005 774158006 781405001 0 0..1 0..0 723597001 723596005 | |
| MRCM AttributeRange files | 1 | 1 records updated, plus 0 updated, plus < f58d75aa-599a-42e7-9f35-31a9c8a7d6d9 20180131 1 900000000000012004 723562003 246501002 << 272394005 |Technique (qualifier value)| << 363787002 |Observable entity (observable entity)|: [0..*] { [0..1] 246501002 |Technique| = << 272394005 |Technique (qualifier value)| } 723597001 723596005 ?????????? 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 | 3 | 3 records updated, plus 0 inactivated, plus 0 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 | 2970 | 205 records updated, plus 663 records inactivated, plus 2102 records added Yong confirmed that this is approximately the expected amount on ?????????? There are ??????? new additions and ????????? inactivation for the 734138000|Anatomy structure and entire association reference set (foundation metadata concept)| | |
| Attribute Value files | 8694 | 358 records updated, plus 189 records inactivated, 8147 records added because of a large number of description changes in product and disease hierarchies. (no data on this from reports) - Yong confirmed that this is approximately the expected amount on ???????????) | |
| Language refset files | 32328 | 1288 records updated, plus 7223 records inactivated, plus 23817 records added because of a large number of description changes in product and disease hierarchies. (no data on this from reports) - Yong confirmed that this is approximately the expected amount on ???????????) |