Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Based on the problems above, the following recommendations have been made by an initial analysis group .(Rong Chen, Heath Frankel, Sebastian Garde, Thomas Beale):

  • Adopt the 'java files' as the basis for going forward.
  • Adopt the design approach that openEHR will actually need to create its own 'code-set' files for external code-sets in a standard format based on internet available lists and pages from IANA, ISO etc.
    • Define an XML 'adjunct format' for this type of file
    • Remove the IANA codes from the existing 'external_terminologies' file, and create a separate file which is derived from the iana.org link above.
    • Remove the ISO 639 codes from existing 'external_terminologies' file and create a new adjunct format file derived from the above Library of Congress ISO 639-1 page.
    • Remove the ISO 3166 codes existing 'external_terminologies' file and obtain and convert the ISO 3166 file to a separate file in the adjunct format
  • Units: TBD

...

A long term solution most likely involves discussion with IHTSDO in order to determine their coverage of the code sets.

Secondly, we should consider SNOMED CT style representation, which is to say, 3 separate tables as described in the IHTSDO TIG section on RF2 . This approach would enable each separate vocabulary in openEHR to be managed as a small hierarchy of its own. In order to use actual SNOMED CT codes, we would need to obtain an openEHR Snomed Extension .