DaVinci PDEX Plan Net
0.1.0 - STU1

DaVinci PDEX Plan Net, published by HL7 Financial Management Working Group. This is not an authorized publication; it is the continuous build for version 0.1.0). 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 Notes

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

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.

Conformance Requirements

The conformance verbs - SHALL, SHOULD, MAY - used in this guide are defined in [FHIR Conformance Rules](https://trifolia-fhir-dev.lantanagroup.com/http:/hl7.org/fhir/R4/conformance-rules.html).

Must Support

When querying and reading the Plan-Net Profiles defined in this IG, Must Support on any profile data element **SHALL** be interpreted as follows:
Health Plan API Requirements
* Health Plan API actors **SHALL** be capable of populating all data elements as part of the query results. * In situations where information on a particular data element is not present and the cardinality is 0.. , the Health Plan API actors **SHALL NOT** include the data elements in the resource instance returned as part of the query results. * In situations where information on a particular data element is not present and the cardinality is >0.. **SHALL** send the reason for the missing information using values (such as nullFlavors) from the value set where they exist or use the dataAbsentReason extension.
Application Requirements
* Application actors **SHALL** be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. * Application actors **SHOULD** be capable of displaying the data elements for human use or storing the information for other purposes. * When querying Health Plan API actors, Application actors **SHALL** interpret missing data elements within resource instances as data not present in the Health Plan API actors system. * Consumer App actors **SHALL** be able to process resource instances containing data elements asserting missing information.

Relationship to US Core

This guide used a corresponding US Core profile as its base profile in all cases where such a profile existed and wasn't in conflict with the Payer data models supporting a provider directory (i.e. Location, Organization and Practitioner). Conflicts prevented the use of the USCore PractitionerRole profile, but all compatible aspects of the USCore PractitionerRole profile were retained in the corresponding Plan-Net profile. </div>