This wiki has undergone a migration to Confluence found Here
Persisting concept codes
Revision as of 20:02, 7 October 2015 by Rene spronk (talk | contribs)
Summary
- If a HL7 v3 application (especially a RIMBAA application) receives a concept code, with original text, and multiple translations, what should it persist? This page seeks to capture guidance as to what the best practices/requirements should be.
Discussion
- Rene: Do we provide any statement or guidance which code to store if one receives one 'original code' with N translations? It seems like a good idea to store the original code as well as the translation one decides to use, but do we require/advise implementers to do so?
- Grahame: my advice is always to store all of them, unless you are *real* sure that you won't need one in the future. But we wouldn't normally make any rules about what they have to do, only that they have to comply with expected externally observable behaviour. Which is why I advise to always store everything ;-)
- Cecil: Well, in our V3 database model, we store them all. This is because there is no guarantee we can recreate those translations from the terminology service, given that they may or may not be 1) part of the codeSystems we use, 2) valid translations 3) identified appropriately.
- Andy Harris: Need to persist value set OIDs (may need to be aware which ones are implied -by context- when one receives a v3 instance)
- 2010-09-04 Vocab Q3: see Vocab page: HL7 proposed guidance on use of displayName(V3 CD) and Text (V2.x CNE,CWE). Provides guidance as to how displayName is to be used; discussion isn't focused on "what should be displayed in a UI" nor "persistence".
- regulatory requirement (at least in the US) to display that synonym (in @displayName, which contains one of the many ways to describe the semantic concept identified by the code) of the code which is present in the message. Some coding systems have multiple descriptions associated with a single code. This use case would (in a typical RIMBAA app) require that one persists displayName.
- extensions to code systems, unknown coding systems. These use cases would (in a typical RIMBAA app) require that one persists displayName.
