Conformance Expectations

Da Vinci Prior Authorization Support (PAS) FHIR IG, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.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-pas/ and changes regularly. See the Directory of published versions

Page standards status: Trial-use

Highlight text changes?

This page contains a table listing all the free-text conformance statements found in the IG. This table is provided as a useful summary for implementers for the purpose of evaluating key features and to support testing. However, reading this table alone is insufficient to understand or successfully implement the specification:

The table only includes conformance expectations expressed as free text. It does not include the computable expectations represented in capability statements, profiles, value sets, etc.
The text text in the table only includes the 'formal' requirement. It does not provide the contextual language around the statement that will be needed for successful explanation. The 'id' of each statement is a hyperlink to the place it appears in the text to assist with gathering the needed context.

A few other notes:

The ids are generally specific to the pages on which the requirements appear, but not always. If content is moved from one page to another, the id will remain the same.
While ids start as contiguous, as the specification is updated, it is possible some conformance statements will be removed, which will create a gap in the numbers. This is not an error.
Ids are not final until published in an official release. At that point, ids will not be changed.
It is possible for the text of a given rules to change somewhat from one release to another so long as the intention of the rule is the same. If the intent has a significant change, the old rule will be removed and a new one added in its place.
The actors are broken down into 'client' and 'server'. There may be multiple systems that actually compose those logical entities which will vary from implementation. It will be up to implementers to determine how the various conformance statements will apply to the actal systems in their architecture.
The categorizations are general. In practice, all 'exchange', 'ui', and 'storage' requirements are some aspect of 'processing' requirements. The categories will give hints as to the architectural layer a requirement will apply to, but there is nothing definitive implied by the category(ies) listed.

The controls at the top of the table allow filtering the content to particular requirement subsets that may be of interest.

Id Expectation Conditional? Actors Rule

SHALL
SHOULD
MAY
SHALL NOT
SHOULD NOT Yes
No
Any PAS Client
PAS Payer

§1 SHOULD ainfo-1^payer^exchange:Payers SHOULD attempt to use the initial DTR invocation to gather all relevant information relevant to the prior authorization request and only use the "additional information" approach when human review or other circumstances not known at the time of the initial DTR call require additional information to be collected.

§conf-1 SHALL PAS Payer Payers SHALL have a distinct endpoint for each different supported version (which are not inter-version compatible) of the PAS specification.

§conf-2 SHALL PAS Payer If a payer supports endpoint discovery, they SHALL have at most a single endpoint for each combination of version of the specification and coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.

§conf-3 SHALL PAS Payer If a payer does not support endpoint discovery, they SHALL expose only one PAS endpoint of each supported version capable of handling all coverages.

§conf-4 SHALL PAS Payer PA Intermediary Systems SHALL be capable of processing all data elements that are marked as Must Support on the Claim Request and Claim Inquiry.

§conf-5 SHALL NOT PAS Payer They SHALL NOT generate an error or cause the application to fail due the presence of any data element marked as Must Support.

§conf-6 SHALL PAS Payer PA Intermediary Systems SHALL be capable of returning resource instances containing any of the data elements that are marked as Must Support on the Claim Response and the Claim Inquiry Response.

§conf-7 SHALL PAS Client PA Client Systems SHALL be capable of receiving all data elements that are marked as Must Support on the Claim Response and the Claim Inquiry Response.

§conf-8 SHALL NOT PAS Client They SHALL NOT generate an error or cause the application to fail when receiving any data element that is marked as Must Support.

§conf-9 SHOULD NOT PAS Client PA Client Systems SHOULD NOT send any data elements that are not marked as Must Support.

§conf-10 MAY PAS Payer If these data elements are included in a Claim Request or Claim Inquiry, the receiving PA Intermediary System MAY ignore those elements.

§conf-11 SHALL NOT PAS Payer When processing prior auth requests and additional data submissions, PAS services SHALL NOT depend on or set expectations for the inclusion of resource instances not compliant with profiles defined in this guide, CRD, DTR, HRex, or US Core.

§conf-12 SHALL NOT PAS Payer Similarly, they SHALL NOT depend on or set expectations for the inclusion of any data elements not marked as mandatory (min cardinality >= 1) or mustSupport in those profiles.

§conf-13 MAY PAS Client
PAS Payer If the proposed change is adopted and published in the PAS continuous integration build or the CI build of one of its dependencies (e.g. US Core), implementations MAY, by mutual agreement, pre-adopt the use of those additional profiles and/or mustSupport data elements and not be considered in violation of #1 above.

§conf-14 SHALL NOT PAS Client
PAS Payer Where cardinality and other constraints present in profiles allow data elements to be omitted, PAS compliant systems SHALL NOT treat the omission of those elements as a conformance error.

§conf-15 SHALL PAS Client
PAS Payer PAS clients and services SHALL use standard PAS data elements (i.e. elements found within PAS-defined or inherited profiles and marked as mandatory or mustSupport) to communicate needed data if such elements are intended to convey such information.

§conf-16 SHALL NOT
MAY PAS Client
PAS Payer PAS implementing organizations SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within PAS and inherited data structures, but MAY submit change requests to PAS, HRex, or US Core requesting that additional guidance be provided to implementers on data structure usage to increase consistency across implementations.

§prof-3 SHALL PAS Client
PAS Payer If a quantity code is present, it SHALL use the X12 quantity units.

§prof-ben-1 SHALL PAS Payer X12 standard requires no dash for ZIP+4 codes and that intermediaries SHALL expect the dash to be present and SHALL remove the dash, if present, when converting the zip code to meet the X12 standard.

§prof-sub-1 SHALL PAS Payer X12 standard requires no dash for ZIP+4 codes and that intermediaries SHALL expect the dash to be present and SHALL remove the dash, if present, when converting the zip code to meet the X12 standard.

§spec-1 SHALL X PAS Client
PAS Payer Along with the profiles defined in the PAS implementation guide, implementations SHALL also support the relevant US Core profiles for supplementary information.

§spec-2 SHOULD X PAS Client
PAS Payer They SHOULD support any other profiles relevant to the types of prior authorizations they process.

§spec-3 SHOULD X PAS Client
PAS Payer Clients and Servers supporting this implementation guide SHOULD also comply with the Da Vinci Coverage Requirements Discovery (CRD) and Documentation Templates and Rules (DTR) implementation guides.

§spec-4 SHALL X PAS Client
PAS Payer Every system claiming conformance to this IG SHALL comply with the Security and Privacy page in the Da Vinci HRex guide.

§spec-5 SHALL X PAS Payer If a payer supports endpoint discovery, they SHALL have at most a single endpoint for each coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.

§spec-6 SHALL X PAS Payer If a payer does not support endpoint discovery, they SHALL expose only one PAS endpoint capable of handling all coverages.

§spec-7 SHOULD PAS Payer All of this SHOULD happen synchronously with a maximum of 15 seconds between the user initiating the prior authorization request and seeing the resulting response - i.e. including network transmission time for request and response.

§spec-8 SHALL PAS Client A subscription-based mechanism SHALL be used by the client to be informed of updates to the authorization.

§spec-9 SHOULD NOT PAS Payer
PAS Client NOTE: The Claim Inquiry response does not include all of the information that can be returned in a request response, such as any request for additional information, so the inquire operation SHOULD NOT be used by the client while waiting for final results.

§spec-10 MAY PAS Payer Provider and EHR Vendor organizations MAY leverage the payer registry developed by PDex (which will eventually fold into the national directory under FAST) as a means of determining which endpoints exist for which payers as candidates for configuration.

§spec-11 SHALL PAS Payer The Bundle SHALL be encoded in JSON.

§spec-12 SHALL PAS Payer The first entry in the Bundle SHALL be a Claim resource complying with the profile defined in this IG to ensure the content is sufficient to appropriately populate an X12N/005010X217 message.

§spec-13 SHALL PAS Payer Additional Bundle entries SHALL be populated with any resources referenced by the Claim resource (and any resources referenced by those resources, fully traversing all references and complying with all identified profiles).

§spec-14 SHALL PAS Payer Each unique resource instance SHALL only appear at most once in the Bundle.

§spec-15 SHOULD PAS Payer Only one unique resource instance SHOULD be created to represent the same information. In other words, avoid creating multiple Practitioner instances for the same person.

§spec-16 SHALL PAS Payer Bundle.entry.fullUrl values SHALL be:

§spec-17 SHALL PAS Payer All GUIDs used SHALL be unique, including across independent prior authorization submissions - with the exception that the same resource instance being referenced in distinct prior authorization request Bundles can have the same GUID.

§spec-18 SHALL PAS Payer Relevant resources referenced by those "supporting information" resources SHALL also be included (e.g. prescriber Practitioner and Medication for a MedicationRequest).

§spec-19 SHALL PAS Payer Any such resource that has a US Core profile SHALL comply with the relevant US Core profiles.

§spec-20 SHALL PAS Payer All "supporting information" resources included in the Bundle SHALL be pointed to by the Claim resource using the Claim.supportingInfo.valueReference element.

§spec-21 SHOULD PAS Payer To attach non-FHIR instance data such as PDFs, CDAs, JPGs, a DocumentReference instance SHOULD be used.

§spec-22 SHALL PAS Payer The Claim.supportingInfo.sequence for each entry SHALL be unique within the Claim.

§spec-23 SHALL PAS Payer All resources SHALL comply with their respective profiles.

§spec-24 SHOULD
MAY PAS Client
PAS Payer FHIR elements not marked as 'must support' MAY be included in resources within the Bundle, but client systems SHOULD have no expectation of such elements being processed by the payer unless prior arrangements have been made.

§spec-25 SHALL
MAY PAS Payer Systems that do not process such elements SHALL ignore unsupported elements unless they are 'modifier' elements, in which case the system MAY treat the presence of the element as an error.

§spec-26 SHALL PAS Client
PAS Payer In addition, the system SHALL make the entire PAS FHIR Bundle available to the intended payer.

§spec-27 MAY PAS Payer The method MAY be based on the X12 275 or another method that trading partners have agreed to use.

§spec-28 SHALL PAS Payer If the X12 275 is used for this purpose, the 275 BDS01 Filter ID Code element SHALL be set to "B64" and the CAT02 Attachment Information Format Code element SHALL be sent to "HL".

§spec-29 SHOULD PAS Payer Translation/mapping systems SHOULD be aware that if the size of the attachments as part of a claims submission would exceed the size limitations of a particular recipient, the intermediary SHOULD split the attachments into separate 275s to remain within the overall limit.

§spec-30 SHALL PAS Payer The Bundle SHALL start with a ClaimResponse entry that contains information mapped from the 278 response.

§spec-31 SHALL PAS Payer Each unique resource instance SHALL only appear at most once in the Bundle.

§spec-32 SHOULD PAS Payer Only one unique resource instance SHOULD be created to represent the same information. In other words, avoid creating multiple Practitioner instances for the same person.

§spec-33 SHALL PAS Payer When echoing back resources that are the same as were present in the prior authorization request, the system SHALL ensure that the same fullUrl and resource identifiers are used in the response as appeared in the request.

§spec-34 SHALL PAS Payer Each item returned on the PAS ClaimResponse SHALL echo the same item.sequence as that same item had on the Claim. The item.sequence element SHALL serve as the main tracing identifier of items throughout requests and responses.

§spec-35 SHALL PAS Client In the case of an error in an Operation invocation (e.g., 4XX error), the receiving system SHALL return a single OperationOutcome that details why the Bundle could not be processed.

§spec-36 SHALL PAS Payer For instances where the authorized item is a modification of the requested item, the requested item details SHALL be returned in the ClaimResponse.item with an adjudication status of A6 - 'Modified'.

§spec-37 SHALL PAS Payer The details of what was actually item SHALL be returned in the ClaimResponse.addItem.

§spec-38 SHOULD PAS Client
PAS Payer Recipients of the transactions SHOULD respond as indicated below and senders of the transaction SHOULD look for the following responses and then take appropriate actions.

§spec-39 SHALL PAS Payer All transactions in PAS are synchronous and SHALL require one of the following HTTP responses:

§spec-40 SHOULD PAS Client If an OperationOutcome is received, it may have information regarding errors that SHOULD be addressed in the future, but did not cause the transaction to fail.

§spec-41 SHOULD PAS Payer NOTE: These errors SHOULD not be returned to the provider but SHOULD be reviewed and addressed by technical staff.

§spec-42 SHOULD PAS Client Although there are no constraints on the frequency of the query, clients SHOULD ensure that no repetitive inquiries do not happen so as not to stress payer systems.

§spec-43 SHALL PAS Payer Intermediaries SHALL interpret the 'not-applicable' code as no product or service code.

§spec-44 SHALL PAS Payer This Claim Inquiry Response SHALL either reference a Claim or have a Data Absent Reason indicating why the Claim can not be referenced (eg. original claim received by fax).

§spec-45 SHOULD PAS Payer The referenced Claim instance SHOULD be returned if there is information in the Response that needs to be present can not be returned in the Claim Response instance.

§spec-46 SHALL PAS Payer the returned ClaimResponse SHALL include the current results for all submitted items, including any items changed or canceled since the original authoriation request.

§spec-47 SHALL PAS Client
PAS Payer if a specific reference number (either the REF-NT or REF-BB) is submitted and is not the 'current' number (because subsequent additions/changes/cancellations have been made to the prior authorization request), the returned record SHALL be the current authorization response - even though it no longer has the same identifier.

§spec-48 SHALL PAS Payer I.e. If a search is for a 'replaced' prior authorization, the search result SHALL include the 'current' prior authorization response for the most recent replacing prior authorization request.

§spec-49 MAY PAS Payer systems MAY withhold information about prior authorizations that are 'open' but are deemed to be not relevant to the provider (eg. prior authorization requests for sensitive care where the requesting provider is neither the ordering nor rendering provider) who is checking for the prior authorization status if not searching by a specific Claim identifier.

§spec-50 SHOULD PAS Payer In such situations the response SHOULD include an OperationOutcome warning that some prior authorizations have been suppressed and provide an alternative mechanism (e.g. telephone number) to provide further information if needed.

§spec-51 SHALL PAS Payer Implementers SHALL support subscriptions to provide the final response.

§spec-52 SHALL ^payerServers SHALL permit access to the prior authorization response to systems other than the original submitter.

§spec-53 SHALL PAS Payer They SHALL require a match on the patient member or subscriber id (identifier on the Claim.patient) plus the ordering and/or rendering provider identifier, i.e. the provider's NPI.

§spec-54 SHALL PAS Payer Implementers SHALL support the R4 Subscriptions referenced in the Subscriptions for R5 Backport Implementation Guide.

§spec-55 SHALL PAS Payer Servers supporting subscriptions SHALL expose this as part of their CapabilityStatement

§spec-56 SHALL PAS Payer Servers SHALL only support the rest-hook channel type

§spec-57 SHALL PAS Payer This Subscription SHALL conform to the PAS Subscription profile.

§spec-58 SHALL PAS Payer The Subscription filter criteria SHALL be org-identifier = [sending system identifier].

§spec-59 SHALL PAS Payer Intermediaries SHALL ensure that subscriptions to monitor a particular sending system's prior authorizations are only created or modified by that sending system.

§spec-60 SHALL PAS Payer Once the subscription has been created, the Server SHALL send a notification over the requested channel indicating that a prior authorization response submitted by the requesting provider organization has changed.

§spec-61 SHALL PAS Payer This notification SHALL include a full PAS Response Bundle.

§spec-62 SHALL PAS Client
PAS Payer Due to the inquiry not supporting all of the required information needed in a PAS response, PAS Clients and Intermediaries SHALL only support subscriptions with content='full-resource'.

§spec-63 SHOULD PAS Client When details of a submitted request change and a provider needs to request prior authorization of a different set of items, clients SHOULD submit an update to the previously submitted Claim.

§spec-64 MAY PAS Client
PAS Payer Servers MAY reject updates and require that a new request is made by providing the appropriate X12 error code.

§spec-65 SHALL PAS Payer The Claim that is being updated SHALL be referenced in the Claim.related.claim element and included in the Bundle.

§spec-66 SHALL NOT PAS Payer If that Claim instance is itself a Claim Update, its referenced Claim SHALL NOT be included.

§spec-67 SHALL PAS Payer All other referenced resources SHALL be included in the Bundle.

§spec-68 SHALL PAS Client When changing the details of the request, the Claim instance SHALL contain all item and supportingInfo entries from the original Claim and any previous update Claims with sequence values preserved, but with the current request details.

§spec-69 SHALL PAS Client
PAS Payer Cancelled entries: item and supportingInfo entries that have been removed from the request SHALL include the infoCancelled modifier extension with a valueBoolean of true in the Claim.item.modifierExtension or Claim.supportingInfo.modifierExtension element.

§spec-70 SHALL PAS Client
PAS Payer Canceled items SHALL additionally contain a certificationType extension with a code of 3 (Cancel) in the Claim.item.extension element.

§spec-71 SHALL PAS Client
PAS Payer Entries added, modified, or cancelled compared to the immediately prior version of the Claim referenced in the Claim.related.claim element SHALL contain a infoChanged extension within the Claim.item or the Claim.supportingInfo element.

§spec-72 SHALL PAS Payer The infoChanged extension for added entries SHALL have a valueCode of changed and those for modified or deleted entries SHALL have a valueCode of changed (newly marking an item as canceled is considered a 'change').

§spec-73 SHALL PAS Payer PAS systems SHALL ensure that prior authorizations that were initially pended remain available for query for at least 6 months after the anticipated completion of the services whose authorization was requested.

Id	Expectation	Conditional?	Actors	Rule
§1	SHOULD			ainfo-1^payer^exchange:Payers SHOULD attempt to use the initial DTR invocation to gather all relevant information relevant to the prior authorization request and only use the "additional information" approach when human review or other circumstances not known at the time of the initial DTR call require additional information to be collected.
§conf-1	SHALL		PAS Payer	Payers SHALL have a distinct endpoint for each different supported version (which are not inter-version compatible) of the PAS specification.
§conf-2	SHALL		PAS Payer	If a payer supports endpoint discovery, they SHALL have at most a single endpoint for each combination of version of the specification and coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.
§conf-3	SHALL		PAS Payer	If a payer does not support endpoint discovery, they SHALL expose only one PAS endpoint of each supported version capable of handling all coverages.
§conf-4	SHALL		PAS Payer	PA Intermediary Systems SHALL be capable of processing all data elements that are marked as Must Support on the Claim Request and Claim Inquiry.
§conf-5	SHALL NOT		PAS Payer	They SHALL NOT generate an error or cause the application to fail due the presence of any data element marked as Must Support.
§conf-6	SHALL		PAS Payer	PA Intermediary Systems SHALL be capable of returning resource instances containing any of the data elements that are marked as Must Support on the Claim Response and the Claim Inquiry Response.
§conf-7	SHALL		PAS Client	PA Client Systems SHALL be capable of receiving all data elements that are marked as Must Support on the Claim Response and the Claim Inquiry Response.
§conf-8	SHALL NOT		PAS Client	They SHALL NOT generate an error or cause the application to fail when receiving any data element that is marked as Must Support.
§conf-9	SHOULD NOT		PAS Client	PA Client Systems SHOULD NOT send any data elements that are not marked as Must Support.
§conf-10	MAY		PAS Payer	If these data elements are included in a Claim Request or Claim Inquiry, the receiving PA Intermediary System MAY ignore those elements.
§conf-11	SHALL NOT		PAS Payer	When processing prior auth requests and additional data submissions, PAS services SHALL NOT depend on or set expectations for the inclusion of resource instances not compliant with profiles defined in this guide, CRD, DTR, HRex, or US Core.
§conf-12	SHALL NOT		PAS Payer	Similarly, they SHALL NOT depend on or set expectations for the inclusion of any data elements not marked as mandatory (min cardinality >= 1) or mustSupport in those profiles.
§conf-13	MAY		PAS Client PAS Payer	If the proposed change is adopted and published in the PAS continuous integration build or the CI build of one of its dependencies (e.g. US Core), implementations MAY, by mutual agreement, pre-adopt the use of those additional profiles and/or mustSupport data elements and not be considered in violation of #1 above.
§conf-14	SHALL NOT		PAS Client PAS Payer	Where cardinality and other constraints present in profiles allow data elements to be omitted, PAS compliant systems SHALL NOT treat the omission of those elements as a conformance error.
§conf-15	SHALL		PAS Client PAS Payer	PAS clients and services SHALL use standard PAS data elements (i.e. elements found within PAS-defined or inherited profiles and marked as mandatory or mustSupport) to communicate needed data if such elements are intended to convey such information.
§conf-16	SHALL NOT MAY		PAS Client PAS Payer	PAS implementing organizations SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within PAS and inherited data structures, but MAY submit change requests to PAS, HRex, or US Core requesting that additional guidance be provided to implementers on data structure usage to increase consistency across implementations.
§prof-3	SHALL		PAS Client PAS Payer	If a quantity code is present, it SHALL use the X12 quantity units.
§prof-ben-1	SHALL		PAS Payer	X12 standard requires no dash for ZIP+4 codes and that intermediaries SHALL expect the dash to be present and SHALL remove the dash, if present, when converting the zip code to meet the X12 standard.
§prof-sub-1	SHALL		PAS Payer	X12 standard requires no dash for ZIP+4 codes and that intermediaries SHALL expect the dash to be present and SHALL remove the dash, if present, when converting the zip code to meet the X12 standard.
§spec-1	SHALL	X	PAS Client PAS Payer	Along with the profiles defined in the PAS implementation guide, implementations SHALL also support the relevant US Core profiles for supplementary information.
§spec-2	SHOULD	X	PAS Client PAS Payer	They SHOULD support any other profiles relevant to the types of prior authorizations they process.
§spec-3	SHOULD	X	PAS Client PAS Payer	Clients and Servers supporting this implementation guide SHOULD also comply with the Da Vinci Coverage Requirements Discovery (CRD) and Documentation Templates and Rules (DTR) implementation guides.
§spec-4	SHALL	X	PAS Client PAS Payer	Every system claiming conformance to this IG SHALL comply with the Security and Privacy page in the Da Vinci HRex guide.
§spec-5	SHALL	X	PAS Payer	If a payer supports endpoint discovery, they SHALL have at most a single endpoint for each coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.
§spec-6	SHALL	X	PAS Payer	If a payer does not support endpoint discovery, they SHALL expose only one PAS endpoint capable of handling all coverages.
§spec-7	SHOULD		PAS Payer	All of this SHOULD happen synchronously with a maximum of 15 seconds between the user initiating the prior authorization request and seeing the resulting response - i.e. including network transmission time for request and response.
§spec-8	SHALL		PAS Client	A subscription-based mechanism SHALL be used by the client to be informed of updates to the authorization.
§spec-9	SHOULD NOT		PAS Payer PAS Client	NOTE: The Claim Inquiry response does not include all of the information that can be returned in a request response, such as any request for additional information, so the inquire operation SHOULD NOT be used by the client while waiting for final results.
§spec-10	MAY		PAS Payer	Provider and EHR Vendor organizations MAY leverage the payer registry developed by PDex (which will eventually fold into the national directory under FAST) as a means of determining which endpoints exist for which payers as candidates for configuration.
§spec-11	SHALL		PAS Payer	The Bundle SHALL be encoded in JSON.
§spec-12	SHALL		PAS Payer	The first entry in the Bundle SHALL be a Claim resource complying with the profile defined in this IG to ensure the content is sufficient to appropriately populate an X12N/005010X217 message.
§spec-13	SHALL		PAS Payer	Additional Bundle entries SHALL be populated with any resources referenced by the Claim resource (and any resources referenced by those resources, fully traversing all references and complying with all identified profiles).
§spec-14	SHALL		PAS Payer	Each unique resource instance SHALL only appear at most once in the Bundle.
§spec-15	SHOULD		PAS Payer	Only one unique resource instance SHOULD be created to represent the same information. In other words, avoid creating multiple Practitioner instances for the same person.
§spec-16	SHALL		PAS Payer	Bundle.entry.fullUrl values SHALL be:
§spec-17	SHALL		PAS Payer	All GUIDs used SHALL be unique, including across independent prior authorization submissions - with the exception that the same resource instance being referenced in distinct prior authorization request Bundles can have the same GUID.
§spec-18	SHALL		PAS Payer	Relevant resources referenced by those "supporting information" resources SHALL also be included (e.g. prescriber Practitioner and Medication for a MedicationRequest).
§spec-19	SHALL		PAS Payer	Any such resource that has a US Core profile SHALL comply with the relevant US Core profiles.
§spec-20	SHALL		PAS Payer	All "supporting information" resources included in the Bundle SHALL be pointed to by the Claim resource using the Claim.supportingInfo.valueReference element.
§spec-21	SHOULD		PAS Payer	To attach non-FHIR instance data such as PDFs, CDAs, JPGs, a DocumentReference instance SHOULD be used.
§spec-22	SHALL		PAS Payer	The Claim.supportingInfo.sequence for each entry SHALL be unique within the Claim.
§spec-23	SHALL		PAS Payer	All resources SHALL comply with their respective profiles.
§spec-24	SHOULD MAY		PAS Client PAS Payer	FHIR elements not marked as 'must support' MAY be included in resources within the Bundle, but client systems SHOULD have no expectation of such elements being processed by the payer unless prior arrangements have been made.
§spec-25	SHALL MAY		PAS Payer	Systems that do not process such elements SHALL ignore unsupported elements unless they are 'modifier' elements, in which case the system MAY treat the presence of the element as an error.
§spec-26	SHALL		PAS Client PAS Payer	In addition, the system SHALL make the entire PAS FHIR Bundle available to the intended payer.
§spec-27	MAY		PAS Payer	The method MAY be based on the X12 275 or another method that trading partners have agreed to use.
§spec-28	SHALL		PAS Payer	If the X12 275 is used for this purpose, the 275 BDS01 Filter ID Code element SHALL be set to "B64" and the CAT02 Attachment Information Format Code element SHALL be sent to "HL".
§spec-29	SHOULD		PAS Payer	Translation/mapping systems SHOULD be aware that if the size of the attachments as part of a claims submission would exceed the size limitations of a particular recipient, the intermediary SHOULD split the attachments into separate 275s to remain within the overall limit.
§spec-30	SHALL		PAS Payer	The Bundle SHALL start with a ClaimResponse entry that contains information mapped from the 278 response.
§spec-31	SHALL		PAS Payer	Each unique resource instance SHALL only appear at most once in the Bundle.
§spec-32	SHOULD		PAS Payer	Only one unique resource instance SHOULD be created to represent the same information. In other words, avoid creating multiple Practitioner instances for the same person.
§spec-33	SHALL		PAS Payer	When echoing back resources that are the same as were present in the prior authorization request, the system SHALL ensure that the same fullUrl and resource identifiers are used in the response as appeared in the request.
§spec-34	SHALL		PAS Payer	Each item returned on the PAS ClaimResponse SHALL echo the same item.sequence as that same item had on the Claim. The item.sequence element SHALL serve as the main tracing identifier of items throughout requests and responses.
§spec-35	SHALL		PAS Client	In the case of an error in an Operation invocation (e.g., 4XX error), the receiving system SHALL return a single OperationOutcome that details why the Bundle could not be processed.
§spec-36	SHALL		PAS Payer	For instances where the authorized item is a modification of the requested item, the requested item details SHALL be returned in the ClaimResponse.item with an adjudication status of A6 - 'Modified'.
§spec-37	SHALL		PAS Payer	The details of what was actually item SHALL be returned in the ClaimResponse.addItem.
§spec-38	SHOULD		PAS Client PAS Payer	Recipients of the transactions SHOULD respond as indicated below and senders of the transaction SHOULD look for the following responses and then take appropriate actions.
§spec-39	SHALL		PAS Payer	All transactions in PAS are synchronous and SHALL require one of the following HTTP responses:
§spec-40	SHOULD		PAS Client	If an OperationOutcome is received, it may have information regarding errors that SHOULD be addressed in the future, but did not cause the transaction to fail.
§spec-41	SHOULD		PAS Payer	NOTE: These errors SHOULD not be returned to the provider but SHOULD be reviewed and addressed by technical staff.
§spec-42	SHOULD		PAS Client	Although there are no constraints on the frequency of the query, clients SHOULD ensure that no repetitive inquiries do not happen so as not to stress payer systems.
§spec-43	SHALL		PAS Payer	Intermediaries SHALL interpret the 'not-applicable' code as no product or service code.
§spec-44	SHALL		PAS Payer	This Claim Inquiry Response SHALL either reference a Claim or have a Data Absent Reason indicating why the Claim can not be referenced (eg. original claim received by fax).
§spec-45	SHOULD		PAS Payer	The referenced Claim instance SHOULD be returned if there is information in the Response that needs to be present can not be returned in the Claim Response instance.
§spec-46	SHALL		PAS Payer	the returned ClaimResponse SHALL include the current results for all submitted items, including any items changed or canceled since the original authoriation request.
§spec-47	SHALL		PAS Client PAS Payer	if a specific reference number (either the REF-NT or REF-BB) is submitted and is not the 'current' number (because subsequent additions/changes/cancellations have been made to the prior authorization request), the returned record SHALL be the current authorization response - even though it no longer has the same identifier.
§spec-48	SHALL		PAS Payer	I.e. If a search is for a 'replaced' prior authorization, the search result SHALL include the 'current' prior authorization response for the most recent replacing prior authorization request.
§spec-49	MAY		PAS Payer	systems MAY withhold information about prior authorizations that are 'open' but are deemed to be not relevant to the provider (eg. prior authorization requests for sensitive care where the requesting provider is neither the ordering nor rendering provider) who is checking for the prior authorization status if not searching by a specific Claim identifier.
§spec-50	SHOULD		PAS Payer	In such situations the response SHOULD include an OperationOutcome warning that some prior authorizations have been suppressed and provide an alternative mechanism (e.g. telephone number) to provide further information if needed.
§spec-51	SHALL		PAS Payer	Implementers SHALL support subscriptions to provide the final response.
§spec-52	SHALL			^payerServers SHALL permit access to the prior authorization response to systems other than the original submitter.
§spec-53	SHALL		PAS Payer	They SHALL require a match on the patient member or subscriber id (identifier on the Claim.patient) plus the ordering and/or rendering provider identifier, i.e. the provider's NPI.
§spec-54	SHALL		PAS Payer	Implementers SHALL support the R4 Subscriptions referenced in the Subscriptions for R5 Backport Implementation Guide.
§spec-55	SHALL		PAS Payer	Servers supporting subscriptions SHALL expose this as part of their CapabilityStatement
§spec-56	SHALL		PAS Payer	Servers SHALL only support the rest-hook channel type
§spec-57	SHALL		PAS Payer	This Subscription SHALL conform to the PAS Subscription profile.
§spec-58	SHALL		PAS Payer	The Subscription filter criteria SHALL be org-identifier = [sending system identifier].
§spec-59	SHALL		PAS Payer	Intermediaries SHALL ensure that subscriptions to monitor a particular sending system's prior authorizations are only created or modified by that sending system.
§spec-60	SHALL		PAS Payer	Once the subscription has been created, the Server SHALL send a notification over the requested channel indicating that a prior authorization response submitted by the requesting provider organization has changed.
§spec-61	SHALL		PAS Payer	This notification SHALL include a full PAS Response Bundle.
§spec-62	SHALL		PAS Client PAS Payer	Due to the inquiry not supporting all of the required information needed in a PAS response, PAS Clients and Intermediaries SHALL only support subscriptions with content='full-resource'.
§spec-63	SHOULD		PAS Client	When details of a submitted request change and a provider needs to request prior authorization of a different set of items, clients SHOULD submit an update to the previously submitted Claim.
§spec-64	MAY		PAS Client PAS Payer	Servers MAY reject updates and require that a new request is made by providing the appropriate X12 error code.
§spec-65	SHALL		PAS Payer	The Claim that is being updated SHALL be referenced in the Claim.related.claim element and included in the Bundle.
§spec-66	SHALL NOT		PAS Payer	If that Claim instance is itself a Claim Update, its referenced Claim SHALL NOT be included.
§spec-67	SHALL		PAS Payer	All other referenced resources SHALL be included in the Bundle.
§spec-68	SHALL		PAS Client	When changing the details of the request, the Claim instance SHALL contain all item and supportingInfo entries from the original Claim and any previous update Claims with `sequence` values preserved, but with the current request details.
§spec-69	SHALL		PAS Client PAS Payer	Cancelled entries: item and supportingInfo entries that have been removed from the request SHALL include the infoCancelled modifier extension with a valueBoolean of `true` in the Claim.item.modifierExtension or Claim.supportingInfo.modifierExtension element.
§spec-70	SHALL		PAS Client PAS Payer	Canceled items SHALL additionally contain a certificationType extension with a code of 3 (Cancel) in the Claim.item.extension element.
§spec-71	SHALL		PAS Client PAS Payer	Entries added, modified, or cancelled compared to the immediately prior version of the Claim referenced in the Claim.related.claim element SHALL contain a infoChanged extension within the Claim.item or the Claim.supportingInfo element.
§spec-72	SHALL		PAS Payer	The infoChanged extension for added entries SHALL have a valueCode of `changed` and those for modified or deleted entries SHALL have a valueCode of `changed` (newly marking an item as canceled is considered a 'change').
§spec-73	SHALL		PAS Payer	PAS systems SHALL ensure that prior authorizations that were initially pended remain available for query for at least 6 months after the anticipated completion of the services whose authorization was requested.