This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Persisting concept codes"

From HL7Wiki
Jump to navigation Jump to search
(New page: Category:RIMBAA Issue ==Summary== *If a HL7 v3 application (especially a RIMBAA application) receives a concept code, with original text, and multiple translations, what should it pers...)
 
Line 10: Line 10:
 
**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.
 
**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)
 
*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 Sept: see Vocab page: [[HL7 proposed guidance on use of displayName(V3 CD) and Text (V2.x CNE,CWE)]]

Revision as of 17:44, 4 October 2010

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)