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

Background

Reading This Guide

This guide is based on the HL7 FHIR 4.0.1 standard. This architecture is intended to maximize the number of information systems, both from industry vendors and provider and insurer in-house teams, that conform to this guide as well as to allow for easy growth and extensibility of system capabilities in the future.

To understand how to read an Implementation Guide implementers should refer to the How to Read page in the FHIR Specification.

FHIR

This implementation guide uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it’s important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.

• FHIR Overview
• Developer’s Introduction (or Clinical Introduction)
• FHIR Financial Introduction]
• FHIR Data Types
• Using Codes
• Messaging in FHIR
• References Between Resources
• How to Read Resource & Profile Definitions and additional IG reading guidance
• Base Resource
• Resource Formats

This guide addresses use cases for providers to exchange financial and administrative transactions with the nphies central clearinghouse, Saudi healthcare insurers and Third Pary Administrators (TPAs).

Key FHIR Resources

This IG also utilizes resources from the FHIR R4 Base Specification, links provided below, and then profiles (constrains and extends) these resources to meet the information exchange requirements for the various uses cases. Implementers should therefore refer to the following resources from the base specification:

• Bundle
• CapabilityStatement
• Claim
• ClaimResponse
• CodeSystem
• CommunicationRequest
• Communication
• CoverageEligibilityRequest
• CoverageEligibiliotyResponse
• Coverage
• DeviceREquest
• Encounter
• Location
• MedicationRequest
• MessageHeader
• OperationDefinition
• Organization
• Patient
• PaymentNotice
• PaymentReconciliation
• Practitioner
• ServiceREquest
• Task
• ValueSet
• VisionPrescription

The nphies profiles of the above resources are found in the Artifacts section of this guide. Note that there are often multiple profiles for some of the resources listed above, for example Claim and Organization, and it is required to follow the correct profile when constructing and validating message instances.

The purpose of this Implementation Guide is to enable data to be exchanged between Healthcare Provider organizations (HCPs) and Health Insurer organizations (HICs) via the central ‘single point of contact’ nphies clearinghouse. Implementers of this specification therefore need to understand some basic information about the FHIR specification and how profiled FHIR resources act as building blocks for this Implementation Guide.

All data exchanged by HICs and HCPs using the interactions and use cases covered in this IG SHALL be transformed to FHIR R4 resources. HCPs and HICs MAY have both data from clinical and claims sources that they store in their Systems of Record. This IG does not require any party to store, persist, this data in FHIR formats, rather parties are only required to be capable of transforming their internal data representations into FHIR resources for the purposes of data exchange with other parties for the interactions covered in this IG.

There are items in this guide that are subject to update. This includes:

• Value Sets
• Code Systems
• Examples

Exchange Method

There is a single exchange method used by this guide: Mutual Authenticated FHIR Messaging as documented in the Message Exchange section. This provides secure, x.509-based authenticated exchanges between parties via the nphies central clearinghouse system.

Provenance

Given that all exchanges explicitly identify the author, target, sender and receiver of exchanges there is currently no need to further identify the provenance of messages or message fragments, resources. If it become of value in the future to add explicit Provenance resources to messages then this can be accommodated in a future version of this guide.