FHIR Chat · How to handle unknown Code Systems · implementers

Stream: implementers

Topic: How to handle unknown Code Systems


view this post on Zulip Pash (Mar 11 2021 at 21:15):

I am pretty sure that it is not a new question, but anyway:
What is the best approach to handle Code Systems if I can receive any data?
EX: third-party system sends to me Allergy resource with something like: "Code": "7982", "Codeset": "RxNorm", "Name": "Penicillin". And I need to convert it to FHIR AllergyIntolerance with AllergyIntolerance.code (CodeableConcept).
Codesets from that third-party are not "official" and no restrictions to them, so anything can be there. The same for code.
So how to convert that data to FHIR?
Options I see so far:

  1. Use only "text" in CodeableConcept? But the type itself will be lost since we can store only one value there. And search by that field will not work.
  2. "System" field = original "Codeset" as is. Not sure.
  3. Use for "System" some custom URLs like "https://myapp.com/CodeSystem/{codeSystemFamily or just "Unknown"}/{codeset received from third-party as is}". Looks as less evil for me but still evil since we are creating CodeSystems on a fly.
    Please advise.

UPD
Or even:

  1. "https://myapp.com/CodeSystem/{codeSystemFamily or just "Unknown"}/{third-party system id}/{codeset received from third-party as is}". In this case it will be linked to a specific third-party source.

view this post on Zulip Lloyd McKenzie (Mar 11 2021 at 21:31):

I'd probably use a normalization algorithm to try to recognize as many variants of RxNorm as possible (RX NORM, Rx-Norm, Rxnrm), etc. based on your historical data for any common/well-known systems that have actual URLs and then map to those URLs. For anything else, send the code with no system and send the "code system name" as an extension. (In fact, submit a change request and we can define a 'standard' extension for this, because it's certainly an issue lots of people will have).

view this post on Zulip Pash (Mar 11 2021 at 21:47):

@Lloyd McKenzie yes, I've already implemented some simple normalization, so "RxNorm" is a bad example here, "hurrdurr" is a better example. Solution with extension is great but it will make it impossible to search by it (I am implementing only proxy app and using FHIR server I can't extend)

view this post on Zulip Lloyd McKenzie (Mar 11 2021 at 21:50):

You can search by identifier without specifying system - but you risk false matches. That's the price of not having a computable system.

view this post on Zulip Lloyd McKenzie (Mar 11 2021 at 21:52):

Generating on the fly doesn't help because the person searching won't know what URL to use to search when they're looking for the "hurrdurr" id. (Also, in some case there are 'standard' URIs defined in the core spec and if you use something other than the approved URI, you're non-conformant.

view this post on Zulip Pash (Mar 11 2021 at 21:57):

@Lloyd McKenzie at least it will be possible to search by "https://myapp.com/CodeSystem/Unknown/hurrdurr". So do you think that it is so a bad workaround?

view this post on Zulip Lloyd McKenzie (Mar 11 2021 at 22:05):

I wouldn't use "CodeSystem" in the URL because it looks like a FHIR URL but isn't. Also, you'd have to worry about whether all of your string values would fit nicely in a URL. However the biggest question is: who's going to know to search on it?

view this post on Zulip Pash (Mar 11 2021 at 22:15):

So will just "hurrdurr" be better for "System" or "https://myapp.com/UnknownCodeSystem/hurrdurr"?
Good point, string values will be escaped, so it should be OK.
Regarding "who's going to know" , yes, it is a problem, but at least we can provide a search mechanism, handle some situation when normalization failed and data already saved, and use guidance "try to search by "https://myapp.com/CodeSystem/Unknown/"code you may expect"" and not just "it's impossible to search by not supported codes (normalized)". So want to find "less evil" here.

view this post on Zulip Lloyd McKenzie (Mar 11 2021 at 22:30):

It really comes down to your clients. If they're going to be customized to work in your space and will have a clue what "hurrdurr" is, then your approach has merit. If not, then you're not achieving interoperability and may be adding complexity to it because you're making it appear that the identifier is a different system than it really is. A system that's looking for a match on BC provincial health number that gets a match on an identifier for an identifier with no system can treat that as a "possible match". On the other hand, if it sees an identifier with a system of "http://myapp.com/CodeSystem/Unknown-bchn", it'll say definitively that that's not a match.

view this post on Zulip Lin Zhang (Mar 12 2021 at 14:15):

Good Qs&As. Looking foward to a standard practice.


Last updated: Apr 12 2022 at 19:14 UTC