Da Vinci PDex Plan Net, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 1.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pdex-plan-net/ and changes regularly. See the Directory of published versions

Home

Official URL: http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net				Version: 1.2.0
IG Standards status: Trial-use				Computable Name: DaVinciPDEXPlanNet

Introduction

This implementation guide defines a FHIR interface to a health insurer's insurance plans, their associated networks, and the organizations and providers that participate in these networks. Publication of this data through a standard FHIR-based API will enable third parties to develop applications through which consumers and providers can query the participants in a payer's network that may provide services that address their health care needs. Although there are multiple types and sources of providers' directories, including provider organizations (i.e., a hospital listing all its physicians), government (i.e., listing of providers in Medicare), payers (i.e., a health plan's provider network), and third-party entities (such as vendors that maintain provider directories), the focus of this implementation guide is on Payer Provider Directories.

The PDEX Payer Network (or Plan-Net) Implementation Guide is based conceptually on the Validated Healthcare Directory Implementation Guide (VHDir IG), an international standard. The VHDir IG is based on FHIR Version 4.0. It was developed in cooperation with the Office of the National Coordinator for Health Information Technology (ONC) and Federal Health Architecture (FHA) with guidance from HL7 International, the Patient Administration Workgroup, and the HL7 US Realm Steering Committee.

The use of VhDir as the conceptual base for the profiles and extensions in the PDEX Payer Network Implementation Guide is intended to protect implementers of the Plan-Net IG from rework/remapping when the VHDir concept reaches implementation, and becomes a source of data for the PDEX Payer Network. The primary changes from the VHDir IG are to:

1. remove the validation and restriction resources
2. use US Core for R4 as the base suite of profiles where possible
3. eliminate extensions that are not necessary for this use case
4. introduce additional constraints (e.g. search criteria, cardinality, value-set bindings and MustSupport) where appropriate.

The diagram below depicts the scope of this implementation guide (IG). The IG defines the API that exposes a payer’s provider network (including pharmacy locations where appropriate) for access by a consumer or provider application. This is a query only API (GET) and does not support PUT or POST.

Content and Organization

The IG is organized into the following sections:

• Conformance Expectations: Conformance rules for this IG.
• Background: Provides examples of how this specification can be used healthcare organizations.
• Implementation: Provides examples of how this specification can be used healthcare organizations.
• Artifacts: The computable FHIR artifacts (profiles, value sets, etc.) for this specification.

Relation to US Core and other IGs

This implementation guide was written for a US audience and profiles resources from US Core STU 4, where available (Practitioner, Organization and Location), and otherwise from R4 (OrganizationAffiliation, PractitionerRole, HealthCareService, Endpoint). The PractitionerRole profile from US Core was not used because it is over-constrained for use in a Provider Directory based on Payer information. The Network profile is based on USCore Organization, since there was no contradiction between the USCore profile and the Plan-Net requirements. However, the NPI and CLIA identifier types, which are Must-Support, are clearly intended for provider organizations only and are not expected to be populated for other organization types. Alignment with VhDir is maintained by adapting VhDir content, where possible.

Disclaimers and Assumptions

• PDEX Payer Network is based conceptually on VhDir: The PDEX Payer Network implementation guide is based conceptually on the VhDir implementation guide, which is still a work in progress. Plan-net will need to track changes to VhDir to fulfill its goal of minimizing rework.
• The PDEX Payer Network endpoint is known to the client: This implementation guide assumes that the directory endpoint is known to the client. There is an overarching system architecture issue that is critical to resolve -- how does the client discover the FHIR endpoint of interest. For the purposes of this IG, we consider that problem out of scope.

Background

Provider directories play a critical role in enabling identification of individual providers and provider organizations, as well as characteristics about them. Provider directories support a variety of use cases, including:

• Patient/Payer focused
• Find provider accessibility information (specialty, office hours, languages spoken, taking patients) - enables individuals and consumers to find contact and other accessibility information for individual healthcare providers and/or healthcare organizations
• Relationship between provider and insurance plan (insurance accepted) or plan and provider (network) - enables individual healthcare providers, organizations, and payers to discover the relationships between providers, organizations, and payers, as well as additional details about the relationships and entities involved
• Basic Information Exchange
• Enable electronic exchange (e.g. discovery of electronic endpoints such as IHE/EHR endpoints, FHIR server URLs, Direct addresses) - enables the electronic exchange of health information by supporting the ability to discover electronic service information including electronic endpoints or electronic addresses
• Find an individual and/or organization (even if no electronic endpoint is available) - enables users to find contact and other identifying information about healthcare organizations and individual healthcare providers

This IG addresses two actors:

• Health Plan API Actor: A payer publishing a directory of its provider networks through a FHIR endpoint.
• Application Actor: A third party using the API published by a payer to provide useful views of the payer's provider networks for end users.

For anticipated query use cases, please see Representing and Searching Provider Data.

Overview of Payer Directory - Resource Relationships

Note: the following diagrams provide a high-level view of the relationships between resources used in this IG. They do not necessarily reflect all of the relationships/references between resources.

Credits

This IG was developed by the MITRE Corporation under the direction of the authors using FHIR Shorthand syntax and the SUSHI tookit, a free, open source toolchain from the MITRE Corporation. Generous guidance on FHIR Shorthand and SUSHI was provided by Chris Moesel. The capability statements were developed with support of tools and generous guidance from Eric Haas, and benefited from critical review by Yengibar Manasyan.

Dependencies

Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00)

Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.uv.bulkdata#2.0.0 FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00)

Package hl7.fhir.uv.sdc#3.0.0 The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR. This includes two components: * Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains. *Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package ihe.formatcode.fhir#1.1.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00)

Package hl7.fhir.us.core#6.1.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Fri, Jun 30, 2023 14:02+0000+00:00)

Package hl7.fhir.us.core#7.0.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Wed, May 8, 2024 15:33+0000+00:00)

Package hl7.fhir.us.davinci-hrex#1.1.0 The Da Vinci Payer Health Record exchange (HRex) Framework/library specifies the FHIR elements used in multiple Da Vinci implementation guides. This includes FHIR profiles, functions, operations, and constraints on other specifications such as CDS-Hooks and other aspects of Da Vinci Use Cases that are common across more than a single use case.\n\nDa Vinci HRex Implementation Guide (IG) will make use of US Core profiles that are based on the FHIR R4 specification wherever practical. The HRex IG will use the HL7 FHIR Release 4/US Core STU3 specification as its base but will provide additional guidance and documentation to support implementations that follow the HL7 FHIR STU3/US Core STU2 and HL7 FHIR DSTU2/Argonaut specifications.\n\nThe HRex profiles documented in this IG will be used to exchange data between providers systems (e.g. EHRs) and other providers, payers, and third-party applications where appropriate. In addition, exchanges from payer systems to providers, other payers, and third-party applications are supported by the HRex profiles and operations.\n\nHRex may define new extensions, profiles, value sets, constraints/extension to other specification (e.g. specific CDS-Hooks) that are specific Da Vinci requirements. Where appropriate these Da Vinci specific artifacts will be promoted for incorporation into the future versions of existing standards (e.g. R4 US Core profiles) and deprecated in this guide on publication in the updated standard. (built Tue, Dec 10, 2024 16:43+0000+00:00)

Intellectual Property Considerations

This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.

This publication includes IP covered under the following statements.

• Copyright HL7. Licensed under creative commons public domain
  Show Usage
  • degreeLicenseCertificate: IndividualSpecialtyAndDegreeLicenseCertificateVS, NonIndividualSpecialtyAndDegreeLicenseCertificateVS... Show 6 more, PlannetPractitioner, PlannetPractitionerRole, Practitioner/HansSolo, Practitioner/JoeSmith, Qualification and SpecialtyAndDegreeLicenseCertificateVS
• ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
  Show Usage
  • ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code: AcceptingPatientsCS, AcceptingPatientsVS... Show 111 more, Accessibility, AccessibilityCS, AccessibilityVS, CommunicationProficiency, ContactPointAvailableTime, DaVinciPDEXPlanNet, DavinciPdexPlanNetCapabilityStatement, DeliveryMethod, DeliveryMethodCS, DeliveryMethodVS, EndpointConnectionTypeCS, EndpointConnectionTypeVS, EndpointPayloadTypeCS, EndpointPayloadTypeVS, EndpointUsecase, EndpointUsecaseVS, HealthcareServiceCategoryCS, HealthcareServiceCategoryVS, HealthcareServiceTypeVS, IndividualAndGroupSpecialtiesVS, IndividualSpecialtyAndDegreeLicenseCertificateVS, InsurancePlanTypeCS, InsurancePlanTypeVS, InsuranceProductTypeCS, InsuranceProductTypeVS, LanguageProficiencyCS, LanguageProficiencyVS, LocationReference, MinEndpointConnectionTypeVS, NetworkReference, NetworkTypeVS, NewPatients, NonIndividualSpecialtiesVS, NonIndividualSpecialtyAndDegreeLicenseCertificateVS, OrgDescription, OrgTypeCS, OrgTypeVS, OrganizationAffiliationRoleCS, OrganizationAffiliationRoleVS, PlannetEndpoint, PlannetHealthcareService, PlannetInsurancePlan, PlannetLocation, PlannetNetwork, PlannetOrganization, PlannetOrganizationAffiliation, PlannetPractitioner, PlannetPractitionerRole, Plannet_sp_endpoint_organization, Plannet_sp_healthcareservice_category, Plannet_sp_healthcareservice_coverage_area, Plannet_sp_healthcareservice_delivery_method, Plannet_sp_healthcareservice_endpoint, Plannet_sp_healthcareservice_location, Plannet_sp_healthcareservice_name, Plannet_sp_healthcareservice_organization, Plannet_sp_healthcareservice_specialty, Plannet_sp_healthcareservice_type, Plannet_sp_insuranceplan_administered_by, Plannet_sp_insuranceplan_coverage_area, Plannet_sp_insuranceplan_identifier, Plannet_sp_insuranceplan_name, Plannet_sp_insuranceplan_owned_by, Plannet_sp_insuranceplan_plan_type, Plannet_sp_insuranceplan_type, Plannet_sp_location_address, Plannet_sp_location_address_city, Plannet_sp_location_address_postalcode, Plannet_sp_location_address_state, Plannet_sp_location_endpoint, Plannet_sp_location_organization, Plannet_sp_location_partof, Plannet_sp_location_type, Plannet_sp_network_coverage_area, Plannet_sp_organization_address, Plannet_sp_organization_endpoint, Plannet_sp_organization_name, Plannet_sp_organization_partof, Plannet_sp_organization_type, Plannet_sp_organizationaffiliation_endpoint, Plannet_sp_organizationaffiliation_location, Plannet_sp_organizationaffiliation_network, Plannet_sp_organizationaffiliation_participating_organization, Plannet_sp_organizationaffiliation_period, Plannet_sp_organizationaffiliation_primary_organization, Plannet_sp_organizationaffiliation_role, Plannet_sp_organizationaffiliation_service, Plannet_sp_organizationaffiliation_specialty, Plannet_sp_practitioner_family_name, Plannet_sp_practitioner_given_name, Plannet_sp_practitioner_name, Plannet_sp_practitionerrole_endpoint, Plannet_sp_practitionerrole_location, Plannet_sp_practitionerrole_network, Plannet_sp_practitionerrole_organization, Plannet_sp_practitionerrole_period, Plannet_sp_practitionerrole_practitioner, Plannet_sp_practitionerrole_role, Plannet_sp_practitionerrole_service, Plannet_sp_practitionerrole_specialty, PractitionerQualification, PractitionerRoleVS, ProviderRoleCS, Qualification, QualificationStatusCS, QualificationStatusVS, SpecialtiesVS, SpecialtyAndDegreeLicenseCertificateVS, ViaIntermediary, VirtualModalitiesCS and VirtualModalitiesVS
• This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
  Show Usage
  • Endpoint Connection Type: EndpointConnectionTypeVS, MinEndpointConnectionTypeVS and PlannetEndpoint
  • Practitioner role: PlannetPractitionerRole and PractitionerRoleVS
  • Service type: HealthcareServiceTypeVS and PlannetHealthcareService
  • ActReason: Endpoint for Acme of CT Portal, EndpointUsecase and EndpointUsecaseVS
  • RoleCode: Cancer Clinic, Hartford Hospital Location 1... Show 5 more, Hartford Hospital Location 2, OrgA CT Location 1, OrgA CT Location 2, OrgA MA Location 1 and OrgA MA Location 2