This wiki has undergone a migration to Confluence found Here

February 19, 2016 Financial Management Work Group Conference Call

From HL7Wiki
Revision as of 21:40, 23 February 2016 by Kathleenconnor (talk | contribs) (→‎Minutes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Return to Financial Management Home Page

Conference Call Schedule

  • Occurs on Fridays, 4 PM Eastern
  • Phone Number: +1 770-657-9270 Participant Passcode: 686300# (alternative for US if the first number doesn't work: +1 888-321-4501)

Attendees

Member Name
Kathleen Connor Co-chair x
Beat Heggli Co-chair
Paul Knapp Co-chair
John Moehrke Security Co-Chair x
Lorraine Constable
Andy Stechishin x
Mark Scrimshire
Grahame Grieve
Corey Spears

Agenda

For example, specifying how policies or obligations shall constrain actions and action reasons permitted or denied on a all or a subset of the Contract.topic (e.g., all or a portion of property being transferred by the contract), agents (e.g., who can resell, assign interests, or alter the property being transferred by the contract), actions, and action reasons; or with respect to Contract.terms, stipulating, extending, or limiting the Contract.period of applicability or valuation of items under consideration.

The Contract.signer applies a signature to the Contract.binding referenced resource, which is the documentation that is the legal "source of truth". The Contract.signer may delegate, such as a legally recognized personal representative, or have a delegate assigned e.g., by a court of law, to actually sign the Contract, such as a trustee in the case of incompetence. The Contract.signer delegatee is specified by the "whoReference" in the Contract.signer.signature. That Signature may reference back to the Contract.signer.party with the "onBehalfOfReference".

  • FM CP 9533Change Contract signature datatype from string to FHIR Signature datatype, and change cardinality to 1..*. Current CP text: "Change Contract signature datatype from string to FHIR Signature datatype and change cardinality to 1..*. Provide documentation in the element description and front matter explaining that the Signature.who type may be a signer on behalf of a signing party. This addresses the use case where an App or mobile device signs a contract/consent directive on behalf of the organization accountable for complying with the contract/consent directive. Make Signature 1..* for use cases in which there may be more than one signature. Examples: Company policy requires that a signer of a contract having a value over $1 million must have two signatures, the grantor/grantee party to the contract, and a second signature from the company's CFO. Signer is a minor with divorces parents who have joint custody. Policy requires that all legal guardians of a minor who signs a consent directive must co-sign that consent directive." However, there now appears to be several approaches across P&S FHIR artifacts to indicate delegation of signing authority beyond just implementation guidance described in this CP:
  • John indicated that theAuditEvent.agent.requestor was intended to indicate delegation, but it's not clear how to differentiate delegatee/delegator from a bag of AuditEvent.agents. Definition = "Indicator that the user is or is not the requestor, or initiator, for the event being audited." [1..1] boolean. Requirements = This value is used to distinguish between requestor-users and recipient-users. For example, one person may initiate a report-output to be sent to another user. re can only be one initiator. Comment: If the initiator is not clear, then do not choose any one agent as the initiator.
  • Provenance.actor/agent has relatedAgenty to track delegation. Definition = "A relationship between two the agents referenced in this resource. This is defined to allow for explicit description of the delegation between agents. For example, this human author used this device, or one person acted on another's behest." Provenance.agent.relatedAgent.target is defined as "An internal reference to another agent listed in this provenance by its identifier."
  • Security CP 9563 Add onBehalfOf to Signature datatype CP Text = To support delegation of signing authority add: "onBehalfOf" [0..1]; "onBehalfOfURI" type = uri; "onBehalfOfReference" type = Reference(Practitioner | RelatedPerson | Patient | Device | Organization). 

Add “onBehalfOf" definition of " = Agent who delegated signing or did not have the legal standing to sign for themselves (such as a child) e.g., a party to a contract, consent directive, witness, attester, etc. Implementer documentation that the References of a Resource element associated with Signature datatype can constrain the onBehalfOfReference" type if, e.g., the Resource element Reference is only Organization, then the onBehalfOfReference can only be an Organization Resource. Add "onBehalfOfReference" definition: The delegator for which the “who” Reference, e.g., a Device, signed on behalf of.  The delegator can only be a Referenced Resource type in the context in which the signature is used.  E.g., in a contract, where a signing party must have legal standing, by limiting Referenced resources to Organizational or Person like Resources, may be enough of a constraint to prevent a device being the delegator to another device and thereby a signer which must have legal standing.  Add Implementer documentation that the References of a Resource element associated with Signature datatype can constrain the onBehalfOfReference" type if, e.g., the Resource element Reference is only Organization, then the onBehalfOfReference can only be an Organization Resource.

  • TO DO Need to decide on delegation approach to finalize on the above CPs. FM needs to implement the Signature DataType replacement of signature with or without the delegation approach. Need to report back to Security to get cross WG delegation approach.
  • Discuss discussion about John Moehrke's Friendly Amendment to FM CP 9533Change Contract signature datatype from string to FHIR Signature datatype, and change cardinality to 1..*] to change cardinality of Contract.signer.type and Contract.signer.role to 0..1 to support use cases where there is no signer.

Outstanding: Proposal tabled until next call because beyond scope of discussion and the implications of doing so in terms of a legal contract haven't been throught through and is independent from implementation of approved CP9533.

We also need a couple of use cases to illustrate the need, e.g., for a contract where one signer is unknown but some entity signer on their behalf. There may be alternative solutions. One big issue is that currently, Contract.signer is optional, which likely doesn't make sense for a contract.

  • Need to expedite review of v2 Table Harmonization for missing FM code systems and Table descriptions.

Minutes

Quorum not met. Will bring agenda forward to February 26 call.