View raw Markdown
type: resourceresource: Contract

Contract

Introduction

Scope and Usage

This resource allows for the instantiation of various types of legally enforceable agreements or policies as shareable, consumable, and executable artifacts as well as precursory content upon which instances may be based or derivative artifacts supporting management of their basal instance. The resource is general enough to encode broad range of legal artifacts such as:

Contracts are promises or understandings that are enforceable by law in case of any violation or breech by any involved party or organization. A Contract instance may be a unilateral mandate such as a policy, or a unilateral, bilateral, or multilateral agreement, which impacts the influence of the parties over the terms of the agreement, and the burdens and risks incurred.

Contract Resource may be typed to support multiple types of domain policies and contractual agreements, and specializations of those types.

A Contract instance must include at least one term with an offer, which obligates the offerer to or not to do, perform, or effectuate some action in exchange for some consideration in return from the offeree, e.g., another obligatory action or non-action, or an asset.

The Contract action element follows the Request Pattern to describe the proposal, plan, or order to effectuate the obligatory service or activity specified in a term’s offer. The Contract action may reference and specify the roles for one or more target entities, the requesters, and performers. By following the Request Pattern, the Contract provides the criteria needed to assess whether the contract obligations have been enforced, for example, in the case of a privacy policy, by an access control system.

The Contract asset element supports detailed description of the consideration being exchanged in a Contract instance or the satisfaction of a policy imperative such as the obligation to render aid as required by local law.

The Contract valuedItem element supports detailed description of the monetary worth of a Contract asset being marketed, the price of products being sold, or the property taxes required under a jurisdictional tax law.

A Contract may be used as a content derivative, which contains the minimal content derived from the basal information source at a specific stage in its lifecycle, which is needed for management and communications about the basal information source. For example, the metadata used to register a Contract’s characteristics and retrieval address in a federated registry/repository exchange ecosystem.

In addition to other uses of derivatives, the Contract Resource may function simply as the computable representation of the executed contract, which may be the attached to the Contract Resource as the 'legally binding' scanned paper contract attachment or referenced location, or as the 'friendly' electronic form such as an html page or a QuestionnaireResponse.

By using the Contract linkID elements, which are associated with key Contract elements, a Contract Resource may be automatically populated with the values expressed in a related QuestionnaireResponse.

Note that the Contract Resource may be considered the legally binding contract only if it is intended to be the sole 'executed' encoding of this contract, and includes the legally binding signatures. I.e., even if the Contract Resource is populated based on content in a hard-copy contract or an electronic contract form intended to collect both the content and the signature of relevant parties to the contract, if contracting parties have agreed or acknowledged that the Contract Resource conveys the binding and enforceable legal contract and that it is fully traceable to the forms used to collect its content, meeting the legal concept of being within the 'four corners of a contract', i.e., that the meaning of the contract, will, or deed is represented solely by this instance of the Contract Resource. This usage could be implemented with digital ledger technology to form a 'smart contract' to the extent that an instance supports elements critical to computable algorithms intended to achieve some output.

Where the Consent resource applies, the Consent resource should be used. Where a Contract exists for a consent directive then if a Consent for this also exists the Consent shall reference the Contract.

Boundaries and Relationships

Background and Context

Implementers should be familiar with legal concepts, Ricardian Contracts and have a general knowledge of recording agreements.

This Resource supports tracking of the progress of a Contract instance during its lifecycle as a 'legal instrument' from inception as a draft, possibly based on a definitional contract template to negotiations and the various permutation on term elements that may occur, on to execution. Then it follows the Contract as enforceable obligations, which may be breached, disputed, or modified, until the Contract reaches renewal, termination, or revocation. This is flow is orthogonal to the Contract.status, which tracks the progress of the documentation of the Contract whether it is definitional, a derivative, or an instance. The legal state value set specifies the characteristics of these states based on legal definitions.

Legal State Machine

StructureDefinition

Elements (Simplified)

Mappings

Resource Packs

list-Contract-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="Contract-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

contract-event-mapping-exceptions.xml

Divergent Elements

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=This element is labeled as a modifier because the status contains codes that mark the contract as not currently valid or active.

The recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance.

It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system.

The recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance.

It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system.

Unmapped Elements

contract-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

contract-request-mapping-exceptions.xml

Divergent Elements

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=This element is labeled as a modifier because the status contains codes that mark the contract as not currently valid or active.

Unmapped Elements