A locally maintained dictionary, look up table or enumeration in an application (for further discussion of locally defined value sets, see “Profiling FHIR”
I am working with a client to build FHIR Resources from HL7 messages. We are using CodeableConcepts, and using coding.code as per above guidance. However, we are running into issues where local codes do not adhere to the code datatype restrictions. Specifically, local codes may have trailing spaces, or multiple spaces between tokens. What are the options for representing these codes in FHIR if we can’t use the coding.code elements due to datatype restrictions?
Please let me know if further clarification is needed. Thanks!
Are the trailing or multiple spaces significant? I.e. would a code with trailing spaces mean something different than the same string without the trailing spaces? If not, then you could normalize/trim the code for exchange purposes and build a hash to map when receiving.
If they are semantically significant, then I guess you’d need to perform some sort of transformation to a FHIR-valid syntax (that would not collide with your internal code mechanism) and also transform back.
(In that second case, you might also consider having a discussion with whomever decided that making whitespace in a code semantically meaningful was a good idea :>)
Unfortunately they are semantically significant - they serve as keys to local data, which may be inactive codes but are still desired in the target FHIR system. Open to suggestions on transformations, unfortunately the source systems are very liberal in their allowed codes, and client also desires traceability so that a given resource in FHIR can be traced back to source system entries, as well as other systems downstream from source.
Also wondering if we should move away from using CodeableConcept.coding.code altogether and use a CodeableConcept.extension to represent “illegal” values. My concern is that we probably want to be consistent in how we represent source system values and we’ve already established CodeableConcept.coding.code for a pilot, then ran into this problem when we onboarded an additional source.
Extensions wouldn’t work for value set checking or anything else.
One simple approach would be to use http escaping - e.g. all whitespace would become ‘%20’. That’s a pretty straightforward transform. It’s verbose, but that’s not the end of the world.
Thanks Lloyd, that seems like it would work, although we’d have to escape all URL codes (or at least %) to avoid collisions, it does seem like a straightforward easily reversible transformation.