FHIR Terminology Service

[codyebberson]

FHIR Terminology Service

This is a discussion about how to publish a FHIR Terminology Service with standard terminologies such as:

• CPT
• ICD
• LOINC
• RxNorm
• SNOMED
• ... and more?

The FHIR documentation includes a guide for the core features of a Terminology Service: https://hl7.org/fhir/terminology-service.html

• Using codes in FHIR
• The CodeSystem resource
• The ValueSet resource
• The ConceptMap resource

The good news is that Medplum already supports most of the required resource types and FHIR operations 🎉

Open Questions

• How do we expose this to consumers?
• What are permissions?
• Are users allowed to modify or extend predefined terminologies?
• Do we need to manage multiple versions of predefined terminologies? (i.e., support 2020 and 2022 releases simultaneously?)
• Do we want unauthenticated access to public terminologies?
• Should we wait for client assigned ID's first? (Client assigned IDs #1175)

Options

In simple terms, here are the general options:

1. Read-only public terminologies
   a. Add new internal mechanism to mark certain FHIR resources as "public"
   b. Add project-level option to include those public resources in a project
   c. If included, then the resources become available in all read and search operations
   d. Public resources would be read-only to all non-super-admin users
   e. Upgrades would be performed by super admins
   f. Only one version of the terminology would be available at a time
   g. If we wanted unauthenticated access, this is the only option

2. Ability to "include" or "link" Medplum projects
   a. Similar to option 1, except rather than a "public" flag, the terminologies would exist in normal Medplum projects
   b. Then add a mechanism to "link" projects, so that "Project A" includes all resources from "Project B"
   c. There is a engineering / mathematical / set theory elegance to this approach
   d. There is a lot of unknown complexity here...

   1. Are linked projects read/write?
   2. How does that work with access policies?
   3. Caching implementation details get really weird

3. Terminologies are always recreated entirely within projects
   a. At the opposite extreme, we just add tools for projects to import terminology
   b. This is the "cleanest" approach from the perspective of providing complete control to project admins
   c. No new code required
   d. It would be extremely inefficient to recreate full terminologies with millions+ of resources for each project
   e. If even 10 projects imported terminologies, that would dwarf our current database usage
   f. It would push the burden of upgrades and maintenance onto project admins -- although that could be made easier with built-in tooling

My current leaning is to start with option 1 (read-only public terminologies), with an eye to how it could evolve into option 2 (linked projects).

Option 3 would be the most expedient, but I think we would regret it almost immediately.

I would also like to call attention to the question of "Should we wait for client assigned ID's first?" (#1175).

• Pros
  • It would enable "pretty URLs" for known valuesets
  • For example, the LOINC CodeSystem could be "https://api.medplum.com/fhir/R4/CodeSystem/loinc"
  • RxNorm Medications could us RX CUI's for ID's, which would (1) be easier and (2) better system performance because it enables a simple "lookup by ID" rather than a search
• Cons
  • We would need to do client assigned IDs first (but maybe that's inevitable?)

See more

• R4 Terminology Service guide: https://hl7.org/fhir/terminology-service.html
• UMLS Terminology Services: https://uts.nlm.nih.gov/uts/
• LOINC Terminology Service: https://loinc.org/fhir/

[reshmakh]

Option 1 is my preference. Reason being, is that they are required to have a compliant EHR per the ONC G10 guidelines. (Particularly RxNorm and SNOMED)

[rahul1]

I like the "Option 1 evolve into Option 2 strategy". Option 2 opens up some potentially nice features for SDLC (like cloning resources from a prod project back to staging to create realistic test data), but agree that there are a lot of unknowns that shouldn't block terminology service.

As for maintenance, as long as each version is immutable, it gives our users control on when they update terminology resources, and we can add some UI sugar on top of that later on.

[rahul1]

Re: "Should we wait for client-assigned ids": my vote is to wait. We keep thinking this will be coming up soon, but we haven't really seen a great concrete use case from our users yet. We have a bunch of assumptions about globally unique ids, so my take is not to block the terminology service on squashing all of those, if the main benefit we're getting is clean URLs.

[rahul1]

One implementation question I had is - where will these public read-only resources live? It feels like having a "privileged project" for them would be cleaner for administration rather than having them just floating around (we could add/remove users, create client apps for maintaining them, etc.).

[arscan]

Are licensing terms for the various terminologies a consideration in your implementation here? IANAL and do not know the answer to this, but was curious if you considered that dimension as I don't see it mentioned above.

[codyebberson]

Hi @arscan - that's an excellent question.

I spent the last few hours reading through license agreements. Full notes below. In short, RxNorm, CPT, and LOINC all seem very straightforward. SNOMED CT seems ok. ICD seems very unclear.

• UMLS in general
  • https://uts.nlm.nih.gov/uts/assets/LicenseAgreement.pdf
  • "2. No charges, usage fees or royalties will be paid to NLM."
  • "3. LICENSEE is prohibited from distributing the UMLS Metathesaurus [...] except (a) as an integral part of computer applications developed by LICENSEE for a purpose other than redistribution of vocabulary sources contained in the UMLS Metathesaurus and (b) if permitted by paragraph 12 of this agreement."
  • Overall, these seem like very sensible restrictions, which we fully intend to follow.
  • We may want to take some additional precautionary steps, such as blocking "Bulk Export" from terminologies.
  • At the extreme end, we could ask users to confirm that they have an active UMLS license? This might be worth a research exercise. For example, could we ask for their UMLS username? Is there some kind of account verification service?
• SNOMED CT
  • https://www.nlm.nih.gov/healthit/snomedct/snomed_licensing.html
  • https://www.snomed.org/SNOMED/media/SNOMED/documents/IHTSDO-Affiliate-License-Agreement_UK_20200101-v1-0.pdf
  • https://www.snomed.org/SNOMED/media/SNOMED/documents/SNOMED-International-2021-Annual-Report.pdf
  • My interpretation of this is that we, as a vendor, are allowed to use and distribute freely to customers in IHTSDO Member countries.
  • Therefore, SNOMED cannot be available globally, and must be opt-in.
  • When a project administrator opts in, we must prompt them to confirm that they agree that they are in an IHTSDO member country, or that they have purchased a SNOMED license separately.
  • We also cannot modify the SNOMED dataset in any way (which we have no intention of doing).
• RxNorm
  • https://www.nlm.nih.gov/research/umls/rxnorm/docs/termsofservice.html
  • Very sensible restrictions.
• CPT
  • From the UMLS License Agreement: "The following special notice must be displayed:"
  • Very sensible restrictions.
• LOINC
  • From the UMLS License Agreement: "The following special notice must be displayed:"
  • Very sensible restrictions.
• ICD
  • ICD-10 codes were developed by the World Health Organization (WHO)external icon.
  • ICD-10-CM codes were developed and are maintained by CDC’s National Center for Health Statistics under authorization by the WHO.
  • ICD-10-PCS codes were developed and are maintained by Centers for Medicare and Medicaid Services.external icon
  • ICD-10-PCS vs. ICD-10-CM: https://www.techtarget.com/searchhealthit/definition/ICD-10-PCS
    • The U.S. also uses ICD-10-CM (Clinical Modification) for diagnostic coding. The main differences between ICD-10 PCS and ICD-10-CM include the following:
    • ICD-10-PCS is used only for inpatient, hospital settings in the U.S., while ICD-10-CM is used in clinical and outpatient settings in the U.S.
    • ICD-10-PCS has about 87,000 available codes while ICD-10-CM has about 68,000.
    • An ICD-10-PCS code can be made up of any combination of numbers and letters while with ICD-10-CM, the first digit has to be either a number or letter and all other digits are numbers.
  • 10 ICD-10 regulation myths demystified
  • Ambiguous, and the links are broken.
  • This one requires more investigation.

[codyebberson]

Zooming out, here's my proposal:

• For Medplum-hosted
  • UMLS terminologies enabled per project
  • UMLS terminologies not available by default
  • UMLS terminologies only available to customers with a contract
  • We can apply some filters here, such as only offering to customers in IHTSDO Member countries
  • In the contract, we include language that is compatible with the UMLS license agreement, where the customer attests that they have a valid UMLS account and that their usage is compatible with UMLS license
  • We consult our legal counsel to write this language
  • We make sure to include all of the necessary requirements such as special notices, logos, etc
  • We never modify any of the underlying datasets, just display them
• For self-hosted
  • We do not include UMLS directly
  • We include a tool that ingests UMLS files and sets up the terminologies in the self-hosted server
  • By virtue of ingesting the UMLS data files, they prove that they have access

[codyebberson]

IHTSDO Member countries from 2021 annual report

[codyebberson]

Update: We engaged legal counsel on this. Stay tuned!

[LJNIC]

Is there an update on this?