|
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
|
|
relationship
|
FinancialContract.code
|
|
periodType
|
FinancialContract.code
|
|
period
|
FinancialContract.activityTime
|
|
usePeriod
|
FinancialContract.effectiveTime
|
|
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
|
|
action
|
Participation
|
|
type
|
RIM
Role,
Participation
Type
classes
|
|
role
|
RoleClass,
RoleCode,
ParticipationType,
ParticipationFunction
codes
|
|
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.
|
.
Page
versions:
R5
R4B
R4
R3
R2
|
Propose
a
change
Financial