Section: 10

modules-fragment.html

Level 1 Basic framework on which the specification is built

Foundation

Base Documentation, XML, JSON, Data Types, Extensions

Level 2 Supporting implementation and binding to external specifications

Level 3 Linking to real world concepts in the healthcare system

Administration

Patient, Practitioner, CareTeam, Device, Organization, Location, Healthcare Service

Level 4 Record-keeping and Data Exchange for the healthcare process

Level 5 Providing the ability to reason about the healthcare process

Clinical Reasoning

Library, PlanDefinition & GuidanceResponse, Measure/MeasureReport, etc.


modules-list.html


modules.html

Getting Started with FHIR

Maturity Level: N/AStandards Status:Informative

FHIR is a platform specification that defines a set of capabilities use across the healthcare process, in all jurisdictions, and in lots of different context. While the basics of the FHIR specification are relatively straight-forward (see the Overviews: General, Developers, Clinical, and Architects), it can still be difficult to know where to start when implementing a solution based on FHIR.

This page provides some guidance to help get new implementers started on their path to successful implementation. Beyond reading the overviews (previous paragraph), where should an implementer start? Generally, an implementer needs to resolve:

The remaining sections provide guidance on specific areas (Foundation, Implementer Support, Security and Privacy, Conformance, Terminology, Linked Data, Administration, Clinical, Diagnostics, Medications, Workflow, Financial and Clinical Reasoning).

All implementers should be aware of how versioning works in the FHIR specification. See both:

Modules

In order to help implementers find their way around the specification and answer these questions, it is organized into a set of "modules". Each module represents a different functional area of the specification, and contains:

Broadly, the modules are organized into 3 groups:

Dependencies between the modules are mainly downwards, with some horizontal dependencies. Implementers should choose the content modules to engage with based on their requirements, and should only engage with the reasoning module if they need to do clinical decision support, and/or Quality Measures.

In addition to the use case based assistance in the modules, these additional documentation pages may be useful:

Finally, one important place to look is the registry of implementation guides, to see whether similar (or identical) requirements have been met.


narrative-definitions.html

Maturity Level: NormativeStandards Status:Normative

narrative-example.html

Example Narrative

Maturity Level: N/AStandards Status:Informative

Plain HTML, No Styles

Heading 3

Heading 4

Heading 5
Heading 6

Paragraph. span. Link. Bold, br:
em, Italics, strong, small, big Teletype Text, small, Definition term, q, var. All provided by HL7, for FHIR (cite).

Paragraph in a blockquote, with an hr after it:


Paragraph in a div (Link Target)

  1. Ordered List Item
DT Item
DD Item
        Some Pre Text
          with a line break
      

Table:

Table Caption
Head Cell 1 Head Cell 2 Head Cell 3
Foot Cell 1 Foot Cell 2 Foot Cell 3
Body Cell 1 Body Cell 2 Body Cell 3
Code Block Sample Block

External Styles

Text:

Example Text: bold, italics, underline and strikethrough

This paragraph is left aligned. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen.

This paragraph is right aligned. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen.

This paragraph is center aligned. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen.

This paragraph is justified. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen.

Table:

Border Left Border Right Border Top Border Bottom

List:

  1. arabic (Item 1)
  2. Item Two
  1. little-roman (Item 1)
  2. Item Two
  1. big-roman (Item 1)
  2. Item Two
  1. little-alpha (Item 1)
  2. Item Two
  1. big-alpha (Item 1)
  2. Item Two

Internal Styles

Example Text: bold, italics, underline and strikethrough. Font-Family Serif and Sans Serif, Font-size 50% 80% 150%, Font-Color Navy Maroon Brown, Background-color Aqua Silver Pink.

Whitespace Control:

Normal Whitespace Test, long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long sentence

No-Wrap Whitespace Test, long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long sentence

Pre Whitespace Test, long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long sentence

Pre-Line Whitespace Test, long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long sentence

Pre-Wrap Whitespace Test, long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long long sentence

This paragraph is left aligned. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen. The content should be laid out aligned at the left of the screen.

This paragraph is right aligned. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen. The content should be laid out aligned at the right of the screen.

This paragraph is center aligned. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen. The content should be laid out aligned at the center of the screen.

This paragraph is justified. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen. The content should be laid out aligned at both the left and right of the screen.

  1. armenian (Item 1)
  2. Item Two
  1. cjk-ideographic (Item 1)
  2. Item Two
  1. decimal (Item 1)
  2. Item Two
  1. decimal-leading-zero (Item 1)
  2. Item Two
  1. georgian (Item 1)
  2. Item Two
  1. hebrew (Item 1)
  2. Item Two
  1. hiragana (Item 1)
  2. Item Two
  1. hiragana-iroha (Item 1)
  2. Item Two
  1. inherit (Item 1)
  2. Item Two
  1. katakana (Item 1)
  2. Item Two
  1. katakana-iroha (Item 1)
  2. Item Two
  1. lower-alpha (Item 1)
  2. Item Two
  1. lower-greek (Item 1)
  2. Item Two
  1. lower-latin (Item 1)
  2. Item Two
  1. lower-roman (Item 1)
  2. Item Two
  1. none (Item 1)
  2. Item Two
  1. upper-alpha (Item 1)
  2. Item Two
  1. upper-latin (Item 1)
  2. Item Two
  1. upper-roman (Item 1)
  2. Item Two
  1. upper-roman (Item 1)
  2. Item Two

narrative.html

Narrative

Maturity Level: NormativeStandards Status:Normative

Any resource that is a DomainResource (all resources except Bundle, Parameters and Binary) may include a human-readable narrative that contains a summary of the resource and may be used to represent the content of the resource to a human.

If narrative is present with a status other than 'empty', it SHALL reflect all content needed for a human to understand the essential clinical and business information for the resource. It SHALL be safe to render only the narrative of the resource without displaying any of the resource's discrete/encoded information. Resource definitions and/or profiles on resources MAY define what content should be represented in the narrative to ensure clinical safety.

The narrative for a resource MAY contain additional information that is not in the structured data, including human-edited content. Such additional information SHALL be in the scope of the definition of the resource, though it is common for the narrative to include additional descriptive information extracted from other referenced resources when describing references. Narrative for a resource SHOULD include summary information about any referenced resources that would be required for a consumer of the resource to be able to understand the key, essential information about a resource without retrieving any additional resources. If the Narrative.status = extensions, the narrative SHALL reflect the impact of all modifier extensions that extend elements that are themselves described by the narrative. Narrative MAY include generated content from other resources and still be considered generated.

For example, the narrative for a MedicationRequest might include brief summary information about the referenced patient, prescriber and medication. Some resources (e.g. List) can provide specific rules about what content must (or must not) be included in the resource narrative. Consideration would be given to the fact that referenced resources may be updated without updating referencing resources, so the proportion of content of a referenced resource included in a referencing resource should be limited.

Systems MAY choose how narrative is generated, including how much de-referencing to perform, but SHALL NOT assume that the resource is rendered in any particular context when generating narrative, since resources will be used in multiple contexts.

Resource instances that permit narrative SHOULD always contain narrative to support human-consumption as a fallback. Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative. However, in strictly managed trading systems where all systems share a common data model and additional text is unnecessary or even a clinical safety risk, the narrative may be omitted. Implementers should give careful consideration before doing this, as it will mean that such resources can only be understood in the limited trading environment. Closed trading partner environments are very likely to open up during the lifetime of the resources they define. Also, many workflow steps involving finding and aggregating resources are much more difficult or tedious if the resources involved do not have their own text.

A resource MAY only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This can be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.

The narrative is an XHTML fragment with a flag to indicate its relationship to the data:

The contents of the div element are an XHTML fragment that SHALL contain only the basic HTML formatting elements described in chapters 7-11 (except section 4 of chapter 9) and 15 of the HTML 4.0 standard, <a> elements (either name or href), images and internally contained style attributes. The XHTML content SHALL NOT contain a head, a body element, external stylesheet references, deprecated elements, scripts, forms, base/link/xlink, frames, iframes, objects or event related attributes (e.g. onClick). This is to ensure that the content of the narrative is contained within the resource and that there is no active content. Such content would introduce security issues and potentially safety issues with regard to extracting text from the XHTML. Note that even with these restrictions, there are still several important security risks associated with displaying the narrative.

The div element SHALL have some non-whitespace content (text or an image).

  <narrative>
    <status value="additional"/>
    <div xmlns="http://www.w3.org/1999/xhtml">This is a simple
          example with only plain text</div>
  </narrative>

  <narrative>
    <status value="additional"/>
   <div xmlns="http://www.w3.org/1999/xhtml">
     <p>
       This is an <i>example</i> with some <b>xhtml</b> formatting.
     </p>
   </div>
  </narrative>

The inner portion of the div content is often used for the innerHTML property in a browser. In order to simplify this kind of processing, when the narrative is represented in JSON, it SHALL be encoded so that the characters between the first '>' and the last '<' delimiters is the content of the <div> element; e.g.

  "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">text</div>"

is legal, but this is not:

  "div": "<?xml ...><div>text</div>"

Note that the XHTML is contained in general XML so there is no support for HTML entities like &nbsp; or &copy; etc. Unicode characters SHALL be used instead. Unicode &#160; substitutes for &nbsp;.

The narrative content SHOULD be in the language of the resource, but there is no reason to expect that HTML enabled tooling would understand the resource language element. For this reason, a lang attribute on the <div> SHOULD also be used if language is declared on the resource (see the note in the HTML 5 specification about use of language).

Multi-language support for Narratives

A narrative may contain content from multiple languages. This is always possible in that the narrative may contain ad-hoc content in any language, often with inline translation provided - this is not unusual in clinical systems when dealing with patients/care providers speaking multiple languages. Some resources - specially standing documentation such as preparation notes - will contain the same documentation in several different languages.

Resources containing the same information in multiple different languages should use a div element with an XHTML lang attribute in the root div. By default, all languages will be displayed to a user, but multi-language aware applications can filter the content by language and only display the language that ia relevant to or chosend by the patient.

See the W3C documentation on Language declarations for further information.

Image References

Image source data (the src attribute) may refer to an image found in the resource (as a contained Media or Binary resource) by its id:

<Patient xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>... <img src="#pic1"/>. ....</p>
    </div>
  </text>
  <contained>
    <Binary><id value="pic1"/><contentType value="image/gif"/><data value="MEKH....SD/Z"/></Binary>
  </contained>
</Patient>

Internal Id References

References between the narrative and the resource data (in either direction) are mediated by the XML id/idref attributes. in JSON, the property "id" is used which is equivalent to the XML attribute "id".

The id attribute SHALL have a unique value within the resource with regard to any other id attributes: the uniqueness and resolution scope of these id references is within the resource that contains them. Contained resources are included in the id uniqueness scope of the resource that contains them.

If multiple resources are combined into a single combined document, such as a Bundle, duplicate values of the id attribute may occur between resources. This SHALL be managed by applications reading the resources.

Since images that are not contained in the resource cannot be guaranteed to be available when the resource is presented to a user, the source for any images that are an essential part of the narrative SHOULD always be embedded as a data: url, in an attachment or a contained resource

Styling the XHTML

The XHTML fragment in the narrative may be styled using cascading stylesheets with either external or internal styles. External styles are applied using the class and id attributes on the XHTML elements and internal styles are applied using a style attribute on the XHTML elements directly.

In order to minimize manageability and security issues, authoring systems cannot specify the CSS stylesheet to use directly, unless the stylesheet is included in a FHIR Document. Instead, the application that displays the resource provides the stylesheets. This means that the rendering system chooses what styles can be used, but the authoring system must use them in advance. Authoring systems can use these classes, which SHALL be supported by all rendering systems:

bold Bold Text { font-weight: bold }
italics Italics Text { font-style: italic }
underline Underlined Text { text-decoration: underline }
strikethrough Strikethrough Text { text-decoration: line-through }
left Left Aligned { text-align : left }
right Right Aligned { text-align : right }
center Center Aligned { text-align : center }
justify Justified { text-align : justify }
border-left Border on the left { border-left: 1px solid grey }
border-right Border on the right { border-right: 1px solid grey }
border-top Border on the top { border-top: 1px solid grey }
border-bottom Border on the bottom { border-bottom: 1px solid grey }
arabic List is ordered using Arabic numerals: 1, 2, 3 { list-style-type: decimal }
little-roman List is ordered using little Roman numerals: i, ii, iii { list-style-type: lower-roman }
big-roman List is ordered using big Roman numerals: I, II, III { list-style-type: upper-roman }
little-alpha List is ordered using little alpha characters: a, b, c { list-style-type: lower-alpha }
big-alpha List is ordered using big alpha characters: A, B, C { list-style-type: upper-alpha }
disc List bullets are simple solid discs { list-style-type: disc }
circle List bullets are hollow discs { list-style-type : circle }
square List bullets are solid squares { list-style-type: square }
unlist List with no bullets { list-style-type: none }

Note: for testing purposes, there is an example resource that includes all of these styles. It is also available as XHTML and a standard stylesheet that includes all of these styles. Use of styles not on this list will require an arrangement between producing and consuming systems.

Authoring systems may refer to additional classes, but cannot rely on the fact that they will be supported. If the additional classes are critical for safe rendering, trading partner agreements will be required.

Authoring systems may also use internal styles using the style attribute. This has the advantage of not depending on external interpretation, but also has the side effect of making content more difficult to manage when rendering, so applications should use this approach with care.

Authoring systems may fix the following styling aspects of the content:

These style properties are specified in-line using the style attribute. Rendering systems SHOULD respect any of these rendering styles when they are specified in the style attribute, although appropriate interpretation is allowed in certain contexts (e.g. a low-contrast display for dark rooms or a high-contrast display for the visually impaired may adjust colors accordingly).

Note that rendering systems can ignore or override any of the internal or external styles described above, but SHOULD be careful to ensure that this is only done in the context of well-maintained trading partner agreements, as altering the presentation of the text may create clinical safety issues.

Authors MAY specify additional styles and style properties as specified in the CSS specification, but these are extensions to this specification and renderers are not required to heed them. It SHOULD be safe to view the narrative without these additional styling features available.

Note that there are additional rules around styling for documents presentation.

Linking between Data and Narrative

In some contexts, it is useful to link between the two representations of the same content: structured data, and human readable narrative. This can be used to assert that the text is a representation of the data, or specifically that the data is derived from some particular text. This specification defines the extensions narrativeLink and originalText to establish these links. Here's an example of using originalText:

{
  "resourceType" : "Condition",
  "text" : {
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">There is a history of <span id=\"a1\">Asthma</span></div>" 
  },
  "code" : {
    "coding" : {
      "system" : "http://snomed.info/sct",
      "code" : "195967001",
      "display" : "Asthma (disorder)"
    },
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/originalText",
      "valueUrl" : "#a1"
    }]
  }
}

This indicates that the word "Asthma" in the narrative is the original text from which the SNOMED CT code "asthma" was derived by some text processing method. Typically, this method is associated with resources built from CDA documents. The same method can be used to reference across resource boundaries, e.g. between a resource and the composition that represents it:

<Bundle xmlns="http://hl7.org/fhir">
  <entry>
    <fullUrl value="http://example.org/fhir/Composition/abcdefghij"/>
    <Composition>
      <id value="c1"/>
      <text>
        <div xmlns="http://www.w3.org/1999/xhtml">
          ...
          <p>There is a history of <span id="a1">Asthma</span></p>
          ...
        </div>
      </text>
    </Composition>
  </entry>
  <entry>
    <Condition>
      <code>
        <extension url="http://hl7.org/fhir/StructureDefinition/originalText">
          <valueUrl value="http://example.org/fhir/Composition/abcdefghij#a1"/>
        </extension>
        <coding>
          <system value="http://snomed.info/sct"/>
          <code value="195967001"/>
          <display value="Asthma (disorder)"/>
        </coding>
      </code>
    </Condition>
  </entry>
</Bundle>

Clinical Safety Concerns

Health care records are often associated with legislative and business requirements for very long retention times (up to a century) and extreme risk aversion with regards to inconsistent display across a variety of devices, rendering engines, and display constraints. Although the narrative is allowed to use the standard XHTML and CSS features as described above, implementations are encouraged to show restraint when using the features available. Even when trading partner arrangements limit the current requirements made on a system, experience shows that these trading arrangements will likely broaden over time.

In particular:


ncimeta.html

Using the NCI Metathesaurus with FHIR

Maturity Level: 2Standards Status:Trial Use

Summary

SourceNCI Metathesaurus the NCI Center for Biomedical Informatics and Information Technology (CBIIT)
SystemThe URI http://ncimeta.nci.nih.gov identifies the NCI Metathesaurus
VersionThere is no version or versioning associated with the NCI metathesaurus
CodeThe Concept Unique Identifier (CUI) is used for the code value for a Metathesaurus concept
DisplayThe name should be used as the display for English usage (e.g. "Aerosol Dose Form" for CUI C1112870)
InactiveTodo: Describe how it is determined which concepts are inactive
SubsumptionNo Subsumption relationships are defined for the NCI Metathesaurus
Filter PropertiesNone are described yet

Version Issues

There are no staged releases of the NCI metathesaurus, so there is no versioning policy.

Copyright/License Issues

The NCI metathesaurus is in the public domain, so there are no copyright notices needed in value sets that refer to NCI metathesaurus concepts, and there are no licensing requirements limiting use of NCI metathesaurus concepts in instances or systems.

MCI Metathesaurus MySQL Database

Like RxNorm, the RRF files that are the distributed source of the NCI Metathesaurus can be used to populate a MySQL database that contains the data. This page provides SQL statements that describe how to implement the features of the NCI Metathesaurus correctly against this database. They are provided only for implementer convenience, and do not imply that any particular approach must be used in implementations. (Note: for consistency, the RxNorm table and column names are used and the CUIs are 1 character longer, so the scripts must be updated).

For example, the correct display name for a CUI is

  select STR from rxnconso where RXCUI = :code and SAB = 'RXNORM' and TTY <> 'SY'
.

NCI metathesaurus Filter Properties

This section documents the property filters that can be used with the RxNorm code system in value set composition statements.

The base SQL statement for returning a list of CUIs that conform to these filters is:

  select RXCUI from RXNCONSO where SAB = 'RXNORM' and TTY <> 'SY' 

Semantic Type

DescriptionAllows for selection of a set of CUIs based on their Semantic Type
Property NameSTY
Operations Allowed= / in
Values Allowed[column:]value
CommentsIf a column is not specified, the default is TUI
SQL
and RXCUI in (select RXCUI from RXNSTY where [:column] = :value)

Source

DescriptionAllows for selection of the set of concepts that have mappings to a particular RxNorm source
Property NameSAB
Operations Allowed= / in
Values AllowedValues from the SAB table (e.g. select RSAB from RXNsab)
SQL
and RXCUI in (select RXCUI from RXNconso where SAB = :value)

Term Type

DescriptionAllows for selection of a concept based on its designated type
Property NameTTY
Operations Allowed= / in
Values AllowedTTY values from the RxNorm Concept table (e.g. select distinct TTY from rxnconso)
SQL
and TTY = :value

Relationship

DescriptionAllows for selection of a concept based on its relationships
Property Name[REL]
Operations Allowed= / in
Values AllowedCUI:[RXCUI] or AUI:[RXAUI] must be a valid CUI or AUI. Note that a CUI does not need to have a SAB=RXNORM entry to be used here
Comments[REL] (:rel) is one of AQ, CHD, PAR, QB, RB, RN, RO, RQ, SIB or SY
SQL for CUI:
and (RXCUI in (select RXCUI from rxnconso where RXCUI in (select RXCUI1 from rxnrel where REL = :rel and RXCUI2 = :value))
for AUI:
and (RXCUI in (select RXCUI from rxnconso where RXAUI in (select RXAUI1 from rxnrel where REL = :rel and RXAUI2 = :value))

Relationship Type

DescriptionAllows for selection of a concept based on the type of its relationships
Property Name[RELA]
Operations Allowed= / in
Values AllowedCUI:[RXCUI] or AUI:[RXAUI] must be a valid CUI or AUI. Note that a CUI does not need to have a SAB=RXNORM entry to be used here
Comments[RELA] (:rela) is one of the relationship types listed in the NCI file "Relationships_Help_Page.txt" - the current list (nearly 1000 types) is at the end of the page
SQL for CUI:
and (RXCUI in (select RXCUI from rxnconso where RXCUI in (select RXCUI1 from rxnrel where RELA = :rel and RXCUI2 = :value))
for AUI:
and (RXCUI in (select RXCUI from rxnconso where RXAUI in (select RXAUI1 from rxnrel where RELA = :rel and RXAUI2 = :value))

Implicit Value Sets

This section needs investigation

Current NCI Metathesaurus relationship types


nd-json.html

ND-JSON Representation of Resources

Maturity Level: 2Standards Status:Draft

ns-json (New line delimited JSON) is a variant of the JSON format that is supported for bulk data transfer. In principle, nd-json is a simple variation on the JSON format, but where resources are serialized with no whitespace, and separated by a newline pair (characters 13 and 10).

{
  { "resourceType" : "[type]", .... }
  { "resourceType" : "[type]", .... }
}

The MIME-type for this format is application/fhir+ndjson.

In order to simplify nd-json processing, each nd-json document contains only resources of a single type - every line contains a resource of a particular type. (though note that resources may still contain contained resources of various types).

On the RESTful API, the nd-json format can only be retrieved using the Asynchronous Pattern.


ndc.html

Using NDC and NHRIC Codes with FHIR

Maturity Level: 2Standards Status:Trial Use

The National Drug Codes (NDC) and National Health Related Items Code (NHRIC) codes are codes issued by the FDA for tracking drugs and devices. Note that the NHRIC codes are being replaced by the UDI system.

Summary

SourceNational Drug Code Directory and the NHRIC Labeler Codes
SystemThe URI to identify NDC/NHRIC codes is http://hl7.org/fhir/sid/ndc
VersionUse YYYYMMDD for the date of publication, but see note below
CodeThe 10 digit NDC code, with "-" included. Note that different NDC codes have different positions for the "-": 1234-5678-90, 12345-6789-0, or 12345-678-90. The "-" must be correct for each NDC code
DisplayUse the PACKAGEDESCRIPTION column value from the TSV or Excel distribution file
InactiveTodo: Describe how it is determined which concepts are inactive
SubsumptionNo Subsumption relationships are defined for the NDC codes
Filter PropertiesNone are described yet

Version Issues

The FDA published list of NDC codes for finished drug products is updated daily. Use the format YYYYMMDD to refer to a particular distribution. Note that while only valid NDC codes appear in the distribution file, there are other NDC codes that organizations have assigned but not yet reported to FDA. Therefore, the full set of NDCs that exists in the marketplace is unknown and cannot be versioned completely.

Copyright/License Issues

NDC codes have no copyright acknowledgment or license requirements.

NDF-RT Filter Properties

No need for filters identified yet.

Implicit Value Sets

No need for implicit value sets identified yet.


ndfrt.html

Using NDF-RT (the National Drug File - Reference Terminology) with FHIR

Maturity Level: 2Standards Status:Trial Use

Summary

Sourcethe National Drug File - Reference Terminology - prepared by Veterans Health Administration, and distributed as part of UMLS by the NLM (direct link)
SystemThe URI to identify NDF-RT is not resolved. As a temporary arrangement, the URL "http://hl7.org/fhir/ndfrt" is to be used
VersionA version is not needed. (Use the date of the UMLS release for the version of NDF-RT if a version is desired.)
CodeThe NUI is used for the code value for an NDF-RT concept
Display??
InactiveTodo: Describe how it is determined which concepts are inactive
SubsumptionSubsumption testing is based in the Is-a relationship defined by NDFRT
Filter PropertiesNone are described yet

This URL is temporary while the NDF-RT and FHIR teams discuss the long term arrangements. Further documentation can be found in evs.

Version Issues

NDF-RT is released as part of UMLS. Therefore, each successive release has the date of the UMLS release as its version.

Copyright/License Issues

NDF-RT has no copyright acknowledgement required. However, users must adhere to the UMLS license.

NDF-RT Filter Properties

This section documents the property filters that can be used with the SNOMED CT code system in value set composition statements.

By Subsumption

DescriptionSelect a set of concepts based on subsumption testing
Property Nameconcept
Operations Allowedis-a
Values AllowedNUI
CommentsIncludes all concepts that have a transitive is-a relationship with the concept Id provided in the value as an NUI (including the concept itself)

Others yet to be done.

Implicit Value Sets

Yet to be done.


newfooter.html