This page is part of the FHIR Specification (v3.2.0: R4 Ballot 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3 R2
Mappings for the contract resource.
| Contract | FinancialContract |
| identifier | FinancialContract id |
| status | Act.status |
| contentDerivative | Maps partially to several v3 codes: ActClass: REG (registration) Description: Represents the act of maintaining information about the registration of its associated registered subject. The subject can be either an Act or a Role, and includes subjects such as lab exam definitions, drug protocol definitions, prescriptions, persons, patients, practitioners, and equipment.
The registration may have a unique identifier - separate from the unique identification of the subject - as well as a core set of related participations and act relationships that characterize the registration event and aid in the disposition of the subject information by a receiving system. Observation: VERIF (Verification) Description: An act which describes the process whereby a 'verifying party' validates either the existence of the Role attested to by some Credential or the actual Vetting act and its details. TRFR (transfer) Description: The act of transferring information without the intent of imparting understanding about a topic to the subject that is the recipient or holder of the transferred information where the participation association must be RCV or HLD. _ActDetectedIssueManagementCode [abstract term] Description: Codes dealing with the management of Detected Issue observations. _ActInformationAccessContextCode [abstract term] Description: Concepts conveying the context in which authorization given under jurisdictional law, by organizational policy, or by a patient consent directive permits the collection, access, use or disclosure of specified patient health information. _ActListCode [abstract term]vDescription: Provides codes associated with ActClass value of LIST (working list). RefusalReasonCode [abstract term] Description:
Description: Identifies why a request to add (or activate) a record is being refused. Examples include the receiving system not able to match the identifier and find that record in the receiving system, having no permission, or a detected issue exists which precludes the requested action. |
| issued | Act.availabilityTime. Definition: A time expression specifying when an Observation, Procedure, or other Act occurs, or, depending on the mood, is supposed to occur, scheduled to occur, etc. The activityTime includes the times of component actions (such as preparation and clean-up). For Procedures and SubstanceAdministrations, the activityTime can provide a needed administrative function by providing a more inclusive time to be anticipated in scheduling. UsageNotes:The activityTime is primarily of administrative rather than clinical use. The clinically relevant time is the effectiveTime. When an observation of a prior symptom is made, the activityTime describes the time the observation is made, as opposed to effectiveTime which is the time the symptom is reported to have occurred. Thus the activityTime may be entirely different from the effectiveTime of the same Act. However, even apart from clinical use cases, designers should first consider effectiveTime as the primary relevant time for an Act. ActivityTime indicates when an Act occurs, not when it is recorded. |
| applies | Act.effectiveTime Definition: The clinically or operationally relevant time of an act, exclusive of administrative activity. |
| subject | RoleClass, RoleCode |
| authority | Organization Role. CONCEPT DOMAIN: OrganizationEntityType Description: Further classifies entities of EntityClass ORG. |
| domain | TERR (territory of authority) Description: Relates a place entity (player) as the region over which the scoper (typically an Organization) has certain authority (jurisdiction). For example, the Calgary Regional Health Authority (scoper) has authority over the territory "Region 4 of Alberta" (player) in matters of health.
Entity Class = Place? A physical place or site with its containing structure. May be natural or man-made. The geographic position of a place might or might not be constant.
CONCEPT DOMAIN: TerritoryEntityType Description: A territorial entity that may be cited as the body over which an agency exercises jurisdiction, or which defines a sphere in which a party has a particular responsibility. CONCEPT DOMAIN: OrganizationEntityType
Description: Further classifies entities of EntityClass ORG. |
| type | Maps to multiple ActClass and ActCode Concept Domains and Code Systems such as the following: In the ActClass Concept Domain: ActClassPolicy. In the ActCode Concept Domain: ActContractType, which generalizes ActFinancialContractType, ActCoverageType, ActBillingArrangementType. ActConsentType, which generalizes ActDataConsentType; ActFinancialParticipationConsentType; ActInformationAccessCode; AdvanceBeneficiaryNoticeType. ActPolicyType, which generalizes: ActPrivacyPolicyType, ActSensitivityPrivacyPolicyType, ActSecurityPolicyType. In the ActClass Code System: CNTRCT (contract) Description: An agreement of obligation between two or more parties that is subject to contractual law and enforcement, lwhich generalizes FCNTRCT (financial contract) and COV (coverage). POLICY (policy) - Description: A mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by one party on: The activity of another party; the behavior of another party; or the manner in which an act is executed. LEAF CONCEPTS: JURISPOL (jurisdictional policy) Description:A mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by a jurisdiction on: The activity of another party; the behavior of another party; or the manner in which an act is executed.Examples:A jurisdictional mandate regarding the prescribing and dispensing of a particular medication. A jurisdictional privacy or security regulation dictating the manner in which personal health information is disclosed. A jurisdictional requirement that certain services or health conditions are reported to a monitoring program, e.g., immunizations, methadone treatment, or cancer registries.ORGPOL (organizational policy)Examples:A clinical or research protocols imposed by a payer, a malpractice insurer, or an institution to which a provider must adhere. A mandate imposed by a denominational institution for a provider to provide or withhold certain information from the patient about treatment options.SCOPOL (scope of practice policy)Description:An ethical or clinical obligation, requirement, rule, or expectation imposed or strongly encouraged by organizations that oversee particular clinical domains or provider certification which define the boundaries within which a provider may practice and which may have legal basis or ramifications.Examples:An ethical obligation for a provider to fully inform a patient about all treatment options. An ethical obligation for a provider not to disclose personal health information that meets certain criteria, e.g., where disclosure might result in harm to the patient or another person. The set of health care services which a provider is credentialed or privileged to provide. STDPOL (standard of practice policy) Examples:A payer may require a prescribing provider to adhere to formulary guidelines. An institution may adopt clinical guidelines and protocols and implement these within its electronic health record and decision support systems. CONS (consent)Description: The Consent class represents informed consents and all similar medico-legal transactions between the patient (or his legal guardian) and the provider. Examples are informed consent for surgical procedures, informed consent for clinical trials, advanced beneficiary notice, against medical advice decline from service, release of information agreement, etc. The details of consents vary. Often an institution has a number of different consent forms for various purposes, including reminding the physician about the topics to mention. Such forms also include patient education material. In electronic medical record communication, consents thus are information-generating acts on their own and need to be managed similar to medical activities. Thus, Consent is modeled as a special class of Act. The "signatures" to the consent document are represented electronically through Participation instances to the consent object. Typically an informed consent has Participation.typeCode of "performer", the healthcare provider informing the patient, and "consenter", the patient or legal guardian. Some consent may associate a witness or a notary public (e.g., living wills, advanced directives). In consents where a healthcare provider is not required (e.g. living will), the performer may be the patient himself or a notary public. |
| subType | Examples of Contract or Policy subtypes in ActCodes:_ActCoverageTypeCode Definition: Set of codes indicating the type of insurance policy or program that pays for the cost of benefits provided to covered parties. Generalizes: _ActInsurancePolicyCode; _ActInsuranceTypeCode; ActProgramTypeCode. _ActPolicyType Description:Types of policies that further specify the ActClassPolicy value set. Generalizes: _ActPrivacyPolicy; _ActPrivacyLaw; _InformationSensitivityPolicy; ActTrustPolicyType; SecurityPolicy. _ActInvoiceAdjudicationPaymentGroupCode Description: Codes representing adjustments to a Payment Advice such as retroactive, clawback, garnishee, etc., e.g. RECOV (recovery) Description: Retroactive adjustment such as fee rate adjustment due to contract negotiations. |
| term | RIM mechanism for grouping or nesting rules, which are likely Acts and Observations. |
| identifier | Act or Observation identifier. |
| issued | Act availabilityTime |
| applies | Act effectiveTime |
| type | See Contract.term mapping. |
| subType | See Contract.topic mapping. |
| offer | Document |
| topic | Includes many ActClass, ActCode, RoleClass, RoleCode, EntityClass, EntityCode, ParticipationType codes from HL7 concept domains and code systems. For example, RoleCode: HLD (held entity) Description: Entity that is currently in the possession of a holder (scoper), who holds, or uses it, usually based on some agreement with the owner. MANU (manufactured product) Description: Scoped by the manufacturer. OWN (owned entity) Description: An Entity (player) for which someone (scoper) is granted by law the right to call the material (player) his own. This entitles the scoper to make decisions about the disposition of that material. WRTE (warranted product) Description:
A role a product plays when a guarantee is given to the purchaser by the seller (scoping entity) stating that the product is reliable and free from known defects and that the seller will repair or replace defective parts within a given time limit and under certain conditions. |
| type | See Contract.term mapping. |
| decision | ActCode: _ActConsentDirective [abstract term] Description: Specifies the type of agreement between one or more grantor and grantee in which rights and obligations related to one or more shared items of interest are allocated. Usage Note: Such agreements may be considered "consent directives" or "contracts" depending on the context, and are considered closely related or synonymous from a legal perspective. |
| text | Document.text |
| linkId | .outboundRelationship[typeCode=DEFN].target[classCode=OBS, moodCode=DEFN].id |
| asset | FinancialContract.paymentTermsCode |
| class | FinancialContract.code |
| code | FinancialContract.code |
| period | FinancialContract.activityTime |
| dataPeriod | FinancialContract.effectiveTime |
| data | FinancialContract.paymentTermsCode |
| meaning | FinancialContract.code |
| reference | Document |
| valuedItem | COCT_RM440000UV09 ValuedItem classCode INVE |
| entity[x] | COCT_RM440000UV09 ValuedItem code |
| identifier | COCT_RM440000UV09 ValuedItem id |
| effectiveTime | COCT_RM440000UV09 ValuedItem effectiveTime |
| quantity | COCT_RM440000UV09 ValuedItem unitQuantity |
| unitPrice | COCT_RM440000UV09 ValuedItem unitPriceAmt |
| factor | COCT_RM440000UV09 ValuedItem factorNumber |
| points | COCT_RM440000UV09 ValuedItem pointNumber |
| net | COCT_RM440000UV09 ValuedItem netAmt |
| securityLabel | See Contract.securityLabel mapping. |
| agent | Participation |
| actor | RIM Role, Participation Type classes |
| role | RoleClass, RoleCode, ParticipationType, ParticipationFunction codes |
| action | Maps to multiple ActClass and ActCode Concept Domains and Code Systems. |
| actionReason | Examples from ActReason Concept Domains: ActCoverageReason Description:Codes used to specify reasons or criteria relating to coverage provided under a policy or program. May be used to convey reasons pertaining to coverage contractual provisions, including criteria for eligibility, coverage limitations, coverage maximums, or financial participation required of covered parties. ActInformationPrivacyReason Description: The rationale or purpose for an act relating to the management of personal information, such as disclosing personal tax information for the purpose of complying with a court order. ClinicalResearchObservationReason Definition: Specifies the reason that a test was performed or observation collected in a clinical research study. SafetyInvestigationReportReasonType Description: Possible reasons generating a report providing information developed during the investigation of an adverse event or a product problem. ControlActReason Description: Indicates the motivation, cause or rationale of an Act which results in a trigger event. NonPerformanceReasonCode Description: The reason the action was not performed, e.g. why the medication was not taken. If an action was not performed, it is often clinically important to know why the action was not taken. RefusalReasonCode Description: Identifies why a request to add (or activate) a record is being refused. Examples include the receiving system not able to match the identifier and find that record in the receiving system, having no permission, or a detected issue exists which precludes the requested action.
Examples from HL7 ActReason Code System: QUALIMP (quality improvement) Description:Operational activities conducted for the purposes of improving the quality of an activity, product, or service. _PatientProfileQueryReasonCode Description: A collection of concepts identifying why the patient's profile is being queried. _ActInformationManagementReason Description:The rationale or purpose for an act relating to information management, such as archiving information for the purpose of complying with an enterprise data retention policy. _ActInvalidReason (ActInvalidReason) Description: Types of reasons why a substance is invalid for use. _NonPerformanceReasonCode Description: The reason the action wasn't performed, e.g. why the medication was not taken. If an action wasn"t performed, it is often clinically important to know why the action wasn"t taken. |
| group | RIM Grouping or Nesting mechanisms |
| signer | Participation |
| type | RoleClass, RoleCode, ParticipationType, ParticipationFunction class codes. |
| party | Role Class |
| signature | Participation.signatureCode :: CD (0..1) Definition: Whether the participant has attested participation through a signature, or whether such a signature is needed. Examples: A surgical Procedure act object (representing a procedure report) requires a signature of the performing and responsible surgeon, and possibly other participants; The participant intends to provide a signature. Participation.signatureText :: ED (0..1) Definition: A textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode. UsageNotes: The signature can be represented either inline or by reference according to the ED data type. Typical cases are
1) Paper-based signatures: the ED data type may refer to a document or other resource that can be retrieved through an electronic interface to a hardcopy archive. 2) Electronic signature: this attribute can represent virtually any electronic signature scheme. 3) Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc. Examples: 1) An "author" participant assumes accountability for the truth of the Act statement to the best of his knowledge. 2) An information recipient only attests to the fact that he or she has received the information. |
| friendly | LanguageCommunication |
| content[x] | Act.text Definition: A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act. |
| legal | LanguageCommunication |
| content[x] | Example: Act.text of an Act coded as with ActPrivacyLaw, ActPolicy code |
| rule | LanguageCommunication |
| content[x] | Computable Policy Consent [Observation: templateId 2.16.840.1.113883.3.445.16] This template is used to represent an alternative representation of the Privacy Consent Directive (e.g.,ODRL, XrML, XACML) as a computer-readable set of rules. An implementation may use any appropriate representations of the privacy consent in addition to the "ConsentDirectiveStructuredDefinition" which uses the Clinical Template structure to express the elements of a consent directive in an interoperable way.
1. SHALL contain exactly one [1..1] templateId ( CONF-CD-16 ) such that it
a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.445.16"
2. SHALL contain exactly one [1..1] @moodCode="DEF" (CodeSystem: 2.16.840.1.113883.5.1001 HL7ActMood) (CONF:14912)
3. SHALL contain exactly one [1..1] code (CONF:9139)/@code="57016-8" Privacy Policy Acknowledgement Document (CodeSystem: 2.16.840.1.113883.6.1 LOINC) (CONF:9138)
It specifies the LOINC code corresponding to "Privacy Policy Acknowledgement Document", it is fixed at this value.
4. SHOULD contain zero or more [0..*] value with @xsi:type="ANY" (CONF:9140) The value contains the computable representation of the policy. This may be a standard-based access control or attribute control based policy (See
"References"). Computable Policy Consent example
<!-- Sample computable policy language representation -->
<entryRelationship typeCode="COMP">
<templateId root="2.16.840.1.113883.3.445.16" />
<observationMedia classCode="OBS" moodCode="EVN">
<value mediaType="text/xml" representation="TXT"> ... </value>
</observationMedia>
</entryRelationship> |
| legallyBinding[x] | DocumentCompletion code system AU (authenticated) Description: A completion status in which a document has been signed manually or electronically by one or more individuals who attest to its accuracy. No explicit determination is made that the assigned individual has performed the authentication. While the standard allows multiple instances of authentication, it would be typical to have a single instance of authentication, usually by the assigned individual. |
|
Propose a change 
Financial