Page tree
Skip to end of metadata
Go to start of metadata


IssueResolution actions


Born inactive stated relationships found for PreAlpha20170131 release

RESOLUTION: Relevant born inactive relationships deleted.

MCH - These born inactive concepts and stated relationships were not identified during authoring validation due to we don't run these type of assertions as they compare against previous release package which slows down the validation process. Maybe we should consider to update existing assertions so that they can be run at task/project level validations as well. These assertions are run during the daily release build.

AAT - we therefore asked Monica/Donna whether or not we have scope to have the RVF slightly in order to cover these issues as part of the authoring task validation. Monica confirmed this would not be possible if these do slow down the validation process.

  • ACTION: MCH therefore will look into whether there is an alternative way of running these 4 assertions without including other "release type" validations (more than 80) that compare current content against previous release. At the meantime Michael will walk through using the Daily Build RVF results with Monica, which will give them quick access to the same results.


Born inactive concepts found for preAlpha 20170131 release

717739000 20170131 0 900000000000207008 900000000000074008
717747000 20170131 0 900000000000207008 900000000000074008

RESOLUTION: Relevant born inactive concepts deleted.

Same as above


The following new RVF failure appeared after applying the Alpha feedback fixes that the Content Team implemented:

testCategory: "release-type-validation",
assertionUuid: "89ceaf00-79b9-11e1-b0c4-0800200c9a66",
assertionText: "All stated relationships inactivated in current release must have been active in the previous release.",
queryInMilliSeconds: 4513,
failureCount: 12,

RESOLUTION: 12 Relationships deleted completely, as they were new to the 20170131 Release cycle, and therefore not previously published.

Same as above


The following RVF failure was newly added after the Alpha fixes that the Content Team implemented:

testCategory: "release-type-validation",
assertionUuid: "5f1a51a3-6200-4463-8799-d75998165278",
assertionText: "New inactive states follow active states in the CONCEPT snapshot.",
queryInMilliSeconds: 91168,
failureCount: 1,
firstNInstances: { conceptId: 723067001, detail: "CONCEPT: id=723067001: is inactive but no active state found in the previous release." }

RESOLUTION: Concept 723067001 deleted completely, as it was new to the 20170131 Release cycle, and therefore not previously published.

Same as above


Six concepts are in the 'SNOMED CT model component module (core metadata concept)' module but the relationships in question here are in the 'SNOMED CT core module (core metadata concept)' module. The associated descriptions are all in the same module as the concept entries.


RESOLUTION: 5 Inferred relationships have been inactivated, and 5 new ones activated with the correct module ID, in order to align the Concept moduleID with the related Relationship moduleID's.

The final concept (900000000000441003) is the Model Component concept, and therefore has its Relationship in the Core module and not the Model Component module for a valid reason, as follows:

• The 2 root modules (Core and Model Component) were setup in the first place so that the Core was dependent on the Model Component module
• This meant that you could distribute the Model Component module standalone, but not the Core module
• Therefore all of the components of this Concept reside correctly in the Model Component module
• However, the Relationship cannot reside inside the Model Component module, as if this module is then distributed standalone the relationship would be a broken one, as the concept it relates to would be inside the Core module and not part of the Model Component module

The only action taken for this concept, therefore, was to update the comments in the code to ensure that this valid state is retained going forward.

 This was a defect in the classifier wrapper, which MCH has now resolved.

ISRS-103, ISRS-104, ISRS-106, ISRS-107, ISRS-108, ISRS-109 and ISRS-110

These are all to be ignored as warnings - do we need to whitelist these? (especially as we've now open-sourced the RVF)

Some of these can be fixed by whitelisting, but some are restraints in the assertions - so we need to fix them. The whitelisting framework is still a reasonably long way away due to capacity - most likely Q3/Q4 2017.

The Release Feedback process is labour intensive and could be refined
  • Action: AAT to setup meeting at the April conference to improve the process (Michael is currently testing a new option in UAT)
  • AAT also to give the requirements for the long term automation in this area to Hunter MacDonald...


IssueResolution actions


Three retired concepts have a historical relationship of an inappropriate type:

RESOLUTION: IHTSDO Content Team resolved as follows:

139521000: Tingling: [sensation] or [has sensation] (finding) now retired as ambiguous
267174001: Tingling: [sensation] or [has sensation] (finding) now retired as amibiguous
(both with Possibly equivalent to 274676007 Tingling of skin (finding))

The third concept (700043003) was found to be valid, and therefore no action required

Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward.


Ten RF1 descriptions for active concepts are status 10 (MOVED_TO), alongside descriptions with active status:
473038012: Hyperprolinemia type II
473040019: Hyperprolinemia, type II
357693015: Lichen planus pigmentosus
377070012: Joubert syndrome
378213010: Irapa type spondyloepimetaphyseal dysplasia
1787720010: Frontal fibrosing alopecia
473039016: Hyperprolinaemia type II
473043017: Hyperprolinaemia, type II
113698011: Warkany syndrome
187742012: Caroli's disease

RESOLUTION: IHTSDO Content team have inactivated all of the descriptions in question with reason "moved elsewhere"

 The Task originally created to resolve this issue somehow got deleted as part of the process, and so never made it into the Jan 2017 Release.


Three concepts in RF1 have more than one historical relationship (except MAY_BE_As, MOVED_TOs OR WAS_As):

RESOLUTION: IHTSDO Content Team remodelled so that the three concepts now have one reason for inactivation and one historical relationship each as appropriate.

Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward.


As part of the previous editing cycle, a minor issue was found with several relationships, which had targets with different semantic tags to their sources. In discussion with the Content Team at the time, we agreed to fix all but one, which was seen to be an example of the exception to the rule, and therefore a valid relationship to retain:

id effectiveTime active moduleId sourceId destinationId relationshipGroup typeId characteristicTypeId modifierId
6598284022 20160731 1 900000000000207008 718447001 363013003 0 116680003 900000000000011006 900000000000451002

187 718447001 718447001 (finding) : 363013003 (disorder) 718447001: Difficult intubation (finding) - 363013003: Complication of introduction procedure (disorder) 9

RESOLUTION: IHTSDO Content Team remodelled this concept and removed the disorder parent.

Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward.


The following 3 concepts had the Core module assigned to them during authoring, instead of the Concept Model module:


RESOLUTION: 3 records updated to the correct ModuleID in the Concept Delta file in the Beta release

These were not assigned, the tool defaulted to the incorrect module ID even when a concept was cloned. Core module vs Model component. This should be default as per hierarchy selected. This was a new item introduced by SCA. Previously it was not a choice for an author to make. Now the team are aware and guidance has been written into the Ed. guide.

  • Action: Monica to continue to chase SCA ticket for improvement

The concept 722541007 has concept modeling of Causative agent (attribute) = Infectious process (qualifier value). The value "infectious process" should not be allowed because it is not in the range for causative agent.

RESOLUTION: Relationship record deleted, to remove the erroneous attribute Causative agent (attribute)

This was identified by the new MRCM validation, and therefore the long term solution for this is to get the MRCM rules into both the SCA input validation, and the RVF, so that these issues can be resolved as part of the editing cycle going forward.


The concept 723017008 has After (attribute) = Intraocular lens implant (physical object). This violated the range for After attribute that should only take values from clinical finding hierarchy or procedure hierarchy.

RESOLUTION: Relationship record updated, to change the erroneous attribute Intraocular lens implant (physical object) (313236002), and add in the new attribute 69724002|Insertion of prosthetic intraocular lens (procedure)|

MRCM rules ought to pick this up or not allow improper selection. Batch uploads bypass the MRCM rules therefore these can slip through.

Since this occurred, the validation of ICD-11 has been changed from small amounts of spot checks to thorough checking by the ICD-11 authors.


A new concept - 723067001 | Transcatheter aortic valve replacement (procedure) | - is a duplicate and so has been inactivated within the same authoring cycle.

RESOLUTION: Concept deleted completely, as it was new to the 20170131 Release cycle, and therefore not previously published.

This was not a duplicate in fact but in as much as it was questioned by an member from a clinical perspective so the right thing to do was to pull it back till further investigation of meaning was carried out.

Therefore this was a one off and will not re-occur.


ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations..

· AFTER(255234002) - only modelled with valid destination concepts
6795991026 Displacement of intraocular lens (disorder) After (attribute) Intraocular lens implant (physical object)

RESOLUTION: 1 Relationship deleted completely, as it was new to the 20170131 Release cycle, and therefore not previously published.

Same as ISRS 91:

Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF?


ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations..

· CAUSATIVE AGENT(246075003) - only modelled with valid destination concepts
6806717028 Megacolon co-occurrent and due to infectious colitis (disorder) Causative agent (attribute) Infectious process (qualifier value)

RESOLUTION: 1 Relationship record updated, in order to replace the Causative agent attribute with Pathological process.

Same as ISRS 90:

Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF?


ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations...

· HAS INTERPRETATION(363713009) - only modelled with valid destination concepts
6795824028 Androgen excess caused by drug (finding) Has interpretation (attribute) Androgen level (procedure)
6799904021 Transient neonatal neutropenia co-occurrent and due to neonatal bacterial sepsis (finding) Has interpretation (attribute) Neutrophil count (procedure)
6804767021 Transient neonatal neutropenia due to congenital viral infection (finding) Has interpretation (attribute) Neutrophil count (procedure)

RESOLUTION: 3 records removed, plus 3 records added in the Relationship and Stated Relationship Delta files in the Beta release, in order to change the attribute to "Interprets".

 Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF?

ICD-11 batch allows incorrect attributes to be selected.


ADHA ran the alpha package through their validation routines. Technically, it passed – from a content persective there looks like a number of concept model violations..

· OCCURRENCE(246454002) - only modelled with valid destination concepts
6622179020 Acquired postural plagiocephaly (disorder) Occurrence (attribute) Acquired (qualifier value)
6646405025 Acquired arteriovenous malformation (disorder) Occurrence (attribute) Acquired (qualifier value)

RESOLUTION: 2 Relationships deleted completely, as they were new to the 20170131 Release cycle, and therefore not previously published.

 Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF?

ICD-11 batch allows incorrect attributes to be selected. This is partly due to the fact that an allowable value for this attribute is CONGENITAL so it is easy to presume that ACQUIRED would belong here too.

Guidance has been clarified in the Ed. guide.


ADHA ran the alpha package through their validation routines. Technically, it passed – from a content perspective there looks like a number of concept model violations..

I’ve got almost 700 observable entity concepts failing the tests below… but…

· observable entity(363787002) only approved defining attributes used
· COMPONENT(246093002) - only modelled with valid source concepts
· SCALE TYPE(370132008) - only modelled with valid source concepts
· TIME ASPECT(370134009) - only modelled with valid source concepts
· USING DEVICE(424226004) - only modelled with valid source concepts
· All concepts within hierarchies without information models are primitive|900000000000074008| or are concepts with less than 2 |Is a| relationships
· Only concepts within hierarchies with information models are defined|900000000000073002| or are concepts with 2 or more |Is a| relationships
It’s likely the concept model here has been updated, and our tests need updating… However, I’ve just checked the most editorial guide and it still lists Observable entity in Table 5 as a “Top-Level Hierarchies That Have No Defining Attributes”.

RESOLVED: This was traced back to a change that was made to the Concept model for Observables, that was implemented in September 2016. The editorial guide was updated accordingly, but has not been published since the update was made, and so ADHA did not have visibility of the updates. IHTSDO therefore provided them with the information on the new Concept model, and they will update their validation rules accordingly. This is therefore a non-issue and no action is required.

 Do these ADHA-discovered issues need to be covered in our input validation and/or the RVF?

Publish the updated editorial guidance along with the Alpha release.


The following RVF failure is now reporting 7 Active Descriptions that have Inactivation reasons assigned to them:

assertionText: "Active descriptions do not have active inactivation indicators",
queryInMilliSeconds: 6970,
failureCount: 7,

Either the Descriptions need to be inactivated accordingly, or the reasons updated/removed as the Descriptions should remain Active.

RESOLUTION: 6 Inactivation reasons were inactivated (as they were previously published), and 1 was deleted (as it was new to this release cycle).

  • Action: Monica to test this in UAT SCA, and if it still causes issues with the invalid inactivation reasons being created then she will raise an SCA bug ticket - if not then we know this was a one-off issue and will not re-occur.


The new refset being added to the January 2017 International Edition (723264001 - Lateralizable body structure reference set (foundation metadata concept)) needs a new record added to the International edition refsetDescriptor files.

RESOLUTION: The following refsetDescriptor record has been added accordingly:

bbdcc9fc-5bc6-415a-a5ee-c5adfc569bd5 20170131 1 900000000000207008 900000000000456007 723264001 449608002 900000000000461009 0

This kind of issue is now being addressed by the new Service Acceptance process, which will prevent these kind of pre-dependencies from being missed at the start of projects.


5251000119108 |Acquired arteriovenous malformation (disorder)| incorrectly uses 255396000 |Acquired (qualifier value)| as the value of |Occurrence|

IHTSDO removed attribute value pair of Occurrence - Acquired.

Concept therefore needs to be changed to primitive.

The related concept, 402847002 |Acquired arteriovenous malformation of the skin (disorder)| was also identified to have an invalid attribute.

RESOLUTION: Both concepts have been remodelled accordingly.

Same as ISRS-96


Three retired metadata concepts were erroneously moved into the Core module:

447564002 1 Non-human simple reference set
(foundation metadata concept)
449609005 1 ICD-10 map category reference set
(foundation metadata concept)
700043003 5 Example problem list concepts reference
set (foundation metadata concept)

These metadata concepts were transferred into the core module when they became inactive, so the RF1 conversion tool thinks they're relevant. The RF1 conversion filters out concepts with a metadata semantic tag, but only if they're also in the model module.

RESOLUTION: ModuleID for all three concepts assigned to the Model Component module (900000000000012004).

Simply a genuine human error, so the content team will improve the editorial guidance in order to prevent these issues going forward.


There are 21 Historical Associations that are active, but which have been found to have inactive concepts for their targetComponentID:

id effectivetime active moduleid refsetid referencedcomponentid targetcomponentid
817ddce9-894d-54b3-84ee-4a94cee2acb5 20100131 1 900000000000207008 900000000000528000 193369009 399625000
946f56dc-684d-5cad-99c7-6f3f5e202a73 20100131 1 900000000000207008 900000000000528000 204273002 204270004
a7d5339d-d51d-5a1f-865c-0bce6af6da90 20100131 1 900000000000207008 900000000000528000 138107003 81877007
acfbb45c-a1b1-5b08-b8a9-1e6e0f0a2ca0 20100131 1 900000000000207008 900000000000528000 137020000 265987007
ad545d56-19c0-5a57-bed4-d0a946d24d79 20100131 1 900000000000207008 900000000000528000 193371009 399625000
b463afa5-7d24-5281-b6a8-ec21b4b0bf9b 20100131 1 900000000000207008 900000000000528000 149532003 274033006
d59ef95e-e87e-5411-bff7-f35c7c4d72ad 20100131 1 900000000000207008 900000000000528000 266937006 81877007
f356bb7a-0fda-5ccc-ba8b-4453fae7f824 20100131 1 900000000000207008 900000000000528000 159721006 265987007
f53222ee-9de3-553a-b192-a85b744a5bac 20100131 1 900000000000207008 900000000000528000 193366002 399625000
01c6981e-075b-511f-b1a3-2a332bdbcaa8 20100131 1 900000000000207008 900000000000528000 287840006 274033006
08e4cfd5-01ba-5ea9-a05c-4aa5ffd8450b 20100131 1 900000000000207008 900000000000528000 186296003 398599000
31c7aadc-1628-5597-8d9a-d7bead9a9661 20100131 1 900000000000207008 900000000000528000 154851005 88339003
3afd517b-1eda-5904-9866-9530e19f3af8 20100131 1 900000000000207008 900000000000528000 136834007 159564001
4f8b9c16-070a-5f49-b9fe-fe9c9c8fe98c 20100131 1 900000000000207008 900000000000528000 267609006 399625000
53202a69-5329-5c06-8242-db94c348892e 20100131 1 900000000000207008 900000000000528000 139355001 267052005
55b96987-32b8-5db6-96bf-d2b282179841 20100131 1 900000000000207008 900000000000528000 162079002 267052005
641f1731-de51-558e-b27b-f135674fa28f 20100131 1 900000000000207008 900000000000528000 193355009 399625000
6b3085fd-51d1-5fd6-a23e-19300773fb02 20100131 1 900000000000207008 900000000000528000 193368001 399625000
75b0053f-210f-5c35-a8ed-53ef0ea33f90 20100131 1 900000000000207008 900000000000528000 159566004 159564001
7b85085f-496b-5163-93d3-f7679cba2d78 20100131 1 900000000000207008 900000000000528000 286932008 88339003
7e9381b9-b964-5517-b419-041eb0339b5e 20100131 1 900000000000207008 900000000000528000 193372002 399625000

RESOLUTION: It was discovered that 2 of the above source concepts actually had 2 concepts referenced, and so 23 associationReference records were updated in order to replace the inactive targetComponentID's with the relevant active concepts. In addition to this, the system then automatically inactivated 12 additional associationReference records, where the source concept was also associated to "Limited components" ([900000000000486000|limited]):

95d6b955-adb9-59fc-a011-93ee592153b1 20170131 0 900000000000207008 900000000000527005 149532003 287840006
f26e9e9e-230a-59a8-8833-c91f916a9ca2 20170131 0 900000000000207008 900000000000527005 287840006 149532003
de91b7cb-7e7b-5ce1-8f68-6664f702d7cb 20170131 0 900000000000207008 900000000000527005 137020000 159721006
39c3ce30-764f-54c3-8fd6-c835100e3883 20170131 0 900000000000207008 900000000000527005 159721006 137020000
d4e899ca-28a1-5aff-8f21-1dac26145649 20170131 0 900000000000207008 900000000000527005 138107003 266937006
faa7f07c-1bb3-5c7a-a90b-4e6b1ad76754 20170131 0 900000000000207008 900000000000527005 139355001 162079002
d9e24c55-5379-5b82-afe8-e8acf8b8d8a8 20170131 0 900000000000207008 900000000000527005 162079002 139355001
01d104e1-cf86-5d04-a42b-a162de76da8b 20170131 0 900000000000207008 900000000000527005 154851005 286932008
e416f825-01e5-59ec-be00-8ec638c0e541 20170131 0 900000000000207008 900000000000527005 136834007 159566004
e28804d0-042d-59c1-940b-7b6b1be69415 20170131 0 900000000000207008 900000000000527005 286932008 154851005
51ccb59d-2090-5611-b2a9-896edde0e029 20170131 0 900000000000207008 900000000000527005 159566004 136834007
39763acf-0f7d-50b5-872d-94741fcd69bb 20170131 0 900000000000207008 900000000000527005 266937006 138107003

This issue needs particular attention, as one of our members is asking why the fix for this changed history?

The issue here is that when the targetComponentID has been changed in the past, the record was inactivated and re-created with the new targetComponentID. However, the termServer considered this a mutable field, and therefore since we moved to the termServer if we change the targetComponentID field it will simply update the record instead of inactivating and re-creating.

  • Action: One of the members has complained about this approach, and so AAT will speak to David/Linda about whether or not the targetComponentID can be considered a mutable field.
  • AAT emailed the question - will post the response once discussed and agreed

Both David and Linda agreed the following:


"As far as I can tell there is nothing in the documents that these fields to be immutable. However, there are some reasons that suggest to me it might be better for them to be immutable.


For example:


  • If the nature of the historical association changes then new rows are needed as they would be in another refset. Similarly, I would be a bit concerned in the case of the ambiguous case "POSSIBLY EQUIVALENT TO" because in that case it would be arbitrary to simply use the same association and change the target concept.
  • The association refsets are similar in function to the relationships ... where both sourceId and destinationId are immutable.
  • If the churn level is fairly low, immutability has a very low-cost and offers significant additional clarity.


Arguably the only case where it would "reasonable" to treat the target as mutable would be where





Then B is inactivated and a new historical relationship is added:






in this case one could argue that the transitive result represents an update of the existing association.






However, overall I would suggest that immutability is clearer and safer in all cases.

We therefore need to take a look at the termServer functionality and update it accordingly...


Mapping Release Notes - They were questioned by our members due to some inaccuracies in the ICD10 map wording.
  • Action: AAT will ensure that from now on Donna will also be included in both meetings and Release Notes review processes going forward.

 Future Improvements

Area for improvementActions

Walk through known issues with the content team, to ensure they will all be resolved in time for the Jan 2018 release…

AAT to discuss with Lesley

ICD-0 map can actually be maintained in the mapping tool now, (and has been able to do so for a year) , so we now need to move to that as termServer isn’t maintaining it properly

AAT to setup a call to discuss with Lesley + Donna + Yong + WCI...


  1. 10 inactivated records came through in the termserver simplemap export:

                                          See ticket

  1. Donna thought these were related to ICD-10 codes (instead of ICD-0 like it supposed to be the scope for simplemap, as ICD-10 is supposed to only be extendedmap), but Yong thought they were Anatomy codes, inactivated automatically by the system because the related concepts had been inactivated. Yong then confirmed these were outside of the scope of ICD-0 mapping.
  2. We may have a small disconnect here, as I’m asking Donna to account for the content of simplemap and extendedmap files, yet she doesn’t have visibility of all of the input for these files!
AAT to discuss with Lesley + Donna - include in ICD-0 conversation

Some Namespace concepts are now being created with the requesting company/body in as a preferred term (eg) 1000198   but this is not being consistently applied (eg) 1000201 - so can we either do it consistently or not at all...

AAT to discuss with Lesley - Yohani actually does this, so AAT to speak to Yo instead... company is available, so should be no issue to include:
We received reports in from one of the community to tell us that they couldn’t access some of the pages that the team linked into the Release Notes. Lesley agreed to just open up content pages

Authors are concerned with the fact that we can’t merge alpha/beta fixes back to main until end of July - this has always been the case but never a problem before due to small volumes of change in the alpha/beta period in the past.  Going forward this will likely increase, so we need to find a way to merge changes back into main after each release stable phase (alpha/beta/member) without any risk to MAIN

Rory confirmed that we can’t promote to main every alpha/beta/member release because you can’t promote without re-basing - so the only option is to fix this restriction might be to have 2x fix branches, then each time you want to do a fix, you test it on the first (release fix) branch until you’re happy with it, then once testing signed off you replicate the change(s) in the second (merge fix) branch, which we will then promote to main in order to keep the authors in sync.  this will allow the merge branch to get re_based with the latest content (for the next editing cycle), whilst keeping the release branch clean with only the current release’s content in it…

AAT to agree the update to the release process with Lesley/Maria in order to ensure she understands that she will need to make each fix twice in the next release...

Lesley to talk to Maria/Monica first to get perspective on how much impact the delays had in the July 2017 release (Toni, Penni and Maria) - then we can all talk together about whether or not tp update the process...


Both Hazel and Genevieve managed to have an adverse impact on our mapping process - so we need to refine the process to ensure that we can check both “New”/“Editing”/“Finished" statuses and “QA” work (Need to ask WCI to update the tool here??  Or just have a manual process whereby Donna asks them on the weekly calls to confirm they have nothing outstanding in QA status after content cut off for each release)

Lesley confirmed Content Release Managers should also have this as a check box on their list - both to communicate to the externals not to touch anythign during Release periods, and also to look into changing externals access rights in the Mapping Tool to Read-only durin htese periods...

NEED TO DECIDE THE PRIORITY OF THE FIXES FOR THE MRCM INFERRED + STATED HISTORICAL ISSUES - for example, there was one concept (717703006) which Jim said should be fixed asap

AAT to discuss with Lesley + Jim - Lesley to plan this out

BATCH IMPORT APPEARS TO BE POTENTIALLY RISKY - quite a few issues we came across in the July 2017 seemed to be rooted in batch content added - so would be good to review and refine the validation around Bulk imports - for example ISRS-221 (concepts marked in white in the spreadsheet attached) - all bulk imported by Toni (or so Monica thinks)

Not much we can do about this technically - need to discuss with Lesley to ensure everyone takes the utmost care when implementing Batch Imports - and also tries their best to finalise content before importing, rather than importing and then changing FSN's, etc.

Batches are all different processes, so Lesley needs me to send her all of the batches in question in order to fix them. I sent her ISRS-221, and she said this was an issue with the dirty content from termMed - Lesley will discuss with Rory how to get these reviewed BEFORE they get put into a task...

Some documentation gaps that still need closing - matt cordell to send details so we can close them in time for jan 2018

AAT to speak to Maria when Matt sends the list
ISRS-221 - we need to agree what the relationship between inactivation indicator & historical association should be, and raise tickets to have the SCA and RVF enhanced to matchAAT to discuss with Michael/Hunter

Re-basing issues! rfbintjula yet again got re-based against our express request 

RDA confirmed that this ticket has already been raised to be able to lock the Release branches - it will definitely get done before the Jan 2018 Release cycle starts in November 2017.

New potential clinical safety issue (see email from Monica at 14:30 on 13/7/2017 - any way to prevent this from happening again going forward?

Not really, but the main learning point here is that we need to ensure that we have reached a full (and unanimous) decision on whether or not these issues are actually Clinical Risks, before we raise the red flag with the Release/Technical teams and start off the whole recall process.  If this had been discussed fully with all Content authors, we may have not needed to perform the recall after all.  Therefore, we need an internal process first which goes through and confirms with their own stakeholders before raising the red flag.

Need to work through all issues found in pre-alpha, alpha and beta testing, both internally +++++ externally, and ensure that we retrospectively update the rvf to cover all these scenarios

AAT to discuss with Hunter as part of the next cycle of Release improvements.
  1. We need to start working on moving the technical back end changes to be able to be fixed by the authors instead. This is causing us a lot of problems in the Alpha/Beta period, where backend fixes are clashing with front end fixes (eg) - where back end fixes (PLUS in this case also changes to the were made for Yong’s SEP Refsets) and so an AssociationReference Delta created for the Release and placed int he Externally Maintained Refset folder, then continue to overwrite changes to the Historical Associations that Monica was trying to fix as part of the Beta feedback period.

    1. This is only likely to get worse going forward, so the more we can move to the authors fixing everything in the SCA (and therefore delivering everything through the termServer Delta exports) the better
    2. This is also a problem for a load of fix types that can’t be fixed by the authors because of the Versioning issue - so all Born Inactive content has to have back end fixes because they’ve already been versioned - this also gets very messy!
    3. Also this is a problem for new changes to the International Release which can’t get include in the International Edition - like Yong’s SEP refsets!  Next time might be slightly easier because we may have HM changes to merge these Delta’s available (if not descoped), but still MUCH better to incorporate all authored content in the termServer or refset/Mapping tools…
    4. Also a problem for the simpleMap files, as the CTV3 map comes out of the termServer, but the ICD-0 map comes from the mapping tool, so we need to manually merge the 2 into one simpleMap file. This means that if any impact o CTV3 from alpha/beta changes, we need to manually export the CTV3 changes from the termServer again, and re-merge the files!  So would be so much better to either host ICD-0 in the termServer, or both CTV3 and ICD-0 in the mapping tool!
  1. Michael hoping to allow them to start doing a lot of these fixes themselves - for example allowing the release lead to delete born inactive content during the release cycle - AAT to raise infra ticket
  2. Hunter work should also improve this situation

We need to fix the conflicts that can happen when runnig multiple jenkins jobs, or possibly even jenkins jobs vs validation runs!  

  1. so if for example i’m running a full international build, but someone kicks of an sca validation run, will that clash? 
  2. could this explain the 409 conflicts i sometimes get when trying to run the international builds, which then magically disappear and fix themselves before we find the root cause?
  3. peter had a look but was not sure that the code for returning a sensible error when an export is already underway was done however, this ticket is still at "assigned" to b2i:
  4. either way we need to be able to run multiple concurrent builds!!!
  1. Hunter work to improve this situation - after hunter complete their work, we should update the status management of the release process as per Michael’s idea, to allow multiple contiguous builds

Need to discuss whether or not we should be going back to the uktc and telling them we will no longer consider any rf1 defects as part of the current release cycle - only as part of ongoing editing cycles for future releases?  (only issue here is that i no longer have a friendly contact in the uktc, or even someone who will talk to us or answer any of our emails!  so could be an issue getting the message across, as might sound harsh via email…)

  1. Rory confirmed any RF1 issues that have their roots in RF2 still need to be fixed, but anything RF1 specific we will no longer fix - but no need to make noise about it now, just wait until the next set of RF1 only defects come through

Traceability database logging - is there any way to break down the logs for concepts which have huge logs? example was isrs-230, where we couldn’t track the root cause of the issue because the log for just one of the 3 concepts in question was over 11mb!!  the logging needs to cut off at 1mb otherwise it’ll break the indexes, so at the moment it just completely fails to log for any large complex changes!  if we could break it down into smaller chunks then this’d be great, as given the likelihood of content authoring continuing to be complex going forward (with all the remodelling work coming down the pipeline), we otherwise run the risk of having holes in our audit trail, making it more time-consuming to track issues down.

  1. AAT to raise infra ticket to say even if a log is too large then truncate it before the limit to prevent crashing.

How realistic would it be to cut off the content slightly earlier than normal next release cycle?  As we saw from the craziness in this release, the volume and complexity of the authoring changes meant we were working long hours right up until the very last day of the release!  this is fine from my perspective, but it will impact the content release lead if this continues, plus it’s a huge risk to the release, as human error is far more likely to creep in if we’re working that late.

AAT to discuss this with the content team for the July 2018 release, as the next Jan 2018 release cycle is already confirmed.
  • No labels

1 Comment

  1. I have reviewed this page and have no updates I can see which I am to provide. The only one which had an apparent TO DO was ISRS-101 and I do not know a way to recreate the action which caused this. Presumably if it happens again, an RVF will be generated as before. thanks, Monica