---
tags: USCDI v3
title: US Core Category Codes
---

# US Core Category Codes Proposal

## Code-Systems:

These are the category code systems in 6.0.0-ballot:

1. [US Core Category](http://hl7.org/fhir/us/core/CodeSystem/us-core-category)
2. [US Core DocumentReferences Category Codes](http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category)
3. [US Core Condition Category Extension Codes](http://hl7.org/fhir/us/core/CodeSystem/condition-category)
4. [US Core CarePlan Category Extension Codes](http://hl7.org/fhir/us/core/CodeSystem/careplan-category)

To reduce the total number of US Core Code Systems from 5 to 2 and address the concern that

>As FHIR US Core grows it has every opportunity to cover other categories as well in other observations beyond screening assessments. Are we going to then have umpteen value set [or code systems !!!] names?"

Redefine US Core Category to include all the US Core defined category codes that US Core Profiles may need and are used across the different Resource Types in US Core. It is expected to grow as US Core grows in the future. We would update the definition to include a property of "Type" to indicate the resource type(s) the code pertains to.

Therefore the *Union* of the 4 code systems above would define these codes for the corresponding Profile Types
Code|Property = intended Resource Types
---|---
sdoh|Observation,ServiceRequest,Condition,QuestionnaireResponse(tag)
functional-status|Observation,ServiceRequest
disability-status|Observation,ServiceRequest
cognitive-status|Observation,ServiceRequest
assess-plan|CarePlan
health-concern|Condition
clinical-note|DocumentReference

Con:
**This would be a breaking change (previously conformant applications are no longer conformant to the updated specification, because the system value would change in the instances)**

## Value Sets:

### *US Core Simple Observation Value Set*

Currently in 6.0.0-ballot *US Core Simple Observation Value Set* is the superset of all category code that are defined for Observation

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                {"US Core Category CodeSystem" "Observation Category Codes CodeSystem*"}->"US Core Simple Observation Category ValueSet"

}

In This Proposal, this Value Set Name not change. However its definition would change to include only the codes in US Category Code with Observation as a property. To wit, this would not change the content from the ballot to published version. It could grow in future versions.

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                {"US Core Category CodeSystem with property =Observation" "Observation Category Codes CodeSystem*"}->"US Core Simple Observation Category ValueSet"

}

\* [Observation Category Codes](http://terminology.hl7.org/CodeSystem/observation-category
) is a defined by HL7 Terminology (THO). The Other places this value set is used is in the *US Core Observation Clinical Result Profile*

|Code|
|---|
|social-history|
|vital-signs|
|imaging|
|laboratory|
|procedure|
|survey|
|exam|
|therapy|
|activity|

---
### *US Core Observation Value Set*

Currently in 6.0.0-ballot *US Core Observation Category ValueSet* is all category codes from *US Core Category CodeSystem* and used in the *US Core Observation Screening Assessment Profile*

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                {"US Core Category CodeSystem"} -> "US Core Observation Category ValueSet" 

}

In This Proposal, this Value Set Name is changed to *US Core Screening Assessment Observation Category*. However its definition would change to include only the codes in *US Category Code* with Observation as a property. To wit, this would not change the content from the ballot to published version. It could grow in future versions.

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                {"US Core Category CodeSystem with property =Observation"}->"US Core Screening Assessment Observation Category"

}

This Proposal would not preclude other valueset being created as US Core Expands. In other words, we may have "umpteen" value set names in future versions of US Core. The approach for managing them will be:

1. If possible, will use an existing value set (e.g., *US Core Observation Category ValueSet*)
2. Else will create a new value set based on existing external (e.g., THO) code systems and the internal US Core Category CodeSystem
- May need to add new codes to the US Core Category CodeSystem
- New valueset name: 'US Core [Profile Name] Category' (e.g. US Core Observation Foo Category)

---
<!-- ###

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                "Observation Category Codes CodeSystem" ->"Observation Category Codes ValueSet"  -> "US Core Observation Clinical Result Profile"

}

---
<!-- ### Other Place the current *US Core Category CodeSystem*. is used is in the *US Core ServiceRequest Profile*

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                {"US Core Category CodeSystem" "Service Request Category Codes (FHIR) CodeSystem" "2 SNOMED CT Codes"}->"US Core ServiceRequest Category Codes ValueSet"

}

-->

---
<!-- ## Proposal for US Core to provide clear instruction on how a resource maps to one or some target profiles.

1. All Observations can be Simple Observations. (superset)
2. Clinical test should not be a survey (apgar?)
- remove survey, vitals, social hx categories ?
- remove survey, vitals, social hx LOINCs from extensible binding?
3. Screening observation should not be a clinical test. (apgar?)

separate category and a testing rule to use a meta.profile if cannot a impute the profile.

most servers and clients look at the superset of profiles and this is not a concern. -->