June
20222023 PreProduction (Version
20)5 - Fixes from version 4) traceability vs June
20222023 Production (Version
21) traceability
SUMMARY COMPONENT REPORT: https://docs.google.com/spreadsheets/d/1jdFDl7lZJDjk2SRMcoFc4h1Rz8Qwnf9EqUzU10UQHd41Q18jq4eHU4-H8hou3U3Pb-4l1jGgqRNSIk-1KvTfrIo/edit#gid=01
MSSP TICKET: https://jira.ihtsdotools.org/browse/MSSP-2072
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
---|
June 2022 PreProduction (Version 20) vs June 2022 Production (Version 1) traceability
Readme file | n/a | All x prefixes removed, and Production naming conventions applied, as expected |
June 2023 PreProduction (Version 4 - COMPLETE RE-START OF SWISS RELEASE, AS IF THIS IS A "FIRST TIME" RELEASE) traceability
vs June 2023 PreProduction (Version 5 - Fixes from version 4) traceability
SUMMARY COMPONENT REPORT: https://SUMMARY COMPONENT REPORT: https://docs.google.com/spreadsheets/d/1jdFDl7lZJDjk2SRMcoFc4h1Rz8Qwnf9EqUzU10UQHd41Q18jq4eHU4-H8hou3U3Pb-4l1jGgqRNSIk-1KvTfrIo/edit#gid=01
MSSP TICKET: https://jira.ihtsdotools.org/browse/MSSP-2072
Differences found in |
---|
package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
---|
RefsetDescriptor files |
June 2022 PreProduction (Version 18) vs June 2022 PreProduction (Version 20) traceability
10 | 8 records had their UUID's reverted to December 2022 (plus 2 records that were missing from the PreProd version 4 package) + new effectiveTime of 20230607 (but NO CHANGES TO ACTUAL RECORDS) as expected, due to NEW "FIRST TIME" RELEASE:
So when compared to the old December 2022 release, the new Version 5 refsetDescriptor records are identical except for the new effectiveTime of 20230607 for each record, as expected. | ||
ModuleDependency files | 2 | 2 records added back in as expected, as remaining 3 from December 2022 were all related to the old dependency on the CF module, which no longer exists!
Therefore, when compared to the old December 2022 release, the new Version 5 moduleDependency records are identical (except for the new effectiveTime of 20230607 for each record) for the 2 records that are still applicable in the new world of hosting all CF + CG records in the CH module instead of in the CF + CG modules. However, we've now removed 3 of the old moduleDependency records, as we no longer need to call out the dependencies on those CF + CG modules:
This is all now exactly as expected. | |
Description-fr FULL + SNAPSHOT files | 7478 | 7478 inactive CF module (11000241103) records have been completely removed from the package. This is exactly as expected, due to the fixes that were applied by Rory after the remaining 7478 CF module records were identified in the Version 4 testing below... | |
Description-fr-ch FULL + SNAPSHOT files | 7478 | 7478 inactive records (from the -fr file, that were removed because they were still in the CF module (11000241103)) have now been added back into the package in the RIGHT MODULE (the Swiss module 2011000195101) This is exactly as expected, due to the fixes that were applied by Rory after the remaining 7478 CF module records were identified in the Version 4 testing below... |
December 2022 Production (PUBLISHED) vs June 2023 PreProduction (Version 4 - COMPLETE RE-START OF SWISS RELEASE, AS IF THIS IS A "FIRST TIME" RELEASE) traceability
SUMMARY COMPONENT REPORT: https://docs.google.com/spreadsheets/d/1Q18jq4eHU4-H8hou3U3Pb-4l1jGgqRNSIk-1KvTfrIo/edit#gid=1
MSSP TICKET: https://jira.ihtsdotools.org/browse/MSSP-2072
Differences found in package Comparison | Number of RF2 records impacted | Related JIRA ticket(s) | Rationale |
---|---|---|---|
RefsetDescriptor files | 10 | 8 records had their UUID's refreshed + new effectiveTime of 20230607 (but NO CHANGES TO ACTUAL RECORDS) as expected, due to NEW "FIRST TIME" RELEASE:
2 records however, DID NOT GET REPLACED IN NEW JUNE 2023 RELEASE as expected???
| |
ModuleDependency files | 5 | 5 records removed completey, replaced with nothing!! SO ALL WRONG!! NEED TO REVERT BACK TO EXTERNALLYMAINTAINED INPUT FOR THIS FILE TO SEE IF THIS FIXES IT!! | |
Readme file | all x prefixes added in, plus PreProduction naming convention applied, as expected. | ||
Association files | 12 | 2 new records added/updated for 20230607, 10 records (from all different effectiveTimes) removed ...NOT as expected due to Summary Component Stats report for this cycle (see link above) showing:
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? ALL HISTORY GONE FROM ASSOCIATION FILES - I GUESS THIS IS WHAT WE WERE AIMING FOR WITH A BRAND NEW RELEASE, BUT JUST NEED TO DOUBLE CHECK WITH RORY... Yes, Rory confirmed this is correct during our call at 17:00 on | |
AttributeValue files | 11613 | 6860 new records added/updated for 20230607, 11613 records (from all different effectiveTimes) removed ...NOT as expected due to Summary Component Stats report for this cycle (see link above) showing:
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? ALL HISTORY GONE FROM ATTRIBUTEVALUE FILES - I GUESS THIS IS WHAT WE WERE AIMING FOR WITH A BRAND NEW RELEASE, BUT JUST NEED TO DOUBLE CHECK WITH RORY... Yes, Rory confirmed this is correct during our call at 17:00 on | |
Language Refset (de-ch) files | 29491 | 27928 new records added/updated for 20230607 - ***** FOR REFSETID: 2041000195100 ***** 1563 records (from all different effectiveTimes) removed ..NOT as expected due to |
Differences found in package Comparison
3 records had their effectiveTimes updated to the new 20220331 version of the Common French release, which this June 2022 CH release was based upon:
< 7321d59a-986d-4496-9cf8-874022470ad5 20220607 1 11000241103 900000000000534007 900000000000012004 20220607 20220331
> 7321d59a-986d-4496-9cf8-874022470ad5 20220607 1 11000241103 900000000000534007 900000000000012004 20220331 20220331
< b3c09a5c-496c-48d7-808a-166f2b6a3c97 20220607 1 11000241103 900000000000534007 900000000000207008 20220607 20220331
> b3c09a5c-496c-48d7-808a-166f2b6a3c97 20220607 1 11000241103 900000000000534007 900000000000207008 20220331 20220331
< dc968531-82da-4aeb-bf59-3ae96cf71dd7 20220607 1 2011000195101 900000000000534007 11000241103 20220607 20210930
> dc968531-82da-4aeb-bf59-3ae96cf71dd7 20220607 1 2011000195101 900000000000534007 11000241103 20220607 20220331
June 2022 PreProduction (Version 9) vs June 2022 PreProduction (Version 18) traceability
Differences found in package Comparison
29 records updated from 1217318005 | Grammatical description error (foundation metadata concept) | to 900000000000485001 | Erroneous component (foundation metadata concept) |
...as expected due to the fixes made in ISRS-1257
52 records updated from 900000000000548007 | Preferred (foundation metadata concept) | to 900000000000549004 | Acceptable (foundation metadata concept) |
+
2558 records added into the Full + Snapshot files, as expected due to fixes in ISRS-1264 to include ALL fr-ch records in the new release package (by spoofing the previousPublishedPackage)
3435 records added into the Full + Snapshot files, as expected due to fixes in ISRS-1263 to include ALL fr-ch records in the new release package (by spoofing the previousPublishedPackage)
1 new record added in:
> 11000241126 20220331 0 11000241103 11000241103 900000000000443000 0 116680003 900000000000011006 900000000000451002
On investigation and manual comparison of the files, the Snapshot files are fine. It's just the latest Full file which contains an extra record where this relationship is first inactivated in the Common French module, before the Swiss module:
11000241126 20211207 1 11000241103 11000241103 900000000000443000 0 116680003 900000000000011006 900000000000451002
11000241126 20220331 0 11000241103 11000241103 900000000000443000 0 116680003 900000000000011006 900000000000451002
11000241126 20220607 0 2011000195101 11000241103 900000000000443000 0 116680003 900000000000011006 900000000000451002
This isn't a critical issue (as the correct final Swiss inactivation still takes priority due to the effectiveTimes), this can be safely ignored.
1 new record added in:
> 1020231000241112 20220331 1 11000241103 77386006 fr 900000000000550004 Patiente enceinte actuellement 900000000000017005
Confirmed that this is definitely a new record added into both Full/Snapshot files for version 18. This is a Common French term, and so must have been added when we changed the dependency of this June 2022 Swiss release from the 20210930 Common French release, to the 20220331 Common French release package.
June 2022 PreProduction (Version 8 PLUS MSSP-1519) vs June 2022 PreProduction (Version 9) traceability
Differences found in package Comparison
2 records updated:
< b3c09a5c-496c-48d7-808a-166f2b6a3c97 20211207 1 11000241103 900000000000534007 900000000000207008 20211207 20210731
> b3c09a5c-496c-48d7-808a-166f2b6a3c97 20220607 1 11000241103 900000000000534007 900000000000207008 20220607 20220331
< dc968531-82da-4aeb-bf59-3ae96cf71dd7 20211207 1 2011000195101 900000000000534007 11000241103 20211207 20210930
> dc968531-82da-4aeb-bf59-3ae96cf71dd7 20220607 1 2011000195101 900000000000534007 11000241103 20220607 20210930
However, no mention of removing the previous invalid records, so running comparison of ModuleDependency file from Version 9 against original December 2021 release:
< 36ddb438-742a-4c97-9dca-b95489b6a08a 20211207 1 2011000195101 900000000000534007 900000000000207008 20211207 20210731
> 36ddb438-742a-4c97-9dca-b95489b6a08a 20220607 1 2011000195101 900000000000534007 900000000000207008 20220607 20220331
< 7321d59a-986d-4496-9cf8-874022470ad5 20211207 1 11000241103 900000000000534007 900000000000012004 20211207 20210731
> 7321d59a-986d-4496-9cf8-874022470ad5 20220607 1 11000241103 900000000000534007 900000000000012004 20220607 20220331
< a4fbf40a-73ae-4e51-80da-cddc448d3a32 20211207 1 2011000195101 900000000000534007 900000000000012004 20211207 20210731
> a4fbf40a-73ae-4e51-80da-cddc448d3a32 20220607 1 2011000195101 900000000000534007 900000000000012004 20220607 20220331
< b3c09a5c-496c-48d7-808a-166f2b6a3c97 20211207 1 11000241103 900000000000534007 900000000000207008 20211207 20210731
> b3c09a5c-496c-48d7-808a-166f2b6a3c97 20220607 1 11000241103 900000000000534007 900000000000207008 20220607 20220331
< dc968531-82da-4aeb-bf59-3ae96cf71dd7 20211207 1 2011000195101 900000000000534007 11000241103 20211207 20210930
> dc968531-82da-4aeb-bf59-3ae96cf71dd7 20220607 1 2011000195101 900000000000534007 11000241103 20220607 20210930
LOOKS GOOD!
Manual checks of SNapshot + Full also look good!
Looks like the previous comparison was actually to Version 8 (NOT Version 8 plus MSSP-1519) and so most of these issues were already fixed!
However, the Version 8 plus MSSP-1519 was also flawed, as the following 2 lines were not correctly updated by the automation code:
b3c09a5c-496c-48d7-808a-166f2b6a3c97 20211207 1 11000241103 900000000000534007 900000000000207008 20211207 20210731
dc968531-82da-4aeb-bf59-3ae96cf71dd7 20211207 1 2011000195101 900000000000534007 11000241103 20211207 20210930
So I still needed to manually update the ModuleDependency file this cycle, as I did from version 9 onwards...
December 2021 Production (PUBLISHED) vs June 2022 PreProduction (Version 8 PLUS MSSP-1519) traceability
Differences found in package Comparison
2 records added, denoting 1 new refset as expected ????
> 1ca3e72a-71ee-436d-9c06-e47e0db53185 20220607 1 2011000195101 900000000000456007 22241000195100 900000000000510002 900000000000462002 0
> 1dda242a-587b-4b38-8eff-f86b509afa22 20220607 1 2011000195101 900000000000456007 22241000195100 900000000000511003 900000000000461009 1
Checking with Pero in MSSP-1518 that this language refset addition is expected...
3 records had their UUID's replaced, BUT ALSO HAD DUPLICATE RECORDS ADDED (presumably by the automated ModuleDependency code):
< 36ddb438-742a-4c97-9dca-b95489b6a08a 20211207 1 2011000195101 900000000000534007 900000000000207008 20211207 20210731
> 36ddb438-742a-4c97-9dca-b95489b6a08a 20220607 1 2011000195101 900000000000534007 900000000000207008 20220607 20220331
> 59cf1492-b48d-4423-bd8d-f690ce8f6e73 20211207 1 2011000195101 900000000000534007 900000000000207008 20211207 20210731
< 7321d59a-986d-4496-9cf8-874022470ad5 20211207 1 11000241103 900000000000534007 900000000000012004 20211207 20210731
> 7321d59a-986d-4496-9cf8-874022470ad5 20220607 1 11000241103 900000000000534007 900000000000012004 20220607 20220331
> 293406ae-3aef-4393-b588-f72479f3075e 20211207 1 11000241103 900000000000534007 900000000000012004 20211207 20210731
< a4fbf40a-73ae-4e51-80da-cddc448d3a32 20211207 1 2011000195101 900000000000534007 900000000000012004 20211207 20210731
> a4fbf40a-73ae-4e51-80da-cddc448d3a32 20220607 1 2011000195101 900000000000534007 900000000000012004 20220607 20220331
> 3e4b83c5-6e40-4793-8d8f-3bf6e0379958 20211207 1 2011000195101 900000000000534007 900000000000012004 20211207 20210731
Also 2 records had their UUID's replaced unnecessarily:
< b3c09a5c-496c-48d7-808a-166f2b6a3c97 20211207 1 11000241103 900000000000534007 900000000000207008 20211207 20210731
> 902510db-1db3-4635-88d0-956467801be5 20211207 1 11000241103 900000000000534007 900000000000207008 20211207 20210731
< dc968531-82da-4aeb-bf59-3ae96cf71dd7 20211207 1 2011000195101 900000000000534007 11000241103 20211207 20210930
> 1b57c717-740e-46c3-8ea1-1726d4c541e1 20211207 1 2011000195101 900000000000534007 11000241103 20211207 20210930
SO ALL WRONG!! NEED TO REVERT BACK TO EXTERNALLYMAINTAINED INPUT FOR THIS FILE TO SEE IF THIS FIXES IT!!
all x prefixes added in, plus PreProduction naming convention applied, as expected.
ALL Delta files removed as well, as expected.
PLUS 2x new file types added in as planned, meaning 4x new files in total added:
- > xsct2_Description_Full-fr-ch_CH1000195_20220607.txt
- > xsct2_Description_Snapshot-fr-ch_CH1000195_20220607.txt
- > xsct2_TextDefinition_Full-fr_CH1000195_20220607.txt
- > xsct2_TextDefinition_Snapshot-fr_CH1000195_20220607.txt
1 new record added for new "Romansh [International Organization for Standardization 639-1 code rm] language reference set (foundation metadata concept)" concept:
> 22241000195100 20220607 1 2011000195101 900000000000074008
VERIFYING THIS WITH PERO IN MSSP-1518, as although all of the relevant components are here as expected (concepts, descriptions in all languages, etc) - there's NO new actual language refset file?!!
Plus 1 inactivated record:
< 394812008 20211207 1 2011000195101 900000000000074008
> 394812008 20220607 0 2011000195101 900000000000074008
Summary Component Stats report for this cycle (see link above) |
showing:
|
|
...as expected due to exact match in Summary Component Stats report for this cycle (see link above)
10840 added/updated??!!!
NOT AS EXPECTED!!! SUMMARY COMPONENT REPORT SHOWS 88 ADDED EXPECTED, WHICH IS MUCH CLOSER TO EXPECTED THAN 10000+!!!!!
10753 records have been added here for the Common French descriptions (11000241103) - question is why?!!
The snapshot of this file had only 20 records in it for the December 2021 release!
However when I run the June 2022 release, it now has over 10000 records! (there’s only been 200 odd Description changes in this cycle!)
The attributeValue config in the manifest is still the same as it was in December 2021:<file Name=“xder2_cRefset_AttributeValueSnapshot_CH1000195_20220607.txt”><sources>
<source>terminology-server</source>
</sources>
<contains-reference-sets>
<refset id=“900000000000489007" label=“Concept inactivation indicator”/>
<refset id=“900000000000490003" label=“Description inactivation indicator”/>
</contains-reference-sets>
<contains-additional-fields>
<field name =“valueId”/>
</contains-additional-fields>
</file>
To be fair, looking at the Common French Description file (https://prod-release.ihtsdotools.org/api/centers/ch/products/snomed_ct_switzerland_releases[…]s/xsct2_Description_Snapshot-fr_CH1000195_20220607.txt), it looks like there were about 10254 records inactivated in the December release - however these were Born Inactive (in the first time release) and so I wouldn’t expect the system to create new attributeValue records for these? But perhaps it has to if it can’t find existing attributeValue records for the old inactive records??
CHECKING WITH QUYEN...Quyen thinks it's a snowstorm bug, so I've raised ticket:
Jira server IHTSDO JIRA serverId b202d822-d767-33be-b234-fec5accd5d8c key ISRS-1254
Michael confirmed them to be all valid in ISRS-1254
DOES THIS MEAN THE SCS REPORT WILL BE INVALID, AS WILL SHOW NOW INACTIVATIONS BECAUSE IT'S A "BRAND NEW RELEASE" WITH NO "PREVIOUSPUBLISHEDPACKAGE" TO COMPARE THE CONTENT TO???? So my manual validation shows:
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |||
Language Refset (it-ch) files | 2603 | 1292 new records added/updated for 20230607 - ***** FOR REFSETID: 2031000195108 ***** 1311 records (from all different effectiveTimes) removed So my manual validation shows:
...as expected ???????????????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Language Refset (en) files | 182 | 96 new records added/updated for 20230607 - ***** FOR REFSETID: 900000000000508004 + 900000000000509007 ***** 86 records (from all different effectiveTimes) removed So my manual validation shows:
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Language Refset (fr) files | 0 | 0 records added/updated, as expected as this is Common French Language file?????? SUMMARY REPORT EXPECTING 0 | |
Language Refset (fr-ch) files | 260,288 | 161,454 new records added/updated for 20230607 - ***** FOR REFSETID: 2021000195106 ***** 98,834 records (from all different effectiveTimes) removed So my manual validation shows:
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Concept files | 46 | 25 new records added/updated for 20230607, 21 records (from all different effectiveTimes) removed ...NOT as expected due to Summary Component Stats report for this cycle (see link above) showing:
DOES THIS MEAN THE SCS REPORT WILL BE INVALID, AS WILL SHOW NOW INACTIVATIONS BECAUSE IT'S A "BRAND NEW RELEASE" WITH NO "PREVIOUSPUBLISHEDPACKAGE" TO COMPARE THE CONTENT TO???? Some of the records removed appear to be absolutely valid, as they are previously inactive records (and therefore there's no need to keep them as "born inactive" records) (eg)
Many more appear to be valid as they're simply "removing" these records to be replaced with the same record just with new effectiveTimes (eg)
Yet more appear to be added in validly as brand new concepts for this authoring cycle (eg)
However, that leaves 1 active record that has just been removed for no apparent reason:
DID RORY PERHAPS INTENTIONALLY MISS OUT ALL CONTENT FOR THIS MODULE (WHEN IMPORTING THE CONTENT INTO THE FRESH NEW CODESYSTEM), BECAUSE THIS IS THE COMMON FRENCH MODULE (11000241103 | SNOMED CT Common French translation module (core metadata concept) |) AND THEREFORE WE'RE NOW GOING FOR AN APPROACH THAT JUST IMPORTS THE COMMON FRENCH CONTENT STRAIGHT INTO THE SWISS MODULE INSTEAD AND THEREFORE THERE IS NO LONGER A DEPENDENCY THERE ON THE COMMON FRENCH MODULE, AND THUS NO REASON TO INCLUDE IT IN THE SWISS PACKAGE???? IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Description (de-ch) files | 29593 | 28030 new records added/updated for 20230607 1563 records (from all different effectiveTimes) removed So my manual validation shows:
due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above) IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Description (en) files | 68 | 40 new records added/updated for 20230607 - 28 records (from all different effectiveTimes) removed So my manual validation shows:
due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above) IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Description (fr) files | 185,262 | 7479 new records added/updated for 20230607 - 177,783 records (from all different effectiveTimes) removed So my manual validation shows:
as planned in INFRA-8967 in order to correctly split out the Swiss French records into their own "fr-ch" Description file, leaving ONLY the Common French records in this "fr" Description file. ...as expected due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above) IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? NO - RORY CONFIRMED (during our call at 17:00 on ) THAT THE 7478 RECORDS STILL LEFT IN THE CF module (11000241103) WERE JUST A MISTAKE WHEN HE WAS DOING THE ORIGINAL UPLOADS | |
Description (fr-ch) files | 158774 | 158,602 new records added/updated for 20230607 - 147 records (from all different effectiveTimes) removed So my manual validation shows:
...as expected due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above) IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? NO - RORY CONFIRMED (during our call at 17:00 on ) THAT THE 7478 RECORDS STILL LEFT IN THE CF module (11000241103) in the description-fr file WERE JUST A MISTAKE WHEN HE WAS DOING THE ORIGINAL UPLOADS. They therefore now need to be added back into this description-fr-ch file in the Swiss module (2011000195101). | |
Description (it-ch) files | 2637 | 1326 new records added/updated for 20230607 - 1311 records (from all different effectiveTimes) removed So my manual validation shows:
due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above) IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Relationship files | 64 | 37 new records added/updated for 20230607 - 27 records (from all different effectiveTimes) removed ...NOT as expected due to Summary Component Stats report for this cycle (see link above) showing:
Some of the records removed appear to be absolutely valid, as they are previously inactive records (and therefore there's no need to keep them as "born inactive" records) (eg)
Many more appear to be valid as they're simply "removing" these records to be replaced with the same record just with new effectiveTimes (eg)
Yet more appear to be added in validly as brand new concepts for this authoring cycle (eg)
The good news here is that the only record related to the now unnecessary Common French module (11000241103) was already inactive, and therefore gets removed anyway:
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
Relationship Concrete Values files | 0 | 0 records added/updated ...as expected due to exact match |
74 added/updated records +
41 inactivated records
...as expected due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above)
2 new records added/updated
...as expected due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above)
110 Swiss French records removed, as planned in INFRA-8967 in order to correctly split out the Swiss French records into their own "fr-ch" Description file, leaving ONLY the Common French records in this "fr" Description file.
...as expected due to close match with TOTAL DESCRIPTION Countsin Summary Component Stats report for this cycle (see link above) |
OWL Expression files |
Original 110 Swiss French records added, as planned in INFRA-8967 in order to correctly split out the Swiss French records into their own "fr-ch" Description file, leaving ONLY the Common French records in this "fr" Description file.
+ 21 records inactivated in the new June 2022 content
+ 30 new records added in the new June 2022 content
...as expected due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above)
46 | 25 new records added/updated for 20230607 - 21 records (from all different effectiveTimes) removed ...as expected ???????????????? Some of the records removed appear to be absolutely valid, as they are previously inactive records (and therefore there's no need to keep them as "born inactive" records) (eg)
Many more appear to be valid as they're simply "removing" these records to be replaced with the same record just with new effectiveTimes (eg)
The good news here is that one of the records related to the now unnecessary Common French module (11000241103) was already inactive, and therefore gets removed anyway:
The other one relating to this module also gets removed, as expected:
Yet more appear to be added in validly as brand new concepts for this authoring cycle (eg)
IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | ||
TextDefinition (de-ch) files | 0 | 0 new records added/updated for 20230607 - 0 records (from all different effectiveTimes) removed ...as expected as this file was empty in the previous releases. | |
TextDefinition (en) files | 0 | 0 new records added/updated for 20230607 - 0 records (from all different effectiveTimes) removed ...as expected as this file was empty in the previous releases. | |
TextDefinition (fr) files | 1 | 0 new records added/updated for 20230607 - 1 records (from all different effectiveTimes) removed 1 record related to the now unnecessary Common French module (11000241103) was removed as expected: 1020231000241112 20220331 1 11000241103 77386006 fr 900000000000550004 Patiente enceinte actuellement 900000000000017005 IS THIS TO BE EXPECTED BECAUSE WE'VE "STARTED FROM SCRATCH" IN THIS RELEASE?????? Yes, Rory confirmed this is correct during our call at 17:00 on | |
TextDefinition (fr-ch) files | 0 | 0 new records added/updated for 20230607 - 0 records (from all different effectiveTimes) removed ...as expected as this file was empty in the previous releases. | |
TextDefinition (it-ch) files | 0 | 0 new records added/updated for 20230607 - 0 records (from all different effectiveTimes) removed ...as expected as this file was empty in the previous releases |
61 added/updated records +
22 inactivated records
...as expected due to close match with TOTAL DESCRIPTION Counts in Summary Component Stats report for this cycle (see link above)
71 records added/updated
+ 41 records inactivated
...as expected due to exact match in Summary Component Stats report for this cycle (see link above)
68 records added/updated
+ 22 records inactivated
...as expected due to exact match in Summary Component Stats report for this cycle (see link above)
67 records added/updated
...NOT as expected due to Summary Component Stats report for this cycle (see link above) expecting 40????
Double checked and this looks like a problem with the Summary Component Report - possibly just because we're comparing to a DIFFERENT previous published package though, because we've generated the new one?!!
0 records added/updated, as expected as this is Common French Language file??????
(but then shouldn't we be moving some into fr-ch, or were these already in December - no they weren't there, they requested no preferences for Common French, just Swiss French)
SUMMARY REPORT EXPECTING 11 - this looks like a problem with the Summary Component Report - possibly just because we're comparing to a DIFFERENT previous published package though, because we've generated the new one?!!
67 records added/updated
+ 89 records inactivated
...as expected due to exact match in Summary Component Stats report for this cycle (see link above)
1 new records added:
> 43341000195128 20220607 1 2011000195101 22241000195100 900000000000506000 0 116680003 900000000000011006 900000000000451002
plus 2 records inactivated, related to newly re-activated Concepts:
< 11000241126 20211207 1 11000241103 11000241103 900000000000443000 0 116680003 900000000000011006 900000000000451002
> 11000241126 20220607 0 2011000195101 11000241103 900000000000443000 0 116680003 900000000000011006 900000000000451002
< 2026638020 20211207 1 2011000195101 394812008 394733009 0 116680003 900000000000011006 900000000000451002
> 2026638020 20220607 0 2011000195101 394812008 394733009 0 116680003 900000000000011006 900000000000451002
NOT AS EXPECTED - THE SUMMARY COMPONENT REPORT (linked) SHOWS 2 new and 1 inactivated expected????) Maybe because it's comparing to a DIFFERENT previous published package though, because we've generated the new one?!! Yes, manual checks show 2 inactivations + 1 addition since previous publication...
0 records added/updated
...as expected due to exact match in Summary Component Stats report for this cycle (see link above)
1 new records added:
> 5a9f6ee1-5e4a-4e6d-b740-e123946cfef6 20220607 1 2011000195101 733073007 22241000195100 SubClassOf(:22241000195100 :900000000000506000)
plus 1 records inactivated, related to newly re-activated Concepts:
< 1ed01c6c-26ea-4b1f-a59e-c79fd882fc51 20211207 1 2011000195101 733073007 394812008 SubClassOf(:394812008 :394733009)
> 1ed01c6c-26ea-4b1f-a59e-c79fd882fc51 20220607 0 2011000195101 733073007 394812008 SubClassOf(:394812008 :394733009)
. |