Generated Narrative: StructureDefinition provider-parameters-multi-member-match-bundle-out Name Flags Card. Type Description & Constraints Parameters 0..* Parameters Operation Request or Response #xD; Slices for parameter 1..3 BackboneElement Provider member match response groups Slice: Unordered, Closed by value:name #xD; parameter:MatchedMembers 1..1 BackboneElement Operation Parameter #xD; name 1..1 string Successfully matched and authorized members Required Pattern: MatchedMembers #xD; value[x] 0..0 If parameter is a data type #xD; resource 1..1 ProviderMemberMatchGroup Group of matched members #xD; parameter:NonMatchedMembers 0..1 BackboneElement Operation Parameter #xD; name 1..1 string Members not found Required Pattern: NonMatchedMembers #xD; value[x] 0..0 If parameter is a data type #xD; resource 0..1 ProviderMemberNoMatchGroup Group of non-matched members #xD; parameter:ConsentConstrainedMembers 0..1 BackboneElement Operation Parameter #xD; name 1..1 string Members who opted out of Provider Access Required Pattern: ConsentConstrainedMembers #xD; value[x] 0..0 If parameter is a data type #xD; <a href="StructureDefinition-provider-parameters-multi-member-match-bundle-out-definitions.html#Parameters.parameter:ConsentConstrainedMembers.resource" title="A Group resource conforming to the [Member Opt-Out Group profile](StructureDefinition-pdex-member-opt-out.html) containing references to members who have opted out of Provider Access API data sharing. The payer has successfully matched these members but cannot provide access due to the member's consent preferences.">resource 0..1 MemberOptOut Group of members who opted out #xD; Documentation for this format
HL7 International / Financial Management
Mark Scrimshire (mark.scrimshire@onyxhealth.io)
HL7 International - Financial Management
A Parameters profile defining the result of a $bulk-member-match operation performed by a payer system in response to a provider request. The response indicates which members were successfully matched and authorized for provider access, which were not found, and which have opted out of Provider Access API data sharing.
Used by permission of HL7 International, all rights reserved Creative Commons License
This resource is a non-persisted resource used to pass information into and back from an [operation](http://hl7.org/fhir/R4/operations.html). It has no other use, and there is no RESTful endpoint associated with it.
The parameters that may be used are defined by the OperationDefinition resource.
The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
The only time that a resource does not have an id is when it is being submitted to the server using a create operation.
The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
A set of rules under which this content was created
A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.
Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.
This element is labeled as a modifier because the implicit rules may provide additional knowledge about the resource that modifies it's meaning or interpretation
The base language in which the resource is written.
Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
Response groups categorizing the results of the provider bulk member match request: matched members (authorized for access), non-matched members (not found), and consent-constrained members (opted out of Provider Access).
A parameter must have one and only one of (value, resource, part)
(part.exists() and value.empty() and resource.empty()) or (part.empty() and (value.exists() xor resource.exists()))
(exists(f:resource) or exists(f:part) or exists(f:*[starts-with(local-name(.), 'value')])) and not(exists(f:*[starts-with(local-name(.), 'value')])) and exists(f:resource))) and not(exists(f:*[starts-with(local-name(.), 'value')])) and exists(f:part))) and not(exists(f:part) and exists(f:resource))
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
Extensions that cannot be ignored even if unrecognized
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R4/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
The name of the parameter (reference to the operation definition).
When resolving references in resources, the operation definition may specify how references may be resolved between parameters. If a reference cannot be resolved between the parameters, the application should fall back to it's general resource resolution methods.
Only one level of nested parameters is allowed.
A parameter passed to or received from the operation.
Successfully matched and authorized members
Group of members who were successfully matched in the payer's system and are authorized for provider access based on the provider's treatment attestation.
A Group resource containing references to successfully matched member records. Each member entry includes a reference to the payer's Patient resource and an extension containing the submitted member demographics from the provider.
This group represents members for whom the payer has successfully matched the provider's submitted demographics to a member in their system, verified the treatment attestation is valid, and determined the member has not opted out of Provider Access API. The provider can now use these matched Patient IDs to request bulk data access.
Entity[determinerCode="GRP" or determinerCode="GRP_KIND"]
Group of members who could not be matched in the payer's system. This may occur if the patient demographics are incorrect, the member is not currently enrolled with the payer, or the coverage information is invalid.
A Group resource containing references to the submitted member demographics that could not be matched to any member in the payer's system.
This group helps providers identify which member match requests failed. Providers may need to verify the patient's insurance information, confirm coverage is active, or check for data entry errors in the submitted demographics or coverage details.
Members who opted out of Provider Access
Group of members who were successfully matched but have exercised their right to opt out of Provider Access API data sharing. These members have explicitly denied permission for providers to access their data through this API.
A Group resource conforming to the [Member Opt-Out Group profile](StructureDefinition-pdex-member-opt-out.html) containing references to members who have opted out of Provider Access API data sharing. The payer has successfully matched these members but cannot provide access due to the member's consent preferences.
Members in this group have affirmatively opted out of sharing their data with providers through the Provider Access API. This is distinct from non-matched members - these members exist in the payer's system and were matched, but have exercised their privacy rights to prevent data sharing. The Member Opt-Out Group profile preserves the type-level distinction between opt-out and no-match outcomes (which use the separate Provider Member No Match Group profile). Providers should not attempt to access data for these members through the Provider Access API and should use traditional methods (e.g., requesting records directly from the patient or other providers) if access to this information is needed for treatment. **Privacy default — SHOULD suppress when opt-out status is sensitive.** A member who opts out of data sharing has, by definition, indicated that they do not want their data disclosed to the requesting provider via this API; the fact of opting out is itself information about that member. Where the payer determines that disclosing opt-out status to the requesting provider — i.e., distinguishing 'opted out' from 'not matched' — would itself constitute a disclosure the member did not authorize (whether under applicable state privacy law, the member's stated preference, or the payer's privacy policy), the payer **SHOULD** suppress this `ConsentConstrainedMembers` parameter and instead include the affected members in the `NonMatchedMembers` Group, making the response indistinguishable to the requester between a true no-match and a matched-but-opted-out outcome. The cardinality on this slice is `0..1`, so suppression is conformant. Payers that determine no such concern applies **MAY** continue to populate this slice.