Stream: terminology
Topic: Where to store hospital proprietary coded values?
Zach Smith (Mar 03 2020 at 17:19):
We're working with a hospital that has proprietary CodeSystems/ValueSets for various pieces of coded patient data, such as marital status, gender, etc. When displaying the coded data in a UI, we'd like to display their proprietary codes, as that's what the clinicians are used to, but internally we'd like to store using the FHIR-standard code systems.
To accomplish this, we're developing ConceptMaps between their proprietary code systems and FHIR code systems, and will call $translate to convert them before submitting the values to a FHIR server. However, we'd like to preserve the original coded value somehow, to continue displaying in the UI, as well as interoperability with their existing infrastructure.
Our plan is to use an extension on code and Coding fields to store the original code, and for CodeableConcept, we can obviously just store both as separate coding elements.
My questions are (1) does this seem like a sane approach and (2) if so, is there already an extension intended for use in a scenario like this, or should we develop our own?
Rob Hausam (Mar 03 2020 at 18:14):
I think this does seem likely to be a reasonable approach to take. And it's interesting that (to my knowledge) this hasn't had previous requests or significant discussion, as you might think that the desire or need for it would be reasonably common. As you mention, CodeableConcept already has the capability for this, so nothing additional should be needed there. Presumably the expectation has been that for elements of both code and Coding (which is relatively rare) data types there won't be a need for this, but obviously as per your request that isn't entirely the case. I don't see that we do currently have a standard extension for this, but probably we should. Something similar to the Original Text extension, but for the coded data (probably "Original Code"), would make sense. You could and may need to create your own extension, but a request can also be made for a standard one to be added to the spec.
Adam Flinton (Mar 04 2020 at 08:07):
This would work so long as it's a 1<>1 map. We have to preserve records with the codes they were written in originally (e.g. old read (4-byte, v2 etc) ) partly because of the potential for discrepancies i.e. where 1<>1 becomes 1<> 2 as the "new" codesystem becomes more precise then which do you map to & then even worse 2<>1 where reverse mapping becomes impossible
Last updated: Apr 12 2022 at 19:14 UTC
