Generated Narrative: Requirements fromNarrative These requirements apply to the following actors: Data Consumer Member Match Client Discovery Server HRex IG Author HRex Implementer Subscription Implementer Polling Implementer Discovery Client Data Source Member Match Server conf-1 SHALL Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile. conf-2 SHALL 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 a listed exception applies. SHALL 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. conf-4 SHALL 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. conf-5 SHALL 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. conf-6 SHALL 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. conf-7 SHOULD-NOT 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. conf-8 SHOULD 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 meeting specified requirements. SHALL 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'): ep-2 SHALL 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. ep-3 SHALL 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. ep-4 MAY 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. ex-1 SHALL 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. mm-1 SHALL The performer SHALL include the target payer for the $member-match and the recipient SHALL include the initiator of the $member-match. mm-2 SHOULD 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. mm-3 SHALL 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. mm-4 SHOULD 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. mm-5 SHOULD-NOT For privacy reasons, the 'CoverageToLink' SHOULD NOT include any data elements not marked as mustSupport in the Coverage profile. mm-6 SHALL 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. mm-7 SHALL 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. mm-8 SHALL A maximum of a SINGLE unique match SHALL be returned. mm-9 SHALL No match SHALL return a 422 status code. mm-10 SHALL Multiple matches SHALL return a 422 status code. mm-11 SHALL If consent is provided, inability to comply with consent requirements SHALL return a 422 status code mm-12 SHOULD Any 422 response codes SHOULD be accompanied by an OperationOutcome that indicates the specific nature of the failure. mm-13 SHOULD 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. Implementations SHOULD follow the recommendations on which resources should be referenced from which data element. SHOULD 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 SHOULD NOT be used in certain circumstances. SHOULD-NOT 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 sec-1 SHOULD 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. sec-2 SHALL 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. sec-3 SHALL 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. sec-4 SHOULD All IGs and implementations SHOULD follow the current Da Vinci Guiding Principles. sec-5 SHALL All IGs and implementations SHALL support patient/member consent and/or treatment of sensitive information consistent with Federal and State statutes and regulations. sec-6 SHOULD 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. sec-7 SHOULD 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. sec-8 MAY to meet the statutes, regulations, and guiding principles above, consent directives and security labels MAY be considered and used. sec-9 SHALL, SHOULD 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). sec-10 SHALL 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 preferred authorization mechanisms. SHOULD 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: theSMART App Launch Authorization, mutually authenticated TLS, theFAST HL7 UDAP Security for Scalable Registration, Authentication, and Authorization IG, or the OAuth Server to Server Authentication as defined inSMART Back-end Services.§ sec-12 SHALL When using OAuth (either through SMART or UDAP), OAuth tokens issued SHALL be tied to the client system's certificate. sec-13 SHALL When mutual TLS is used, it SHALL be done in accordance with RFC8705 sec-14 SHALL The TLS authorization mechanism SHALL be PKI-Mutual TLS (i.e. not self-signed certificates) sec-15 SHALL Signing options SHALL use URIs, not DNS, IP, email, etc. sec-16 SHALL If mutual TLS is used with OAuth, the OAuth tokens SHALL be bound to the client system's certificate (and are therefore not shareable) sec-17 SHALL Where permitted by law and in accordance with legal requirements, systems SHALL always support release of additionally protected information. sec-18 SHALL 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. sec-19 SHALL Information Source systems SHALL log all IDs, access rights, requests, and exchanges. sec-20 SHALL Information Source systems SHALL verify rights of the requestor to have access to the member's/patient's record. task-1 SHALL, SHOULD 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 task-2 SHOULD-NOT Polling systems SHOULD NOT query more often than every 15 minutes unless there is an urgent change they are monitoring for. task-3 SHALL Implementers of this Da Vinci IG who choose to support Subscription SHALL comply with the Subscription Backport IG for the purpose of monitoring Tasks. task-4 SHALL Systems supporting subscription SHALL support the rest-hook channel mechanism, though they might choose to support other channel approaches. task-5 SHALL Systems using subcription SHALL support id-only, though they can also support other content approaches. task-6 MAY If search is used, systems MAY use _include=Task:output to retrieve the referenced results as well.
HL7 International / Clinical Interoperability Council
Conformance statements found throughout the narrative of the IG consolidated into this computable resource for traceability purposes
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 a listed exception applies.
* 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](http://hl7.org/fhir/R4/conformance-rules.html#isModifier).
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 meeting specified requirements.
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](http://hl7.org/fhir/R4/capabilitystatement.html) 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](OperationDefinition-member-match.html) 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](http://hl7.org/fhir/R4/operationoutcome.html) 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.
Implementations SHOULD follow the recommendations on which resources should be referenced from which data element.
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 SHOULD NOT be used in certain circumstances.
`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](https://www.healthit.gov/isa/standards-version-advancement-process#:~:text=ONC%20has%20established%20the%20voluntary,of%20Certification%20requirement%20(%C2%A7%20170.405))) unless an exception has been granted.
All IGs and implementations **SHOULD** follow the current [Da Vinci Guiding Principles](davinci-guiding-principles.html).
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)](https://tools.ietf.org/html/rfc8446) as specified by the current release of [National Institute of Standards and Technology (NIST) guidelines (SP 800-52)](https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final).
TLS **SHALL** be implemented as per [RFC8705](https://datatracker.ietf.org/doc/html/rfc8705).
When the identity of the requesting or receiving party is important, implementations SHOULD use one or more of the preferred authorization mechanisms.
* 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. the[SMART App Launch Authorization](https://hl7.org/fhir/smart-app-launch/index.html), 1. mutually authenticated TLS, 1. the[FAST HL7 UDAP Security for Scalable Registration, Authentication, and Authorization IG](https://hl7.org/fhir/us/udap-security), or 1. the OAuth Server to Server Authentication as defined in[SMART Back-end Services](https://hl7.org/fhir/smart-app-launch/backend-services.html).§
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](https://datatracker.ietf.org/doc/html/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.