TOPIC 1: Frequency of Releases

Assumptions

• Benefits of frequent international releases understood, including much quicker turnaround time to promote local, add new and maintain/fix existing content, reduction in need for local 'temporary' content and subsequent untangling of data

• Move to more regular releases, initially 12 a year, monthly.

• QA will be reduced, but more automated with any issues will be fixed in the following release.

• Needs to be backwards compatible (still twice a year RF2 releases for example)?

SNOMED International Notes

• Projects which span releases and potential conflicts (see inactivations that get versioned when a concept is in use in the 'longer' project)

• Less time to 'fix' an unpublished change and it is guaranteed that some will appear in published editions, but get fixed in the following monthly release

• How does external QA get involved? Is there a month lag between end of authoring and the release to enable some feedback? Is there no more external beta QA, only release QA with issues incorporated into the next release?

• Still 'official' twice yearly releases in Jan & July?

• How many deltas are required? For example, only monthly deltas? Or should both monthly and 6-monthly deltas be provided?

• Need to introduce a robust Triage process to properly analyse issues reported in Prod and decide when to fix - otherwise this could result in a perceived drop in quality, when in fact it's due only to the Incident Management process.

• The Derivative product cycle needs to be considered - still just every 6 months?

• We also need to consider the translation implications for our internally produces products (Spanish Edition, Starter Set Translations)

• How do we cope with the possibility that whilst we can attempt to re-organise content projects to make them smaller and able to be published monthly instead of every 6 months, there will always be projects that cannot be broken down into smaller parts.  Drugs for example, would need to be published as one huge project, which would put a massive strain on the QA for that particular month's release.

• Can we move a lot of the QA to the front of the process, rather than leaving it all until the end?  Can we massively increase the amount of validation that happens  a) at authoring point, b) at review point, and c) just before promotion to MAIN?  Would this mean that we could then run purely automated regression testing at the Release point, as all that would be required is a quick triple check to ensure that nothing slipped through the main validation stages at the start of the process.

Authoring process consideration

• SI Content authoring workflow will require some refinement:

•  

  1. Projects would benefit from splitting up into much tinier sections, in order to be deliverable in monthly segments where possible, that are promoted and tested in time for monthly releases

  2. This means that MAIN needs to be a guaranteed clean branch, as the content there should be ready for release at any given time - therefore the review process would benefit from additional reinforcement

  3. This will require impact analysis/discussion across all authors/projects, in order to prevent either a) content being promoted to MAIN without dependent changes from other tasks, or b) concepts being continuously changed in MAIN (adding/deleting/updating) due to changes in approach or design.  All of this currently takes place within the 6 monthly editing cycles and is therefore transparent to the members, but could cause issues for users if it happens regularly between monthly releases, as not everyone will be able to take each monthly release straight away.
     
     
     

• How does this fit with current approach to new content requests, or does it sit alongside it?

• Mapping needs to be reconsidered, in order to either run it a month behind, or possibly split it off as derivative products of the International Edition, thereby decoupling it from the critical path of the monthly International releases.

NRC Notes

• Difficulty 'Importing' an International Edition release every month, or does the smaller amount of content to process make this easier? (similar issue for Managed Service)

• Translations and possible acceptance of local editions no longer fully translated (see Swedish approach)

• How long does the NRC QA take?  Can we automate everything over the next few months, or will there always be manual steps involved?  Do they do 2 weeks of solid QA, or do they spend 2 days of effort spread out over 2-3 weeks because of their capacity and the other constraints on their workloads?  How can we scale this to ensure that we still have external QA coverage?

• If we update the Release Notes to contain more detailed information, will this help with external reviews?

Implementor Notes

• Which version does a vendor use and does this impact national ehealth interoperability? (more version for vendors to use and therefore more difference in a market)

• More frequent RF2 import complexity, depending on local implementations - just deltas?

• We need to carefully engage with all vendors and NRC’s, to see what the potential impact is to them.  For example, how many people still use Delta’s, and how many would need to change their processes in order to accommodate these changes?

• Will multiple effectiveTimes in Delta’s be a problem for them?

• Might the perceived drop in quality be an issue, or will they be happier with the ability to get new changes (and fixes) in quickly each month? (also would we actually be able to do that?  Do we have the internal capacity in tech team and content team to keep up with reported issues and improvements every month?)

• How do they play catchup if they haven't updated their SNOMED source in say 2 years?  Will they have to run 24 Delta's through, or do we need to provide a custom Delta service?