1) Change Definition of SBADM in ActClass to:

"<p>The act of introducing or otherwise applying a substance to the subject.</p>
 <p><i>Discussion:</i> The effect of the substance is typically established on a biochemical basis, however, that is not a requirement. For example, radiotherapy can largely be described in the same way, especially if it is a systemic therapy such as radio-iodine.  This class also includes the application of chemical treatments to an area.</p>
 <p><i>Examples:</i> Chemotherapy protocol; Drug prescription; Vaccination record</p>"


2) Definition change in
 
codeSystemId=2.16.840.1.113883.5.1079
conceptCode=17895 
[Correct spelling of "multideimensional" to "multidimensional" Leaving definition:]
"A Region of Interest (ROI) specified for a multidimensional observation, such as an Observation Series (OBSSER). The ROI is specified using a set of observation criteria, each delineating the boundary of the region in one of the dimensions in the multidimensional observation. The relationship between a ROI and its referenced Act is specified through an ActRelationship of type subject (SUBJ), which must always be present. Each of the boundary criteria observations is connected with the ROI using ActRelationships of type ""has component"" (COMP). In each boundary criterion, the Act.code names the dimension and the Observation.value specifies the range of values inside the region. Typically the to be bounded dimension is continuous, and so the Observation.value will be an interval (IVL) data type. The Observation.value need not be specified if the respective dimension is only named but not constrained. For example, an ROI for the QT interval of a certain beat in EKG Lead II would contain 2 boundary criteria, one naming the interval in time (constrained), and the other naming the interval in ECG Lead II (only named, but not constrained)."

3) Definition change in
 
codeSystemId=2.16.840.1.113883.5.1079
conceptCode=10346
Description="A goal-evaluation links an observation (intent or actual) to a goal to indicate that the observation evaluates the goal. Given the goal and the observation, a ""goal distance"" (e.g., goal to observation) can be ""calculated"" and need not be sent explicitly."


4) DELETE Code and concept REFR (11538) from "ActClass" table

5) ADD AbstractDomain "ActListCode" to ActCode table

6) In ActMood table, change PRMS (16728) from a Specializable domain to a LEAF term

7) In ActMood table, change PRP (16726) from a Specializable domain to a LEAF term

8) In ActMood Table, concept 10200 (was ORD) -- change:
8A) Code from "ORD" to "RQO"
8B) printName from "order" to "request"
8C) Description to:
"<p>A request or order for a service is an intent directed from a placer
(request author) to a fulfiller (service performer).</p>
<p><i>Rationale:</i> The concepts of a ""request"" and an ""order"" are viewed as
different, because there is an implication of a mandate associated with
order.  In practice, however, this distinction has no general functional
value in the inter-operation of health care computing.  ""Orders"" are
commonly refused for a variety of clinical and business reasons, and the
notion of a ""request"" obligates the recipient (the fulfiller) to respond to
the sender (the author).  Indeed, in many regions, including Australia and
Europe, the common term used is ""request.""</p>
<p>Thus, the concept embodies both notions, as there is no useful distinction
to be made.  If a mandate is to be associated with a request, this will be
embodied in the ""local"" business rules applied to the transactions.  Should
HL7 desire to provide a distinction between these in the future, the
individual concepts could be added as specializations of this concept.</p>
<p>The critical distinction here, is the difference between this concept and
an ""intent"", of which it is a specialization.  An intent involves decisions
by a single party, the author.  A request, however, involves decisions by
two parties, the author and the fulfiller, with an obligation on the part of
the fulfiller to respond to the request indicating that the fulfiller will
indeed fulfill the request.</p>"

