R4 Ballot #1 (Mixed Normative/Trial use) Current Build
This page was published as part of FHIR v3.3.0: R4 Ballot #1 : Mixed Normative/Trial use (First Normative ballot). It has been superceded by R4 . For a full list of available versions, see the Directory of published versions .
Financial Management Work Group Maturity Level : N/A Ballot Standards Status : Informative Security Category : Patient Compartments : Not linked to any defined compartments

Mappings for the contract resource (see Mappings to Other Standards for further information & status).

Contract
    status FiveWs.status
    contentDerivative FiveWs.what[x]
    type FiveWs.what[x]
    subType FiveWs.what[x]
    term FiveWs.what[x]
        issued FiveWs.recorded
        applies FiveWs.done[x]
        type FiveWs.what[x]
        subType FiveWs.what[x]
            type FiveWs.what[x]
            decision FiveWs.what[x]
                entity[x] FiveWs.what[x]
                effectiveTime FiveWs.done[x]
                quantity FiveWs.what[x]
                unitPrice FiveWs.what[x]
                factor FiveWs.what[x]
                points FiveWs.what[x]
                net FiveWs.what[x]
            securityLabel FiveWs.what[x]             actor FiveWs.actor         action FiveWs.what[x]         actionReason             intent FiveWs.why[x]
        group FiveWs.what[x]
        type FiveWs.actor
        party FiveWs.author
        signature FiveWs.author
    friendly FiveWs.what[x]
        content[x] FiveWs.what[x]
    legal FiveWs.what[x]
        content[x] FiveWs.what[x]
    rule FiveWs.what[x]
        content[x] FiveWs.what[x]
Contract Request
    identifier Request.identifier
    status Request.status
    issued Request.authoredOn
    applies Request.occurrence[x]
    subject Request.subject
    type Request.code
        identifier Request.identifier
        issued Request.authoredOn
        applies Request.occurrence[x]
        type Request.code
            topic Event.context
            actor             type Request.performer
        actionReason             intent Request.reasonCode
        party Request.requester
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             relationship FinancialContract.code
            code             periodType FinancialContract.code
            period FinancialContract.activityTime
            dataPeriod             usePeriod 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         action Participation
            actor             type RIM Role, Participation Type classes
            role                 role RoleClass, RoleCode, ParticipationType, ParticipationFunction codes
        action Maps to multiple ActClass and ActCode Concept Domains and Code Systems.         actionReason             intent 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.