pan-Canadian LOINC Observation Code Database Maintenance Guide

pan-Canadian LOINC Observation Code Database (pCLOCD) Terms of Use:

https://infocentral.infoway-inforoute.ca/en/about/tou/pclocd-terms 

LOINC and RELMA Terms of Use:

https://infocentral.infoway-inforoute.ca/en/about/tou/loinc-terms

1. General pCLOCD Information

The pan-Canadian LOINC Observation Code Database (pCLOCD) is based on international standards and customized to meet the needs of Canadian stakeholders.  It is intended to support the use of electronic data exchange using both existing standards as well as laboratory messaging standards.  Together, these standards are required to achieve an interoperable pan-Canadian Electronic Health Record and facilitate the electronic exchange of laboratory information.

The pCLOCD is not expected to be “complete” at any given time since laboratory testing technology changes continually as new tests are devised and reporting requirements change.  The pCLOCD will be maintained and revisions published periodically by the Infoway Standards Team.

The pCLOCD was created using the LOINC records and attributes that specifically meet Canadian laboratory ordering and reporting requirements.  It will include records that cover most laboratory domains pertaining to laboratory testing on humans and non-humans.

LOINC is the most comprehensive and flexible standard from which the pan-Canadian Laboratory Observation Specification for test request and result codes could be developed.  LOINC was initiated in 1994 by the Regenstrief Institute and developed by Regenstrief and the LOINC committee as a response to the demand for electronic movement of clinical data from laboratories that produce the data to hospitals, physician's offices, and payers who use the data for clinical care and management purposes. There are gaps in LOINC which created a requirement to generate new codes to meet Canadian ordering and reporting. This process is ongoing as new Canadian ordering and reporting requirements are identified.

The pCLOCD standard is published as an Excel file that contains ten tabs.

• The “Overview” tab provides a brief description of the tabs in the entire nomenclature workbook.
• The “How to Read” tab outlines a color code used for column headings and also clearly describes the various columns in the “Nomenclature” tab.
• The codes are found on the “Nomenclature” tab.
• The “Terms of Use” tab provides the Canada Health Infoway Copyright notice and license terms of use, the LOINC Copyright provides LOINC’s notice and license terms.
• Users should be familiar with the “Overview”, “Terms of Use”, “LOINC Copyright” and “How to Read” tabs before utilizing the “Nomenclature” tab.

The standard is also published as a Microsoft Access database. The Access file includes the same LOINC and Canada Health Infoway copyright information and "Nomenclature" tab content found in the Excel file. The table is conceptually identical to the “Nomenclature” tab although various columns may be expressed in a more specific data type (e.g. A "Yes/No" column in Excel may be expressed as a formal Boolean attribute in the MS-Access version; calculated fields may be translated to direct value fields).

The core LOINC components of the pCLOCD are translated to Canadian French and the pCLOCD has been published as a bilingual artifact since 2009.

The pan-Canadian LOINC Observation Code Database (pCLOCD) was designated as a Canadian Approved Standard (CAS) in March, 2011.

2.   Published Versions

2.1 Identifying Releases

The pCLOCD standard is published twice a year. Each version can be distinguished from the previous by its unique release number. Release number formatting holds key information about the data. All Releases for all Specification Types will be identified by a unique Release Identifier using the following scheme from the Product Release Management Policies:

Rxx.yy.zz (ER) where:

• xx is the Major Number for a Release.  This will only change due to Major Change in functionality or format (e.g. Cross Product Harmonization caused a shift from 01 to 02).
• yy is the Minor Number for a Release.  Each Full Release, if it does not cause a change in the Major Number, will result in the Minor Number of the Release being incremented by 01 (e.g.: from 02 to 03).  When a new Major Number is published, the subsequent Minor Number is set to “00”.
• zz reflects the Delta Number, incremented for each subsequent Delta Release applied to a Full Release.  When a new Full Release is published, the subsequent Delta Number is reset to “00”. 
• (ER) is only added to the end of a Release Identifier when the release is published for external review.  This allows the same major/minor/delta numbers to be used for a release even though the content may differ after an external review.  For instance, rather than R02.10.00 referring to the external review publication and R02.11.00 referring to the post-review publication, these would be identified as R02.10.00 (ER) and R02.10.00.

The LOINC version is important version information published by Regenstrief and referenced in the Regenstrief RELMA mapping tool. This number is contained within the file name and also in the Release_Version Identifier Column in the Nomenclature tab.

The format of the release number is RXX.YY.ZZ. Working versions created between publications will have a different extension number (ZZ) with each change. These versions will not be published, but they will be shared if requested. The format of the file name is:

pCLOCD-FR-EN-RXX.YY.ZZ_LOINCn.nn-YYYYMMDD.xlsx.

Each changed record will be marked with the release number and LOINC version of the change (RXX.YY.ZZ_LOINCn.nn).

The most recent version of the pCLOCD can be found on InfoCentral in the Terminology Gateway, located at the following URL:

https://tgateway.infoway-inforoute.ca/pclocd.html

InfoCentral will also contain the previously published versions for reference purposes or restorations, if older versions are required, please contact us.

3.   Basic Utilization Information

If the pCLOCD is being accessed and utilized for the first time, some important aspects of the data need to be understood.

3.1 Customizations

The pan-Canadian Component name is derived from the LOINC component name. The pan-Canadian Name is derived from the pan-Canadian Component name. The following rules have been applied to customize the LOINC component to create the pan-Canadian Component Name:

1. Acronyms have been spelled out from the LOINC Component Name (e.g. Ab - spelled out to antibody)
2. Common terms are used for allergens, vitamins, hormones, & coagulation tests
3. Removed most punctuation (i.e.”^”, “.” Etc) and replaced with a space
4. If there is a modifier separated by a period (“.”), the modifier MAY come first
5. Microscopic observation replaced by Microscopic Examination
6. Timing abbreviations written in full (i.e. “H” replaced by Hours)
7. In the Challenge Class, where the challenge is not specific in the LOINC Component Name (i.e. “analyte” post XXX Challenge), the XXX was dropped
   1. Cortisol^2H Post XXX Challenge has a pan-Canadian Component Name of Cortisol 2 Hours Post Challenge
8. In the Chemistry Class the following rules were applied
   1. Acidity.Total replaced by Acidity
   2. Hemoglobin Gastrointestinal replaced by Occult Blood
9. If the LOINC name is shown as “analyte”/Creatinine or Protein, the “/Creatinine” or Protein will be retained in the pan-Canadian Component Name.  The unit will not reflect that part of the name.
10. When the LOINC Component Name contains “XXX”, the “XXX” will be dropped or replaced with “Other”.
11. In the Coagulation Class, where “Coagulation” has been used to preface the analyte in the LOINC Component Name, it has been dropped (e.g. Factor assays)
12. In the Allergy Class, the LOINC Shortname is used with no abbreviations.
13. In Micro when the LOINC Component Names includes “Identified” in the name, it will be dropped in the pan-Canadian Component Name. 
14. When the LOINC Component Name is “Bacteria Identified” the pan-Canadian Component Name will be blank. In these cases, the pan-Canadian Name should be used.

3.2 Units of Measure

In order to ensure interoperability, units of measure must be expressed in accordance with the vocabulary specification of the LaboratoryObservationUnitOfMeasureCode concept domain within the messaging portion of the specification.  Consistent with the general direction of HL7 V3 as well as with other pan-Canadian EHR information standards such as the CeRx and iEHR specifications, this domain designates the Unified Code for Units of Measure (UCUM) as the applicable code system from which the value set is derived.

The Unified Code for Units of Measure (UCUM) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. It is inspired by and heavily based on ISO 2955-1983,ANSIX3.50-1986, and HL7's extensions called “ISO+”.  The purpose is to facilitate unambiguous electronic communication of quantities together with their units.

UCUM provides a single coding system for units that is complete, free of all ambiguities, and that assigns to each defined unit a concise semantics (ref.: http://aurora.regenstrief.org/~ucum/ucum.html).  It consists of a basic set of symbols for units, called atomic unit symbols or unit atoms, and multiplier prefixes. It also consists of an expression syntax by which these symbols can be combined to yield valid unit expressions (with no spaces between atomic units, prefixes, and annotations). 

Implementers may map the units’ value-set to their local units or adopt the UCUM code system for expressing units.  Moreover, consistent with the two levels of conformance documented within UCUM, senders and receivers may simply treat units as a display string although proper mathematical interpretation of mathematically equivalent unit strings is encouraged, particularly for those systems offering special analytical capabilities pertaining to laboratory results (e.g. trending, alerting, etc.).

To assist implementers, the pCLOCD contains example units of measure, formatted using appropriate UCUM format rules. To further assist implementers, the pCLOCD also contains recommended units of measure for those codes in which a recommended unit has been received.

When implementing the UCUM standard, the following considerations or exceptions should be noted:

• UCUM formatting is intended for use with a message specification and is not a requirement for viewer or print displays
• Pan-Canadian specifications have restricted the number 10 for arbitrary powers to 10* (10^ is not permitted)
• Pan-Canadian specifications have restricted the code for litre to L (l is not permitted)
• Timed specimens must separate the amount of time from the time frame in the unit with a period (ie: mmol/8h becomes mmol/(8.h))

3.3 Result Value Type

The pCLOCD “Result Value Type” attributes designate the recommended or, as outlined below, the required reporting data format to be selected.  The following table summarizes the possible Result Value Type values:

Table 1 pan-Canadian LOINC Observation Code Database Attribute

The purpose of coding the result value is to provide the practitioner with consistent terminology that can become part of the patient’s electronic health record for “significant” result observations.  It will also provide a valuable base of data for management reporting.  ”Significant” observations are those that define or lead to a diagnosis.  Microbiology and Anatomic Pathology reporting will include most of the coded result values.  The Result Value Type has been identified as “Coded or Text” for most of these types of records. This allows either to be reported for ease of implementation and flexibility to handle new terms not yet available in SNOMED CT.

There are result observations in classes other than Microbiology and Anatomic Pathology where interpretations are reported.  These “interpretation” types of records are characterized by a LOINC Property of “IMP” and will allow for coded and text result values.  The expected result value is differentiated only by the LOINC Scale.  The observation records in the pCLOCD that should be used for text result values will have the LOINC scale as NAR (Narrative).  The records that should be used for coded text result values will have the LOINC scale as NOM (Nominal).  Examples include:

3.4 Pan-Canadian Name

The natural language test name is the name that is most often referred to for ordering and reporting a laboratory test/observation.  The structure of LOINC sufficiently demonstrates the difficulty to fully identify tests using test names that are both unambiguous and yet easy to read. Many LOINC attributes are abbreviated for database use and not easily understandable; therefore, translations for the LOINC attributes have been included in the pCLOCD and used to automatically generate the pan-Canadian Name.

The Name can accomplish two things: (1) provide a name that can be used in the pan-Canadian messaging standard and (2) provide naming that supports searching using common Canadian naming conventions.

Guidance for a longer name using the LOINC attributes, should a jurisdiction choose to implement into their architecture, is provided. Given the core requirements for display and searching, as well as to provide the needed degree of jurisdictional flexibility, the format for the longer name using LOINC attributes is as follows:

Pan-Canadian Component Name; LOINC System; LOINC Timing; LOINC Method

The LOINC System, Timing and Method are all optional but, if included, must be in the order provided above.

4.   French Translation

The core attributes of the LOINC/pCLOCD record have been translated to Canadian French and are published in the pCLOCD. These core attributes are:

1. Component
2. Property
3. System
4. Timing
5. Scale
6. Method

Along with the core attributes, pCLOCD also provides a French Canadianized Component Name, which, when included, provides the basis for the French Canadian Name.

Maintenance processes will consider both the French and the English attributes as part of the maintenance process.

5.   Maintenance

Maintenance of standards is required to ensure they meet clinical, technical, business, and operating requirements. The maintenance processes are structured to manage errors, change requests (both urgent and non-urgent), and LOINC version updates. Some changes may require more than maintenance, and thus justify standards development efforts. These types of changes will be brought to the applicable pCLOCD Community (Health Terminologies Community on InfoCentral and Lab Jurisdiction contacts) for discussion and recommendation for approval as the first step in the process of approving development efforts.  For the purposes of this maintenance document, changes that require more than maintenance procedures will not be covered here.

From time to time a change will result in the deprecation of an existing code within the pCLOCD.  Any change that results in a code being deprecated will be indicated as such but implementers must plan for viewing and receiving of deprecated codes in historical queries.

5.1 Maintenance Considerations

The maintenance processes are based on the following concepts and considerations:

1. The process for establishing “urgent” codes must meet timely turnaround and solid practices.  Establishment of codes too quickly risks that the codes duplicate an existing code or, worse, are poorly defined (i.e. become an incorrect code). 
2. Vendors that bring new laboratory instruments or laboratory information systems to market should be encouraged to deliver them together with the associated LOINC mappings.
3. Changes will be made available in both official languages.
4. Each publication will have release notes to summarize the type of changes made.
5. Each version of the pCLOCD will include records that have changed and those that remain the same.  The records that have changed will be identified within the pCLOCD to assist implementers.

6.   Requesting a Change

Requests for change (RFC) can be made using Infoway's Request Management System (InfoRMS) tool.  To use this tool, a Infoway account with access to InfoRMS is required. Once your access is confirmed, you can login at the following URL: https://informs.infoway-inforoute.ca/projects/PCL

The tool provides the ability to log an RFC by single entry or by using a template for batch requests. For batch requests, download most current version of pCLOCD RFC template on InfoRMS. The template is an Excel file that contains multiple tabs. The “How to Read” tab outlines the color code used for column headings and also clearly describes the various columns and tabs. Users should be familiar with the “How to Read” tab before utilizing any other tab. Once completed it can be uploaded, this will automatically generate tickets for each RFC.

When a RFC batch or single ticket is received, it will be evaluated as to its completeness, accuracy, and priority level. Users will be notified of incomplete or inaccurate requests using the workflow status in the tool. An acknowledgement of the RFC is provided each time a request is submitted.

6.1 Requesting a New Code

RFC’s are most commonly a request for a new record.  When implementers have a local test request or test result observation that cannot be located within the pCLOCD, they can apply to have a new record added to the standard to meet their needs.

Occasionally the new code that is required may already exist in the LOINC database but will be missing in the pCLOCD. Implementers should look:

• first within the current LOINC database (using the RELMA mapping tool or the online search from Regenstrief web site for searching) for an applicable record to determine if it is already present in LOINC. Note: A LOINC user account is required.
• second, review the LOINC Submissions Queue (in real time), to ensure that a similar or equivalent term has not already been requested
• third, ensure that a similar or equivalent term has not already been accepted and is under development for the next official release by way of searching the LOINC Pre-release terms.

If it is present in LOINC and not in the pCLOCD, then submit a request to have it added to the pCLOCD using the InfoRMS tool. If there is not currently a LOINC code available, then more information must be provided to facilitate the addition of the applicable record. 

The type of information required includes:

• detailed description of the request (test name, units, scale, property, specimen etc)
• units of measure for all quantitative tests
• product inserts from appropriate vendors of instruments or kits used in the test
• example answers or answer lists for those tests that are not reported a quantitative
• laboratory procedure specific to the test if available
• example reports if available
• jurisdictional unique identifier

The jurisdictional unique identifier must be provided in the following format:

XAAnnnnn-n” where,

• “XAA” represents the source jurisdiction from the following list: BC, AB, SK, MB, ON, QC, NB, NS, PE, NL, NU, YT, NT;
• “nnnnn” is a five digit sequential number that will increment by one for each new observation code; and
• “-n” represents the check digit created from the five digits using the Mod 10 algorithm provided in Appendix A.

The unique jurisdictional identifier can be used until a LOINC or XCA code is returned.   Jurisdictions that intend to use their temporary jurisdictional code must plan appropriate processes for ensuring that all receivers of the data (within and outside of the jurisdiction) can interpret the data.  

All requests for change will be logged and tracked.  An analysis will be undertaken that may result in further communication with the requestor.  If the request is determined to be a valid request for a new record, it will be assigned a pan-Canadian code using the following format:

• “XCAnnnnn-n” where,
  • “XCA” is the permanent first three characters;
  • “nnnnn” is a five digit sequential number that will increment by one for each new observation code; and
  • “-n” represents the check digit created from the five digits using the Mod 10 algorithm provided in Appendix A.

The pan-Canadian code will be the unique identifier that is used to submit the code to Regenstrief. The new XCA/ LOINC code will be sent back to the original requestor as soon as possible. The unique temporary jurisdictional identifier can be used until the Infoway Standards Team provides the LOINC or final XCA code.  Jurisdictions that plan on using their temporary jurisdictional code must plan appropriate processes for ensuring that all receivers of the data (within and outside of the jurisdiction) can interpret the data.

6.2 Requesting a Change or Correction

Requests to correct or change an existing code can be made using InfoRMS.

6.3 Preferred SI Units

Occasionally a new code is required by an implementer that may already exist in the LOINC database but will be missing in the pCLOCD. Typically, but not exclusively, such a situation arises for a test which outside of Canada may be reported in either mass or substance units, but for which substance units are the preferred units in Canada. If such a record is present in LOINC and not in the pCLOCD, implementers may submit a request to have it added to the pCLOCD. Each request must contain a clinical justification or explanation why the record is required and an example unit. All requests of this type will be reviewed by the Infoway Standards Team prior to being added to pCLOCD. These records, when added, will show the example unit in the Example Unit field, and have the notation NR (Not Recommended) in the Recommended Canadian Unit field.

7.   Co-ordination with Regenstrief

Regenstrief maintains the LOINC code database. They publish an update twice a year, in approximately June and December. Requests for new records that have been approved by the Infoway Standards Team will be submitted to Regenstrief for approval and incorporation into the bi-annual update. All requests to Regenstrief for new records should be facilitated through the Infoway Standards Team to ensure there is no duplication of requests from all stakeholders.

Updates from Regenstrief will be reviewed and incorporated into the pCLOCD. New versions of the pCLOCD will be published twice a year, once in approximately March and September (typically one month after the Regenstrief file is published).

Requests for new LOINC codes will be submitted to Regenstrief as they are received and approved by the Infoway Standards Team. The Infoway Standards Team will return a LOINC code to the requesting jurisdiction as soon as it is received from Regenstrief. Jurisdictional maintenance processes should be evaluated to determine how many change points are required from the conception of their new temporary jurisdictional code to the final LOINC code. Implementers may choose to keep their jurisdictional code in place until the LOINC code is received, minimizing the number of change points. Jurisdictions that plan on using their temporary jurisdictional code or the LOINC code must plan appropriate processes for ensuring that all receivers of the data (within and outside of the jurisdiction) can interpret the data. 

Other Jurisdictions can also begin using the new LOINC code as published in the Completed RFC in InfoRMS.

8.   Understanding Changes to the pCLOCD

When implementing the changes that occur in a new release of the pCLOCD, several factors should be taken into consideration. Changes made to each record are based on the change process that was developed by Regenstrief. The Infoway Standards Team utilizes the same change nomenclature and change principles.

8.1 Categories of Changes

There are several kinds of changes that are included in each new release of the pCLOCD. The changes are grouped into four categories. Each type should be reviewed independently. The four categories are:

1. Changed Codes
2. New Codes
3. Deprecated Codes
4. Other Changes

8.2 Changed Codes

There are three types of changes that can be made to pCLOCD codes. Each change type is identified appropriately in the “Current Release Change Type” attribute of the pCLOCD. Each changed code should be reviewed separately, they include:

1. Change Major – this includes changes to Property, System (specimen), Scale, Method as well as changes and/or corrections to the Canadian Component Name. These changes may impact mapping decisions made previously and may change the intent and use of the code; they need to be reviewed carefully.
2. Change Minor – this includes subtle corrections to the Class, Time or Canadian Component Name. These changes will have less of an impact on previously mapped tests, but should be reviewed nonetheless. They will not typically impact the intent of the code.
3. Change Name – this includes changes to the LOINC component name which ultimately affects the Canadian Component name and the Canadian Name. These changes may impact mapping decisions made previously and may change the intent and use of the code; they need to be reviewed carefully.

8.3 New Codes

When the update is published, it will include some new codes. These new codes will be one of two types.

1. New LOINC Code – Regenstrief reviews submissions from around the world and incorporates the requests into new and distinct LOINC codes. The update includes new codes that have been requested by Canadian implementers. Two things identify new LOINC codes: a change type of “Add” in the “Current Release Change Type” attribute and a blank field in the “XCA Cross Reference” attribute of the pCLOCD. These new LOINC codes should be incorporated into each jurisdiction.
2. Converted or New XCA Code – Submissions from across Canada are reviewed and incorporated into new and distinct XCA codes. These codes are submitted ongoing to Regenstrief for approval and conversion to a LOINC code. The majority of XCA codes that are in the pCLOCD have been rejected by Regenstrief.  Due to the rigorous RFC process incorporated by Regenstrief, XCA codes that are in the submission process are not included in the published release of pCLOCD due to the high volume of change they undergo prior to being approved.

A change type of “Add” in the “Current Release Change Type” and a jurisdiction or XCA code in the “XCA Cross Reference” attribute of the pCLOCD identifies the Converted XCA Codes. Depending on implementation schedules, this code may or may not be previously present in your jurisdictional system and may only be previously present in the jurisdictional system in which it originated.

The codes that are rejected, but required for Canadian implementers will be published a new Canadian XCA Code and identified by the unique XCA number and a change type of “Add” in the “Current Release Change Type”. All new XCA or Converted XCA Codes should be incorporated into each jurisdiction.

8.4 Deprecated Codes

Codes that are no longer in use within Regenstrief will no longer be in use within the pCLOCD and will be marked as Deprecated. Codes that are deprecated are indicated with a change type of “Deprecated” in the “Current Release Change Type”. Any change that results in a code being deprecated will be indicated as such but implementers must plan for viewing and receiving of deprecated codes in historical queries. All codes deprecated by Regenstrief will also be marked with a LOINC Status of DEPRECATED.

Some LOINC codes that are deemed no longer used in Canada will be deprecated in the pCLOCD only. These records maintain their published LOINC status in the LOINC Status attribute and an Inactive status in the pCLOCD Status attribute. This combination identifies them as active LOINC records outside of Canada, but not recommended for use within Canada.

8.5 LOINC Status

Regenstrief publishes other status for LOINC codes that are not reflected in the pCLOCD Status attribute. In these cases, the pCLOCD Status remains “Active”. These LOINC statuses are:

• DISCOURAGED
• TRIAL

For more information on the LOINC status, see the LOINC users’s guide at the following URL: https://loinc.org/learn/

8.6 Other Changes

• V Name Changes
  The pCLOCD includes an example viewer name for each active code that is published. The viewer name is based on the pan-Canadian Component Name and follows the Guiding Principles and Rules. Current maintenance practises allow for corrections and changes that result from changes to the core LOINC components to be reflected in the example viewer name. When the only change to a code is in the viewer name, the change type is identified as V Name.
• No Change
  The pCLOCD tracks changes to both languages, and periodically, a change will be made to either the English or French only version and there has been no impact to the other language. In those cases, the appropriate language change type will be indicated as “No Change”.
  
  

9.   Implementing a New Release

Jurisdictions that have not previously used the pCLOCD may begin to use the new version immediately.

Jurisdictions that have already begun mapping to the pCLOCD will need to do a careful quality control review of a new release to determine how the changes will impact the work they have completed so far.

Some things to consider:

1. Review the records that have been deprecated to see if they are currently in use. Alternate codes will need to be chosen for those records deprecated from the pCLOCD.
2. Review records that have been modified to ensure the modification does not impact the use of that record in the jurisdiction.
   Things to consider with each Change Type:
   1. Change Major – this includes system (specimen) changes, methodology changes and property changes as well as changes and/or corrections to Canadian Component Name. These changes may impact mapping decisions made previously and may change the intent and use of the code; they need to be reviewed carefully.
   2. Change Minor – this includes subtle changes to the Canadian Component Name or changes to the LOINC class. These changes will have less of an impact on previously mapped tests.
   3. Name – this includes changes to the LOINC component name which ultimately affects the Canadian Component name and the Canadian Name. These changes may impact mapping decisions made previously and may change the intent and use of the code; they need to be reviewed carefully.
3. Review records that have had the XCA code changed to a LOINC code number and ensure the LOINC code is implemented within the jurisdiction. It may be important to keep track of the previous XCA code in the audit trail of that record and its associated mapping and cross reference it back to a jurisdictional number if appropriate.
4. Review new XCA records if present to ensure there are no duplicates with temporary jurisdictional codes. If a new XCA code is a duplicate of a temporary jurisdictional code that has been created but not yet submitted to Infoway, the XCA code should take precedence.
5. Review new LOINC records added to the pCLOCD to see if they solve any current mapping problems or if they match temporary jurisdictional codes that have been previously created but not yet submitted to Infoway. The LOINC code should take precedence.
6. Review new LOINC records that have not been added to the pCLOCD to see if they solve any current mapping problems or if they match temporary jurisdictional codes not yet submitted to the Infoway Standards Team. Each release, the newly published LOINC Codes are found on InfoCentral.

10.        Maintenance Schedules

The Infoway Standards Team publishes an update to the standard twice a year, once in March and September (typically one month following the Regenstrief publication). Timely submission of new codes to the Infoway Standards Team from any jurisdiction will be included in these updates. Regenstrief publishes an update to the LOINC standard twice a year, in February and August. The changes from these publications will be analyzed and reflected in the published Canadian update in both official languages. Release cycles for pCLOCD can be found here.

The ongoing process of creating new codes from jurisdictional requests will not be published outside of the scheduled dates as outlined above, except within the InfoRMS RFC. Whether jurisdictions plan on using their temporary jurisdictional code or the new LOINC code, they must understand that other jurisdictions may not have those new codes in their database until the next release of the standard and so must plan appropriate processes for ensuring that all receivers of the data (within and outside of the jurisdiction) can interpret the data.

11.        Additional Artifacts and Support

Readers should recognize that new codes will be added from time to time to accommodate the requirements of Canada's health jurisdictions.  As such the aggregate list can never be seen as "complete" but rather as a framework through which data interchange can be enabled by recognizing and documenting applicable order and/or result observation codes.

Questions and comments regarding the current version of the pCLOCD can be made via the Forum in the Health Terminologies Community on InfoCentral. The forum can be accessed via the following URL:

https://infocentral.infoway-inforoute.ca/en/collaboration/communities/health-terminologies

Contact Us for inquiries.

The algorithm for calculating a Mod 10 check digit for a LOINC code is as follows:

Table 2 Mod-10 Algorithm