Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-27780

Add a regular expression for codes to CodeSystem

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Low Low
    • FHIR Core (FHIR)
    • R4
    • Terminology Infrastructure
    • CodeSystem
    • Hide

      Ticket was discuss on 2022-04-18 and it was felt that this functionality goes beyond the 80% rule for core FHIR. Further, it was also raised that a regular expression is unlike to address the need. Thus it Is felt that this sort of functionality is better addressed through terminology servers which under stand the particular code system and can implement the checks in the server's code.

      Show
      Ticket was discuss on 2022-04-18 and it was felt that this functionality goes beyond the 80% rule for core FHIR. Further, it was also raised that a regular expression is unlike to address the need. Thus it Is felt that this sort of functionality is better addressed through terminology servers which under stand the particular code system and can implement the checks in the server's code.
    • Reuben Daniels/Michael Lawley: 3-0-0

    Description

      For many 'large' code systems, it will be common to have CodeSystem instances that have 'content' values other than 'complete'.  At the moment, that means that when validating, any code value that's not found in the list of CodeSystem concepts has to be treated as a warning - as there's no way of evaluating whether the code is valid or not.

      However, the reality is that most code systems have 'rules' that govern what valid 'code' values are allowed to be.  For example, for the current release of both SNOMED CT and LOINC, you'll never see a LOINC code that looks like 1234567890, nor will you ever see a SNOMED CT code that looks like 1234-5.  If we allowed a code system to have a regular expression, if content weren't 'complete, you still wouldn't be able to definitively say that a code was valid, but you'd be able to very easily assert that many codes weren't valid - because the didn't meet the regular expression.  I think this would be a valuable thing and would catch a lot of 'simple' errors.

      (If we wanted to be fancier, we could also add an extension that allowed identification of how to extract a checksum value and perform a checksum validation test on the code, but I suspect it would be hard to define that in a 'standard' way.  Perhaps an embedded CQL expression?)

      Attachments

        Activity

          People

            rhausam Robert Hausam
            lloyd Lloyd McKenzie
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: