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 2.0.0-ballot 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

Implementation

Page standards status: Informative

Highlight text changes?

Implementation Notes

This page contains miscellaneous information on FHIR implementation. The content is primarily directed at implementers of Plan-Net.

Conformance Requirements

The conformance verbs SHALL, SHALL NOT, SHOULD, and MAY) used in this guide are defined in FHIR Conformance Rules.

Privacy Considerations

Access to the Plan-Net service should not require authentication, and the server should not maintain any records that could associate the consumer with the entities that were queried.

A conformant Plan-Net service SHALL NOT require a directory mobile application to send consumer identifying information in order to query content.

A directory mobile application SHALL NOT send consumer identifiable information when querying a Plan-Net service.

Client Detection of Updates Directory Content

Clients that cache query results can track additions or modifications to directory content through queries that filter content using the _lastUpdated search parameter. Clients should periodically check that data cached from past queries has not been deleted by querying for the same elements by _id. Note that _lastUpdated is server-controlled metadata, and it represents the time the server content was updated, not necessarily the update date from a business perspective. For example, if an InsurancePlan was updated in a backend system a week ago, but the changed content was added to the server today, the _lastUpdated date will be today.

Representing and Searching Provider Directory Data

Server Actors SHALL use the Plan-Net profiles and search parameters defined in this IG as well as the core FHIR R4 search parameters used by this IG consistently in order to achieve true interoperability of directory information among payers. The intent of this section is to provide examples of the canonical use of the profiles provided in this IG that will guide implementers towards the consistent use of these profiles that will enable 3rd party applications to search the data. The Plan-Net design is based around the following types of searches.

Search	Example	Focal  Resource and Field	Qualifications of Search
General Search	Pharmacy	HealthcareService.category, HealthcareService.specialty	Location, network
Provider by Name	Joe Smith	Practitioner.name	Location, network, specialty, role/privileges
Organization by Name	Montgomery Cardiology or CVS	Organization.name	Location, network, specialty
Provider by Specialty	Cardiologist	PractitionerRole.specialty	Location, network, name
Organization by Specialty	Compounding Pharmacy	OrganizationAffiliation.specialty	Location, network, name

The content in this section of the IG is based on the examples provided and on the patterns provided (here}[a href="patterns.pptx"]

Specific examples are referenced in the text below.

Searching for active Practitioners and Organizations

Sample query to search for currently active Practitioners (replace date in query with current date):

https://plan-net-ri.davinci.hl7.org/fhir/PractitionerRole?date=ge2021-10-25

Sample query to search for currently active Organizations (replace date in query with current date):

https://plan-net-ri.davinci.hl7.org/fhir/OrganizationAffiliation?date=ge2021-10-25

To search for Practitioners or Organizations that will be active at a future time, change the date to a future date.

If no period is provided, then it is assumed the role is active with no expiration date. If period is provided, the entry is assumed to be active during that period. Plan-Net requires that all resources in the directory have active set to true, since Plan-Net directories are assumed to contain only entries that are active currenly, historically, or in the future. When sourcing data from other sources such as a generic FHIR server, setting active to false in the source system will make the data invalid from a Plan-Net perspective, so it SHALL be removed from the target Plan-Net directory.

HealthcareService

The first type of search starts from HealthcareService.category and HealthcareService.specialty. For this to work, Server Actors SHALL provide appropriate set of Plan-Net HealthcareService instances. HealthcareServices are typically provided by an organization, except in the case of a Practitioner that is not associated with an organization (see the solo practitioner example), and can be linked to a set of locations where service is provided, or identified as virtual services through an indicated set of virtual modalities.   The examples illustrate this with an organization that provides three distinct Pharmacy services – retail, compounding, and mail-order – across its locations.  All organizations that provide service should define an appropriate set. of HealthcareServices to facilitate search.  The HealthcareService category, specialty and type fields are the highest level of organization of the services provided by the provider's network.

Relevant examples:

Scenario	Example Instances
Retail Pharmacy Chain	PharmChainRetailService
Compounding Pharmacy	PharmChainCompService
Mail Order Pharmacy (virtual service with no physical location)	PharmChainMailService
Provider Group	HartfordOrthopedicServices
Emergency Room	HospERService
Cancer Clinic	CancerClinicService
Virtual Counseling Service	VirtualCounselService
Solo Family Practitioner	HansSoloService

Insurance Plan and Network

Each payer will offer one or more products – Insurance Plans – and each plan is associated with one or more Networks.  Practitioners and Organizations indicate participation in a Network with a link to the Network using a PractitionerRole or OrganizationAffiliation instance, respectively.   PractitionerRole and OrganizationAffiliation instances are what tie Practitioners and Organizations to HealthcareServices, Organizations, Networks and Locations.

The examples demonstrate the use of the InsurancePlan profile to represent two distinct Qualified Health Plan products covering the state of Connecticut, using a pair of Networks.  The practitioners and organizations in the examples participate in one or both of these networks.

Relevant examples:

Scenario	Example Instances
Insurance Company	Acme
QHP Gold Plan with two networks	AcmeQHPGold
QHP Bronze plan with one network	AcmeQHPBronze
Standard Network	AcmeofCTStdNet
Premium Network	AcmeofCTPremNet

Location

Location instances provide information about location where service is provided, including contact information, address, accessibility, hours of operation and contact, as well as position (lattitude and longitude).   Locations can also be used to represent regions using an associated or attached GeoJSON object.

Relevant examples:

Scenario	Example Instances
Hospital Location #1	HospLoc1
Hospital Location #2	HospLoc2
Pharmacy Location #1 .  Shows newpatient, accessibliity, and contactpoint-availabletime extensions	PharmLoc1
Pharmacy Location #2	PharmLoc2
Location used as CoverageArea	StateOfCTLocation

Practitioners and PractitionerRoles

Practitioner instances provide information about a specific person, including name, gender, languages spoken, and qualifications.   PractitionerRole defines a role for a particular practitioner, and associates it with locations, specialties, an organization, and networks.

Scenario	Example Instances
Solo Practitioner (no organization)	HansSolo, HansSoloRole1, HansSoloService
Anonymous role (not associated with a specific practitioner)	AnonRole
Physician working at a provider group	JoeSmith, JoeSmithRole2
Physician with admitting privileges	JoeSmith, JoeSmithRole3
Physician working at a hospital	JoeSmith, JoeSmithRole1
Counselor working virtually	CounselorRole1

Organizations and Organization Affiliations

Organization instances provide information about a specific organization and organizational hierarchies, including organization name, specialty, type, address and contact information.  Organization Affiliation instances describe a role, and link a participating organization that provides or performs the role, with an organization where that role is available, and also links the participating organization to a HealthcareServices and networks. OrganizationalAffiliation can also be used to associate a HealthcareService provided by an organization with networks.

Scenario	Example Instances
Pharmacy services are associated with a specific provider network	PharmChain, PharmChainAffil1, PharmChainAffil1, PharmChainAffil1
Clinic Providing Service to a Hospital	BurrClinic, BurrClinicAffil, Hospital
Clinic that is part of a Hospital	HamiltonClinic, HamiltonClinicAffil, Hospital
Specialty group providing service to a network at hospital	HartfordOrthopedics, HartfordOrthopedicAffil, Hospital
Clinic that is a member of a regional HIE	BurrClinic, ConnHIE, ConnHIEAffil

Endpoints

An Endpoint instance provides  technical details of an endpoint that can be used for electronic services, such as a portal or FHIR REST services, messaging or operations, or DIRECT messaging.

Scenario	Example Instances
Payer Portal	AcmeOfCTPortalEndpoint

Search Parameters

Plan-Net servers and clients SHALL support the following search parameters:

• All the search parameters defined on the Artifacts page of this IG.
• All the seach parameters defined in the US Core implementation guide for the US core resources inherited in this IG.
• The following Core FHIR R4 search parameters:

Endpoint

• organization

HealthcareService

• coverage-area
• identifier
• endpoint
• location
• name
• organization
• service-category
• service-type
• specialty

InsurancePlan

• administered-by
• identifier
• name
• owned-by
• type

Location

• address
• address-city
• address-country
• address-postalcode
• address-state
• address-use
• endpoint
• organization
• partof
• type

Organization

• address
• endpoint
• name
• partof
• type

OrganizationAffiliation

• endpoint
• location
• network
• participating-organization
• primary-organization
• role
• service
• specialty

Practitioner

• family
• given
• name

PractitionerRole

• endpoint
• location
• organization
• practitioner
• role
• service
• specialty

Plan-Net servers and clients SHOULD support all core FHIR search parameters for the resources used in this IG.

Note that versions of Plan Net prior to 2.0.0 contained custom search parameters that were duplicates of core FHIR search parameters. Those have been removed in 2.0.0 and later releases. See the Change Log for details.

Chaining and Reverse Chaining Requirements

Server Actors SHALL support chaining for the following resources and search parameters and SHOULD support reverse chaining as well.

Resource	Search parameter	SearchParameter.chain values
Endpoint	[organization][endpoint-organization]	name, address, partof, type
HealthcareService	[endpoint][healthcareservice-endpoint]	organization
HealthcareService	[location][healthcareservice-location]	address, address-postalcode, address-city, address-state, organization, type
HealthcareService	[organization][healthcareservice-organization]	name, address, partof, type
InsurancePlan	[administered-by][insuranceplan-administered-by]	name, partof
InsurancePlan	[owned-by][insuranceplan-owned-by]	name, partof
Location	[endpoint][location-endpoint]	organization
Location	[organization][location-organization]	name, address, partof, type
Location	[partof][location-partof]	type, address, organization
Organization	[endpoint][organization-endpoint]	organization
Organization	[partof][organization-partof]	name, address, type
OrganizationAffiliation	[endpoint][organizationaffiliation-endpoint]	organization
OrganizationAffiliation	[location][organizationaffiliation-location]	address, address-postalcode, address-city, address-state, organization, type
OrganizationAffiliation	[network][organizationaffiliation-network]	name, partof
OrganizationAffiliation	[participating-organization][organizationaffiliation-participating-organization]	type, address, name, partof
OrganizationAffiliation	[primary-organization][organizationaffiliation-primary-organization]	type, address, name, partof
OrganizationAffiliation	[service][organizationaffiliation-service]	service-category, organization, location
PractitionerRole	[endpoint][practitionerrole-endpoint]	organization
PractitionerRole	[location][practitionerrole-location]	address, address-postalcode, address-city, address-state, organization, type
PractitionerRole	[network][practitionerrole-network]	name, address, partof, type
PractitionerRole	[organization][practitionerrole-organization]	name, address, partof, type
PractitionerRole	[practitioner][practitionerrole-practitioner]	name
PractitionerRole	[service][practitionerrole-service]	service-category, organization, location

Bulk Data

The HL7 FHIR Bulk Data Access Implementation Guide (4.0.0-ballot) defines mechanisms for exchanging large datasets of FHIR resources. Plan-Net directories may contain large numbers of insurance plans, networks, providers, locations, and healthcare services. Bulk Data provides an efficient alternative to retrieving this information through individual FHIR RESTful queries.

Plan-Net servers SHOULD support one or both of the following Bulk Data mechanisms:

• Bulk Export: Enables a Data Consumer to request and retrieve directory information from a Plan-Net server using an asynchronous export operation.
• Bulk Publish: Enables a Data Provider to publish directory information as downloadable files for retrieval by multiple Data Consumers without requiring each consumer to initiate a separate export.

Implementations supporting either mechanism SHALL conform to the applicable requirements of the Bulk Data Access IG.

Plan-Net Bulk Data Resources

A Plan-Net Bulk Data dataset SHOULD include all applicable resources conforming to the Plan-Net profiles defined in this IG, including the following FHIR resource types:

Resource Type	Description
InsurancePlan	Insurance products and their associated provider networks.
Organization	Payers, provider organizations, facilities, and networks.
OrganizationAffiliation	Relationships between organizations, including network participation.
Practitioner	Individual healthcare practitioners.
PractitionerRole	Practitioner roles, specialties, practice locations, and network participation.
HealthcareService	Healthcare services provided by organizations and practitioners.
Location	Physical and virtual service locations, including geographic coverage areas.
Endpoint	Electronic service endpoints associated with directory entities.

The dataset SHOULD include sufficient related resources to allow Data Consumers to resolve references and reconstruct the relationships between insurance plans, networks, providers, healthcare services, locations, and endpoints.

Resources included in a Bulk Data dataset SHALL conform to the applicable Plan-Net profiles and requirements defined in this IG.

Bulk Export

Plan-Net servers supporting Bulk Export SHOULD support the System Level Export operation:

POST [base]/$export

The system-level export enables Data Consumers to retrieve Plan-Net directory information, including resources that are not associated with individual patients.

For Bulk Export:

• The server SHALL support exporting all eight Plan-Net resource types listed above.
• The server SHOULD support the _type parameter to allow Data Consumers to request specific resource types.
• The server SHOULD support the _since parameter to allow Data Consumers to retrieve resources updated since a specified point in time, consistent with the Bulk Data Access IG.
• The server SHOULD include resources of the requested types that are necessary to represent the directory information within the scope of the export.
• The server SHALL implement the applicable Bulk Data Export kick-off, status, and file retrieval interactions as defined in the Bulk Data Access IG.

Exported resources are delivered in newline-delimited JSON (NDJSON) files, with the file locations identified in the Bulk Data Export completion manifest.

Bulk Publish

Plan-Net servers supporting Bulk Publish SHOULD implement the Bulk Publish mechanism defined in the Bulk Data Access IG.

Bulk Publish allows a Data Provider to make Plan-Net directory data available through a published manifest and associated downloadable resource files. Unlike Bulk Export, the Data Provider determines the contents of the published dataset, and multiple Data Consumers may retrieve the same published files.

For Bulk Publish:

• The Data Provider SHALL support publishing all eight Plan-Net resource types listed above, as applicable to the directory.
• The Data Provider SHALL make a Bulk Publish manifest available through an HTTP GET endpoint terminating in $bulk-publish, as defined in the Bulk Data Access IG.
• The manifest SHALL identify the downloadable files containing the published FHIR resources.
• The published files SHALL conform to the applicable file format, access, and retrieval requirements of the Bulk Data Access IG.
• The Data Provider SHOULD update the published dataset regularly to reflect changes to directory information.

Bulk Publish also supports incremental updates, allowing Data Providers to publish changes to directory information without requiring Data Consumers to download the entire dataset each time. Implementations MAY use this capability to distribute additions, modifications, and deletions to directory resources.

A draft CapabilityStatement for Bulk Publish is available on the Artifacts page of this specification. The CapabilityStatement uses rest.operation to declare $bulk-publish, without requiring conventional FHIR resource-level REST interactions. This is consistent with the ballot's allowance for a simple HTTP server to host Bulk Publish. This will likely be updated when Bulk Data 4.0.0 is updated with it's own Bulk Publish CapabilityStatement, which the authors agreed to add during ballot reconciliation.

Bulk Data Security and Authorization

Plan-Net directory information is generally intended to be publicly accessible. Bulk Data implementations SHOULD provide unauthenticated access to public directory data, consistent with the privacy and security requirements of this IG.

When authentication or authorization is required, implementations SHALL follow the applicable security requirements of the Bulk Data Access IG, including its guidance for SMART Backend Services Authorization.