SNOMED on FHIR

Space shortcuts

Page tree

Versions Compared

Old Version 1

changes.mady.by.user Peter G. Williams

Saved on

compared with

New Version Current

changes.mady.by.user Peter G. Williams

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Restrict bodySite to [0..0] and require finding site in code
  2. BodySite can only be populated if code has no finding site
  3. BodySite (if exists) must be a specialization of finding site
  4. BodySite must always be a specialization or self of finding site (or absent, since redundant)
  5. Only allow conditions with no finding sites and include bodySite
  6. Any condition and any bodySite

The SNOMED on FHIR group have a discussion page for these 6 options here:  Binding patterns

We should list the implications of each of these choices.  Also the use each solution in terms of the other.  For example, option 1 is the simple case of version 4.   

If we were to say that all of the semantic meaning exists in the code, then that increases the burden on the maintenance of SNOMED.

Any solution that allows for population of multiple fields must deal with potential conflict - or worse, where a value has been deliberately populate to indicate some other meaning eg second body site affected, and this is mistaken for a conflict.