Da Vinci Health Record Exchange (HRex)
1.2.0-snapshot - STU 1.2 United States of America flag

Da Vinci Health Record Exchange (HRex), published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 1.2.0-snapshot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ehrx/ and changes regularly. See the Directory of published versions

Conformance Details

Page standards status: Trial-use

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:

  1. 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.
  2. 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 a number of discrete instances allowing tighter control over conformance expectations in downstreem systems. 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. As well, a computable representation (XML and JSON) of the requirements can be found here.

IdExpectationConditional?Actor(s)Category(ies)Rule
 SHALL
 SHOULD
 SHOULD NOT
 MAY		 Yes
 No
 Any		 Data Consumer
 Data Source
 Discovery Client
 Discovery Server
 HRex IG Author
 HRex Implementer
 Member Match Client
 Member Match Server
 Polling Implementer
 Subscription Implementer		 business
 exchange
 processing
 storage
§conf-1SHALL Data SourceexchangeData Sources SHALL be capable of populating the data element when sharing resources compliant with the profile.
§conf-2SHALL Data ConsumerexchangeData Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
§conf-3SHALLXData SourceexchangeIf 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.
§conf-4SHALL Data ConsumerprocessingData 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-5SHALLXData SourceexchangeWhere 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-6SHALL Data ConsumerexchangeData 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-7SHOULD NOT Data ConsumerexchangeSystems 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-8SHOULDXData SourceexchangeFor 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.
§ep-1SHALLXDiscovery ServerexchangeWhen 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.
§ep-2SHALL Discovery ServerexchangeRegardless 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-3SHALLXDiscovery ClientprocessingAs 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-4MAYXDiscovery ClientexchangeIn 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-1SHALL HRex IG AuthorbusinessAll 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-1SHALLXMember Match Client
Member Match Server		exchangeThe performer SHALL include the target payer for the $member-match and the recipient SHALL include the initiator of the $member-match.
§mm-2SHOULDXMember Match Client
Member Match Server		exchangeAs 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-3SHALLXMember Match ClientexchangeAfter 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-4SHOULDXMember Match ServerexchangeIf 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-5SHOULD NOT Member Match ClientexchangeFor privacy reasons, the 'CoverageToLink' SHOULD NOT include any data elements not marked as mustSupport in the Coverage profile.
§mm-6SHALL Member Match ClientexchangeThe 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-7SHALL Member Match ServerexchangeServers 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-8SHALL Member Match ServerexchangeA maximum of a SINGLE unique match SHALL be returned.
§mm-9SHALL Member Match ServerexchangeNo match SHALL return a 422 status code.
§mm-10SHALL Member Match ServerexchangeMultiple matches SHALL return a 422 status code.
§mm-11SHALLXMember Match ServerexchangeIf consent is provided, inability to comply with consent requirements SHALL return a 422 status code
§mm-12SHOULD Member Match ServerexchangeAny 422 response codes SHOULD be accompanied by an OperationOutcome that indicates the specific nature of the failure.
§mm-13SHOULD Member Match ServerexchangeThe 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.
§prov-1SHOULD HRex ImplementerexchangeImplementations SHOULD follow the recommendations on which resources should be referenced from which data element.
§prov-2SHOULD NOTXHRex ImplementerexchangeProvenance.agent.onBehalfOf SHOULD NOT be used in certain circumstances.
§sec-1SHOULD HRex IG AuthorbusinessIGs 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-2SHALL HRex Implementerexchange
processing		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-3SHALLXHRex IG AuthorbusinessAll 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-4SHOULD HRex Implementer
HRex IG Author		business
exchange
processing		All IGs and implementations SHOULD follow the current Da Vinci Guiding Principles.
§sec-5SHALL HRex Implementerexchange
processing		All IGs and implementations SHALL support patient/member consent and/or treatment of sensitive information consistent with Federal and State statutes and regulations.
§sec-6SHOULDXHRex Implementerexchange
processing		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-7SHOULDXHRex Implementerexchange
processing		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-8MAY HRex Implementerexchangeto meet the statutes, regulations, and guiding principles above, consent directives and security labels MAY be considered and used.
§sec-9SHALL
SHOULD		 HRex ImplementerexchangeWhen 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-10SHALL HRex ImplementerexchangeTLS SHALL be implemented as per RFC8705.
§sec-11SHOULDXHRex ImplementerexchangeWhen the identity of the requesting or receiving party is important, implementations SHOULD use one or more of the preferred authorization mechanisms.
§sec-12SHALLXHRex ImplementerexchangeWhen using OAuth (either through SMART or UDAP), OAuth tokens issued SHALL be tied to the client system's certificate.
§sec-13SHALL HRex ImplementerexchangeWhen mutual TLS is used, it SHALL be done in accordance with RFC8705
§sec-14SHALL HRex ImplementerexchangeThe TLS authorization mechanism SHALL be PKI-Mutual TLS (i.e. not self-signed certificates)
§sec-15SHALL HRex ImplementerexchangeSigning options SHALL use URIs, not DNS, IP, email, etc.
§sec-16SHALL HRex ImplementerexchangeIf mutual TLS is used with OAuth, the OAuth tokens SHALL be bound to the client system's certificate (and are therefore not shareable)
§sec-17SHALLXData SourceexchangeWhere permitted by law and in accordance with legal requirements, systems SHALL always support release of additionally protected information.
§sec-18SHALL Data SourceexchangeImplementations 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-19SHALL Data SourcestorageInformation Source systems SHALL log all IDs, access rights, requests, and exchanges.
§sec-20SHALL Data SourceprocessingInformation Source systems SHALL verify rights of the requestor to have access to the member's/patient's record.
§task-1SHALL
SHOULD		XPolling ImplementerexchangeFor 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-2SHOULD NOTXPolling ImplementerexchangePolling systems SHOULD NOT query more often than every 15 minutes unless there is an urgent change they are monitoring for.
§task-3SHALLXSubscription ImplementerexchangeImplementers of this Da Vinci IG who choose to support Subscription SHALL comply with the Subscription Backport IG for the purpose of monitoring Tasks.
§task-4SHALLXSubscription ImplementerexchangeSystems supporting subscription SHALL support the rest-hook channel mechanism, though they might choose to support other channel approaches.
§task-5SHALLXSubscription ImplementerexchangeSystems using subcription SHALL support id-only, though they can also support other content approaches.
§task-6MAYXSubscription ImplementerexchangeIf search is used, systems MAY use _include=Task:output to retrieve the referenced results as well.