Page tree
Skip to end of metadata
Go to start of metadata

US Realm Specifications 

-- overview

  • US Core
  • Da Vinci
  • ...

Underlying specifications

  • FHIR R4+
  • CDSSHooks
  • SMART on FHIR Launch
  • FHIRcast - future


Problem

  • Need consistent FHIR conformance across US Implementation Guides
  • Need best practices
    • How to reuse specifications
      • API
        • search
        • hooks
        • create/update
        • custom operation
      • Data Structures
        • US profiles reuse
        • US profile testing
          • "Mandatory" element use to specify "supported" and "must be specified"
          • Use of null flavor (i.e. "dataAbsentReason"
          • Allowing and prohibiting modifiers extensions
            • what is the default  behavior? Allo
        • adding local extension (e.g. Z-SEgments)
          • grouping extension similar to Z-segments
          • specifying which resource can use an extension (e.g. Patient-specific extensions, Observation-specific, Global extension)
        • Extensions
          • IG specific extensions - adding mapping to external terminology (concept domains) to avoid duplication?
          • modifier extensions - are they allowed for "mandatory" data elements (e.g. USCDI)?
          • data type extensions - new to FHIR, not present in V2 or CDA !!!

Data Validation rules for US Realm 

  • Applicable for all specification that use FHIR resources

Transition Table from Base Standard to Profile 

What are the rules for organizations (like VA) when reusing/containing/extending a US-realm IG/profile?

This section will describe the rules relate to mandatory/cardinality/extensibility: 

  • Add transition table base standard -vs profile

Support and Presence Rules

US Realm Adjective/
Extensions
Min CardinalityMax Cardinality

"Must Support"

(boolean)

Data Absent Reason
(null indicator)
Local Extensions (not in IG)Coded Data ElementsTerminology bindingTesting (preliminary discussion)Client  responsibilitiesServer responsibilities

Mandatory

Data Element

1>0truenot allowed

not allowed

(modifier, data type, element)

"unknown" or equivalent  is not allowed as a valuerequired (value set mandatory)

All test cases will mandate the presence of this data element.

Some of these elements may be mandatory in the base standard (e.g. Observation.status).

must be able to process the data consistent with the IG requirementMust produce a clear exception if the data element is missing

Required

Data Element

1>0trueallowednot allowedany valid code allowedextensible
(value set mandatory)

Data absent must be used when the value is not available:

  • pss: test for absence with null indicator
  • pass: test for presence
  • fail: absence without null indicator
must be able to process the data consistent with the IG requirement

R/E

Data Element

0>0trueallowednot allowedany valid code allowedextensible
(value set mandatory)

Test cases may validate:

  • pass: absence of value (e.g. data doesn't appear in the EHR)
  • pass: absence of value + null (e.g. patient refused to answer)
  • pass: in some cases/pre-conditions, the value will be expected (e.g. gender at birth was entered)
must be able to process the data consistent with the IG requirement
Not supported00false (explicitly stated)not applicablenot applicablenot applicablenot applicableAll test cases will mandate the absence of this data element.no action
<unspecified>anyanynot specifiedundeterminedundeterminedundeterminedundetermined

? (ask Brett, Hans, Dan)

If present, it should be correctly populated based on the base standard (v2 best practice).

Test cases cannot require the presence of these data elements but the best-practice recommendation is to add a derived profile that identities additional "must supporte" data elements. This way it's clear to implementers if another data element beyond the core data is needed for this use case.

?

undetermined


Conditional, slices, conditional









(

  • Invariant expressions are inherited from base resource/data elements

Profiles identify:

  • Mandatory (is supported and must be valued)
  • Supported (is supported and may be valued, if not valued a "dataAbsentReason" must be specified)
  • Not supported (in the US)

Data elements not constrained in the profile are "unspecified" - they inherit the invariant and data semantics in the base standard.  

Principles...

  1. A profile must contain at least  one "required" data element
  2. All data elements affected by the project requirements will be annotated with the "must support" indicator: set to "true" or "false"(if the data element is explicitly out-of-scope)
  3. If a data element has a min cardinality of 1 in the base resource (e.g. status) the profile cannot mark that data element as "not supported". As a best-practice it should be included in either "mandatory" or "required"
  4. CapabilityStatement 
    1. Multiple levels of capability statements  that can be reused across servers
    2. US ARC statement may be reused by implementers

TODO: server vs client responsibilities for read/only ("search", "get") APIs

  • display responsibilities clients:
    • may be transformed/computed for display 
    • unless explicitly specified, all supported/mandatory data will be displayed

Modifier Extensions

By default, not supported in US Realm implementation guides

If they are added by an organization or project, these extensions MUST by registered to the US Core Registry. 

Q: US registry of templates and extensions will be available before January 2020?


Adding Local Extensions 

Z-segments to FHIR extensions

  • No labels