NCPI FHIR Implementation Guide
0.2.0 - ci-build

NCPI FHIR Implementation Guide - Local Development build (v0.2.0). See the Directory of published versions

Resource Profile: Raw Data Observation

Official URL: https://nih-ncpi.github.io/ncpi-fhir-ig/StructureDefinition/raw-data-observation Version: 0.2.0
Active as of 2022-12-09 Computable Name: RawDataObservation

Representation for a row of data from one of the dataset’s tables.

Code Must be Present

While there may be more than one coding associated with these Observations, one of them must be the code from the Table’s data-dictionary entry in the data-set CodeSystem. This provides basic context associated with what the contents of the resource relate to.

Components Represent the Row’s Columns

Each of these Observations represents a single row from a single table from the study’s dataset. The individual cells are captured as components such that each non-missing data point will be stored in a separate component.

There must be at least one component present.

Usage:

  • This Resource Profile is not used by any profiles in this Implementation Guide

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from Observation

NameFlagsCard.TypeDescription & Constraintsdoco
.. Observation 0..*ObservationMeasurements and simple assertions
... code
.... coding 1..*CodingCode defined by a terminology system
... component 1..*BackboneElementComponent results

doco Documentation for this format

 

Other representations of profile: CSV, Excel, Schematron

Notes:

Component Definition

The components represent non-missing data from the table of origin for the given row. As such, each will have some data stored in the value[x] property, along with a proper code from the table’s data-dictionary CodeSystem.

Data Dictionary Codes Provide Context

In order to establish what each of the components represents, one of the component’s codings should point to the appropriate code from the related table’s data-dictionary CodeSystem.

Typed Data is Encouraged Within Limits

Given a reasonably complete data-dictionary, it should be possible to properly type most of the data and correctly assign those typed data to the appropriate value[x] properties. Where the data actually fails to conform to the data-dictionary’s established type, the resource will validate fine with an appropriate value[x] type that can support the non-conforming data, such as signifying NaN as a code for non-numeric numerics, or choosing a valueString to handle cases like “< 1”.

In general, it is assumed decimal numbers will be represented as valueQuantity, however, unless there is some specification from the data-dictionary about the value’s type, that quantity may simply contain the singular value property.

Each Non-Missing Column Should be Present

While it may seem appropriate to merge certain types of columns together to take advantage of their known relationship, such as using a separate column’s contents to assign the units associated with a quantity, the objective here is to establish as accurate a picture of what the original data looked like as possible. As such, resource generators should avoid any such transformations for these raw data resources. Leave those to the interoperable portion of the FHIR transformation.