Canadian SNOMED CT® Extensions Challenges & Lessons learned Presentation to Implementation SIG October 2012 Presented by Linda Parisien and Beverly Knight

Agenda Provide an overview of our Canadian (CA) National extensions Share some challenges with the CA extensions — Discuss some options and ask questions Share lessons learned from Request for Change (RFC) process 1

Background Canada has 2 ‘active’ Namespaces for Canadian national extensions — English (New concepts, descriptions, relationships) (en-CA) Active or current & pending move status Updated frequently based on RFCs Never released — French (New Preferred Terms) (fr-CA) French Canadian language translation +35,000 terms Released with the international release Has not been updated since 2009 RF1 format 2

Background / General Challenges Tooling — CliniClue — RFC Request and Tracking: Excel Template and Spreadsheet — Modelisation, ID generation and Distribution files: DTS Editor — No other tools to validate e.g. SQL or Access database Knowledge & Resources — Small team — Not all with the same technical and content knowledge — Feels like we are “challenging new ground” 3

Decisions related to the language code of English content : — Canadians use a mix of GB and US, For SNOMED CT core content, will use en-US English extension created in 2009 and en-CA was used as the language code — Confusion now with language code because we are limited by using RF1 at the moment FSN are language code: en PT are language code: en-CA Question: — For RF1 users, what language code(s) did you assign to national descriptions in your extension? 4 Challenge: English Language Code

Challenge: How to constraint content (using RF1) -1 5 Need to constrain content for Canadian use that would override International content Ex.: Klebsiella species (organism) = Core not to use in CA Klebsiella species not specified (finding) = CA to use instead Options considered: 1. Develop and release an exclusion subset 2. Develop an exclusion subset, apply it to Core content and release very large file with exclusion applied Question: - Have you faced this issue? - How did you constrain your extension content?

Challenge: How to constraint content (using RF1) -2 6 Need to define other parents than the current one in Core. While waiting for IHTSDO decision, a new parent is created in Extension. Ex.: Route of administration value (qualifier value) = Core - intraventricular (qualifier value) = CA - - Intraventricular route - cardiac (qualifier value) = Core Questions: — How do we deal with this type of addition when not accepted in Core? — What is the impact on implementers?

SNOMED CT Identifiers are too lengthy for some vendors & we have been told a barrier. Different SNOMED CT Identifier length — French language subset = Item identifier was incremental for a total length between 12 and 15 digits — English Extension = Item identifier is randomly allocated and fills all space (8), for a total length of 18 digits Options being considered for future: 1. to generate the item identifier incrementally 2. decrease the fixed length to 16 digits 3. create another shorter identifier that would be mapped to the SCTID 4. status quo: Maintain the Canadian SCTID to a fixed length of 18 digits Questions: - Did you face this issue in your country? - Would a variation in SCTID have an impact on querying data? - How will the RF2 impact us? 7 Challenge: SNOMED CT Identifier Length

Our Successes Several strategies & papers developed to get the team on the same page — “external” guidance documents Pre-adoption paper Terminology selection guide More flexible to workaround the issue/barrier of post coordination = pre-coordinated concepts will be added to our Canadian extension Addition of Canadian principles and editorial guidelines to IHTSDO guidelines Have acquired some tooling support to generate CA Extension Reaching out to other member countries was quite helpful: UKTC, NLM, Nehta, and others Internal knowledge is growing 8

Lessons Learned from Extension management Extension — Clean data to import in the tool to achieve modelisation — Training related to tooling took much more time than expected Refset — Distribution files in text file rather than in excel, zipped — Create one ‘definition’ file and one ‘members’ files — Publish them at the same time as the Canadian extension to get the modeling piece (e.g.: IS-A relationship) — Need for French Translation 9

Lessons Learned from Managing Requests Expectations from requestors needs to be managed (process takes quite a bit of time). There was a gap in expectations with what could be delivered. — Need to emphasize the time it takes to process requests Weekly meetings with implementers with large volume of requests works very well — we collaboratively worked out the best solution for the implementer. — The SC provided the requestor with an opportunity to confirm everything where there was a slight change. This resulted in a better product 10

Request for Change Metrics 11

Additional questions 12 Format — RF2 format is complex How many modules should be used?

Thank you