Healthcare Financial Services IG Edition 1 - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Artifact Overview

The following sections provide a high-level overview of the contents and purpose of the types of artifacts provided on the Artifacts tab on the top-level menu.

Behavior: Capability Statements

The Council for Health Insurance regulations require healthcare providers and insurers to exchange eClaims messages via the nphies clearinghouse by implementing the messages, profiles, terminologies and exchange specifications provided by this guide and subsequent versions of this guide.

The FHIR CapabilityStatement defines the resources and operations supported by the resources exposed via the FHIR API which provides implementers with computable end-point technical definitions.

The Capability Statements artifacts section provides templates detailing permitted operations for the FHIR messages supported by the nphies clearinghouse are defined in the nphies Capability Statement and the permitted operations for insurers are defined in the nphies Insurer Capability Statement.

Structures: Abstract Profiles

The Abstract Profiles section documents resource profiles which are intended to support the creation of production-level profiles and are specifically not for production implementation. These design-level profiles are used as part of an inheritance-chain in the creation of production-level profiles.

For example, a resource from the FHIR specification (which are typically inherently abstract) may have cardinality, terminology and extensions applied to create a country or business appropriate abstract profile which may in turn be profiled to provide one or more use-case specific production-level resource profiles.

A concrete example would be the FHIR R4 Claim resource which supports authorization, pre-determination and claims across the healthcare spectrum which is profiled in this guide to provide a base abstract Authorization profile which is then profiled to product production-level resource profiles for the institutional, professional (out-patient), oral health (dental), pharmacy and vision authorization use cases.

Structures: Resource Profiles

The Resource Profiles section documents production-level profiles which are intended to support defined use cases such as institutional prior authorization or vision claims. These profiles provide the data element, cardinality, data types, terminology and other constraints with which implementations SHALL integrate to be conformant with this specification and Implementation Guide.

Structures: Data Type Profiles

Datatype patterns are provided to implementers to simplify their review of specifications and, should they choose, to aid in automation of instance validation. The patterns used within this FHIR IG are implemented as Data Type profiles and the name of the datatype pattern appears in the Data Type column of Abstract and Resource profiles, and their associated StructureDefinition resources, but do not appear in instances exchanged between parties.

The datatype patterns in the prior Word-based implementation guide have been implemented in this FHIR IG as Data Type profiles with more consistent naming ([prefix]FHIR Datatype[suffix]).

Note: Data type profiles once used in production cannot be changed, they are only subject to technical corrections. Any desired changes will result in a new Data Type profile, updating of Abstract and Resource Profile to use the new Data Type profile and perhaps deprecation of the existing Data Type profile.

Structures: Extension Definitions

Extensions are the mechanism provided by FHIR to add additional data elements to resource instances, via inclusion in resource profiles, in order to meet the information exchange requirements of defined use cases. This guide will use some extensions already defined in the FHIR R4 specification and also defines some new extensions just for the purpose of this guide.

Note: Extension definitions, StructureDefinitions, once used in production cannot be changed, they are only subject to technical corrections. Any desired changes will result in a new extension, updating of Abstract and Resource Profile to use the new extension and perhaps deprecation of the existing extension.

Terminology: Value Sets

Value Sets define the specific list of codes which are used by this guide, as indicated within both Abstract and Resource Profiles. These codes are drawn from one or more Code Systems, both international and Saudi provided, to create the suite of allowed codes within the Value Set.

Many Value Sets used within this guide are dynamic in nature, meaning that the Value Sets as shown in this guide are correct and complete at the time of publication of this guide but may change independent of this guide to adjust to industry needs. Implementers should monitor terminology servers and Value Set distribution points to obtain the up-to-date Value Sets.

Terminology: Code Systems

HL7-defined and Internationally-defined Code Systems and Saudi-defined Code Systems define the list of codes which comprise a concept domain such as: administrative gender, diagnosis, billing codes; and, processing error codes. These codes are used within Value Sets to define the exact suite of allowable codes for coded data elements within resource instances.

Many Code Systems used within this guide are dynamic in nature, meaning that the Code Systems as shown in this guide are correct and complete at the time of publication of this guide but may change independent of this guide to adjust to industry needs. Implementers should monitor terminology servers and Code System distribution points to obtain the up-to-date Code Systems.

Example: Example Instances

Examples of individual resources and full message examples are provided to further illustrate the conformant use of this guide to support the use cases addressed by this guide.

Note: Examples are informative and therefore where there is variance between any example and the profiles defined for a use case the profile definition is deemed to be correct as it is the normative specification of requirements.