Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile.

Data Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.

• If the minimum cardinality of an element is greater than 0 – i.e. the element is 'required', then the element SHALL be present in the instance and SHALL have a value unless:
• The profile explicitly declares the dataAbsentReason extension or other extension for the element, in which case an extension can be present in place of the value.
• The profile is inherited from U.S. Core, in which case a dataAbsentReason extension can be sent in place of the value even where dataAbsentReason is not explicitly declared in the profile.

Data Consumers SHALL interpret missing data elements within resource instances as data not being present in the Data Source's systems or was not deemed to be shareable with the Data Consumer for privacy or other business reasons.

Where the value set for an element includes concepts such as "unknown", "refused to answer", "not available" or where dataAbsentReason is explicitly referenced in a profile, then Data Sources SHALL use these values/that extension to communicate the reason for missing data.

Data Consumers SHALL be able to process resource instances containing data elements that have extensions in place of a value where such extensions are declared as part of the profile.

Systems are free to include additional data - and Data Consumers SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements.

For any other references not formally defined in a US Core profile, the referenced resource SHOULD be a US Core profile if a US Core profile exists for the resource type.

When the payer responds to an Eligibility Inquiry indicating that the patient has coverage, the payer SHALL include exactly one 2000A loop repetition such that:

• The NM1-01 is populated with PR.
• There is exactly one PER repetition that has a URL communication number that fits the pattern below. (i.e. in exactly one of the PER04, PER06, or PER08 where the preceding Communication Qualifier Number is set to 'UR'):

Regardless of how it is retrieved, the .well-known endpoint SHALL be accessible with a simple TLS (not mutual TLS) connection and resolve to a JSON document.

As well, codes for new 'final publication' versions of specifications that already have defined base codes (following the convention of appending '#' and then the first two nodes of the version number) SHALL be treated as valid, even if not yet listed in this specification.

In situations where an endpoint turns out to not be functional, client systems MAY choose to re-query the .well-known endpoint and/or to re-run the eligibility check to see if the end point has changed.

All Da Vinci IGs that define CapababilityStatements setting expectations for support for certain FHIR interactions, operations, or other exchange mechanisms SHALL include a 'design' section that explains the IG's choice of exchange architecture in terms of the decision tree found in the FHIR core specification.

The performer SHALL include the target payer for the $member-match and the recipient SHALL include the initiator of the $member-match.

As a rule, all Coverage elements available SHOULD be populated, even if not all might be strictly necessary to identify the member because rules can vary from insurer to insurer about which pieces of information are necessary to uniquely identify a member.

After a successful $member-match the requesting system SHALL then use the UMB provided by the target payer in the Patient.identifier field in any subsequent transactions with the same system.

If the requesting system was a payer with coverage for the member, the receiving system SHOULD create a linkage between their own member information and the Coverage provided by the requesting system.

For privacy reasons, the 'CoverageToLink' SHOULD NOT include any data elements not marked as mustSupport in the Coverage profile.

The Coverage and Consent references SHALL be 'local' references (i.e. starting with "Patient/" rather than "http"), SHALL be resolved to the parameter with the name "MemberPatient", and SHALL refer to the same id.

Servers SHALL monitor for and take measures to prevent brute force attacks where the same or similar set of demographics are repeatedly searched with differing card information in an attempt to achieve a match when the card information is unknown.

A maximum of a SINGLE unique match SHALL be returned.

No match SHALL return a 422 status code.

Multiple matches SHALL return a 422 status code.

If consent is provided, inability to comply with consent requirements SHALL return a 422 status code

Any 422 response codes SHOULD be accompanied by an OperationOutcome that indicates the specific nature of the failure.

The recipient of a member match SHOULD store the parameters of the consent (Validity Period, Scope etc.) to enable the authorization server to evaluate the consent before issuing a token for data access during subsequent requests.

The following table lists the various agent codes and what resource types are appropriate. These recommendations SHOULD be followed

| element | Allowed target resources |

| transmitter | This could be Patient, RelatedPerson, Practitioner or PractitionerRole or Organization. A second transmitter could capture the specific Device used | | enterer | Patient, RelatedPerson, Practitioner or PractitionerRole | | performer | could be anything | | author | could be anything | | verifier | generally only Practitioner or PractitionerRole | | legal | Only Practitioner or PractitionerRole | | attester | Patient, RelatedPerson, Practitioner or PractitionerRole | | informant | Patient, RelatedPerson, Practitioner or PractitionerRole | | custodian | usually Organization, could also be Device, Practitioner or PractitionerRole | | assembler | usually a Device, could be Practitioner or PractitionerRole | ——————————————

Provenance.agent.onBehalfOf is only relevant in certain circumstances:

• onBehalfOf SHOULD NOT be populated if RelatedPerson is acting on behalf of the Patient. (Because that is the assumption and there is already a link to the Patient on that resource)
• onBehalfOf SHOULD NOT be populated with an Organization if the agent is Practitioner - use PractitionerRole instead (even if it is a contained PractitionerRole)
• onBehalfOf SHOULD NOT be populated with an Organization if the agent is PractitionerRole unless PractitionerRole is pointing to an organization and the onBehalfOf is different (i.e. Dr. Smith for Clinic A did something on behalf of clinic B)
• It is unusual for onBehalfOf to be populated if the agent is Patient or RelatedPerson
• onBehalfOf SHOULD NOT be populated with an Organization if it is the same as Device.owner

IGs derived from HRex SHOULD all reference this section, though they can qualify and supplement the content here as appropriate for the specific technologies they are using, and the threat environment and privacy considerations involved in their specific use case.

All implementations of any Da Vinci FHIR Implementation Guides (IG) SHALL meet all current relevant Federal and State statutes and regulations regarding security and privacy.

All IGs SHALL use applicable technical standards required by current regulations published by the Centers for Medicare and Medicaid Services (CMS) and the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC) (allowing for voluntary use through the SVAP) unless an exception has been granted.

All IGs and implementations SHOULD follow the current Da Vinci Guiding Principles.

All IGs and implementations SHALL support patient/member consent and/or treatment of sensitive information consistent with Federal and State statutes and regulations.

All IGs and implementations SHOULD support the consent and data sharing policies of trading partners involved in the exchange that are more protective so long as policies are consistent with or more restrictive than Federal and State statutes and regulations.

All FHIR Implementation Guides SHOULD follow the FHIR Security guidance and FHIR Implementer's Safety guidance as defined in the relevant FHIR specification (e.g. Release 4.1.0) where applicable and not superseded by this Section or specific IG requirements.

to meet the statutes, regulations, and guiding principles above, consent directives and security labels MAY be considered and used.

When exchanging Protected Health Information (PHI) between entities, the exchange SHOULD use the current version and SHALL use either current or the immediately prior release of Transport Level Security (TLS) as specified by the current release of National Institute of Standards and Technology (NIST) guidelines (SP 800-52).

TLS SHALL be implemented as per RFC8705.

• When the identity of the requesting or receiving party is important, implementations SHOULD use one or more of the following as defined in the specific Da Vinci IG:

1. theSMART App Launch Authorization,
2. mutually authenticated TLS,
3. theFAST HL7 UDAP Security for Scalable Registration, Authentication, and Authorization IG, or
4. the OAuth Server to Server Authentication as defined inSMART Back-end Services.§

When using OAuth (either through SMART or UDAP), OAuth tokens issued SHALL be tied to the client system's certificate.

When mutual TLS is used, it SHALL be done in accordance with RFC8705

The TLS authorization mechanism SHALL be PKI-Mutual TLS (i.e. not self-signed certificates)

Signing options SHALL use URIs, not DNS, IP, email, etc.

If mutual TLS is used with OAuth, the OAuth tokens SHALL be bound to the client system's certificate (and are therefore not shareable)

Where permitted by law and in accordance with legal requirements, systems SHALL always support release of additionally protected information.

Implementations SHALL ensure that release of the information without explicit request of the patient/member is based on organization policy consistent with Federal and State regulations.

Information Source systems SHALL log all IDs, access rights, requests, and exchanges.

Information Source systems SHALL verify rights of the requestor to have access to the member's/patient's record.

For Da Vinci, systems that use polling SHALL check for new/updated information at least once per business day and SHOULD check for information at least once per hour during

Polling systems SHOULD NOT query more often than every 15 minutes unless there is an urgent change they are monitoring for.

Implementers of this Da Vinci IG who choose to support Subscription SHALL comply with the Subscription Backport IG for the purpose of monitoring Tasks.

Systems supporting subscription SHALL support the rest-hook channel mechanism, though they might choose to support other channel approaches.

Systems using subcription SHALL support id-only, though they can also support other content approaches.

If search is used, systems MAY use _include=Task:output to retrieve the referenced results as well.