# USAMP-II RIM changes

NewInfo:
A service is an intentional action in the business domain of HL7.  Healthcare (and any profession or business) is consitituted of intentional actions.  A Service instance is a record of such an intentional action.  The terms service, action, activity, and service action are all used interchangeably, but service has been selected as the principle name of this class. 

Any intentional action can exist in different "moods."  The mood of an action tells whether the action represents a fact (event) an order, a plan (intent), a goal, a risk, a potential (definition) or the like.  A service instance represents an action in one and only one such mood.  Thus, service definitions (master), orders, plans, and performance records (events) are all represented by an instance of class Service.

Any instance of a Service assumes one and only one mood and will not change its mood along its life cycle.  The moods definition, intent, order, event, etc. seem to specify a life cycle of an activity and thus seem like state changes.  However, the actors of these different moods are different, and so is the data different.  It is important to keep track of those differences (variances) in business processes.  Therefore, the mood of a service instance is static and not part of the state, not part of the life cycle.  The progression of the idea of a service towards actualization (i.e., the progression from defined, through planned and ordered to being performed) is called "business cycle" to distinguish it from the "life cycle" of a single service instance.  
Related service instances that form such a "business cycle" are linked through the Service_relationship class.

Examples for services in health care are: a clinical test, an assessment of health condition (such as problems and diagnoses),  the setting of healthcare goals, the performance of treatment services (such as medication, surgery, physical and psychological therapy,) assisting, monitoring or attending, training and education services to patients and their next of kins, notary services, such as advanced directives or living will.

Services have actors and targets.  Examples for actors are nurses, doctors, family members, notary publics, and service organizations -- every entity that is capable of independent decisions and can thus be responsible (and liable) for the actions performed.

Target participants may include, the patient, the patient's spouse, family, or community, a specimen drawn from the patient or from any object of interest. As patients do play active roles in their own healthcare, the patient can be both an active participant and a target participant at the same time (self-administered or reflexive services.) 

A service_event can have multiple active participants and multiple target participants, their specific role is distinguished in the "type_cd" of the respective instance of the participation class. In particular, a service event involving coordination of care may involve two or more active participants -- playing different roles -- who interact on behalf of a patient, family, or aggregate in the role of target participant.  For example, a nurse (active participant) calls Meals on Wheels (active participant) on behalf of the patient (target participant).

A service includes the "results," "answers" or informational "procedure products" gained during the service. In this model, "results" do not exist without a service, and every clinical result, including those results gained accidentally, are service events.  In other moods, such as definition, goal, and criterion, the results are the possible results, the expected or aimed-for results, or the tested-for results.


Changed Model Element:
Service :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..*)

NewInfo:
Services are delivered in the context of encounters, this association establishes the relationship between a service to an encounter. Services can be mentioned independent from an Encounter, which is why Encounter is optional.

Issue:
Association naming is very broad: "has assigned to" does not say what this assignment means.


Changed Model Element:
Service :: is_associated_with(0..*) :: Financial_transaction :: pertains_to (1..1)

NewInfo:
This asociation links a Service with financial transactions that represent the billing for this service.  This association is primarily used for the Service in event mood, i.e., the Service that did actually happen and is now billed for.

Issue:
Association names are not descriptive of what this association means. There is currently no way to describe fees for services in a master file. The issues of fees, fee schedule and their relationship to actual charges need to be modeled.  Or does the assoication between RIM092.Master_service and Coverage_item allow to assign different fees to the same master service?


Changed Model Element:
Service :: is_charged_to(0..1) :: Patient_billing_account :: has_charges_for (0..*)

NewInfo:
This association links a Service with a billing account.  It may specify the account to which a service is billed, before the service is even executed.  For example, an order might select a specific billing account.

Issue:
This association and the one between Service and Financial Transaction both come from Service_event.  Why is it that they both existed for Service_event? Does the Financial Transaction for the service need to be associated with the same account as the service? Isn't Financial Transaction an associative class between an Account and a billable item (e.g. Service)?  How does one distinguish charges to be billed to an account from charges actually billed?


Changed Model Element:
Service :: is_documented_by(0..*) :: Clinical_document_header :: documents(0..*)

NewInfo:
This association stands for any documentation of Services in clinical documents.

Issue:
This many-to-many association should be resolved.


Changed Model Element:
Service :: is_covered_by(0..*) :: Coverage_item :: provides_coverage_for(1..*)

NewInfo:
Describes the coverage of a service under a healthcare benefit product. The service is usually in defnition mood, as coverage item describes whether a certain kind of service is covered.

Issue:
Could the coverage_item be applicable for actual services (event) too?  Use case: a service was done on the basis of an emergency indication without any prior knowledge to coverage. A request is sent to a billing system or insurance, asking whether this actual service was covered and in what way it was covered?


NewInfo:
This is an instance identifier of a particular Service object. For example, whenever a service is carried out, there is a new service object instantiated with an identifier that uniquely distinguishes this service object from every other service object.


NewInfo:
Webster’s dictionary defines mood as a “distinction of form […] of a verb to express whether the action or state it denotes is conceived as fact or in some other manner (as command, possibility, or wish)”  This definition of mood can be directly applied to the USAMP-II model, where the service action (corresponding to a verb in natural language) may be conceived as an event that happened (fact), an ordered service (command), a possible service (master), and a goal (wish) of health care.  The mood code is critical to the design of this model.  Without the mood_cd, the model above would be at least three times as big, in order to distinguish service events, from orders, schedules, goals, and master service items.

One of the “infinitive” moods is used for describing potential services that can have actual services associated with them.  Common use of the infinitive mood is for dictionary entries (so called “master service”) and all “knowledge” links (e.g., possible reason, cause, manifestation, etc.) Other special infinitives are goal and trigger mood.  A goal describes a wish for a certain outcome (typically an observation) to be achieved in the future. An observation in goal mood is not actually made, thus is an infinitive. Goals are evaluated later.  Triggers are service descriptions that can match actual services (like a query.)  When a trigger matches, it enables, suggests, or demands the associated action to be performed. Triggers are most often used to fully describe PRN medication orders, but can serve to build reminder systems too.


NewInfo:
A code for the kind of action (e.g., physical examination, serum potassium, etc.), used to be called “universal service identifier”.  The Service.type_cd specifies the service conceptually by using a code from a code system.  We often refer to the Service.type_cd as the “name” of the Service.  In any case, the type_cd or “name” is a handle on the concept of the action, not on the individual action instance.

Different code systems cover different kinds of services, which is why there is not one single code system to be used for the Servcie.type_cd.  Furthermore, the data type Concept Descriptor (CD) allows the action to be named by multiple code systems at the same time, whereby each term from a coding system is assumed to be a synonym.  For example, a Thrombectomy service may be named “34001” using the CPT-4 code, “P1-30322” in SNOMED, or “38.00” in ICD-10-PCS.


NewInfo:
The description of a service is a piece of free text or multimedia data that describes the service in all necessary detail.  There is no restriction on length or content imposed on the description attribute.  However, the content of the description is not considered part of the functional information communicated between systems.  Descriptions are meant to be shown to specially interested human individuals.  All information relevant for automated functions must be communicated using the proper attributes and associated objects.
Note that the description attribute is not a service “name.”  All names of the service can be communicated in the Service.type_cd attribute as codes together with readable print-names.

As with any attribute of class Service, the meaning of the description attribute is subject to the Service.mood_cd.  For service definitions, the description can contain textbook like information about that service.  For service orders, the description will contain particular instructions pertaining only to that order.  Filler order systems must show the description field to a performing provider.

For Service records of actual services  (Service.mood_cd = actual,) the description is an important part of the documentation.  The description will contain textual reports on the service.  This is true for any service, in particular for surgical procedures, where the description attribute is the place to put the entire surgery report.  If the surgical procedure is reported as multiple interrelated Service instances, each instance may contain the part of the report pertinent to that step of the procedure.  However, there is no need to break a service report apart into sub-services only to break the textual report apart into multiple sections.  The Encapsulated Data type is capable of handling formatted textual reports in HTML, PDF, or word processor  formats.  In addition, the HL7 PRA working group defines standards to use XML as a markup language for report documents. 
Note that textual reports should always be sent in the Service.descr; this includes reports of observation services.  The Observation.value field is reserved for information that is processed automatically and that is accessible to automated processes.  Human authored free text reports are not easily accessible to automated processing, which is why they should be communicated in the Service description attribute.  Of course, free text documents can be analyzed by natural language parsers and similar tools.  We encourage that any output of such natural language parsers be communicated in the Observation.value attribute in the form of structured machine accessible data.  Since narrative text and observation value are in different attributes, they can be communicated together, without interfering with each other.


NewInfo:
The state of the action (e.g., newly ordered, in process, completed.)  The state is communicated in coded form.  The codes are strictly defined by the state-transition model of a service class.  No alternative coding system can be used for the status_cd attribute (CNE, coded no exceptions.)

Issue:
No particular State-Transition model has been included in this specification as of yet.  Various state transition models have been proposed in the orders committee in the past (although these have never been reconciled.)  This proposed model understands that, in principle, it must (and can) accommodate any state-transition logic that has bee defined using the previous model.  In particular, the extensive merging of classes and the mood code attribute do not impact the scope and definition of currently proposed state-transition models.


NewInfo:
This is the time when the action happened, is ordered or scheduled to happen, or when it can possibly happen (depending on the mood of the Service object.)  The timing of actions is a very important concept that is explained in greater detail in USAMP-II part A, Section 2.5.3.


NewInfo:
This is the “biologically relevant” time of an action.  The concept is best understood with observations, where the time of the observation action may be much later than the time of the observed feature.  For instance, in a Blood Gas Analysis (BGA), a result will always come up several minutes after the specimen was taken, meanwhile the patient’s physiological state may have changed significantly.  Even more so in history taking, when the doctor records an episode of Hepatitis A under which the patient suffered last year for several weeks.  For surgical procedures the time between first cut and last suture is taken as the critical time of the procedure.  For transport and supply services the critical time is the time en route or time of delivery respectively.  Critical time and total time of a service may often be related in a certain way, which will be discussed in USAMP-II Part A, Figure 10.


NewInfo:
For any service there may be several different methods to achieve by and large the same result, but may be important to know when interpreting a report more thorroughly (e.g., blood pressure method: arterial puncture vs. Riva-Rocci, sitting vs. supine position, etc.) 
 
Method concepts can be “pre-coordinated” in the Service definition, so that there is never an option to select different methods.  Pre-coordinating methods into the service code (type_cd) avoids having to standardize on method codes.  There are so many possible methods which all depend heavily on certain kinds of services, so that defining a vocabulary domain of all methods is close to impossible.  The pre-coordinated approach avoids relying on the impossible to be done.

However, a code system might be designed such that it specifies a set of available methods for each defined service concept. Thus, a user ordering a service could select one of several variances of the service by means of the method code.  Available method variances may also be defined in a master service catalog for each defined service.  In service definition records (Service.mood_cd = DEF) the method_cd attribute is a set of all available method codes that a user may select while ordering, or expect while receiving results.

Although the authors of this proposal believe that the pre-coordinated approach to methods goes a long way and should be followed as far as possible, the same information structure can handle both the pre-coordinated and the post-coordinated approach.


NewInfo:
Most health care services have a focus on a particular anatomic structure of the patient (the “target” of service.)  This information is found in body_site_cd.  The coding system to be used for anatomic site is not specified in detail.  Anatomic sites, body parts, and functional body systems are huge and highly complex domains that require a very sophisticated terminology system.  Candidates are Galen, SNOMED, or Read codes.  Alternatively, a simple local coding system can be used to identify exactly the common body sites used. 

Some body sites can also be “pre-coordinated” in the Service definition, so that there is never an option to select different body sites.  The same information structure can handle both the pre-coordinated and the post-coordinated approach.

For administrative body sites (i.e. where medications are administered) HL7 used to define a table (0163) that must be used as defined in Table 4 below.


NewInfo:
This attribute allows for a very rough interpretation of the course or outcome of a service action.  This is sometimes called “abnormal flags”, however, the judgement of normalcy is just one of the common rough interpretations, and is often not relevant.  For example, for the observation of a pathologic condition, it doesn’t make sense to state the normalcy, since pathologic conditions are never considered “normal.”


NewInfo:
This is a code that limits the disclosure of information about this service.  The codes refer to confidentiality policies as listed in the normative table [see USAMP-II document]

Confidentiality policies may vary from institution to institution and not all systems are capable of abiding by all details of the confidentiality policies suggested in the above table.  However, these are the items that are being used in some institutions and which implementers may want to consider supporting.

It is important to note that good confidentiality of the medical record can not be achieved through confidentiality codes only to filter out individual record items to certain types of users.  There are two important problems with per-item confidentiality: one is inference and the other is the danger of holding back information that may be critical in a certain care situation.  Inference means that filtered sensitive information can still be assumed given the other information not filtered. The simplest form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known.  Very often, diagnoses can be inferred from medication, such as Zidovudin for treatment of HIV infections.  The problem of hiding individual items becomes especially difficult with current medications, since the continuing administration of the medication must be assured.

A similar confidentiality code attribute is therefore required in the Patient class to cover the entire patient record.  But this is outside the scope of the present proposal.

The flags HIV, PSY, ETH, and SDV may only be used on service items that are not patient related.  Typically, they are used in the service definition object (“master” service) to indicate a generic disclosure policy of any actual service item of that type.

Aggregations of data should assume the privacy level of the most private action in the aggregation.


NewInfo:
This is the maximum number of repetitions of a service.  Typical values are 1, some other finite number, and the infinity (a specific null value for numbers.)  See the discussion on service plans in the USAMP-II specification, part A, on how specifically this is used.


NewInfo:
Indicates whether a service is interruptible by asynchronous events (such as “through”-conditions to turn false, or time running up.) See discussion on activity plans in the USAMP-II document, part A.


NewInfo:
Indicates whether an ordered or intended service may be or has been substituted for a different service. The fact that the actual service differs from the planned or ordered service, and the details of the variance can be seen by comparing the service as planned or ordered from the service as performed.  Both service records should be sent in a message where this difference is important.  The Service.substitution_cd attribute is mainly used in an order, to specify whether an ordered service may be substituted and in what way it may be substituted.


NewInfo:
This attribute encodes the urgency under which the service is to be scheduled and performed, or was performed.  This attribute is used in orders to indicate the ordered priority.  It is also used in the service event documentation to indicate the actual priority used to perform the service, which is used to determine the charge.  In master service definitions it indicates the available priorities.


NewInfo:
This attribute indicates whether this service can be requested independently from other services.  Some services can only occur as subordinate to a super-service; others are abstractions of services or service groups that should not be ordered in one piece.  Since in principle everything that can be done can potentially be requested, this attribute is true by default.  It is usually only used for master file definitions.


NewInfo:
The Service relationship class is a recursive associative class with two associations to the Service class, one named “source” the other named “target”. Consider every Service_relationship instance an arrow with a point (headed to the target) and a butt (coming from the source.)  For each relationship type the functions (or roles) of source and target Service are different as specified in Table 13 below.

In principle the assignment of functions (roles) to each side of the relationship “arrow” is completely arbitrary.  However since a service is the core element of a medical record, proper attribution of the medical record items is an important issue.  The relationships associated with a Service are considered  properties of the source service object.  That means, that the originator of the information reported in a service object is not only responsible for the attribute values of that object, but also for all its outgoing relationships.

The rule of attribution is that all service relationships are attributed to the responsible actor of the 
Service at the source of the Service_relationship (the "source service".)

With this recursive service relationship one can group actions into “batteries,” e.g. LYTES, CHEM12, or CBC, where multiple routine laboratory tests are ordered as a group. Some groupings, such as CHEM12, appear more arbitrary; others, such as blood pressure, seem to naturally consist of systolic and diastolic pressure.

Actions may also be grouped longitudinal, in a sequence of sub-actions to for temporal and conditional (non-temporal) action paths (e.g., care plan, critical path, clinical trials, drug treatment protocols).

Actions may be explicitly timed, and may be conditioned on the status or outcome of previous actions. Concurrent collections of actions allow expressing logical branches as well as parallel tasks (tasks carried out at the same time.) These constructs can be organized in multiple layers of nesting, to fully support workflow management.

The relationship class is not only used to construct action plans but also to represent clinical reasoning or judgements about action relationships. Prior actions can be linked as the reasons for more recent actions. Supporting evidence can be linked with current clinical hypotheses.  Problem lists and other networks of related judgements about clinical events are represented by the service relationship link too. 

The Service_relationship.type_cd identifies the meaning and purpose of every service relationship instance.


Changed Model Element:
Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)

NewInfo:
A service relationship is like an arrow with a butt (source) and a point (target).  A Service instance is on each side. This association is the source (butt) of the arrow.  The service relationship is -- without exception -- attributed to the originator of this source service.

For example, if the service relationship type is called "has_plan_component" then the source service represents the plan of which the target is a component.  Note that the service_relationship.inversion_ind attribute can invert the meaning of the relationship.  However, the rule of attribution does never change, i.e., it is always the originator of the source service who is responsible for the relationship.


Changed Model Element:
Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)

NewInfo:
A service relationship is like an arrow with a butt (source) and a point (target).  A Service instance is on each side. This association is the target (point) of the arrow.  

For example, if the service relationship type is called "has_plan_component" then the target service is that plan component, while the source would represent the plan of which the target is a component.  Note that the service_relationship.inversion_ind attribute can invert the meaning of the relationship.


NewInfo:
Determines the meaning of a relationship between two Services.  This attribute is probably the most important attribute in this entire model besides the Service.mood_cd.  It is a “structural” attribute inasmuch as each of its values implies specific constraints to what kinds of Service objects can be related and in which way.  Refer to the USAM specification document for defined service relationship types and examples of their use.


NewInfo:
The inversion indicator is used when the meaning of the relationship type must be reversed.  For example, we define a relationship type reason to express the reason for an action as in

a) “A cholecystectomy was performed because of symptomatic cholelithiasis without signs for cholecystitis.”  (cholecystectomy has-reason cholelithiasis)

This statement of rationale is attributed to the responsible performer of the cholecystectomy.  Now consider the following statement:

b)  “The finding of symptomatic gall stones (cholelithiasis) with no signs of acute cholecystitis suggests a cholecystectomy.”

While sentence a) declares a reason for an action, sentence b) suggests an action.  Reason and suggestion links are reciprocal, i.e., if X has-reason Y, then Y suggests X.  The second statement would have been made by the originator of the cholelithiasis finding.

In the “network” of interrelated services, we need to make sure that we do not lose proper attribution of statements to originators (“who said what?”)  Since attribution is so important, we adopt a very simple rule for it: a service relationship is always attributed to the originator of the source service.  No exceptions to this rule are permitted whatsoever.  If attribution needs to be different one can invert the relationship type by setting the inversion_ind attribute to true.

If the inversion indicator is true, source and target service swap their roles, that is, the reason and the suggested action swap their roles, so that cholecystectomy can be the source and colelithiasis can be the target.  Note that the attribution rule is always unchanged, i.e., the service relationship is always attributed to the responsible author of the source service, no matter what the inversion_ind value is.


NewInfo:
This integer number allows one to specify an ordering amongst the outgoing relationships of a service. This is used to represent sequences of actions in execution plans.
  
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle has a distinct sequence number.  (A relationship “bundle” is a sub-set of the relationships originating in the same service instance and usually having the same relationship type).  If, however, some relationships in the bundle share the same sequence number, we have a partial ordering.  In such a case the services with the same sequence number are concurrent.


NewInfo:
This integer number allows to specify another kind of ordering amongst the outgoing relationships of a service.  This is used to represent the priority ordering of conditional branches in service execution plans, or priority ranking in pre-condition, outcome or support links, and preferences among options.  

The ordering may be total or partial.  A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of the relationships originating in the same service instance and usually having the same relationship type) has a distinct priority number.  If, however, some relationships in the bundle share the same priority number, we have a partial ordering.  Those links with the same priority will have undefined ordering of consideration.


NewInfo:
The time that should elapse after this activity has got clearance to execute and the actual begin of execution. Any entering pre-conditions are tested before the slot is entered, so the pause specifies a minimal waiting time before the service is executed after its pre-conditions become true.


NewInfo:
Indicates when associated pre-conditions are to be tested. The following values are defined:

Concept	Code	Definition
entry	S	Condition is tested once before the service is executed (IF condition THEN service).
beginning	B	Condition is tested every time before execution of the service (WHILE condition DO service.)
end	E	Condition is tested at the end of a repeated service execution.  The service is repeated only if the condition is true (DO service WHILE condition.)
through	T	Condition must be true throughout the execution and the service is interrupted (asynchronously) as soon as the condition turns false (asynchronous WHILE loop.)  The service must be interruptible.
exit	X	Condition is a loop checkpoint, i.e. it is a step of an activity plan and, if negative causes the containing loop to exit.


NewInfo:
When an activity plan has a branch (indicated through multiple steps with the same item number) the split code specifies how branches are selected for execution.  The values are defined as follows:

Concept	Code	Definition
exclusive
try once	E1	The pre-condition associated with the branch is evaluated once and if true the branch may be entered.  All other exclusive branches compete with each other and only one will be selected.  This implements a COND,  IF and CASE conditionals, or “XOR-split.”  The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.
exclusive
wait	EW	A branch is selected as soon as the pre-condition associated with the branch evaluates to true.  If the condition is false, the branch may be entered later, when the condition turns true.  All other exclusive branches compete with each other and only one will be selected.  Each waiting branch executes in parallel with the default join code wait  (see below.) The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.
inclusive
try once	I1	A branch is executed if its associated preconditions permit. If associated preconditions do not permit, the branch is dropped.  Inclusive branches are not suppressed and do not suppress other branches. 
inclusive
wait	IW	A branch is executed as soon as its associated conditions permit.  If the condition is false, the branch may be entered later, when the condition turns true.  Inclusive branches are not suppressed and do not suppress other branches.  Each waiting branch executes in parallel with the default join code wait  (see below.)


NewInfo:
In a parallel branch construct the join code indicates how the concurrent activities are resynchronized.

Concept	Code	Definition
wait	W	Wait for this branch to terminate.
kill	K	When all other concurrent branches are terminated, interrupt and discontinue this branch.
exclusive wait	X	Wait for any one of the branches in the set of exclusive wait branches to terminate, then discontinue all the other exclusive wait branches.
detached	D	Detach this branch from the other branches so it will not be resynchronized with the other branches.

A kill branch will only be executed if there is at least one active wait (or exclusive wait) branch.  If there is no other wait branch active, a kill branch is not started at all (rather than being discontinued shortly after it is started.)  A detached branch will be unrelated to all other branches, thus a kill branch will be discontinued no matter whether there are detached branches still running.


NewInfo:
For conditions and criteria links indicates whether the meaning is negative (condition must not be true.) Normally all conditions are interpreted as affirmative, i.e., the condition must be true.  The negation_ind is part of the condition so that the Boolean outcome of the condition XOR-ed  with the negation_ind of the condition link must be true.  We thus say the “condition is true” even if the test was negative if the negation_ind is true.


NewInfo:
In a bundle of precondition or outcome relationships, this code indicates the logical conjunctions of the criteria.

Concept	Code	Definition
and	AND	This condition must be true.
or	OR	At least one of the condition among all OR conditions must be true.
exclusive or	XOR	One and only one of the XOR conditions must be true.

All AND criteria must be true.  If OR and AND criteria occur together, one criterion out of the OR-group must be true and all AND criteria must be true.  If XOR criteria occur together with OR and AND criteria, exactly one of the XOR criteria must be true, and at least one of the OR criteria and all AND criteria must be true.  In other words, the sets of AND, OR, and XOR criteria are in turn combined by a logical AND operator (all “AND” criteria and at least one “OR” criterion and exactly one “XOR” criterion.)


NewInfo:
All people, things and locations involved in a Service (or for scheduling purposes “all resources of an activity”) are associated with the Service as either actors or targets.  Actors are mostly professional provider personnel, but also the patient (for self-administered services,) or a proxy (e.g. next of kin.)

Actors can participate in an action in different ways.  For example, primary surgeon, assistant surgeon, sterile nurse, and nurse assistant are all actors in a surgical procedure, who are more or less immediately involved in the action.  However, payers, supervisors, provider organizations (e.g., “MicroLab”) and their delegates may be actors too, even though they might not be individual persons who have their “hands on” the action.  The patient himself is a performing actor in self-care procedures  (e.g. fingerstick blood glucose, insulin injection, etc.)

The Stakeholders, people and organizations that can be actors and targets of a service action are capable of and accountable for their independent decisions.  Capability of independent decision and accountable usually applies only to persons under the law, including both organizations and natural (human) persons.  This “legal person” as a subject of legal rights and obligations is a very obvious interpretation of the RIM Stakeholder construct (it is a well-known legal notion.)

The notion of multiple actors with specific functions touches and partially overlaps on two “sides” with related concepts of the RIM, and understanding the distinctions is important to use the RIM constructs correctly.  On the one “side” actor functions look similar to Stakeholder roles (e.g., healthcare practitioner, guarantor, contact-person,) and capability and certification (e.g., certified surgeon vs. resident, certified nurse midwife vs. other midwife practitioner, registered nurse vs. other nurse practitioner.)  The professional credentials of a person may be quite different from what a person actually does.  The most common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists.  The opposite example is people who are both medical doctors and registered nurses and who perform the function of a nurse.  Thus, roles and certification refer to the static capabilities of a person (person-related) while actors and Actor.type_cd refer to the particular function an actor played in the service (activity-related.)

On the other “side” the actor concept interferes with sub-activities.  Whenever multiple actors are involved in a service, each actor performs a different task (with the extremely rare exception of such symmetrical activities as two people pulling a rope from either end.)  Thus, the presence of multiple actors could be equally well modeled as a service consisting of sub-services (through the Service_relationship class,) where each service would have only one performing actor 

For example, a record of a surgical service may include the actors of type: (a) consenter, (b) primary surgeon, and (c) anesthesist.  These three actors really perform different tasks, which can be represented as three related services:  (a) the consent, (b) the surgery proper, and (c) the anesthesia service in parallel to the surgery.  If we used the sub-services, the consenter, surgeon and anesthesist could simply be of actor type “performer.”  Thus the more sub-services we use, the fewer different actor types need to be distinguished, and the fewer sub-services we use, the more distinct actor types we need.

Note that the perception of a task as “atomic” or “composite” (of sub-tasks) depends on local business rules and may differ from department to department.  In principle, every task can be thought of as being a composite of sub-tasks.  We thus say that actions are “fractal.”  The paradigmatic example of the fractal nature of activities is a “robotic arm” doing some simple action as reaching for a tool in front of it.  The seemingly simple activity of the robotic arm decomposes into complex control and coordination procedures and movements, action of separate motors and switches, etc.  (We sometimes use the key-phrase “robotic arm discussion” to recall the fractal nature of actions, since this example has been brought up over and over again, independently by different people.)  

As a rule of thumb, sub-tasks should be considered instead of multiple actors when each sub-task requires special scheduling, or billing, or if overall responsibilities for the sub-tasks are different.  In most cases, however, human resources are scheduled by teams (instead of individuals,) billing tends to lump many sub-tasks together into one position, and overall responsibility often rests with one attending physician, chief nurse, or head of department.  This model allows both the multi-actor and the muli-service approach to represent the business reality, with a slight bias towards “lumping” minor sub-activities into the overall service.


Changed Model Element:
Actor :: for(1..1) :: Service :: has(0..*)

Rationale:
Actor (and Target) are purely associative classes.  This means, their instances have no use nor identity apart from the Service and Stakeholder instances that they connect. For this reason the association role names are very short.  These role names are read as "Service has 0..* Actors is_participation_of 1..1 Stakeholder" and
"Stakeholder participates_as 0..* Actor for 1..1 Service"


Changed Model Element:
Actor :: participation_of(1..1) :: Stakeholder :: participates_as(0..*)

Rationale:
Actor (and Target) are purely associative classes.  This means, their instances have no use nor identity apart from the Service and Stakeholder instances that they connect. For this reason the association role names are very short.  These role names are read as "Service has 0..* Actor participation_of 1..1 Stakeholder" and Stakeholder participates_as 0..* Actor for 1..1 Service"


NewInfo:
Identifies a particular function or a set of functions that a person performs in the Service. 

Note that the Actor.type_cd designates the actual function performed in the service.  This is quite different from a role associated with a person or a profession- or specialty-code, although, some of the Actor.type_cd values may suggest that they are the same.  While a person’s role, a profession code, or a specialty code may signify a general capability and authority of that person, an Actor.type_cd rather represents a part or sub-task of the associated Service activity. 

Most notably the role “performing surgeon” is not necessarily played by a certified surgeon, but in many cases by a resident (in which case an attending surgeon is designated as the “responsible” actor.)  The same is true for the “anesthesist” which doesn’t have to be an “anesthesiologist” and will in most cases be a resident or sometimes even a nurse.

An actor can do multiple of such functions identified by the Actor.type_cd at the same time.  This can be represented in two ways: either the same Actor instance can be used with multiple Actor.type_cd values (hence, it’s a set of code values).  Alternatively, one can use multiple Actor-instances with just one Actor.type_cd value relating to the same Stakeholder.  A mixture of both approaches is also possible.  The rationale when to use just one or the other approach can be, e.g., an actor playing three roles two of which are closely related whereas the third role may have a different time range.  A more concrete ruling on a standardized use may follow in the future.


NewInfo:
This attribute can specify the time range during which the associated person was an actor of the specified Actor.type_cd in the associated service.  This may be needed when the actor’s involvement spans only part of the service, and if this fact is worth mentioning.  The Actor.tmr does not need to be used in cases where this detail is irrelevant.


NewInfo:
An actor can make a comment about this service item in the note attribute.


NewInfo:
Some Actors must provide a signature on the service instance.  For example, a procedure report requires a signature of the performing and responsible surgeon.  Or a consent requires the signature of the consenter.  This attribute allows to specify whether or not such a signature is on file, it does not itself provide evidence for the signature.

required X A signature for the service is required of this actor.
signed   S A signature for the service is on file from this actor.

In today’s environment, with the advent of digital signatures, this treatment appears to be insufficient.  We will continue to work on integrating this to a framework of digital signatures.  However, there are severe technical obstacles to overcome: digital signatures do not exist over abstract information.  Only concrete bit-representations of information can be signed.  Since HL7 version 3 tries to separate abstract information from bit-encodings, it is not clear how such a digital signature could exist.

We are aware of the X.509 approach of Distinguished Encoding Rules (DER), but there is currently no definition for encoding HL7 data structures in DER, nor does it seem like the industry prefers DER as the principle message encoding rules. Furthermore, there needs to be a framework to integrate traditional paper-based signatures as well.  Hence, we acknowledge that the Actor class may be the principle point of implementing electronically authenticated medical records, but we defer the elaboration of this approach to later.


NewInfo:
Target is an associative class linking physical entities, including humans, other living subjects and inanimate material to the Service.  The targets of a Service are like the objects and adverbial phrases of a verb in a sentence.  This include direct objects (the things subjected to the action), indirect objects (e.g., beneficiary), and adverbials (e.g., means, location.)

Every target object is linked with the Service through a target instance.  The target has a type_cd that identifies the function (or role) played by the target in the service.  In the natural language analogy, the type_cd provides the case of the object and the preposition of an adverbial phrase.

The Target class maintains a choice to link to either a Person or a Material as its substance.


Changed Model Element:
Target :: in(1..1) :: Service :: has(0..*)

Rationale:
Target (and Actor) are purely associative classes.  This means, their instances have no use nor identity apart from the Service and Person/Material instances that they connect. For this reason the association role names are very short.  These role names are read as "Service has 0..* Target participation_of 1..1 Person/Material" and "Person/Material participates_as 0..* Target in 1..1 Service"


Changed Model Element:
Target :: participation_of(0..1) :: Person :: participates_as(0..*)

NewInfo:
Any one Target instance connects one Service to either a Person or a Material but not both.

Rationale:
Target (and Actor) are purely associative classes.  This means, their instances have no use nor identity apart from the Service and Person/Material instances that they connect. For this reason the association role names are very short.  These role names are read as "Service has 0..* Target participation_of 0..1 Person" and "Material participates_as 0..* Target in 1..1 Service"


Changed Model Element:
Target :: participation_of(0..1) :: Material :: participates_as(0..*)

Rationale:
Target (and Actor) are purely associative classes.  This means, their instances have no use nor identity apart from the Service and Person/Material instances that they connect. For this reason the association role names are very short.  These role names are read as "Service has 0..* Target participation_of 0..1 Material" and "Material participates_as 0..* Target in 1..1 Service"


Changed Model Element:
Target :: participation_of(0..1) :: Living_subject :: participates_as(0..*)


NewInfo:
Just as with actors, different participation types can be identified for targets.  By “target” of an action we basically mean objects of a verb. Objects appear in different cases: direct objects, indirect objects or adverbial objects according to their roles in a sentence. Target participation type codes distinguish those different roles. For instance, patient, guarantor, custodian, or family members are examples of target participation types. These are in the role of direct target on whom (accusative) or the indirect beneficiary (on behalf of whom) the service action is performed.  In addition any material, specimen, device, or location used or produced by a service is a target of the service.


NewInfo:
This is the time range in which the associated person or thing was a target of the specified Target.type_cd in the associated service.


NewInfo:
For person targets indicates whether the associated patient or family member is aware of the service, and especially of the observation made.  For example, a patient (or his next family members) may not be aware of a malignancy diagnosis, the patient and family may be aware at different times, and some patients may go through a phase of denial.  For other than person targets this attribute is not applicable and shall not be valued.


NewInfo:
Observations are actions performed in order to determine an answer or result value. Observation result values are specific information about the observed object. The type and constraints of result values depend on the kind of action performed.

The observation action and observation result are modeled as being the two aspects of the same concept, just like the two faces of a coin are not separable from each other. Most other published healthcare models, including earlier HL7 RIM versions, separate the activity of observing and the observation result into different classes. These models label the kind of action in one class and the kind of observation result in the other.  In most cases, however, the test name is a label for both activity and  observation result.  So, in merging action with the result, the two codes are now only one.


Changed Model Element:
Observation is specialization of Service


NewInfo:
The result value of an observation action.  As was true with HL7 v2, this value can be of any data type.  However, there are clearly more or less reasonable choices of data types as indicated in the table below.

Kind of observation	Data type	Notes
Quantitative measurements	PQ	Physical quantity (real number with unit.) This is the most usual choice.  Note that numeric values must not be communicated as a simple character string (ST.)
Titer (e.g., 1:64) and other ratios (e.g. 1 out of 1000)	RTO	A ratio of two integer numbers (e.g., 1:128.)  Sometimes by local conventions titers are reported as just the denominator (e.g., 32 instead of 1/32)  Such conventions are confusing and should not be followed in HL7 messages.
Index (number without unit)	REAL	When a quantity does not have a proper unit, one can just send the number as a real number.  Alternatively one can use a PQ with a dimensionless unit (e.g., 1 or %).  An integer number should only be sent when the measurement is by definition an integer, which is an extremely rare case and then is most likely an ordinal (see below.)
Ranges (e.g., < 3; 12-20)	IVL<PQ>	Interval of physical quantity.  Note that sometimes such intervals are used to report the uncertainty of measurement value.  For uncertainty there are dedicated data type extensions available.
Ordinals (e.g., stage “IIa”)	CV, INT	At this point, ordinals should be reported either as code values, (e.g., +, ++, +++; or I, IIa, IIb, III, IV) or as integers. In the future ordinals may be addressed by a separate data type.
Nominal results, “taxons” (e.g. organism type.)	CD	The Concept Descriptor (CD) is the most common data type to use for categorical results (e.g., diagnosis, complaint, color.)  Such qualitative results are rarely simple Code Values (CV) if there is a tightly defined code system which everyone uses.
Image (still, movie)	ED	The encapsulated data type allows one to send an image (e.g., chest X-ray) or a movie (e.g., coronary angiography, cardiac echo.)
Waveform		Waveforms can be sent using the waveform template developed by the Automated Data SIG for version 2.3.  A mapping onto version 3 is shown farther below.  In addition one can use the Encapsulated Data (ED) type to send waveforms in other formats.
Formalized expressions	ST	The character string data type may exceptionally be used to convey formalized expressions that do not fit in any of the existing data types.  However, use of the string data type is not allowed if the meaning can be represented by one of the existing data types.  Note that many of the data types do have character string literal expressions too, so the field in the message can be formatted using character string literals and still have a distinct data type.
Bulk text reports	ED	A detailed procedure report should normally be sent in the attribute Service.descr. The Observation.value should be reserved for computer interpretable or automatically generated information.  Note that the Encapsulated Data type (ED) can accommodate formatted text in such common formats as HTML, PDF, or Word Processor formats.  The ED data type can also carry dictation that is not yet transcribed.  We strongly discourage to send formatted text as result values.  At the very least, the formatted text should be broken down into sections, one per sub-service object.


NewInfo:
Derived observations can be defined through association with other observations using relationships of derivation type (Service_relationship.type_cd = derivation.)  For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with an Hemoglobin (HGB) observation (Service_relationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation (Service_relationship.sequence_nmb = 2)  Since  MCH = HGB / RBC, the value of the derivation expression would be “$1 / $2”.

The derivation expression is a character string with a simple syntax similar to that of the UNIX “expr” utility, or the expression subset of the PERL or TCL language.   All observations that are cited in the formula must be associated with the derived observation through links of type derivation with a  unique Service_relationship.sequence_nmb.  Such observation values are referred to by that sequence number preceded by a dollar sign ($).

Defined operators are addition (+), subtraction (?), multiplication (*) and division (/).  Parentheses can be used to overcome the usual precedence (left to right, multiplication before addition.)  In addition to the basic arithmetic operations the usual mathematical functions are defined.

Issue:
The definition of this field's syntax needs to be completed.


NewInfo:
This attribute describes the scientific property of the observation value.  For quantitative observations, this is the kind of quantity.  The code table to be used will represent all the concepts defined in the IUPAC Compendium of Terminology and Nomenclature of Properties in Clinical Laboratory Sciences (“Silver Book”.)  This concept has a large intersection with the LOINC “Kind of Property” table, which is also featured by HL7 v2.3.1 as Table 0254.

Issue:
Table needs to be defined (significantly revised from LOINC)


NewInfo:
Medication is an indirect care-intervention using a material substance as a therapeutic agent.  The effect of the therapeutic 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.  Whether or not radiotherapy will be covered by a separate class is open.

Medication as a service indicates the administration of a generic class of medication to a patient.  The administration of a particular preparation (in the U.S. typically represented by NDC code) requires the association of the material class with the Medication service.  The material information is usually added to the order by the pharmacist when the prescription is filled as a revision or substitution to the original order.

Because medication deploys material substances, a number of attributes arguably pertain to the material rather than the medication action.  Therefore, some information may be representable in two ways: as attributes of the medication service or as attributes of the material.  This is especially obvious with the kind of substance applied.  For example, an Amoxicillin treatment is usually described as Medication.type_cd = Amoxicillin; however, it could also be described as Medication.type_cd = administer with an associated Material target of type Amoxicillin.  At this point naming the Service Action after the generic administered substance is the preferred strategy.

This design allow simple medications to be described without having to use the Material class.  Only if such actions as dispensing, or such information as the manufacturer are relevant, or if a recipe prescription is written, should one have to deploy the Material class.


NewInfo:
The dose form of the therapeutic substance. Examples are tablet, capsule, suppository, etc.

Issue:
This field must have a mandatory HL7 table for interoperability purpose.  Such a table could cover at least 90% of all cases.


NewInfo:
The route of the medication.  Medication route is similar to an anatomic body site through which the therapeutic agent is incorporated or otherwise applied to the body.  It is an open issue whether a specialized route_cd could be replaced by a general anatomic site code.  The typical routes are per os (PO), sublingual (SL), rectal (PR), per inhalationem (IH), ophtalmic (OP), nasal (NS), otic (OT), vaginal (VG) , intra-dermal (ID), subcutaneous (SC), intra-venous (IV), and intra-cardial (IC).  

However, as the table below suggests there are other routes and there are many variations as to how to access a specific route.  For instance, an oral administration with the patient swallowing will usually have the same effect as if the same substance is given through a gastric tube.  A more systematic approach to analyze the route into components such as site of primary entry (e.g. oral, nasal), site/system of  substance uptake (e.g. gastrointestinal, bronchial, nasal mucosa), method (e.g., swallow, inhale), and device (e.g., gastric tube, tracheal tube) should be considered.  At this point the version 2.x code table is used.


NewInfo:
The dose is the amount of the therapeutic agent given at one administration event. This attribute can be used all by itself, or in combination with a strength.  In theory, a physician’s prescription could suffice with just the dose specification.  For example, if Azythromycin is to be given at 80 mg once a day for three days, there is no need to specify a strength.  The pharmacist can figure out the right preparation given what is available in stock or on the marketplace.  When the pharmacist dispenses a particular preparation with a particular strength and packet size from a particular manufacturer, etc., this detail should be communicated using the Material class.


NewInfo:
The strength of a medication is the amount of therapeutic agent per each unit of administration (entitic mass, amount of substance, etc.)  If the dose form is continuously divisible (e.g., liquid, gas), the strength is a concentration (volumic mass, amount of substance, etc.)

We generally discourage using this attribute, because in theory, a physician’s prescription could suffice with just the dose specification.  For example, if Azythromycin is to be given at 80 mg once a day for three days, there is no need to specify a strength.  The pharmacist can figure out the right preparation given what is available in stock or on the marketplace.  When the pharmacist dispenses a particular preparation with a particular strength and packet size from a particular manufacturer, etc., this detail should be communicated using the Material class.

When the strength attribute is used, the actual administered amount is the product of dose_qty and strength_qty.


NewInfo:
With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified.  The Medication.rate_qty is specified as a physical quantity in time (a duration.) Hence, the rate_qty is really the denominator of the dose rate.  For example, if an Ringer solution is to be given at 100 mL/h i.v., the dosis_qty would be 100 mL and the rate_qty would be 1 h.  Note that there is no difference in the actual values of dosis_qty and rate_qty as long as the quotient of both has the same value.  In this example, we could just as well specify dosis_qty as 50 mL and rate_qty as 30 min, or 200 mL and 2 h or any other combination where the quotient equals 100 mL/h.

Note that in principle one could again suffice with just the dosis_qty attribute specifying the rate right in that one attribute (e.g., dosis_qty = 100 mL/h.)  However this practice is not allowed.  Systems that implement the semantics of units according to the Unified Code for Units of Measure would have no problem noting the fact that a dose_qty is really a rate.  Other system however will have difficulties to tell an at-once dose from a dose rate from just looking at the units.  If a system wishes to deal only with a single quantity describing the dosage, it can always calculate such a quantity as

real_dosis_qty = dosis_qty x strength_qty / rate_qty.


NewInfo:
This attribute should not generally be used, it is only provided for a special purpose.  In some countries, especially Japan, there is a regulatory requirement to note the total daily dose on the prescription and associated documentation.   The purpose of this requirement obviously is to encourage and facilitate reviewing the total dose prescribed to avoid over- (or under-) dosage.  Rather than to define a “total daily dose” attribute as HL7 v2.3 did, we define this general purpose dose_check_qty attribute that can be used in various ways as required by local business rules or regulations.  For example, in Japan one would use this field as a total daily dose by calculating the “real” dose as noted above and then adjusting the denominator to 1 d.   For example, with Erythromycin 250 mg 1 tablet 3 times a day one can calculate the total daily dose as

dosis_check_qty = dosis_qty (1) * strength_qty (250 mg) * frequency (3 /d) = 750 mg/d.

For the i.v. example above this term would be

dosis_check_qty = dosis_qty (100 ml) * strength_qty (1) / rate_qty (1 h) = 100 mL/h

which can be calculated on a daily basis as

dosis_check_qty = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d.

So, in Japan, the denominator of the dosis_check_qty unit must always be 1 /d.  In other countries the constraints on the dosis_check_qty may be different or, most likely, the attribute would not be used at all.  In any case this dosis_check_qty attribute must not be used to carry any functional information.


NewInfo:
The term "procedure" typically stands for surgical procedures. But the Procedure class covers all direct  care activities, whether performed by physicians, nurses, physiotherapy providers, etc.


NewInfo:
All procedures other than dermatological has an anatomic site of access or entry and an anatomic site which the procedure is targeted at and that is reached through the entry site.  For example an arteria pulmonalis catheter targets a pulmonary artery but the access site is typically the vena carotis interna or the vena subclavia, at the neck or the fossa subclavia respectively.

The coding system is the same as for Service.body_site.


NewInfo:
Supply orders and deliveries are very simple services that mainly focus on the delivered product.  The product is associated with the supply service as a Material target of type product (PRD).  Just as with Medication services there are in principle two ways to represent the type and identity of supplied material, i.e. as the Supply.type_cd or as the Material.type_cd of the target material (Target.type_cd = product.)  With general supply orders the precise identification of the Material, its manufacturer, serial numbers, etc. is important, and supply services are only very marginal parts of the electronic patient record.  Therefore, most of the detail information about the supply should be represented using the Material class. 

Note that if delivery needs to be scheduled, tracked, and billed separately, one can associate Transportation services with the supply.

Pharmacy dispense services are represented as supply services, associated with a medication service.  The medication class represents the administration of medication, while dispensing is supply.


NewInfo:
Specifies the quantity ordered or supplied (depending on the mood_cd.)  This is a physical quantity (PQ) that must be from a constrained set of extensive “amount” kind of quantities. Refer to Section 2.7.1.10 for a definition of such “amount” quantities.


NewInfo:
Diet services are very much like supply services, with some aspects resembling Medication services: the detail of the diet is given as a description of the Material associated as a target of type product.  Medically relevant diet types may be communicated in the Diet.type_cd, however, the detail of the food supplied and the various combinations of dishes should be communicated as Material instances.


NewInfo:
The most important medically relevant parameter of a diet order is the supplied biologic energy (Calories) per day.  This value may be specified in the Diet.energy_qty attribute as a physical quantity.  This physical quantity should be convertible to 1 kcal/d (or 1 kJ/d.)  Note, that there is a lot of confusion about what is a “calorie.” There is a “large Calorie” and a “small calorie.”  On “nutrition facts” labels, the large “Calories” is used.  More appropriately, however, one should use the small calorie, which is 1/1000 of a large Calorie.  In the Unified Code for Units of Measure, the proper unit symbol for the large calorie is “[Cal]” and for the small calorie it is “cal”, or, more commonly used as a kilo-calorie “kcal”.


NewInfo:
For diabetes diet one typically restricts the amount of metabolized carbohydrates to a certain amount per day (e.g., 240 g/d).  This restriction can be communicated in the carbohydrate_qty.

Rationale:
Although not typically used in the U.S., the carbohydrates are a routine parameter in diabetes mellitus diet orders in Germany.

Issue:
Unclear whether the same should not be expressed as associated observations in goal mood (observation.type_cd = carbohydrate intake.)


NewInfo:
The condition node service type is used to represent problems (medical conditions.) The primary purpose of the condition node is to arrange other services of the patient record into a longitudinal thread that represents the patient’s condition.  Condition nodes are lined up along the time axis through links of type updates condition.  Thus, a Condition node instance is not a condition or problem in itself, the condition is the entire thread or network of chain-linked condition nodes.  

Each condition node represents a revision of the problem in the form of added evidence, or changing of the “name” assigned to the problem.  A “name” is assigned to a problem thread by a condition node that binds another observations (diagnosis) to the thread.  Consequently, conditions may change their “names” over time to represent the progression of disease, and the changing of knowledge about the disease.

A condition thread may have more than one current name.  Consequently, conditions may accumulate names over time as different practitioners develop opinions or descriptions of the condition.  It will not be unusual that these names may be in conflict with one another, such as when two clinicians disagree about the nature of a condition.  In addition, these names may also change over time to represent the progression of disease or the changing of knowledge about the disease.


Changed Model Element:
Condition_node is specialization of Service


Changed Model Element:
Condition_node :: defines(0..1) :: Episode_of_condition :: is_defined_by(1..1)

NewInfo:
This association binds an episode of condition to a condition thread that defines that episode.

Rationale:
From RIM092, renamed "Episode* :: links_condition" to "Episode* :: is_defined_by" to maintain consistency of the meaning of this association (the association roles must be reciprocal, and one role "links condition" should not imply a broader meaning than the other "defines".)


NewInfo:
Transportation is the moving of a payload (people or material) from a location of origin to a destination location.  Thus, any transport service has the three target instances of type payload, origin, and destination, besides the targets that are generally used for any service (i.e., performer, device, etc.)

Rationale:
Transportation of patients or material is an important support activity in the delivery of health services.  Transportation is usually performed by other responsible parties than the health care providers who do the medical work on the transported payload.  Therefore transportation is a service of its own right, with separate actors, separate scheduling, and separate billing.


Changed Model Element:
Transportation is specialization of Service


NewInfo:
The Consent class represents informed consents and all slimilar medico-legal transactions between the patient (or his legal guardian) and the provider.  Examples are informed consent for surgical procedures, 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 kinds of purposes, that remind the physician about the topics to mention.  Such forms also contain patient education material.  In electronic medical record communication consents thus are information entities on their own and need to be managed similar to medical activities.  Thus, consents are modeled as a special class of Services.

The “signatures” to the consent document are represented electronically through Actor instances to the consent object.  Typically an informed consent has actors of type performer (the physician informing the patient, and consenter, the patient or legal guardian.  Some consents may associate a witness or a notary public (e.g., living wills, advanced directives.)  In consents where a physician is not required (e.g. living will,) the performer may be the patient himself or a notary public.

Some consents have a minimal required delay between the consent and the service, so as to allow the patient to rethink his decisions.  This minimal delay can be expressed in the service definition by the service_relationship.pause_qty attribute that delays the service until the pause time has elapsed after the consent has been completed.

Rationale:
Obtaining informed consents is an important medico-legal activity.  Consents need to be documented just as any other medical record information, with proper attribution, and all the context of who, whom, when, where, etc.  The obtaining of a consent takes a considerable share of a physician’s time and needs to be scheduled in a more or less formal way.


NewInfo:
The Material class represents all physical and physiological things that are used, assessed, and acted upon in a service action.   This includes pharmaceutical substances or disposeable supplies as well as durable medical equipment, prosteses, implantable devices, accesses, drains,  literally everything.

Notably the material class includes facilities, such as immovable service locations or ambulances.

Rationale:
Since all material has common information elements and is subject to common business processes such a super class for anything is necessary to unify the various business processes that involve material.  These business processes include: acquisition, materials management, stock inventory, trade (supply and purchase orders,) equipment and facility maintenance,  resource scheduling, dispensing (pharmacy), and manufacturing (recipe orders, prosteses.)


NewInfo:
As a substantive class reflecting physical entities, material has instance identifiers.  Note that an instance identifier is a pure identifier and not a classifier.  That means, this identifier is not used to store information about what kind or type of material this is.  Ideally each entity will have only one identifier assigned to it, however, since different systems will maintain different material data bases, there may be different instance identifiers assigned by different systems.

Note that for serial numbers assigned by specific manufacturers, catalog numbers of specific distributors,  or for inventory numbers issued by owners, the attribute Responsibility.material_id : SET<II> can also be used.  This allows to more clearly express the fact that such a code is assigned by a specific party associated with that material.  In any case, all values of Responsibility.material_id may occur in Material.id just as well.


NewInfo:
This code describes what kind of material this is.  It is an arbitrarily precise classification.  We do not expect any single terminology to provide all concepts that are types of material, since it is simply too broad a domain. Instead of limiting the Material.type_cd to a single domain, we allow various code systems to be used, and thus, the actual domain of Material.type_cd becomes the union of all the possible code systems for material.

For example, specimen types (e.g., whole blood, serum, urine) can be used in this attribute.  For chemicals, IUPAC codes might be used here.  For arbitrary products one can use the Universal Product Code (UPC) code or a particular manufacturer’s serial number.  For pharmacological substances yet another coding system may be applicable such as the U.S. National Drug Code (NDC.)  The concept descriptor data type allows for multiple codes used as synonyms for each other, thus, one can specify an UPC code next to an NDC code and an IUPAC code.


NewInfo:
This is a classifier describing the form of the material.  This includes the typical state of matter (solid, liquid, gas) and, for therapeutic substances, the dose form.


NewInfo:
A free text description of the material.  May contain multimedia, such as a drawing or image depicting the material.


NewInfo:
The status_cd tracks the state of the state-transition model of the material.  This may be a rather trivial state-transition model, since the more concrete and detailed state-transition models may be assigned to the material role classes.


NewInfo:
The time interval a certain material is in existence.  The high boundary of this interval is the expiration date if it is defined for the material.

Expiration dates does not always have a “day” component; therefore, such a date may be transmitted as YYYYMM.


NewInfo:
The lot number is the number printed on the label attached to the container holding the substance and on the packaging which houses the container.  A “lot” is a collection of products produced in one cycle.  This means, for instance, if one bottle of a lot is spoiled, chances are high that the entire lot is spoiled.  Conversely, product defects that occur in routine production are likely to be contained in one lot. 

Note that a lot number is not meant to be a unique identifier, but is meaningful only when the product kind is identified.


Rationale:
A lot number is not meant to be a unique identifier, but is meaningful only when the product kind is identified.


NewInfo:
A code to describe how the material needs to be handled to avoid damage.  

Concept	Implies	Code	Definition
room temperature		RMT	Keep at room temperature, about 20 ?C
body temperature		BDT	Keep at body temperature, about 36 to 37 ?C
cool		COO	Keep cool at about 5 to 8 ?C
frozen		FRZ	Keep frozen below 0 ?C
deep frozen		DFR	Keep deep frozen, below  – 16 ?C
nitrogen		NTR	Keep in liquid nitrogen
dry		DRY	Keep in a dry environment
dark		DRK	Protect against light
no shock		PSO	Protect against shock
upright		UPR	Keep upright, do not turn upside down
no shake		PSA	Do not shake
… more …


NewInfo:
A code signaling whether there are certain dangers or hazards associated with this material.

Concept	Implies	Code	Definition
tissue		TIS	The normal dangers associated with normal human or animal tissue. I.e. potential risk of unknown infections.  Routine blood or excretions of humans and animals.
infectious		INF	Material known to be infectious with human pathogenic microorganisms.  Those who handle this material must take precautions for their protection.
biohazard	infectious	BHZ	Material contains microorganisms that is an environmental hazard.  Must be handled with special care.
radioactive		RAD	Material is a source for ionizing radiation and must be handled with special care to avoid injury of those who handle it and to avoid environmental hazards.
poison		POI	Material is poisonous to humans.  Special care must be taken to avoid incorporation, even of small amounts.
acid		ACI	Material is acid and may cause severe injury to human skin and eyes. Avoid any unprotected contact.
inflammable		IFL	Material is highly inflammable and in certain mixtures (with air) may lead to explosions.  Keep away from fire, sparks and excessive heat.
explosive	inflammable	EXP	Material is an explosive mixture. Keep away from fire, sparks, and heat.


NewInfo:
For many materials, the individual thing has no relevance.  Especially continuously divisible forms come only in “amounts” rather than as individuals.  There is a specific class of physical quantities that can be used for amounts, count (number), amount of substance, mass, and volume.  This class of physical quantities is called “extensive” quantities.  A quantity is called extensive if it can be added up (if it is additive.)  For example, if you have 1 gallon of water and you add another gallon of water, you wave two gallons of water, since volume is an additive quantity.  By contrast, if you have one gallon of Glucose 5% and add to it another gallon of Glucose 5% you still have Glucose 5%, thus, mass fraction is not an additive (extensive) kind of quantity.  

Only extensive quantities are permitted as elements of the Material.qty set.  Typically the kinds of quantities shown in Table 34 will occur.  Extensive quantities are simpler to deal with than intensive quantities.  Extensive quantities are never fractions or ratios, no denominator can cancel out the units of a numerator, and therefore, with extensive quantities we can conclude the kind of quantity from the unit of measure.

Table 34: Kinds of quantities for amounts of material
Kind of quantity	Typical Unit	Forms	Examples
Number	1	solid	Material that is large enough that is can be counted (“eaches”)
Mass	1 g	liquid, solid	Tissue, chemical substances, food.
Amount of substance	1 mol	all	Chemical substances, small particles.
Volume	1 L	liquid, gas	Chemical substances in liquid and gas state. Amorphic tissue.
Length	1 m	solid	Long material measured in length, e.g., tape, pipes, hose, etc.
Area	1 m2	solid	Flat material measured in area, e.g., covers, foils, etc.
Energy	1 J, 1 kcal	solid, liquid	Chemical substances, especially food.
Catalytic amount	1 kat, 1 U, 1 i.U.	all	Enzymes and other chemical substances having catalytic activity.
Radioactivity	1 Bq, 1 Cu	all	Radioactive substances.
Reaction equivalent	1 Eq	all	Ionized chemical substances measured through titration. Deprecated, use proper amount of substance instead.

The Material.qty attribute permits to convey a collection of physical quantities.  This collection feature must be used in the following way.  When the set contains more than one quantity, the quantities must have different units.  Furthermore, all quantities in the set must denote an equivalent amount.  For example, for the material Glucose, we may specify an amount as the mass of 1 g.  If we also want to specify the amount in amount of substance (moles) we must specify the equivalent of 1 g Glucose in mole, which is 5.556 mmol.  For another example, if we specify the amount of a material Water as 1 L, and we want to provide a mass, the mass must be the mass of 1 L water, which is 1 kg.

Rationale:
By specifying the amount in multiple units representing multiple kinds of (extensive) quantities, we not only allow for flexibility.  This brings about a simple yet powerful way to represent material constants, such as molar mass, molar volume, mass density, biologic energy content, etc.  So, if we specify mass, amount of substance, volume and energy content of a substance, we can convert to any of those kinds of quantities given any other quantity.


NewInfo:
Material relates to other material largely in some kind of whole-part or containment relationship.  The special functioning of the material relationship depends on the nature and role of material, i.e. whether the material is a discrete thing, a homogenous amorphic substance, a container, a facility, etc.

Analogous to the service relationship, the material relationship is a directed link between material entities.  This means, the relationship is like an arrow with a butt and a point.  The entity at the side of the butt is called the source, and the entity at the point is called the target of the relationship.


Changed Model Element:
Material_relationship :: has_source(1..1) :: Material :: is_target_for(0..*)

NewInfo:
A material relationship is like an arrow with a butt (source) and a point (target).  A Material instance is on each side. This association is the source (butt) of the arrow. 

For example, if the material relationship type is called "has_part" then the source material represents the whole of which the target is a part.  Note that the material_relationship.inversion_ind attribute can invert the meaning of the relationship.


Changed Model Element:
Material_relationship :: has_target(1..1) :: Material :: is_target_for(0..*)

NewInfo:
A material relationship is like an arrow with a butt (source) and a point (target).  A Material instance is on each side. This association is the target (point) of the arrow. 

For example, if the material relationship type is called "has_part" then the target material represents the part and the source the whole.  Note that the material_relationship.inversion_ind attribute can invert the meaning of the relationship.


NewInfo:
Material relationships can be of different types, i.e., may express different kinds of relationships.  The relationship concepts are exhaustively defined in USAM specification Table 35, that is. The concepts of that table must be used.

Every relationship type implies certain roles for the material at each side of the relationship.  The notion of roles in a material relationship is very similar to material roles as defined in Section 2.8 below.  Where in Table 35 the roles are so generic that they are not represented as a material role class in the model, that generic role name is printed in italics.  Role names in upright font refer to the same concept as represented by the material role class of the same name.  In general a material filling that role should be accompanied by the detail defined in the role class, but it is not an absolute requirement.  For example, if a material is taken as a container but none of the container-specific attributes are applicable, the instance of the Container role class need not be present.


NewInfo:
The role type may be used in the opposite direction.

For example, instead of listing a material instance representing a mixture and subordinate to it mentioning the ingredients as target material instances, one can use one ingredient and subordinate to it mention the mixture in which it happens to exist.  This is the common way of thinking of pharmaceuticals.  In most pharmaceuticals, we have one main ingredient which we consider “therapeutically active” and which we mention, although we know that this substance always comes as an ingredient of a mixture containing diluents, stabilizers, preservatives, flavors and colors.  This active ingredient can then be specified as the top material instance ->inverted ingredient -> mixture -> ingredient -> other ingredients. 

Another notable example for inversion of the relationship type is for containers.  The content relationship type allows one to first list a container (e.g. package) and then provide a list of content as subordinate (target) material.  In other cases, one wants to mention the material first and by the way describe it being contained in a container.  Therefore, when the content is the important thing and the container just goes with it (e.g., for most medications,) one will use the inverted content link.


NewInfo:
For some transient relationships between material one can specify a time in which the relationship is valid using the Material_relationship.tmr attribute.  As with any interval of points in time, a start time, an end time, or a just a duration may be specified.


NewInfo:
Some containers have discrete positions in which content may be located.  Depending on the geometry of the container, the position may be referenced as a scalar ordinal number, or as a vector of ordinal numbers (coordinates.) Coordinates always begin counting at 1.  

Some containers may have customary ways of referring to the positions.  Take a checkboard, for example, in which rows are specified A-H and columns specified 1-8.  In these cases, the non-numeric coordinate must be converted into a numeric.  The in absence of any specific regulation for a specific container type, the rule of thumb is that the coordinate that is changed earlier is positioned first.  For the checkboard example, this means that the columns are changed or traversed first.  When you start placing the figures in the start position, you chiefly align them in the columns, and only then you start moving them ahead in rows (and columns too.)

For an automated blood chemistry analyzer, with a square shaped tray, this means that the first coordinate is the one in which direction the tray moves at each step.  Whereas the second coordinate is the one in which the tray moves only every 10 (or so) steps. 

As a final example, the positions on a computer screen that works in usual left-to-right and top-to-bottom direction, the columns would be the first coordinate and the lines would be the second coordinate.  (Note however, that this is just an example to clarify the rule.  It does not mean that a character displayed on a screen would be an instance of the Material class.  In fact, it’s immaterial.)


NewInfo:
This attribute specifies how much of the target material is contained in the source material of a relationship.  For example, if a box contains 10 eggs, the box is the relationship source is the box and the relationship target is the egg, where the relationship quantity is 10.   For mixtures with multiple ingredients, the relationship quantities specify the relative amounts of the ingredients in the mixture (proportion.)  

The quantity must be a quantity that specifies an “amount” (refer to Table 34 in Section 2.7.1.10).  The amounts specified as the proportion quantity for each ingredient are taken to be numerators over the same denominator.  For example, D5W is a mixture consisting Water (H2O) and 5% (= 50 g/L) Glucose (Glc.) The proportions can be either of the following pairs: H2O:1 g + Glc:50 mg; H2O:1 L + Glc:50 g; H2O:500 mL + Glc:25 g; or any combination that amounts to the same concentration of Glucose in Water.

Note that the value of the proportion quantity does not matter as long as the proportion between the ingredients of a substance is kept invariant.  If, for example, we specify D5W as having ingredients 500 mL of H2O and 25 g of Glucose this does not mean that D5W could only be dispensed in multiples of 500 mL.

Rationale:
The benefit of specifying the proportion in terms of amounts is that it is simple and straightforward, and there is no ambiguity that we often face with intensive measures, such as concentrations, mass fractions vs. mass ratios, etc.  For example, the unit percent (%) is ambiguous, since it could be a mass fraction or a volume fraction or any kind of ratio.  All ratios are ambiguous since one needs to know what is the numerator substance and what the denominator substance.  This ambiguity is all removed by specifying the proportion in terms of extensive measures (additive amounts.)


NewInfo:
Material can have many kinds of relationships with Stakeholders.  We subsume all the relationships between material and stakeholders under the notion of Responsibility.  The reason being that responsibility for the existence of material, any specific property of material, or performance of functional material (devices) is with some stakeholder.  The underlying reason for stakeholder associations to material is that the material is somehow acted upon by the stakeholders.  In that sense, one could subsume the Responsibility association under the Service action class.  However, just as we chose to represent minor sub-activities around Services as Actors with various actor types, we allow the responsibilities that come from actions of stakeholders to be persistently “coined” on the material.

For example, manufacturing is certainly an activity (Service) with the manufacturer (Organization) as an Actor and the material as a Target of type product.  However, in many cases we are not interested in the activity of manufacturing the material, when it took place and what its circumstances were, but what we are interested in is just: who made it?  This interest in the manufacturer is chiefly one of responsibility and liability: if the material is different than expected, does not perform well, or does harm, one would probably consider holding the manufacturer liable.  Responsibility and liability are concepts that form the very basis of a society based on the law, and emphasis on those terms should by no means imply an undue “legalization” of relationships.

Other relationship types between Material and Stakeholder are: owner, distributor, custodian/holder.  All those relationships can be considered to be characterized by responsibilities.  This even goes so far as if a human fetus would be considered Material, motherhood (and fatherhood!) would be a type of Responsibility between a Stakeholder (Person) and that fetus.  This example shows that responsibility has two aspects: responsibility is not only being held liable by others for malfunctioning, disappointment, and harm caused by the material; responsibility also means an ethical responsibility towards the “material” and even to the extent of being held liable by society for neglect of one’s responsibility towards that “material.”  This latter kind of responsibility is clearly present between fetus and parent, but also between animal and owner or custodian.


Changed Model Element:
Responsibility :: for(1..1) :: Material :: is_the(0..*)

Rationale:
Responsibility is a purely associative classes.  This means, its instances have no use nor identity apart from the Material and Stakeholder that they connect. For this reason the association role names are very short.  These role names are read as "Material is the 0..* Responsibility of 1..1 Stakeholder" and "Stakeholder has 0..* Responsibility for 1..1 Service".


Changed Model Element:
Responsibility :: of(1..1) :: Stakeholder :: has(0..*)


NewInfo:
Specifies the kind of responsibility of the Stakeholder to the Material.

Concept	Implies	Code	Definition
manufacturer		MAN	Someone bringing a specific material instance into existence, or, if the material is not a specific instance, someone capable of doing so.
distributor		DST	Someone distributing material between a manufacturer and a buyer or retailer.
retailer	distributor	RET	Someone selling a material, also giving advice to prospective buyers.
transporter		TRP	Someone in transient possession of a material for the purpose of relocating it.
owner		OWN	Someone to whom law grants the right to call a material his own, which entitles him to make decisions about the disposition of that material.
holder		HLD	Someone who is currently in possession of the material, who holds, or uses it, usually based on some agreement with the owner.
trainer		TRN	Of a companion animal, someone who is training the animal on behalf of the animal’s owner.
parent		PRN	One of the two direct ancestors of a human fetus, in case a fetus is not considered a person.
father	parent	FTH	The male parent of a human fetus, in case a fetus is not considered a person.
mother	parent	MTH	The female parent of a human fetus, in case a fetus is not considered a person.


NewInfo:
Allows to specify a limitation in time during which the responsibility holds.


NewInfo:
The same piece of material may be given different identifiers by different responsible parties.  For example, a manufacturer may assign a manufacturer id, a distributor may assign a catalog number, etc.  All those identifiers can in principle occur under the Material.id attribute, i.e., as a property of the material itself.  However, this attribute allows to make the scope of the id more clear, i.e. it helps to easily distinguish a specific manufacturer’s id from a distributor’s id much more directly and obvious as can be done using the assigning authority component of the instance identifier data type.


NewInfo:
According to Webster’s dictionary, a specimen is “an individual, item, or part considered typical of a group, class, or whole” or “a portion or quantity of material for use in testing, examination, or study.”  In the practice of clinical medicine and especially in previous HL7 specifications,  specimen was tightly related to the container which holds the specimen.   However, there is an important difference between a container and a specimen.  Through the material class with roles for both specimen and container one can manage containers separately from specimen.  With the same class one can manage empty specimen containers (material management) the same way as the container filled with specimen.


Changed Model Element:
Specimen :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


Changed Model Element:
Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..*)


Changed Model Element:
Specimen :: is_sourced_from(0..1) :: Person :: is_source_for(0..*)


NewInfo:
Body site has been retained as an attribute of the specimen, since it may be relevant in some cases, e.g., if multiple liver needle biopsies are taken from different lobes and locations of the liver.  The value of the Specimen.body_site_cd should be identical to the value of the Service.body_site_cd of an associated specimen collection service.  This attribute therefore is used only if such an associated specimen collection service is not communicated.  When the rule is to always send a specimen along with a record of the specimen collection service, this attribute needs not be valued.


NewInfo:
A container is a thing that is used to hold other things for some purpose of transportation or to protect its contents from loss or damage. Especially with amorphic substances (liquids, gases) the content can not be had without some container.  However, the content of a container is always distinguishable and relatively easyly separable from the container, unlike the content (ingredient) of a mixture. 

A container is related to a content material through a Material_relationship of type content.

OtherInfo3:
The design of the Container role class is heavily


Changed Model Element:
Container :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


NewInfo:
From NCCLS, a geometric property of the container.

Issue:
How do we know that we do not need to describe other arbitrary properties of containers? If we do, how do we do that?


NewInfo:
From NCCLS, the kind of separator material.

Issue:
Code appears to be undefined.  This attribute will be dropped if we do not get in a half-way complete concept repertoire by September 2000.


NewInfo:
Access tubes and drains are anything used (actually) to administer therapeutic agents (medication and vital elements) into the body, or to drain material (e.g., exsudat, pus, urine, air, blood) out of the body.  Typically an access is a catheter, cannula or flexule proceeded into a compartment of the body.

Therefore, (target) body site and entry site are attributes of the access.  Note that the Access role primarily exists in order to describe material actually deployed as an access, and not so much the fresh material as it comes from the manufacturer.  For example, in supply ordering a box of catheters from a distributor, it is not necessary to use the access role class, since the material attributes will usually suffice to describe and identify the product for the order.  But the Access role class is used to communicate about the maintenance, intake/outflow, and due replacement of accesses and drains.

Material in the role of an Access is typically used in intake/outflow observations, and in medication routing instructions.  Microbiologic observations on the material itself or on fluids coming out of a drain, are also common.

Rationale:
Especially in intensive care units, the management of accesses is a task that needs explicit support in information models.  In the past, it was difficult to impossible to track the life-cycle of one particular access, since one usually only has recordings of activities (placement, exchange, etc.) on accesses, tracked by site and time stamps of those activities.  Note, while the access hose or cannula itself may be considered a device, the Access role focuses of the specific functioning of an access.


Changed Model Element:
Access :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


NewInfo:
The gauge of an access is a measure for the inner diameter of the tube (the lumen.)  Typically catheter gauge is measured in terms of units not seen elsewhere.  Those units are defined in the Unified Code for Units of Measure.


NewInfo:
The Access.entry_site_cd specifies the anatomic site where the access first enters the body.   For example in a arteria pulmonalis catheter targets a pulmonary artery but the access entry site is typically the vena carotis interna at the neck, or the vena subclavia at the fossa subclavia.

The coding system is the same as for Service.body_site.

Entry site has been copied from the Procedure service class into the Access role class. The value of the Access.entry_site_cd should be identical to the value of the Procedure.entry_site_cd of an associated access placement service.  This attribute is used if such an associated access placement service is not communicated.  Since accesses are typically placed for a considerable period of time and since the access is used as a Target (resource) of many services, the entry site seems to have become an important attribute of the access itself.  The entry site is one of the most distinctive descriptors that help in locating a specific access among many others.


NewInfo:
This is the anatomical target site of the access, i.e., the body compartment into which material is administered or from which it is drained. For example, a pulmonary artery catheter will have the target site arteria pulmonalis with or without a known laterality.

The coding system is the same as for Service.body_site.

Body site has been copied from the Service class into the Access role class. The value of the Access.body_site_cd should be identical to the value of the Service.body_site_cd of an associated access placement service.  This attribute is used if such an associated access placement service is not communicated.  Since accesses are typically placed for a considerable period of time and since the access is used as a Target (resource) of many services, the target body site seems to have become an important attribute of the access itself.  The body site is an important information that determine what kinds of substances may or may not administered (e.g., special care to avoid medication injections into an arterial access.)


NewInfo:
Food is a role of material.  Food is anything that is ingested by humans to address hunger and provide nutrition to the body.  Food is often combined into dishes, which are combined into full meals.  Since the Material_relationship class can express this combination there are little additional properties needed in the food class.  There is only one classifier attribute that seem to be relevant and special for food.  We call that classifier “preference”, which is described below.


Changed Model Element:
Food :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


NewInfo:
The food preference describes the “style” and properties of the food that is selected mainly to meet the preference and customs of the recipient of the food.  The term “preference” was selected to express that this property of food meets a preference of the consumer, not in order to limit this attribute to describe only the preferred style of food but not the actual style.  The following concept repertoire is defined:

Table 40: Preferences, or “styles” of food
Concept	Implies	Code	Definition
non-vegetarian		NVEG	Supposedly every reasonable food is permitted.
no beef	NVEG	NBEF	Everything but beef (e.g., a hindu will absolutely not eat beaf.)
no pork	NVEG	NPRK	Everything but pork (e.g., muslims and jews)
kosher	NPRK	KOSH	Prepared after the traditional jewish rules
no beef and no pork	non-veg.	NBOP	Everything except beef and pork (e.g., many hindus today will not eat beaf, but will also stay away from pork), allowed meat is mutton, poultry, and fish.
no meat but fish	non-veg.	NMBF	Fish is the only allowed meat.
vegetarian		VEG	No meat at all. The only allowed animal product is egg and milk.
vegan	VEG	VEGN	vegetarian without eggs


NewInfo:
A device is anything used in an activity without being substantially changed through that activity.  This includes durable (reuseable) medical equipment as well as disposable equipment.

There are a few device concepts defined by HL7 version 2.3 which are suggested for use in HL7 v2.3 as Material.type_cd values if the material is a device of one of the defined kinds and if it is not otherwise specified.  See USAMP documentation, Table 38.

Table 38: Devices commonly used to administer medication (from HL7 v2.3 table 0164)
Value	Description	Value	Description
AP	Applicator	IVS	IV Soluset
BT	Buretrol	MI	Metered Inhaler
HL	Heparin Lock	NEB	Nebulizer
IPPB	IPPB	PCA	PCA Pump
IVP	IV Pump

Issue:
Currently there are no attributes of device that would not also be applicable to any kind of material.  This role class is shown anyway, in order to make the use of material for devices obvious.  If there are no properties defined for this class by September 2000 it will be deleted from the model.


Changed Model Element:
Device :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


NewInfo:
Indicates wheter the device can be moved to a location of service or whether the other targets of service must come to the location of the device.


NewInfo:
Duration for a single schedulable unit in a schedule for a resource.


NewInfo:
A therapeutic agent is anything that is brought to interact with the human body in order to achieve therapeutic effects.

Issue:
Currently there are no attributes of therapeutic agent that would not also be applicable to any kind of material.  This role class is shown anyway, in order to make the use of material for therapeutic agents obvious.  If there are no properties defined for this class by September 2000 it will be deleted from the model.


Changed Model Element:
Therapeutic_agent :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


Changed Model Element:
Master_patient_service_location :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)


NewInfo:
A service list is owned by one and only one Stakeholder, which may be an individual, or organization (e.g., care team.)  A Stakeholder can have multiple service lists.  Each service list has a subject, i.e., a material (e.g. today’s schedule for operating room 12a,) or a patient (patient’s problem list) or another person.  If the service list has no subject but just an owner, the owner is considered the subject.  Thus, any stakeholder can maintain personal to-do lists, diaries, logbooks, etc.


Changed Model Element:
Service_list :: owned_by(1..1) :: Stakeholder :: owns(0..*)

NewInfo:
Each service list is owned by one Stakeholder, which may be an individual practitioner (Person,) or a department or care team (Organization.)


Changed Model Element:
Service_list :: is_about(0..1) :: Person :: is_subject_of(0..*)

NewInfo:
Each service list is about something specific, e.g., a problem list is about a patient (Person.)

This relationship and the relationship Service_list :: is_about(0..1) :: Material :: is_subject_of(0..*) are mutually exclusive. But one of them must be present.  The 0..1 multiplicity is thus not a true optionality.

Rationale:
The "about" link establishes the subject of the service list even before a single service has been entered on the list.


Changed Model Element:
Service_list :: is_about(0..1) :: Material :: is_subject_of(0..*)

NewInfo:
Each service list is about something specific, e.g. the schedule for operating room 12a is about a facility (Material) and the worklist for CAT scan machine 123 is about that machine (also a Material.)

This relationship and the relationship Service_list :: is_about(0..1) :: Person :: is_subject_of(0..*) are mutually exclusive. But one of them must be present.  The 0..1 multiplicity is thus not a true optionality.


Changed Model Element:
Service_list :: has_parts(0..*) :: List_item :: is_part_of(1..1)


Rationale:
As with all identifiers, this is needed to address the same service lists in multiple transactions.


NewInfo:
Code identifying the kind of service list.  Refer to the following Table for defined list types.

Concept	Implies	Code	Definition
schedule		SCH	A work-list, a schedule, or a personal to-do list of items intended to be done.
logbook		LOG	A diary of past services.
issues		ISS	A  collections of any kinds of services as issues that need to be resolved.
problem list	issues	PRB	A patient’s problem list as seen by a particular provider.


NewInfo:
A short name that the owner of the list chooses to find this list among others.  The name must be unique among all the lists that the stakeholder owns.


NewInfo:
A description of this list.  This may be considerable amount of text that explains what the list is for and how it is used.  This is especially relevant if the owner is an organization or work group.


NewInfo:
A list item represents one service on a service list.  It holds sequence and priority numbers to establish the list-specific ordering of the service.


Changed Model Element:
List_item :: represents(1..1) :: Service :: represented_as(0..*)


NewInfo:
The items of the list can be sequenced using this attribute.  It is a real number in order to allow dynamic insertion without having to renumber all the items every time an insertion or deletion is made.


NewInfo:
Items in the list can be ranked by priority.  This is used to help deciding which item to address next when the items are not sequenced.


NewInfo:
A note may be attached to each list.  Since stakeholder owned lists are not part of the medical record, these notes are private notes of the list owner and are not subject to the rules of auditing and archiving that apply to medical record items.


# Affected RIM092 elements

Description:
A role class that captures the multiple roles various entities play e.g., orderer, attending, witness, transcriber, etc., in delivering a service to a target of service.

Rationale:  Since multiple entities participate in the delivery of services to particular targets of service, a role class is needed to capture the multiple roles these participants play in delivering a service to a target of service.

OpenIssue:  There is as need to re-examine the manner in which attending physicians is representing because this will cause two different ways of identifying it.


ModelElement:
Active_participation :: has_as_participant(1..1) :: Stakeholder :: participates_in(0..n)

Description:
Rationale:  replaces the following classes and connections - Service_event_provider, Order_healthcare_practitioner, Advance_directive_witness, Notary_public notarizes 0..m Advance_directive.

Mapping:
Actor :: participation_of(1..1) :: Stakeholder :: participates_as(0..*)


ModelElement:
Active_participation :: participates_in(0..1) :: Service_event :: has_as_active_participant(0..n)

Description:
Rationale:  each Active_participation instance connects to either a Service_event or a Service_intent_or_order.  It therefore cannot have a mandatory connection to either of those classes.  We are lacking the formalism to indicate that one of these two relationships MUST be in effect for each Active Participating instance.

Mapping:
Actor :: for(1..1) :: Service :: has(0..*)


ModelElement:
Active_participation :: participates_in(0..1) :: Service_intent_or_order :: has_as_participant(0..n)

Description:
Rationale:  each Active_participation instance connects to either a Service_event or a Service_intent_or_order.  Therefore, there cannot be a fully mandatory relationship between Active_participation and Service_intent_or_order.  We are lacking the formalism to indicate that one of these two relationships MUST be in effect for each Active Participation  instance.


Description:
The nature or purpose of the participant's participation.  Examples:  order healthcare practitioner, service event provider, advance directive witness, notarizer.


Description:
The effective and termination dates of the active participation.

Rationale:  Manage active participations.


Description:
An authoritative instruction or direction from or on behalf of a patient regarding their healthcare or the disposition of their remains.


Description:
The date and time the advance directive was identified.

Rationale:  To replace attribute previously inherited from Patient_clinical_item.

OpenIssue:  Amplify definition.  Is this when patient or rep made the directive?  When it was noted by a clinician?  When it got an official ID?

Comments:
The high boundary of a time interval.

However, note the interference with Advanced_directive.notarization_dttm


Description:
An indication as to whether the patient was mentally competent when completing the advance directive.

Comments:
Suggested mapping is tentative.  We can as well add the attribute Consent.competence_ind.


Description:
A code depicting the nature of the advance directive.

OpenIssue:  Amplify definition.  Provide indication of how the directive nature is typed.  That is what kind of discrimination is being made.


Description:
The level of disclosure allowed for this advance directive.


Description:
An indication that the advance directive is employment related.

To replace attribute previously inherited from Patient_clinical_item.

OpenIssue:  Amplify definition.  Explain why directives would be employment related.

Comments:
Alternatives are:
a) a code in Service.interpretation_cd 
b) an attribute in Service

note that employment-relatedness may be assumed of observations as well.


Description:
A free for text describing quality of life preference of the patient to be used in making intervention decisions.

Comments:
As a piece of free text it belongs into Service.descr, however, with a little more work this might be coded, and then can become interopeable.


Description:
The name of the patient's preferred mortuary.

Comments:
This should even be an association to an Organization that as the preferred Mortuary.  In this case, "mortuary" may become an Actor.type_cd used in an acvanced directive.


Description:
The date the advance directive was notarized.

Comments:
low boundary of interval

this mapping is under the assumption that a notarization i required for this particular kind of advanced directive.  In most cases no notarization is required, so that the critical_time.low would be the date signed by the author.

This is one of the state history information captured as "slotted time stamps".


Description:
A subclass of Service_event and a superclass that captures the data related to a kind of service that represents abstraction and interpretation of data from a data source and includes observations, metaobservations, assignment of an observation or metaobservation to a problem list of allergy list or goal e.g. lab results, question results, physical exam results, impressions problem list entry, allergy list entry, goal assignment, etc.  This class is orthogonal to Care_event

Rational:  Since multiple kinds of assessments are delivered as a healthcare service, a class is needed to record the nature of those assessments and the resulting values(s) associated with those assessments.  An assessment is a kind of service that describes the collection and interpretation of data from a data source and the nature of that data.  In this class, it also describes the value(s) associated with the action of data collection and interpretation.  

OpenIssue:  Need a better name.

Comments:
Delete without replacement.  This class was an attempt at a taxonomy of Services which is not what a class diagram is used for.


ModelElement:
Assessment :: generalizes(1..1) :: Clinical_observation :: specializes(1..1)

Mapping:
Observation is specialization of Service


ModelElement:
Assessment :: generalizes(1..1) :: Condition_node :: specializes(1..1)

Mapping:
Condition node is specialization of Service


ModelElement:
Assessment :: generalizes(1..1) :: Goal :: specializes(1..1)

Comments:
Remember that "goal" is a mood of an Observation!


Description:
A subclass of Service_event and a superclass that captures the data related to a kind of service that produces a change in the target of service and includes medication administration, surgeries, teaching, dressing changes, therapeutic listening, etc.  This class is orthogonal to Assessment_event.

Rationale:  Since some healthcare services produce changes in the target of service, these actions need to be captured and statused with their own set of attributes.

Comments:
This was an attempt at a taxonomy of Services in the class diagram, which is not what a class diagram is for.


ModelElement:
Care_event :: generalizes(1..1) :: Procedure :: specializes(1..1)

Description:
Rationale:  Allows interrelationship with other service events.


ModelElement:
Care_event :: generalizes(1..1) :: Treatment_service_event :: specializes(1..1)


Description:
Documentation of a health related factor concerning a patient.  See the class Document Header in the MDR 2300 model.

OpenIssue:  This needs to be extended to be the state attribute of the class and to have all of its transition and code values identified.  Needs to be reconciled with the other status codes that exist for this class.  This should be just status_cd rather than completion_status_cd. - the other three fragments must be

OpenIssue:  Expand definition.  Header and "documentation" seem different.  Remove reference to MDR 2300 and replace with explanatory material.

OpenIssue: The State transition diagram needs to be drawn.  Information provided to RIM Harmonization 06/99 included:
DI ---> AU | IN | LA | IP | PA
DO ---> AU | PA | LA
IP ---> IN | AU | LA | PA
IN ---> AU | LA | PA
PA ---> AU | LA
AU ---> LA
LA ---> <final state>


Description:
The information or record secured by an act or instance of viewing or noting a fact or occurrence for some health related purpose.

OpenIssue:  Consideration should be given to the identification that the Gen-Spec (clinical_observation is a specialization of Assessment) may be flawed and that it may be replaced with a simple association.


Description:
A code specifying the degree of abnormality of the observation value, e.g., Normal, Abnormal, Low, High, Critical.  This is NOT trying to represent severity.

OpenIssue:  The committee MUST address the issue of 
how to represent severity of the result, both for clinical and for administrative type observations (for allergy severity representation).


Description:
The clinically relevant begin and end dates/times for the observation.  In the case of observations taken directly from a subject, it represents the actual dates and times of the observation.  In the case of a specimen-associated study, this field shall represent the dates and times of specimen collection.

Rationale: This is the definition that has been developed by the committee and balloted.  This is the field that is wanted in the message, not separate fields for the specimen collection time and the time of the observation.  Often, an interim time is chosen as "clinically relevant".  There would be too much overhead in maintaining separate fields for all the possible interim times.

Comments:
Typically just some point in time (close to the specimen collection time), may be the intervl of the specimen collection service, but that is not necessarily more clinically relevant than some point in time within the specimen collection service. 

For direct observations, this is the time point or interval that the observation was made.


Description:
A code depicting the level of verification for the patient problem (e.g., confirmed, differential, provisional, rule-out, . . .).

Comments:
As far as the confirmation status is coordinated into the code for diagnoses.


Description:
When a Method Code is specified for this observation, this field contains the date and time of changes in the specified method that would make values obtained from a previous version of the method not comparable with those obtained from the current version.

OpenIssue: This is being returned to committee to be reworked to remove the inconsistency between the name and the definition.

Rationale: This information is required here, since by definition the master test file does not distinguish this method from others (see definition of Method_cd attribute), and therefore cannot provide change dates at this level of detail. Such change information must be provided by the observation provider.

Comments:
A the last normal observation can be linked with this observation rather than vaguely cited via a time stamp (that in fact functions as a forreign key here!)

The RIM092 definition of this attribute appears mismatched?


Description:
Used to transmit the method or procedure by which an observation was obtained when the sending system wishes to distinguish among one measurement obtained by different methods and the distinction is not implicit in the test ID.  Chemistry laboratories do not usually distinguish between two different methods used to measure a given serum constituent (e.g., serum pottassium) as part of the test name. See the LOINC Users Manual for a more complete discussion of these distinctions.  If an observation producing service wanted to report the method used to obtain a particular observation, and the method was NOT embedded in the test name, they can use this field.  The Centers for Disease Control and Prevention (CDC) Method Code (CDCM) (see Figure 7-3) is one candidate code system for reporting methods/instruments.  EUCLIDES method codes are another.  User-defined tables are an alternative.


Description:
When an abnormal result code is present, this attribute indicates the type of control population against which the observation was tested for abnormalcy. Control population might be based on age, sex, race, etc., or a combination of these.  It may also be a generic normal range.  Combination control populations are expressed as  multiple individual codes (ie. this attribute must be of the Set datatype).

OpenIssue:

Comments:
… of an Observation in criterion mood linked to an observation in reference mood linked to the observation in event mood.  This is straight forward mapping of the semantics of reference ranges! See discussion about reference ranges.


Description:
This field is used to order multiple related clinical observations delivering the same master service.  

The sub-identifier is also used to group related components in reports such as surgical pathology.  It is traditional for surgical pathology reports to include all the tissues taken from one surgical procedure in one report.  

It can be used to organize the reporting of some kinds of fluid intakes and outputs.  For example, when intake occurs through multiple intravenous lines, a number of separate observations--the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, etc. may be needed for each intravenous line.  If more than one IV line is running, we can logically link all of the observations that pertain to the first IV line by assigning them an observation sub ID of 1.  We can do the same with the second IV line by assigning them a sub ID 2 and so on.  The same would apply to the outputs of surgi al drains when there are multiple such drains.

OpenIssue:  consider whether this should be accomplished in or through the Service_event_relationship.

Comments:
If this (in)famous OBX.sub_id doesn't go away, what use is our modeling for? Of course the sub_id is represented through the service_relationship!!!


Description:
When an abnormal result code is present, this attribute contains the high and low limits of the reference range for quantitative observations, or the normal value for qualitative observations.  The range is taken to be inclusive (i.e., the range includes the end points).  

When the reference range applies to the amount of a toxic substance, then the upper limit of the range identifies the toxic limit.  If the range applies to  a drug, the lower limit identifies the lower therapeutic bound and the upper limit represents the upper therapeutic bound above which toxic side effects are common.

OpenIssue:

Comments:
… of an associated observation in reference mood. See discussion of reference ranges.


Description:
A code indicating the lifecycle status of the clinical_observation.  See state/transition model for an exhaustive list of lifecycle states.

OpenIssue:  Amplify definition.  Provide examples or explain how statuses are differentiated.


Description:
The effective date and time of the clinical result status.

Comments:
The status code can be sent as a history item or a history list of status codes with a time range associated to either the most recent status or more (all) statuses.  That way one can send time stamp information for the entire life-cycle, not just for the most recent status.  Also, that way one can get rid of slotted time stamps whose primary purpose is to communicate status information.


Description:
Suffixes identify the common components of narrative reports.  Each type of narrative report is assigned a universal_service_id.  The actual report components are reported in separate observation service events, all linked to the master service for the report.  The suffix test for the observation further qualifies the observatuion as to which component of the narrative report it contains.

The applicable three-character mnemonics given in ASTM Table 20 (or others appropriate to the application) should be used.  For example, a chest X-ray may use the suffixes IMP, REC, DEV, or others.

Comments:
The subsections of reports are better fully precoordinated into the service.type_cd but canstill be sent as modifiers in the type_cd's code phrase structure.  Remember that the u.s.id suffix was a modifier on the type_cd and modifiers is what the Code Phrase data type was designed for.


Description:
Permits the producer to record results-dependent codes for classifying the observation at the receiving system.  This field should be needed only rarely, because most classifications are fixed attributes of the observation ID and can be defined in the associated observation master file.  However, there are a few cases when such controls vary with the value of the observation in a complex way that the receiving system would not want to recalculate.  An example is an antimicrobial susceptibility result.  Some systems prefer to dispaly only the susceptibility results of inexpensive antimicrobials depending upon the organism, the source of the specimen and the patient's allergy status.  The sending service wants to send all of the susceptibilities so that certain privileged users (e.g., Infectious Disease specialists) can review all of the results but nonprivileged users would see only the "preferred" antimicrobials to which the organism was susceptible.  We expect that other cases also occur.

Comments:
(see this HL7 v2.3 field discussed in USAMP part B)


Description:
Value observed by the observation producer.

Units of measure will be included as appropriate for the datatype of the value.  Also includes the degree of certainty in the observation.

The appropriate generic datatype to represent probability will be bound to the observation value at instantiation, depending on the actual datatype of the instantiated observation value (discrete or ordered), and the nature of the probability representation (narrative or numeric; parametric or non-parametric).


Description:
HL7 datatype in which the observation value and any reference range are expressed. These must be represented according to a data type defined for HL7.

All HL7 data types are valid with certain exceptions (eg. need list from current datatypes).

All data types are valid with certain exceptions (e.g., CM, CQ, SI, and ID).

Comments:
The ANY data type implies the type information about the actual type. In other words, in an ANY data type, the value comes as a pair of data type code and value.


Description:
A sample of a substance or material for examination or study (a urine specimen; a tissue specimen).

Comments:
as a role of Material.  Specimen and Container have been separated in USAMP (this time, the lumper-splitter theme is inverted :-)  See attribute mapping about how this unfolds.  In general, a specimen is related to its container through the Material_relationship class (of type "contains".)


ModelElement:
Collected_specimen_sample :: is_collected_by(1..1) :: Stakeholder :: collects(0..n)

Comments:
The collector can be tracked through the service for which the specimen is a product. The collector does not need to be associated permanently with the specimen.


ModelElement:
Collected_specimen_sample :: is_collected_during(0..1) :: Procedure :: collects(0..n)

Comments:
The collected specimen is a Target of type "product" of a Service.  The collaction service may be a Procedure, Observation action, or some not otherwise classified Service action.


ModelElement:
Collected_specimen_sample :: is_sourced from(0..1) :: Living_subject :: is_source_for(0..n)

Mapping:
Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..*)

Comments:
In any case the Target (Target.type_cd = subject) of the specimen collection service is the source of the specimen.  However, the specimen-material needs a direct link to its source.  The technique depends on the relationship of Living_subject to material.  At this time, a direct association Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..n) is proposed.  However, the plan is to make Living_subject a specialization (not a role!) of material.


ModelElement:
Collected_specimen_sample :: is_sourced_from(0..1) :: Patient :: is_source_for(0..n)

Mapping:
Specimen :: is_sourced_from(0..1) :: Person :: is_source_for(0..*)

Comments:
In any case the Target (Target.type_cd = subject) of the specimen collection service is the source of the specimen.  However, the specimen-material needs a direct link to its source.  The technique depends on the relationship of Living_subject to material.  At this time, a direct association  is proposed.  However, the plan is to make Living_subject a specialization (not a role!) of material.

See Target_participation for the issue with Person vs. Patient as the target.


ModelElement:
Collected_specimen_sample :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)

Description:
Rationale:  Replaces association Collected_specimen_sample is_used_during Service_event.

Mapping:
Target :: participation_of(0..1) :: Material :: participates_as(0..*)


Description:
Action to be taken with respect to the specimens that accompany or precede this order.  Allowable values: Add ordered tests to the existing specimen (A); Generated order; reflex order (G); Lab to obtain specimen from patient (L); Specimen

Comments:
This modeling style is at odds with the MDF. An "action code" of HL7 v2.x is a hidden trigger event (sometimes overloaded with the meaning of a state attribute.)  The code values suggest that this attribute manages the ordering of a specimen collection service, which has a straightforward representation in USAMP -- even in the RIM092! Other uses seem to be the addition of services to an existing specimen, which also has a straightforward representation in USAM and RIM092 alike.  This attribute is superflous in either model!


Description:
Free text representation of additives to the specimen such as Heparin, EDTA, or Oxlate.

Comments:
of type "additive".  This allows properly coded/structured additive information to be sent, allows for multiple additives, allows to specify the proportion of the additive to the specimen (important since additives dillute the specimen!)  If for compatibility with legacy systems the free text description is all we want to require it still goes into the Material.descr of the Material related as additive.


Description:
The body site from which the specimen was obtained.  Coded concepts include:  Ear, Chest Tube, Arm, Lower Forearm, Anterior Chest, Vastus Lateralis, Nebulized.


Description:
The site modifier for the body site from which the specimen was obtained.  For example, the site could be anticubital foss, and the site modifier "right".  Coded concepts include:  right, left, bilaterial.


OpenIssue:

Comments:
Code modifiers are sent in the Code Phrase data type along with the primary code.


Description:
A description of the method used to collect the specimen.


Description:
Indicates whether the specimen is frozen as part of the collection method.  Coded concepts are frozen, refrigerated, room temperature.

Comments:
… of the specimen collection Service.  Code modifiers are sent in a Code Phrase together with the primary code.

Interestingly RIM092 has method_desc (free text) and method_modifier_cd, but not a primary method_cd.


Description:
The date and time the analyzed object is scheduled to be collected.

Comments:
… of the Specimen collection service intent (mood_cd = intent.)  Usually an (estimated) point in time.

Of course, in USAMP-II one can also order the specimen collection to happen at a specific time (e.g., important for a TRH test, or any kind of lab test involving challenges.)


Description:
The start and end dates and times of analyzed object collection.

Comments:
… of the specimen collection service.  Usually an interval of time, just as in RIM092.


Description:
Coded or free text additional comments related to the collected specimen.  Example: difficult clotting after venipunctue and echymosis.

Comments:
… of the specimen collection service.  

Remember, in event mood the description is the description of what actually happened in the service, including (and foremost!) unusual noteworthy things.


Description:
Code and/or text indicating any known or suspected specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient.


Description:
A code indicating the action taken after collection of the sample (e.g., air-dried, refrigerated overnight, maintained at body heat, centrifuged immediately, maintained on ice, . . .).


Description:
Unique identifier of the collected specimen sample.


Description:
Identifies the number of containers for a given sample.  For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

OpenIssue:

Comments:
… of the container-material.  If there are multiple containers one should enumerate all of them rather than just counting their number.  If, however, the content of the containers is completely identical, and if there is no meaningful reason for having two containers (other than just to have more of that specimen,) then, one can use the Material.qty as a number in the class that represents the multiple containers.  Note, the containers are counted, not the (usually amorphic, uncoutable) specimen. Hence the Material instance representing the container is the one whose qty attribute may indicate multiples.


Description:
Contains the specimen source name or code.  Even in the case of tests whose name implies the source, a source may be required, e.g., blood culture-heart blood.  Example sources are abscess, blood arterial, blood bag, burn, dose med or substance, ear, filter, gastric fluid, marrow, patient, tissue, urine.


Description:
The means by which a sample reaches the diagnostic service provider.  This information is to aid the lab in scheduling or interpretation of results.  Coded concepts include:  routine transport van, public postal service.

Comments:
If transportation of specimen (or anything else) is a noteworthy issue (often it is not), then the Transportation service class provides everything needed to order, schedule, document, and bill for that transportation. The generic action management functionality of USAMP are to be used, rather than a non-interoperable  ad-hoc code!


Description:
A code identifying the type of sample collected (e.g., urine, blood, sputum, swab, synovial fluide, ...).

OpenIssue:  committee needs to determine whether this attribute is redundant with Collected_specimen_sample.source_cd.

Rationale:  This is a direct connection between Stakeholder and Collected_specimen_sample because there is no persistent role of "Specimen collector" that a stakeholder can have.  There is no need to resolve a M:M.  There is no need to know effective dates for the stakeholder collecting the specimen, beyond the actual collection dates themselves, which are attributes of the specimen.

Comments:
… of the specimen-material.

Note that RIM092's specimen "source" and "type" were redundant indeed.


Description:
A Condition_node is used to document the action of associating one or more Service_events through one or more Service_event_relationships to a Condition.  As such, a Condition_node is used to document and name a judgment (e.g., clinical, administrative, financial) as to the semantics of the association(s) between instances of service_events and the associated condition.  Over time, multiple Condition_nodes and their associated Service_events and Service_event relationships form a network which represents a judgment as to the existence, form, evolution, life-cycle, and/or priority of a condition.  This network is named by an instance of Condition.

Examples OF CONDITIONS:
Chromosomal anomaly, e.g. sickle cell--begins at conception, lasts for lifetime;
Pregnancy - specific beginning and end, even if not identified until condition has existed for a period of time.

OpenIssue:  Where do all these use cases belong?   Do we need them to make these definitions clear?  Definition needs further work.


ModelElement:
Condition_node :: defines_episode(0..1) :: Episode_of_condition :: links_condition(1..1)

Description:
This association binds an episode to a Condition, whose root node is the associated condition node.

Rationale:  Association to Encounter is determined by association through service_event.condition_node.

Mapping:
Condition_node :: defines(0..1) :: Episode_of_condition :: is_defined_by(1..1)


Description:
An indication that the condition under evaluation is employment related.

Rationale:  To replace attribute previously inherited by Diagnosis from Patient_clinical_item

OpenIssue:  Should this be handled as an explicit diagnosis  in Health_issue or should it be deleted completely, or does this require longitudinal linkage through Condition_node?  

OpenIssue:  This is a candidate for moving or complete removal.


Description:
Indicates the beginning date/time of the current status as indicated in condition_node.lifecycle_status_cd.

OpenIssue:  Description needs to be clearer.

OpenIssue:  Should this be an interval.


Description:
Indicates the current status of the condition.  eg. Active First, Active Baseline, Active Exacerbated, Inactive,

OpenIssue:


Description:
The categories of caregivers with interest in having this specific condition on their condition/problem list.  Examples include nursing, medicine, respiratory therapy, dietary, etc.  The codelist for this should be consistent with the vocabulary list for individual healthcare practitioner type code.


Rationale:  2.3 definition was wrong.

OpenIssue:  Has to be multiple, and how can we indicate when a particular category initiates or withdraws their indicated interest.

OpenIssue:  Consider removing rationale.

Comments:
A problem list is represented by a stakeholder owned Service list.  In inpatient and care team settings, that list will be owned by a team or group (at this point an Organization stakeholder.)  Rather than a non-interoperable code, we use a direct relationship to the owner (group).


Description:
A  number that allows a relative ranking of conditions on an ordered list.

OpenIssue: Formalize use cases for this attribute.

Comments:
A problem list is represented by a stakeholder owned Service list.  In inpatient and care team settings, that list will be owned by a team or group (at this point an Organization stakeholder.)  Ranking is identified through the sequence number in the list


Description:
The link that exists between a current service event or source service event and a previous or target service event which defines a predicate between the result or status of the target service event and the instantiation of the source service event, e.g., begin IV (source service event) if Na was <130 (target service event); repeat medication administration (source service event) if > 1h since last medication administration was completed (target service event).

Comments:
This has only recently been broken out of service_relationship (by some of the USAMP-II authors) for specific reasons (to teach the model.)  It was always understood, that this particular action would yield to whatever the USAM-II would propose.


Description:
A subclass of Service_event that records the collection of consent signatures.

Rationale:  Healthcare requires consents to be collected from various parties prior to some services.  This class allows recording of that action.

OpenIssue:  Expand definition. Consent to what?


ModelElement:
Consent :: generalizes(1..1) :: Advance_directive :: specializes(1..1)

Comments:
Advanced directive is a concept in the vocabulary domain of Consent.type_cd.


Description:
The specification of the amount of financial coverage for a healthcare service or category of services.  Example 1: physician office visit - 100% coverage, no co-pay in network, $15 co-pay out of network.  Example 2: inpatient semi-private room rate @ 100%.  Stop-loss of $2,000 per inpatient stay.  Outpatient coverage: 80% with out-of-pocket limit of $2,000 per year.  Note: each of the above examples would require more than one instance of this class to express.

Rationale:  This class allows clinical and financial systems to communicate with payor systems regarding financial responsibility.

OpenIssue:  Should this Class be 'masterized"?  Is it *really* per patient, or per-plan, or associated in some other way?


Description:
An authoritative direction or instruction concerning the system or course of diet for a patient.


Description:
A code identifying a special diet type for a patient.


Description:
This field defines the specific instructions for dietary.  These instructions may address specific patient needs, such as isolation, or contain special instructions associated with a tray (e.g., "plastic silverware").  This field provides the ordering provider's dietary instructions as free text.  It can represent the full dietary instruction or indicate supplemental information.

Comments:
Note that logically the description in an order is an instruction!  (What else would one describe in an order?)


Description:
A code identifying the service period for a diet order.  This field allows you to order a modification for one or more of the service periods during a day.  Suggested service periods are:  Breakfast, mid-morning snack, lunch, mid-afternoon snack, dinner, bedtime snack.

Comments:
The time of serving and the food that is servced often depend on each other. E.g., a breakfast is a distinguished (though broad) class of meals served in the morning.  Snack is a category of foods (e.g., yoghourt, crackers, etc.)  The time of serving should be specified in the Service.critical_time attribute as a quantitative time or a "symbolic" time (e.g., HS for before the hour of sleep.)

Why should there be an attribute that merges the two different dimensions of timing and food type into one non-interoperable code?


Description:
A code for the type of dietary tray.  Tray specifications are useful for early and late tray delivery in cases where a patient undergoes a procedure during normal feeding times. Tray specifications can also be used for guest trays, no trays, and messages.  A tray message does not specify the type of tray but provides additional information about an existing tray in the text instructions.  Allowed types are:  Early Tray, Late Tray, Guest Tray, No Tray, Tray Message Only.

Comments:
A tray is for food what a container is for specimen.  Thus, a tray is an associated material that holds the food.  May be a container.  Tray is not currently modeled as a special role class.

Note that the v2.3 definition of the Tray issues is very unclear.  This issue needs input from people interested and knowledgeable in diet services.  From the v2.3 definition (that RIM092 recites here) it almost vaguely sounds as if the tray specification would be more about timing or exceptional handling of the diet rather than about some kind of tray material.


Description:
A tangible material item used to perform a Healthcare Service.


ModelElement:
Durable_medical_equipment :: belongs_to(0..n) :: Durable_medical_equipment_group :: contains(1..n)

Comments:
A group of equipment is an equipment that contains parts.  The whole-part type of material relationship is used.  A specific material relationship type may be defined if it is felt that grouping (group-member) and composing (whole-part) are different concepts to be distinguished (likely so.)


Description:
A unique identifier for a specific piece of equipment.

Comments:
Note that an equipment group is a kind of composite material.


Description:
Duration for a single schedulable unit in a schedule for a resource.

Rationale: Provides visibility into scheduling details.

Comments:
For future consideration: this may be generalizeable into an attribute Material.increment_qty so as to specify what the smallest quantum is.  Material.qty itself is not strongly defined as the increment.


Description:
Identifies what kind of equipment the particular instance is.

OpenIssue:


Description:
A pool of like-type equipment available for scheduling purposes.

Rationale: Currently in 2.3

OpenIssue:  There are probably two concepts to be included in scheduling, both of which are vying for attention here.  The first is the ability to establish a pool.  Give me one ventilator, but I do not care which one.  That is covered by the current definition.  The other is the ability to aggregate resources and schedule them as a group or a team.  Schedule a surgical team or request a set of equipment needed for a particular procedure.  This latter grouping is not represented in these classes.


Description:
Request information about equipment that is controlled by a schedule

Rationale: Specializes the request by type of resource

OpenIssue:

Comments:
A resource is requested as because it is needed for a service.  Resource utilization of Services is uniformly modeled as a Target association between Service and Material (in this case.)  The Service mood code used for scheduling requests is SCH.


ModelElement:
Durable_medical_equipment_request :: requests(0..1) :: Durable_medical_equipment_group :: is_requested_by(0..n)

Comments:
… of a Service in scheduling request (SCH) mood. Target is of type "reuseable device".


ModelElement:
Durable_medical_equipment_request :: requests(1..1) :: Durable_medical_equipment :: is_requested_by(0..n)


Description:
The quantity of the specified resource or resource type.

Rationale: Currently in 2.3

OpenIssue: The name quantity_amt is not communicating the meaning of the attribute.

OpenIssue:  We would like better (more explanatory) names for attributes that are meaningful by themselves.


Description:
Identifies what type of equipment or equipment group is being requested in this instance of request.

Comments:
… of a Service in scheduling request (SCH) mood. Target is of type "reuseable device".

Note that this code in RIM092 appears to be redundant given the association between Durable_medical_equipment and D.m.e.request?


Description:
An allocation of time defined when a specific piece of medical equipment is available for use for a healthcare service.

Comments:
on a Service_list of type "schedule" which :: is_about(1..1) :: Material.

The only issue (that is easyly resolved) is that the List_item does not have a Service bound to it in an open slot, and we may want a code in the List_item indicating the slot status … a List_item.status_cd!


ModelElement:
Durable_medical_equipment_slot :: is_scheduleable_unit_for(1..1) :: Durable_medical_equipment :: is_scheduled_by(0..n)

Description:
Association links an item of medical equipment to the calendar slots in which it is scheduled.  A slot gives the starting date-time, and the length of time the item is scheduled for.

Mapping:
Service_list :: is_about(0..1) :: Material :: is_subject_of(0..*)


Description:
A state of being which has a beginning and an eventual end. "End" may represent resolution of an illness or death of the patient, family or other aggregate unit, e.g. population or community. Functionally, an episode of condition is a named, evolving aggregation of service_event.condition_nodes. Composition membership of condition nodes in episode of condition represents a judgment (e.g., clinical, administrative, financial) that the condition relates to one or more condition nodes. Examples include: pregancy, injuries, acute diseases, chronic diseases, risk factors, and wellness deficiencies.


Description:
A charge, credit, or adjustment to charges in a patient's billing account.


Description:
This class represents the setting or modification of a goal.  Setting a goal includes a statement that a hoped-for observation value, value range, or observation pattern will be the result of a particular observation on a specific date/time in the future. Specifically, goal setting is made up of the following three components:  the value or value set, the target date, and the named observation that measures progress towards the goal.


Rationale:  For Goal is specialization of Assessment- this class captures the hope to meet a specific goal by a specific date.  Note that the measurement of the gap between the "real observation" and the hope is itself a metaobservation and is captured under Calculated_observation.  Also note that the measurement of the "real observation" is captured as well under Target_observation.

OpenIssue:  Need to have vocabulary define a service name and value set for service_event.clinical_observation which covers "goal-gap determination: A code depicting the progress towards achievement of the goal (e.g., achieved, ahead of schedule, delayed, ...)


ModelElement:
Goal :: is_measured_by(1..1) :: Master_observation_service :: measures(1..n)

Description:
The connection to the observation method that is needed to measure progress towards the goal, e.g., WBC for a WBC goal of 10,000; ambulation assessment for an ambulation goal of 20 feet.

Rationale:  Goal_set definition includes three needed elements:  date in the future, name of the observation method and hoped for observation value.

Comments:
of type instantiates.  An observation in goal mood instantiates a master observation into goal mood, just as an observation in event mood instantiates a master observation into event mood.


Description:
Date goal is expected to be achieved

Rationale: Conformance with v 2.3

OpenIssue:

Comments:
same considerations as for Observation critical time.  The Observation critical time never catches the exact time of onset of the observed physiolosgical state, but is merely a point within the interval for which the physiological state may be asserted as true (given some tolerance.)


Description:
A number that allows a relative ranking of goals on an ordered list.

Comments:
A goal list is, like a problem list, a kind of Stakeholder owned Service_list.


Description:
Value of goal-setting action which may be coded, numeric, or a range, e.g. "20 feet" for an ambulation goal; "successful" for a speech goal.

Rationale:  Vocabulary reference

OpenIssue:  See class definition requires complex datatype for value of goal_set.  Cd is not sufficient since the value of a goal may be a code or may be numeric or a range.  This is a candidate for that funky "any" datatype.  Attribute name needs to be updated once MnM and CQ resolve the "any" datatype issue.


Description:
A code indicating the caregiver disciplines responsible for managing a patient pathway goal.

OpenIssue:  Definition not clear; not evaluated since USAM.

OpenIssue:  Since this is a coded data type, it needs example codes.

Comments:
… associated to the goal class.  Typically the Actor is a care team (an "Organization").  The actor who sets the goal takes on responsibility for tracking it. 

In addition, goals may live on different Stakeholder's Service_lists (of type "goal list", or more generally "issues" list.)

Discipline_cd (just as the service_section code) is no longer a (non-interoperable) code but an explicit association to a stakeholder!


Description:
A code indication the review interval for the patient pathway goal.

OpenIssue:  Definition not clear; not evaluated since USAM.

OpenIssue:  Since this is a coded data type, it needs example codes.

Comments:
… of a service intent associated with a goal throug the Service_relationship of type "evaluates". Note that the review schedule is a service intent, not the goal by itself.  These intents can then be instantiated into events, or ordered to somebody else.


ModelElement:
Healthcare_service_provider :: participates_as(0..n) :: Producer_of_master_service :: has_as_participant(1..1)

Comments:
The actor of a Service in definition mood (master) is the provider that provides the service.


Description:
The link that exists between a current service event or source service event and a previous or target service event which defines a semantic relationship of another nature (besides set membership or predicate relationship) joining the two instances of service event (e.g., "supportedBy;" "hasReason;" "pertainsTo;" "namedBy").  For example, "The diagnosis of Lupus is supported by the previous observations of fever, butterfly rash and increased sed rate."


Description:
Used to document the nature of the relationship of a current service event to a previous service event(s) that carries a semantic other than membership in a set or membership in a guidelines, e.g. subsumes, is support by, supports, etc.


Description:
Any living organism or complex animal.  This includes mammals, birds, fishes, bacteria, parasites, fungi and viruses.

OpenIssue:  There are a number of duplicated attributes with Patient that need to be fixed.  This probably needs to be remodeled properly.

Rationale:  The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each Target_participation instance to select the appropriate target from among the possible targets.

Comments:
Note: plans are to associate Living_subject as a specialization class of Material.


ModelElement:
Living_subject :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)

Description:
Rationale:  The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each Target_participation instance to select the appropriate target from among the possible targets.

Mapping:
Target :: participation_of(0..1) :: Living_subject :: participates_as(0..*)


Description:
The date and time of a living subject's birth or hatching.


Description:
The place the living_subject was born or hatched.


Description:
A text string representing the breed of the living subject.


Description:
A string description of the marking and coloring of the feathers, coat, scales, or skin of a living subject.


Description:
A code specifying the nature of publicity protections in place for this living subject.


Description:
The date and time that a living subject's death occurred.


Description:
An indication that the living subject is dead.


Description:
An indication that the living subject was euthanised.


Description:
A user-defined code representing the color of each eye.


Description:
A code specifying the gender of a living subject.


Description:
A code indicating the sexual status of a living subject.


Description:
A text string indicating the living subject's economic or psychological importance to the owner.


Description:
The country in which the living subject was born, captured or killed.


Description:
Represents the type of name, e.g., Common, Registered, Display, etc.


Description:
A code indicating the primary use for which the living subject was bred or grown.


Description:
The quantity of individual living subjects represented by this instance of the class.

OpenIssue:  This attribute is not the correct way to model populations, but it could be construed as this, which is incorrect.  This needs to be modeled differently.


Description:
A text string representing the genotypic or phenotypic strain of the living subject.


Description:
A code representing the taxonomy of the living subject.


Description:
Predefined reference values to which results of quantitative observation services may be compared.  Values are identified for categories of subjects according to age, sex, race, and other conditions.  Ranges include normal (reference), critical, and absolute.

Comments:
… in reference mood. 

Reference ranges are a short hand representation of a frequency distribution of a measured value over a population.  Usually the “normal” healthy human is used as the reference population, but sometimes values are distributed differently in different populations, so that the population on which reference ranges are based must be identified.  This used to be done in HL7 v2.3 in special fields or components using special codes and conventions.  In USAMP we represent all population characteristics as observations.

For example, if we want to specify reference ranges for Aldosterone (a test to help monitor hypertension) we have to distinguish different age goups.  The USAMP specification, Figure 11, shows how Aldosterone normal values for age groups 1–10 years and 10–12 years are specified.  It also shows how the applicable reference range is connected to a particular observation report.

Figure 11's text sais:

Reference ranges are frequency distributions of observations among populations.  The reference ranges (mood: REF) are associated with the master observation (upper left, mood: DEF) through reference links. The reference value is usually an interval of physical quantity (low–high) or, with nominal observations, a set of value codes.  If a reference range has no criterion, it is the typical “normal” range, based on the not further specified healthy population.  If criteria are associated with the reference, the criteria can be any observation (mood: EVN+CRT), but sex and age are the most common reference range criteria.  An actual observation (upper right, mood: EVN) may be linked with the applicable reference range in order to specify which range has been applied to determine the interpretation (abnormal) flag “H” on the service report.


ModelElement:
Master_numeric_range :: applies_to(1..1) :: Master_quantitative_observation :: conforms_to(0..n)

Comments:
with relationship type being "has reference value" linking to a Servcie in reference mood.


Description:
This attribute contains the age range, usually in years or fractions thereof, for which the value range is valid.  Ages of less than one should be specified as a fraction (e.g., 1 month - 0.0830 year, 1 week = 0.01920 year, 1 day = 0.0027300 year).  However, for most purposes involving infants, the gestational age (usually measured in weeks) is preferred.  Often only the upper end of the range is included to assure that series or age ranges do not overlap.

OpenIssue:

Comments:
… of an observation in criterion mood, of type "AGE", associated as the target of a "has_precondition" relationship with an observation in reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.

It does require, though, that age be recognized as a clinical observation (independent from any administrative date of birth).  This is logically correct and technically straight forward to implement.


Description:
This attribute allows for definition of ranges based on any arbitrary condition, e.g., phase of menstrual cycle or dose of a particular drug.  It is provided as a way to communicate the benchmarks for special conditions.  It does not allow automatic checking of these text conditions.

Comments:
… of an observation (of any type) in criterion mood", associated as the target of a "has_precondition" relationship with an observation in reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.

Note that the criterion appears in a very similar form as would appear actual observations, which makes this strategy technically easier to handle than did the separate code. Note also that this gets rid of one more "free floating" code attribute.  Coded attributes are significant pitfalls for introperability, reducing free standing codes to a minimum is part of the intention of USAMP-II.


Description:
This attribute specifes te gender for which the range is valid.

OpenIssue:

Comments:
… of an observation in criterion mood, of type "GENDER", associated as the target of a "has_precondition" relationship with an observation in reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.

It does require, though, that gender be recognized as a clinical observation (independent from any administratively assumed  gender).  This is logically correct and technically straight forward to implement.


Description:
This attribute contains the gestational age (time from conception) for which the range is valid.  It is relevant only when the range is influenced by the stage of pregnancy.  A range of values is required.  The gestational age is generally measured in weeks from conception.  Often only the upper end of the range is included to assure that series of age ranges do not overlap.

Rationale:  

OpenIssue:

Comments:
… of an observation in criterion mood, of type "GESTATIONAL AGE", associated as the target of a "has_precondition" relationship with an observation in reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.


Description:
Specifies the race or subspecies for which the range is valid.  In the case of humans (the default), the race is specified when race influences the range.  When ranges for animals are being described, this attribute can be used to describe subspecies or special breeds of animals.

OpenIssue:


Description:
This attribute specifies the species for which the range is valid.  It is assumed to be human unless otherwise stated.  The species should be represented as text.

OpenIssue:


Description:
Specifies the type of numeric range.  Types allowed are reference range, critical range, or absolute range.

Comments:
… of an observation in criterion mood, associated as the target of a "has_precondition" relationship with an observation in reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.


Description:
This attribute contains the high and low limits of the reference range.  The range is taken to be inclusive (i.e., the range includes the end points).  

When the reference range applies to the amount of a toxic substance, then the upper limit of the range identifies the toxic limit.  If the range applies to  a drug, the lower limits identify the lower therapeutic bounds and the upper limits represent the upper therapeutic bounds above which toxic side effects are common.

OpenIssue:


Description:
A type of master service specific to observation services.


ModelElement:
Master_observation_service :: generalizes(1..1) :: Master_qualitative_observation :: specializes(1..1)

Comments:
The peculiarities of the nature of observation values is contained in the Observation.value attribute of type ANY.  So, a descriptive class is not needed (as we shall see below.)


ModelElement:
Master_observation_service :: generalizes(1..1) :: Master_quantitative_observation :: specializes(1..1)


ModelElement:
Master_observation_service :: has(0..n) :: Master_specimen_requirement :: is_specified_for(1..1)

Description:
Rationale:  Rarely can precisely the same set of specifications apply to specimens for two or more master services, and there is no business case for tracking generic specimen specifications, separate from the services for which they are to be collected.   In the rare event when specimen requirements for different master services coincide, each service will have separate, identical master_specimen_requirement instances related to it.

Comments:
… of type specimen of a Service in definition mood.

It has been asked (Jane Curry) whether we'll see mood codes for Material, distinguishing whether it's a potential or actual material, etc. Most human languages do not distingusish moods of substantives, but only moods of verbs.  This is an indication for an underlying logic:  In mentioning a material, we do not say anything about its existence. For example, if I say "Napoleon" I refer to an idea of a substance that may or may not exist or have exited.  Only if I say "Napoleon lived in the early 19th century" or
"I am Napoleon", or something like that, only then do we have knowledge about the mood of existence of Napoleon.


ModelElement:
Master_observation_service :: has_as_basis(0..n) :: Master_observation_service :: is_basis_for(0..n)

Comments:
… since RIM092 does not say what this association is used for, we can not determine a relationship type code for it.  But we know that it would be a relationship between two Services in definition mood, and that whatever semantics is intended with this association, we can map onto existing concepts, or define a new concept in the service relationship type code.


Description:
This field is used when there are patient variables that are derived from one or more other patient variables (e.g., creatinine clearance, ideal weight, maximum daily temperature, average glucse, framingham risk).  This field contains the rules for deriving the value of this variable.  These can be described in terms of humanly understandable formulas or descriptions.  When possible, however, they should be defined in terms of the Arden Syntax for specifying selection and transcendative functions and algebraic operations, ASTM E1460-92.  Derivation rules that are represented in Arden Syntax should be identified by the universal service identifier.  We recommend the use of the Arden Syntax because it permits the unambiguous specification of most such derived values and is a published standard for medical logic modules.


Description:
This field identifies the instrument or device that is used to generate this observation or battery;.  Examples are the automated instrument in the laboratory, the imaging device and model number in  radiology, and the automatic blood pressure machine on the ward.

Rationale:  This attribute stands in for a relationship to an "instrument_type" class, which does not currently exist in the RIM.

Comments:
… of type device to Material.  The instrument code of RIM092 is an ambiguous concept: does it mean the kind of instrument or the instance of an instrument?  Kind would be Material.type_cd and instance would be Material.id.

Another free floating code is gone!


Description:
This field contains the allowed HL7 data type(s) for this observation.  A given observation may, under different circumstances, take on different data types.  Some HL7 data types are not valid for any observations.  Consult the domain specification for the full list of data types which are allowed to represent observation values.

Comments:
The ANY type consists of a type tag and a value. No need to communicate the data type out of band.


Description:
The usual length of time (generally in minutes) between the start of a test process and its completion.

Comments:
The width of an occurrence interval may still be specified even though the start and end are unknown.


Description:
An indication that a specimen is required for this observation service type.

Comments:
This is redundant in RIM092, since the specimen requirement is represented as an association between Master_observation and Master_specimen_requirement.


Description:
The typical processing time for a single test/observation.  This field indicates the time from the delivery of a specimen or transport or a patient to a diagnostic service and the completion of the study.  It includes the usual waiting time.  The units are generally measure in minutes.

Comments:
as the width of an interval of time.  This is the attribute of a super-service that includes transportation and everything that is required for the support of a linical service.  See USAMP specification for discussion of this.

As it stands, the RIM092 definition is not interoperable, since noone knows what really is included in this "turn around time".  So, site negociation (or ideosyncratic assumptions) will have to take default.  The USAMP approach appears more complex, but it is much clearer.

Open Issue: We don't have a good handle on waiting time yet, neither in RIM092 nor in USAMP. It is a very important concept in customer-oriented service rendering, which will become an issue in health care if it isn't already.


Description:
A place where patient services are delivered.

Mapping:
Master_patient_service_location :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)

Comments:
… but we associate it as a role of material, at this point without resolving the attributes (?)


ModelElement:
Master_patient_service_location :: belongs_to(0..n) :: Patient_service_location_group :: contains(1..n)

Comments:
of type "has parts" linking the location group with the location.  Note that this vocabulary must distinguish between the locations contained in each other (like room in building) vs. the locations grouped rather arbitrarily.


ModelElement:
Master_patient_service_location :: includes(0..n) :: Master_patient_service_location :: is_included_in(0..1)

Comments:
… of type "has parts" linking the super-location with the sub-location.  Note that this vocabulary must distinguish between the locations contained in each other (like room in building) vs. the locations grouped rather arbitrarily.


ModelElement:
Master_patient_service_location :: is_entry_location_for(0..n) :: Service_intent_or_order :: is_entered_at(1..1)

Comments:
… of type "entry location" … if this is really needed.  The use case of this "order entry location" is quite questionable.


ModelElement:
Master_patient_service_location :: is_requested_by(0..n) :: Patient_service_location_request :: requests(1..1)


ModelElement:
Master_patient_service_location :: is_target_for(0..n) :: Target_participation :: has_as_target(0..1)

Description:
Rationale:  replaces associations:  Patient_service_location receives Treatment_service_dispense - Patient_service_location receives_medication_dispense_recorded_on Treatment_service_give - Patient_service_location receives_medication_delivery_specified_on Treatment_intent_or_order_revision.

Rationale:  The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each Target_participation instance to select the appropriate target from among the possible targets.

Comments:
… since service location is a role of material.


Description:
A description of the location to facilitate recognizing it and its characteristics.

Rationale: 

OpenIssue:


Description:
the e-mail address for the patient location, if any.

Rationale: required by components of V2.3 field (XTN datatype)

OpenIssue: this is not a location oriented data item

Comments:
Note: an e-mail connection is rarely placed into a location like a telephone mounted on a wall.  E-mail is read by users or user groups (teams … Organizations?)

The rationale sais that this attribute was created automatically.  Since XTN is dead and lives on in TEL, this attribute can go away.


Description:
For room or bed locations, identifies what types of eqipment are built in, e.g., telemetry equipment.

Rationale:  Currently in 2.3 as LOC-8-Location Equipment.

OpenIssue:  Note that this is just a placeholder for a 2.3 item and needs more work with internationalization and Inter-Enterprise.

Comments:
Material that is "is present at" the location is linked through the material relationship of respective relationship type.  In USAM all material is consistently referred to as instances of the class Material.  Conversely in RIM092 material was coded in various un-coordinated attributes: as instrument_cd, as equipment_cd, etc.  The USAMP-II improves interoperability by reducing the amount of coded attributes that need coordination!


Description:
A unique identifier of a patient care location.


Description:
The number of licensed beds at the location.

Comments:
… that is it may be a valid attribute in the location/facility role class.  While the beds can be enumerated, a facility with 180 beds will not want to enumerate beds, but will want to say what it's nominal capacity is.


Description:
The name by which the service location is known.

Comments:
Names of instances are identifiers (though not always unique.)  The SET<II> data type assignment for all .id attributes allows for multiple names, and attaches prefixes to the id that makes the id unique.

The issue of location names is not free of complexity, but neither RIM092 nor USAMP has yet taken on the task to work through the issues of location names.


Description:
The period from when the location opened until it closed.

Comments:
… stays as an attribute of the service location role class.


Description:
The specialty code of the service.

OpenIssue:  This attribute may move to a masterfile class later.  

OpenIssue:  This does not appear to be a proper attribute of location.  It appears to be an association to a clinical service (organization) that has a specialty code.  At best, it might be re-structured or described to reference a set of specialty codes that can be supported by this location.

Comments:
… so it stays.

Note that the open issue is outdated.

Also note tha the definition is bad.

Also note that the likely intention is served better by the association of Location to Stakeholder (provides service at) since a location has no specialty, but only the user of the location has a specialty. 

The Responsibility class may make the direct association between location ans stakeholder redundant.


Description:
Duration for a single schedulable unit in a schedule for a resource.

Rationale: Provides visibility into scheduling details.

OpenIssue: Does this match any V2.3 field?


Description:
A code indicating the status of the location.


Description:
A code indicating the type of patient care location (e.g., hospital, clinic, hospital ward, room, bed, . . .).


Description:
A service for which qualitative, rather than quantitative, results are generated.  Qualitative results are represented on nominal scales (nor ordinal, interval or ration scales) are presented as coded values (whether numeric codes or alphabetic codes), and are ooften called "categorical" results.


Description:
A list of the text answers that are abnormal for the test.

Rationale: Clarity, or better representation of V2.3 element name

Comments:
… of an observation in reference mood.  The set of normal result codes resides in a instance of the SET<CD> data type assigned to the Observation.value.  For normal ranges, the Observation.interpretation_cd must be N - normal.  The abnormal results are derived as the set difference between the set of possible codes and the set of normal codes.  The set of possible result codes is found right in the Observation.value of the observation definition (master.) Thus, the set of abnormal results is:

observation-definition.value - normal-reference.value

it needs not be communicated explicitly.


Description:
A list of coded results that are critically abnormal for this observation.

Rationale: Clarity, or better representation of V2.3 element name

Comments:
… of an observation in reference mood.  The set of critical result codes resides in a instance of the SET<CD> data type assigned to the Observation.value. Where the Observation.interpretation_cd must be AA - abnormal alert.

Note that critical ranges are really alert triggers.  If there is any specific action that should be taken upon a critically abnormal result, this should be represented as an alert trigger that reminds the physician of a "recommended" service.


Description:
Normal text/codes for categorical observation.

Rationale: Clarity, or better representation of V2.3 element name

Comments:
… of an observation in reference mood.  The set of normal result codes resides in a instance of the SET<CD> data type assigned to the Observation.value.  For normal ranges, the Observation.interpretation_cd must be N - normal.


Description:
Preferred coding system for observations whose categorical responses are taken from a specified table of codes.

Comments:
When the observation value of a singleton result is of the Concept Descriptor (CD) data type, the Observation.value of a master service definition contains a SET<CD> with all possible result values enumerated.  The coding system used in this enumeration is obviously the preferred coding system.


Description:
a list of valid coded answers

Rationale: previously unmatched V2.3 field

OpenIssue:

Comments:
… of the Observation in definition mood (the master observation.)  This value is usually of data type SET<CD>, where the set enumerates all the valid answers, just like the RIM095 attribute does.


Description:
A test/observation service for which quantitative results are generated.  Quantitative results are those represented on oordinal, interval or ration scales.


Description:
The SI units of measure, when these differ from the customary units of measure

Rationale: 

OpenIssue:

Comments:
Unit conversion is defined externally by the semantics of units.  The Unified Code for Units of Measure that is the preferred code for units to be used in the data type Physical Quantities defines a methodology and the necessary constants for conversion between all convertible units.  

The issue between SI and customary units is not as simple than it is implied by RIM092 here, since SI is an entire class of units, that still need to be converted.


Description:
Specifies whether the change for triggering a delta check warning is computed as a percent change or an absolute change.  Allowable methods are:  "as percent" and "as absolute change."

OpenIssue:

Comments:
Delta checks are not yet mapped in detail.  Delta checks are derived observations that are used in some laboratories, and are only very rarely  used in clinical systems.  As derived observations, delta checks will map to Observation structures built by the service relationship class.


Description:
Specifies the minimum change that will trigger a delta check warning.

Rationale: 

OpenIssue:


Description:
Specifies the low value information for controlling delta check warnings.  More than one delta check rule can apply.

Rationale: required by components of V2.3 field

OpenIssue:


Description:
The length of time that the service retains a V2.3 language value fr computing delta checks.

OpenIssue:


Description:
The range of values for which delta check warnings can be generated.  If no value range is given, the check applies to all values.

OpenIssue:  The RIM090 descriptions lead one to believe that delta_check ranges, delta_check thresholds, and delta_check methods occur in sets ("more than one rule can apply").  If that is so, then delta check should be a separate class that associates with the continuous observation.


Description:
Specifies the total length in characters of the field needed to display the observation, and the number of digits displayed to the right of the decimal point.  This is coded as a single number in the format <length><decimal-digits>.  For example, a values of 6.2 implies 6 characters total (including the sign and decimal poiont) with 2 digits after the decimal point.  For integer values, the period and <decimal-digits> portion may be omitted (that is, 5.0 and 5 are equivalent).  More than one such mask may be specified when it is necessary to define multiple display formats that are possible.

Comments:
The observation.value of a master observation (mood_cd = definition) is an interval of Physical Quantity (IVL<PQ>).  This specifies:

- the range of the value (through the interval)
- the precision of the values (through the precision of the real numbers representing the boundaries)
- the physical dimension of the quantity (through the unit)
- the preferred unit (through the unit)

There is thus no need for a special field with special syntax defining these things.


Description:
The smallest meaningful difference between reported values (the effective resolution of the measuring instrument or technique for continuous data, or the smallest discrete interval that can occur for discrete data).  This is a pure number.

Comments:
as of yet, this concept is not mapped.  Few clinical systems specify such a value, and it is medically questionable how such a concept of minimal meaningfulness could be defined.  Thjs issue is to be addressed together with the delta checks.


Description:
This is a factor for converting the customary units to SI units.

In the case that the observation units are not SI units, this field provides the formula needed to convert from the reported units to SI units, this shall include the equation needed to coonvert from the reporting to the SI units.

In the case that the relation is simply multiplicative, this field shall include only the conversion factor.  For example, if (results SI units) = c* (results reporting units), then only c would be stored in this field.  In the case of any other functional relationship, the entire equation would be stored for a test.

Comments:
Unit conversion is defined externally by the semantics of units.  The Unified Code for Units of Measure that is the preferred code for units to be used in the data type Physical Quantities defines a methodology and the necessary constants for conversion between all convertible units.  

The issue between SI and customary units is not as simple than it is implied by RIM092 here, since SI is an entire class of units, that still need to be converted.  

The "equation" suggested by RIM092 is not interoperable without significant further work to solve a problem that is already solved elsewhere (in the units coding scheme.)


Description:
The customary unit of measure for a tests/observation that has quantative values 

Rationale:This field is not part of an anount/UOM combination, and is therefore not representable as a component of a quantity data type.

OpenIssue:

Comments:
The observation.value of a master observation (mood_cd = definition) is an interval of Physical Quantity (IVL<PQ>).  This specifies:

- the range of the value (through the interval)
- the precision of the values (through the precision of the real numbers representing the boundaries)
- the physical dimension of the quantity (through the unit)
- the preferred unit (through the unit)

There is thus no need for a special field for units and conversions any more.


Description:
An individual test observation, test observation battery or panel, individual medication, diet, or procedure.


ModelElement:
Master_service :: generalizes(1..1) :: Master_observation_service :: specializes(1..1)


ModelElement:
Master_service :: generalizes(1..1) :: Master_treatment_service :: specializes(1..1)


ModelElement:
Master_service :: is_covered_by(0..n) :: Coverage_item :: provides_coverage_for(1..n)

Mapping:
Service :: is_covered_by(0..*) :: Coverage_item :: provides_coverage_for(1..*)


ModelElement:
Master_service :: is_delivered_during(0..n) :: Service_event :: delivers(1..1)

Comments:
of type_cd "fulfills" linking the Service in event mood as source with the Service in definition mood as target of the Service_relationship.


ModelElement:
Master_service :: is_requested_by(0..n) :: Service_scheduling_request :: requests(1..1)

Comments:
of type_cd "instantiates" linking the Service in schedule request mood (SCH) as source with the Service in definition mood as target of the Service_relationship.


ModelElement:
Master_service :: is_source(0..n) :: Master_service_relationship :: has_source(1..1)

Mapping:
Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)


ModelElement:
Master_service :: is_target(0..n) :: Master_service_relationship :: has_target(1..1)

Mapping:
Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)


Description:
This field contains one or more available priorities for performing the observation or test.  This is the priority that can be specified in the order_qt attribute for a Service_intent_or_order.  When  a specimen is collected for the test, this attribute specifies the priority with which the producer service will process the specimen, produce the observation, and return results.  Allowable processing priorities include stat; as soon as possible; preoperative; routine; timing critical.

Comments:
of a service in definition mood (master). Remember that the mood code modifies the entire service with all its ttributes in the same logical manner: the priority of a master is the available priorities to choose from, the priority of the order is the priority requested for the service,  the priority of the service event is the priority that was actually used (important because that makes a difference in billing.)


Description:
The availablle priorities for reporting the test results when the user is asked to specify the reporting priority independent of the processing priority.  Allowable reporting priorities are call back results; rush reporting.

Comments:
The Service.priority_cd specifies the priority of the service in every respect.  Performing and reporting priorities are very interdependent (e.g., it is unreasonable to request STAT priority but allow delayed reporting.)  The Service.priority_cd is a SET<CV> and allows to specify values for both processing and reporting priorities.


Description:
An alternate unique identifier for the master service.

Rationale: 

OpenIssue: Should this attribute be combined with universal_service_id as a set?  How can we specify that the first in the set is the universal_service_id, but the order doesn't matter among the rest?

Comments:
The RIM092 specification is vague here, given how the phrase "a unique identifier for …" is used elsewhere in the RIM092.  Two options exist:
- alternate instance identifiers: are sent as on element in the Service.id SET<II>
- alternate type code: is sent as one code translation in the CD value of the Service.type_cd
Thus both alternatives are covered neatly, it's just not clear which one the RIM092 wants.


Description:
use for which an alternate service name is created, e.g., long name, short name, name for reports, report subheader.

Rationale: 

OpenIssue:  More sorting out.

OpenIssue:  Need ruling from CQ on whether we will be able to link a name with it's usage in a single data type (e.g., phone numbers with home/office/daytime/evening; alternate service names with primary/report/short).  Otherwise, we need a separate Service_name class.

Comments:
see the discussion for the following mapping of Master_service.alternate_nm


Description:
An alternate name for the master service.

Rationale: 

OpenIssue:  Need ruling from CQ on whether we will be able to link a name with it's usage in a single data type (e.g., Phone numbers with home/office/daytime/evening; alternate service  names with primary/report/short).  Otherwise, we need a separate Service_name class.

Comments:
A name of a test is basically a symbol for a concept.  It does not matter whether we refer to serum potassium as "sK", "K+", "POTASSIUM", or "2823-3". All of these are symbols for the concept, understood by some convention.  Thus, there is no fundamental difference between name and
concept code.  All of these names are communicated in one attribute, the Service.type_cd as Code Translations within the Concept Descriptor data type.

Each code translation is from one code system.  There are standard code systems and local code systems, which both can be sent.  The various kinds of names defined in the HL7 v2.3 OM1 thus map to various local codes.  Thus, an institution can define arbitrarily many names, long and short, medium, 5-, 8-, 10-, 16-, 32-, characters in size, some all caps, some mixed caps, some plain US ASCII, some UNICODE, each being used by a different application in different circumstances.  The static categories "long name" and "short name" do not hold any more in today's variety of application systems installed at one site.

Note that as of RIM092 it is no longer possible to have multiple special names, such as a long name and a short name, since there is only one attribute left and the pair alternate_nm_use_cd and alternate_nm would require to be maintained as "parallel lists" to match a name and a "use_code".


Description:
information for classifying observations by the challenge component of the test, if a challenge does speciate the observation, for example, tests that include a glucose challenge.

OpenIssue:

Comments:
A challenge (Medication) and a subsequent observation are linked as service plan components under one supe-service.  With USAM's Workflow support, this allows detailled timing and condition information to be supplied in order to interoperably and clearly specify the challenge-test procedure.

If for backwards compatibility we decide that systems may stick to the "free text" manner  of sending this information, it can be done either in the Servcie.descr of the super-service or in associated services that only fill in their descriptions.


Description:
This field contains the degree to which special confidentiality protection should be applied to the observation.  For example, a tighter control may be applied to an HIV test than to a CBC.  Suggested confidentiality protections include very restricted; usual control; AIDS patient; psychiatric patient; very important person.


Description:
A code depicting the type of consent that must be obtained for permission to treat the patient. May not represent consent from the patient.

Identifies whether or not an Informed Consent is required for this service.

OpenIssue:   This should be investigated whether or not it may be more appropriately added as an indicator rather than a code.  And examples are needed if it remains a code.

Comments:
linking a master service with a Consent definition.   Different consents in different circumstances can be expressed by attaching criteria to the consent.


Description:
This field contains the diagnosis or problem for which the service is a contraindiction or of possible danger (e.g., pacemaker, pregnancy, diabetes).  For example, if the service were an intravenous pyelogram, this field would include warnings about the use of contrast media in diabetes.

Most contraindication rules will be transmitted as free text.  In such ases, the contents serve only as information for human reading.  However, an alternative for machine readable contraindiction rules also exists.  The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information sorted in the computer record.  Contraindication rules that are written in Arden Syntax should begin and end with a double semi-colog (;;), the Arden slot delimiter.

Rationale: 

OpenIssue:  Is there only one contraindication?  Either a set or a dependent class.

Comments:
of type "has contraindication" linking any Service (in moods definition, order, intent, event, …) with another Service in criterion mood. The contraindication is usually an Observation, but can be a Procedure too.  The contraindication criterion can be a criterion in the moods definition (to refer to a possible contraindication) or in event mood (to refer to an actually present contraindication.)


Description:
A description of the master service.

Rationale:


Description:
The start and end dates for the interval during which the master service is active in the service catalog.

Comments:
using the history item to attach time stamps or intervals to any status.  Statuses of Services in definition mood include: under-specification --> active --> retired.


Description:
Text description of the foods, diagnosis, drugs, or other conditions that may influence the interpretation of the observation including information about the direction of the effect, and any recommendation about altering the diet, conditions, or drugs before initiating the test observation.


Description:
The codes and a fixed text message that is always associated with the test described by this master service.

Most rules about patient testing will be transmitted as free text.  In such cases, the contents serve only as information for human reading.  However, an alternative for machine readable rules also exists.  The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information stored in the computer record.  Rules about patient preparation and written in Arden Syntax should being and end with a double semi-colon (;;) the Arden slot delimiter.

Rationale: The EXPR attribute type is not used here because a) it does not accommodate both codes and text; and b) at times this text must be human-readable.  This attribute will use the CD data type.

OpenIssue:  Need example values.  Probably overlap of concepts.

OpenIssue:  It is not clear from the definition what differentiates "fixed canned messages" from other standard text - e.g., patient_preparation_desc, procedure_medication_cd.

Comments:
There is no understandible definition of this attribute anywhere in the RIM nor in HL7 v2.3.  This field must go, nobody can use it in an interoperable manner.


Description:
the modality used to classify the observations, e.g., radiograph, ultrasound, CT scan, NMR, etc.  Especially important for imaging studies.  

Rationale: 

OpenIssue:

Comments:
Classifications should be part of terminology systems rather than sent explicitly.  If a system knows what a CAT scan is, it will also be able to categorize this under "advanced radiologic studies" or whatever categorization it deems important.  Such a classifying code is not interoperable and should not be sent this way.


Description:
The date and time of the last change in the test procedure that would make previous results incompatible with new results, e.g., the last time that normal reference range or units changed for a numeric test/observation.

We strongly suggest that observation producers never use the same observation ID when the measurement procedures change in such a way that results produced under the new procedure are clinically different from those produced with the old procedure.  Rather, the producer should try to adjust the new procedure so that its values are clinically indistinguishable from the old.  Failing that, one should create a new observation ID for the observation produced under the new procedure.

In the rare circumstances when a procedure change occurs and neither of the above two options is viable, this field shall be used to transmit the effective date/time of the new procedure.  The receiving systems shall assume that any values that come across under this observation ID are under the new procedure after this date and take appropriate  steps to distinguish the old from the new observations.  

This number is included to provide a means of communicating with the observation producing service when they have questions about particular observations or results.

Rationale:

OpenIssue:

Comments:
Just as no service event should be overwritten, no service definition should be overwritten incompatibly.  This would render any attempt at interpreting old observations useless.  There is no need to support such malpractice.


Description:
the clinical information about interpreting test results.  Examples are the conditions (drugs) that may cause false abnormals, and the information about the sensitivity and specificity of the test for diagnoses

Rationale: OM1/Interpretation of Observations and OM1 /Factors that may effect the Observation contain different information, and therefore require different attributes.

OpenIssue:


Description:
Designates whether two or more succeeding master services, as specified in Master_service_relationship, are to be joined with and-logic or with or-logic.

Comments:
This attribute was introduced into RIM087 by the USAMP-I.  It was meant to support Workflow specification, but the Workflow specification has never been completed.  USAMP-II has taken this attribute into the Service_relationship class and has defined it completely so it is now the first time that it's useable.  There are no issues of backwards compatibility.


Description:
The underlying kind of property measured by this service.  Distinguishes concentrations from total amounts, molar concentrations from mass concentrations, partial pressures from colors, and so forth



OpenIssue:

Comments:
Note: this attribute (from HL7 v2.3 OM1) was always misplaced, it belongs into Master_observation.


Description:
Contains the date and time that the last of any field change was made in the source record corresponding to the service catalog item.

Rationale:

OpenIssue:

Comments:
The timed life-cycle information can be supplied in the using the history item and history lists for the status code.  This is another case of the "slotted time-stamp" issue.


Description:
This attribute contains the codes and narative for a method that may be used to produce the observation.  Bibliographic citations may be included in the narrative.  More than one method may be listed for a master service, but only if they produce results that are clinically indistinguishable.

OpenIssue:  Need example values.


Description:
A code used to classify the service.  Indicates whether the service is a test battery, an entire functional procedure or study, a single test value (observation), multiple test batteries or functional procedures as an orderable unit (profile), or a single test value (observation) calculated from other independent observations.

Profiles or batteries consisting of many independent atomic observations (e.g., SMA12, electrolytes), functional procedures that may consist of one or more interrelated measures (e.g., glucose tolerance test, creatine clearance), and supersets--sets of batteries or procedures ordered under a single service identifier but processed as separate batteries (e.g., routines - CBC, UA, electrolytes) should be associated with each included member service through the Master_service_relationship.  In the ASTM context, most text reports are considered as sets, in which each section of the report (e.g., description impression , and recommendation of an X-ray report) is considered a separate observation.

Comments:
This attribute from HL7 v2.3 OM1 is not necessary since the "nature" of the service is all obvious in its definition.  There is no need to paraphrase the definition using some code in the message.


Description:
This attribute applies to the tests or procedures that produce an observation which uses observation ID suffixes following the test/observation ID code.  Suffixes identify the common components of narrative reports.  Each type of narrative report is assigned a universal_service_id.  The actual report components are reported in separate observations, all linked to the universal service for the report.  The suffix text for the observation further qualifies the observation as to which component of the narrative report it contains.

If this master service produces a narrative report, this field in the master service lists the allowed suffixes for this report.  All observations containing components of this narrative report must be identified with one of these suffixes.  The applicable three character mnemonics given in ASTM Table 20 (or others appropriate to the application) should be used.  For example, a chest X-ray may use the suffixes IMP, REC, DEV, or others.  Each of the expected suffixes should be listed here.

OpenIssue:  Looks like an implementation requirement in a logical attribute.  Resolvable by a code scheme structure? 

OpenIssue:  The link from a specific service_event to the master_service identifies the "observation_id" for the service being delivered.  The present attribute defines the sub-portions of the results from that master_service which may be reported in separate service events.  Should this information be pre-coordinated in the master_service instead (i.e., an X-ray would become 3+ services)?  Or, should it be moved to the Master_service_relationship, and specified as part of the link between the sub-service and the major service (e.g., impression is a subservice of X-ray, and carries the suffix IMP.  Impression can also be a subservice of another service and have the same or a different suffix for that other service).

Comments:
See discussion in Clinical_observation.universal_service_identifier_suffix_txt (BTW: this is the same concept modeled twice in RIM092 in different places under different names.)

The subsections of reports are better fully precoordinated into the service.type_cd but canstill be sent as modifiers in the type_cd's code phrase structure.  Remember that the u.s.id suffix was a modifier on the type_cd and modifiers is what the Code Phrase data type was designed for.


Description:
An indication that the service is an orderable service.


Description:
A description of special patient preparation, diet, or medications for this service.

Comments:
Preparation for a service means that that service of interest is a plan component under a super-service with predecessors in the plan.  This is how preparation can be clearly specified in the service /relationship structure using the "plan component" relationship type. Timing and conditionals may be specified.


Description:
This field applies to the diagnostic studies/tests that are performed only at certain times during the course of a work day or work week.  This field indicates the maximum interval between successive test performances (the test may actually be performed more frequently).  If necessary, multiple codes may be given.  The use of multiple codes indicates that the test is performed at multiple concurrent intervals.  For example, Q6H indicates that the test is performed at least once every 6 hours around the clock.  QJ1 indicates that the test is performed at least every week on Mondays.  QAM~QPM indicates that the test is performed at least once every morning and every evening. 

QJ1~QJ3~QJ5 indicates that the test is performed at least every week on Mondays, Wednesdays, and Fridays.  C indicates that the test is performed continuously, 7 days per week.

Rationale: 

OpenIssue:

Comments:
In a master service (mood_cd = DEF) the timing specification expresses when the service can be performed.  This may be a precise listing of office hours and business days, weekends, and holidays.


Description:
classifies this service as measuring the patient's state either at a point in time (e.g., spot urines, random urines, serum potassium), or averaged over a interval of time (e.g., concentration, total amount, or clearance over a 24-hour collection).  

OpenIssue:  This may be converted to an indicator.

Comments:
This atribute is a LOINC specific classification of tests.  It is not necessary to imply procedural requirements, as the service plan may be specified in all necessary detail anyway.  The implication for interpreting the observation is not clear.  By no means is thie code a modifier, since there is no choice for any given test.  Thus, this attribute better stays precoordinated in the LOINC code.


Description:
An indication that a portable device may be used for the test or observation service.

Comments:
The device is linked with the service through a Target link of type "reuseable device."

In resource scheduling, a system will search through all resources to find out whether there is a non-portable device among them.  The location of this non-portable device is the location at which the service necessarily needs to take place.   However, the service location can be specified simpler through the Target location (Target.type_cd = LOC).


Description:
The primary or preferred name of the master service.

Rationale: 

OpenIssue:  Need ruling from CQ on whether we will be able to link a name with it's usage in a single data type (e.g., Phone numbers with home/office/daytime/evening; alternate service names with primary/report./short).  Otherwise, we need a separate Service_name class.

Comments:
Same issue as for Master_service.alternate_nm:

A name of a test is basically a symbol for a concept.  It does not matter whether we refer to serum potassium as "sK", "K+", "POTASSIUM", or "2823-3". All of these are symbols for the concept, understood by some convention.  Thus, there is no fundamental difference between name and
concept code.  All of these names are communicated in one attribute, the Service.type_cd as Code Translations within the Concept Descriptor data type.

Each code translation is from one code system.  There are standard code systems and local code systems, which both can be sent.  The various kinds of names defined in the HL7 v2.3 OM1 thus map to various local codes.  Thus, an institution can define arbitrarily many names, long and short, medium, 5-, 8-, 10-, 16-, 32-, characters in size, some all caps, some mixed caps, some plain US ASCII, some UNICODE, each being used by a different application in different circumstances.  The static categories "long name" and "short name" do not hold any more in today's variety of application systems installed at one site.


Description:
A means of providing default or standard specifications for when the master service is to be performed and how frequently.  It is a complex multicomponent field that can have repeats.  If a speciment is required for the service, the Priority component contains specimen collection priority rather than processing priority.  The extent to which these specifications can be modified in the delivery of the master service to a particular subject of service is regulated by business rules established by each institution.

Comments:
Service plans can be constructed using the USAMP Workflow features.  

Note: the QT is not a viable alternative for HL7 v3 since it violates modeling rules in many ways.  Notably QT relies on forreign keys. The service plan construction functionality hardly fits into one attribute.


Description:
defines the sort order in which this observation is presented in a standard report or display that contains the many observations

Rationale: 

OpenIssue:

Comments:
The "report display order" is principally determined by the receiving system.  For a battery, the order can be specified through the Service_relationship.priority_nmb.  However, display order is entirely dependent on the display.  This can never be sufficiently communicated in one attribute.  As a possible alternative the stakeholder owned Service_lists can specify an ordering among services, e.g., for certain reports.  However, common practice is to specify reports as Services in the service catalog.


Description:
The normal time required for performing the service across organizational provider and client base.

Rationale: 

OpenIssue:

Comments:
Needs to be better distinguished from Master_observation_service.typical_turn_around_time and .processing_time.  But will be mapped to an interval width in the Servcie.total_time attribute.


Description:
Formally indicates the site of the observation (to make it easy for a system to find all tests related to one anatomic site). It can be used to classify the observation by target site of the examination.  For example, "heart" might be recorded as the target of the electrocardiogram, cardiac echo, and thallium exercise test.

This attribute would be applicable to most imaging and electro-physiologic examinations.  The SNOMED topology axis is an example of a coding system ofr anatomic sites.  User-defined tables may also apply here.

Rationale: 

OpenIssue:


Description:
The primary or preferred unique identifier for the service.

Rationale: 

OpenIssue:  Should this attribute be combined with service_alternate_id as a set?  How can we specify that the first in the set is the universal_service_id, but the order doesn't matter among the rest?


Description:
Specifies the standard timing of billing the charges associated with the service, and determines the master template for the timing of billing the charges associated with the order service item.  eg.: On Discharge (D); On Receipt of Order (O); At time service is completed (R); At time service is started (S); At a designated date/time (T)

Comments:
The relationshjp between a service and its charge needs to be improved on.  Only as a last resort should this attribute admitted into the Service class.  It is not a problem to put this attribute into the service class, notably, it is applicable to all moods (especially definition, order, and event.) 

Instead of distributing charge-relevant attributes over multiple classes in the RIM, wouldn't it be possible to consolidate them all in one class, representing charges.  The class Financial_transaction seems to be the best class for that purpose.  It could represent the charges (with fee schedule) one would incur when ordering the service, as well as the actual bill, and billing transaction.


Description:
Associates a composite or dependent (target) master service with one of the multiple (source) services which participates in the composition or dependency.  Allows specification of constraints for each association.

Rationale:  Routine order sets, clinical trials, and pathways require groupings of services such as panels or "batteries" of unlike tests delivered at one time, groupings of the same tests delivered along a timeline, or grouping combination of these concepts.

Note:  Linda Quade must go over these details to make certain that the names are all correct, since there are some small errors on the spreadsheet.


Description:
Textual description of any arbitrary constraint on the source service when participating in the target service.

Rationale:  Detail of a possible relationship between services.

Comments:
A constraint is a criterion linked to the service through a service relationship of type "has-precondition".   It can be fully coded for interoperable automated communication. For backward compatibility the constraint can be represented just as free text in the Service.descr attribute of the criterion service.


Description:
A means of qualifying the relationship between a source and a target Master_service, specifying when the source service is to be performed and how frequently.  It is a complex multicomponent field that can have repeats.  If a specimen is required for the source service, the Priority component contains specimen collection priority rather than processing priority.  The extent to which these specifications can be modified in the delivery of the target master service to a particular subject of service is regulated by business rules established by each institution.

Comments:
The Workflow capabilities of HL7 have been completely redesigned.  There are similarities, but no direct mapping to QT is possible.  Note that the QT has never been fit into the version 3 RIM.  Especially the promiscuous use in multiple places was intended more as a placeholder than as any functional design.  This particular situation came out of the Spring '98 Harmonization meeting, where it was felt that the timing capability proposed for USAMP-I was not sufficient.


Description:
A description of the rules that trigger reflex testing for a service catalog item.

Rationale:

Comments:
in trigger mood, linked through a service relationship of type trigger with a master service that is invoked on that trigger.


Description:
Specifies the basis for the association of the source to the target.

Rationale:


Description:
A specification of specimen requirements for test/observation service catalog items which require a specimen.

Comments:
… associated with the master service as a target of type specimen.

It has been asked (Jane Curry) whether we'll see mood codes for Material, distinguishing whether it's a potential or actual material, etc. Most human languages do not distingusish moods of substantives, but only moods of verbs.  This is an indication for an underlying logic:  In mentioning a material, we do not say anything about its existence. For example, if I say "Napoleon" I refer to an idea of a substance that may or may not exist or have exited.  Only if I say "Napoleon lived in the early 19th century" or
"I am Napoleon", or something like that, only then do we have knowledge about the mood of existence of Napoleon.


Description:
A code for the additive required for the collected specimen used in the associated observation service type.

Comments:
of type additive.   Additives to specimen are material mixed with the specimen-material.  This allows to specify the proportion, which is important to account for dilluting effects and effects of other physico-chemical properties of the specimen-additive mixture.


Description:
A description of the container requirements for a specimen collected for the observation service type.  The description includes specification of the physical appearance, including color of tube tops, shape, and material composition (e.g., red top glass tube).

Comments:
for the container-material associated with the specimen-material.


Description:
The special processing that should be applied to the container (e.g., add acidifying tablets before sending).

Rationale:

Comments:
This RIM092 attribute has an unclear semantics.  It is either a handling instruction or (as in the cited example) an additive. 
- Material.handling_cd
- Material_relationship of type additive.


Description:
A specification of the containers volume capacity.


Description:
This field contains the codes that distinguish the parent and children for diagnostic studies--especially
 in microbiology--where the initial specimen (e.g., blood) is processed to produce results (e.g., the identity of the bacteria grown out of the culture).  The process also produces new "specimens" (e.g., pure culture of staphylococcus, and E. Coli), and these are studied by a second order process (bacterial sensitivities).  The parents (e.g., blood culture) and children (e.g., penicillin MIC) are identified in such cases.

OpenIssue:  Do these codes apply to the specimen, or to the Master_service requiring the specimen?

OpenIssue:  This should be an indicator if only 2 possible states (parent and child) exist.

Comments:
A derived specimen is called an "aliquot".  The derivation can be fully specified through a specimen derivation action (Service) with the source specimen as target of type consumable and aliquot as a target of type product.  If only the relationship bewteen the parent and aliquot is to be captured, the Material_relationship can be used as well (type_cd = "is_aliquot")


Description:
The amount of specimen needed by the most specimen sparing method.

Comments:
Specified as a probability distribution (uniform, normal, or "guess") with mean and standard deviation. Simple mathmatical transformations exist between a min-max representation and a probability distribution.


Description:
A specification of the normal specimen volume required.  This is the amount used by the normal methods and provides enough specimens to repeat the procedure at least once.

Comments:
The quantity can be specified as a probability distribution (uniform, normal, or "guess") with mean (the "normal collection volume" value) and standard deviation (describing minimum, and, theoretically, a maximum.) Simple mathmatical transformations exist between a min-max representation and a probability distribution.


Description:
The allowed priorities for obtaining the specimen.

Valid priorities are:  Stat, As Soon As Possible, Routine, Pre-operative, Timing Critical.

The specimen priority for an order is communicated in the quantity-timing attribute of the service intent or order.

OpenIssue:

Comments:
This attribute is about a specimen collection service, not about the material specimen.  USAMP-II puts it where it logically belongs. Thus, we can reuse an existing attribute rather than making a new one. (BTW: this has nothing to do with the "merger", but it's in the same spirit: "rationalize and reuse.")


Description:
The usual time that this specimen is retained after the observation is completed.

Comments:
The "extent" is the time a material is in distinguished existence.  It is an interval of time. For a specimen used as a requirement description, the extent_tmr will be specified only as the width of that interval.


Description:
Special handling requirements for the collected specimen.


Description:
A code identifying the specimen required by the observation service type.  Codes should be drawn from ASTM Table 14 of 1238-91.

Rationale: 

OpenIssue:


ModelElement:
Master_treatment_service :: is_ordered_on(0..n) :: Treatment_intent_or_order_revision :: orders(0..1)

Comments:
of type "instantiates" source is a service in order or intent mood, target is a service in definition mood.


Description:
The drug enforcement agency level for the pharmacy treatment service.

OpenIssue:  Need example values.

Comments:
This attribute is so badly defined and has no HL7 v2.3 traditions that one should kick it right out!
However, some reseach in this field has led to the following hypothesis (one should not have to hypothesize about attributes that dare to come with a one sentence  pseudo-definition with 99% redundancy!)

The U.S. Drug Enforcement Agency (DEA) maintains a classification of drugs in 5 classes, called "schedules" (not "levels"!) and numbered in capital roman numerals I, II, III, IV, and V.  This classification is established in 21 USCS Section 812 "Schedules of controlled substances".  Schedule I represents the highest level of restriction (e.g. Heroine) and section V the lowest.  This classification is fequently updated by regulatory actions and is thus not a static coding system for concepts.  Note that DEA schedule V is basically "unclassified" which means, one would not have to link members of that schedule V.

Since other countries have drug control agencies and their regulations as well, and since this is an issue in medication treatment, we define the following strategy:  

Drug categories shall be represented as Medication services in definition mood. The type_cd shall cite a code from a country specific (or treaty specific) coding system. E.g., for the U.S., the codes would be I, II, III, IV, and V and the code system would be called "DEA Schedules of controlled substances" with reference to the U.S. code.)   Each class shall be instantiated in one Medication service in definition mood (master.)  Classified medications would then be linked through service_relationships of type "has-species" with the source being the class and the target being the specific Medication service, also in definition mood.

This is the way how any kind of categorization shall be maintained: use master services and the "has-species" relationship rather than to cite (mostly non-interoperal) codes in all the services.


Description:
The drug category code of the pharmacy treatment service.

Comments:
Attributes for classification an categorization should not be admitted into the RIM without a detailed rationale and use cases.  Coded attributes should not be admitted into the RIM without a full interoperable specification of what the domain is (if only by external reference.)  This attribute is in the RIM without heritage in HL7 v2.x and whithout any helpful definition. It must go until the a proper use case and definition is made.  Once we know what it is, we will be able to find an appropriate disposition in USAMP-II.


Description:
A code depicting the formulary status of a dispensed medication.

Rationale:

OpenIssue:  Need example values.

Comments:
Again, this attribute exists in the RIM without heritage in HL7 v2.x and without any sensible definition that would make it useable.  It must therefore go until a proper use case and definition is made.  Once this is properly defined, the USAM will find a good disposition for it.


Description:
A code depicting the form of the medication comprising the pharmacy treatment service.

OpenIssue:  Need example values.

Comments:
Note: this is one of those shallow definitions …anyway, the name suggest the mapping is correct.  The talk is about doseform, e.g., tablet, suppository, spray, vial, etc.


Description:
The pharmaceutical class of the pharmacy treatment service.

OpenIssue:  Need example values.


Description:
A code depicting the administration route for the pharmacy treatment service.

OpenIssue:  Need example values.

Comments:
Note: this is one of those shallow definitions …anyway, the name suggest the mapping is correct.  The talk is about medication route, e.g., oral, rectal, inhalation, i.v., etc.


Description:
A code depicting the therapeutic class of the pharmacy treatment service.

OpenIssue:  Need example values and clarification of description.


Description:
An authoritative direction or instruction concerning an observation service for a patient.

Rationale:


Description:
Code and/or text indicating any known or suspected patient or specimen hazards e.g., patient with active tuberculosis or blood from a hepatitis patient.

Rationale: 

OpenIssue:

Comments:
this takes care of hazards emerging from a specimen.  A patient hazard should be noted in the Patient or Person class, where it can be tracked an reused, it certainly is not exclusively pertinent to an order.
Living subjects, if modeled as a specialization of material, would inherit the danger_cd from Material.


Description:
Additional clinical information about the patient or specimen, such as the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies.

Rationale: :

Comments:
… to the relevant clinical information in structured form, rather than in a free text field.  No need for another free text attribute.


Description:
A code identifying the action to be taken with respect to the specimen which precedes or accompanies the order.  Actions include:  Add ordered tests to the existing specimen; Lab to obtain specimen from patient; Pending specimen - Order sent prior to delivery.

OpenIssue:


ModelElement:
Patient :: is_scheduled_by(0..n) :: Patient_slot :: is_a_scheduleable_unit_for(1..1)

Comments:
of a stakeholder owned Service_list of type "schedule". The Service_list :: is_about(1..1) :: the patient (Person). The booked slots are represented by list_items with associated Service for which the slots are booked. A receiver of a message containing such a service list can find the open slots as being everything that is not booked.

Issue: We may want to allos List_items not bound to any Service, but with a time range to indicate blocked slots that are not available but also not booked with any service.  In addition the List_item could specify (in a status_cd) whether it is held reserved for a service or whether it is actually booked.


ModelElement:
Patient :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)

Description:
Rationale:  Replaces associations:  Patient may_be_the_subject_of order - Patient is_subject_of Clinical_observation - Patient has Goal.

Rationale:  The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each Target_participation instance to select the appropriate target from among the possible targets.

Comments:
Since the patient is always also a person, the two links from Target to Person and to Patient are often redundant.  This only causes confusion since there is no sensible way to decide which one to use.  Since the link to Person is more general (e.g., allowing family members as targets, who are not registered as "patients"), the Target-Patient link can be safely deleted.


Description:
A financial account established for a patient to track the billable amount for services received by the patient and payment made for those services.


ModelElement:
Patient_billing_account :: has_charges_for(0..n) :: Service_event :: is_charged_to(0..1)

Description:
OpenIssue:  What is the difference between charging to and billing to a patient account?  Service_events and_service_intent_or_orders are different.

Mapping:
Service :: is_charged_to(0..1) :: Patient_billing_account :: has_charges_for (0..*)


ModelElement:
Patient_billing_account :: is_billed_from(0..n) :: Service_intent_or_order :: is_billed_to(0..1)

Description:
Rationale: supports use of BLG segment in the ORM message

OpenIssue: Open issue: needs joint work with OO-PAFM

Comments:
Note that the mood code modifies the meaning of ALL properties of the Service class in a consistent logical way. This is true for attributes and associations alike:

event: I have done something.
order: Please, do something.
event: I have charged this account.
order: Please, charge this account.

Open Issue to PAFM: Why does the account need to be constrained to "Patient billing"? Why could one not have a general class for Account that allows us to bill to clinical study account, special budgets, bill organizations for maintenance and supply services, etc.? What do we gain by such overspecification?


Description:
An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient.  For example, outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call.

OpenIssue:  This MUST be discussed with Patient Care in the context of Episode and Service Event definitions.  Episode and Encounter definitions needs to be discussed.

OpenIssue:  The status_cd attribute as the state attribute may not be in the right place in the Gen/Spec tree.

OpenIssue:  States of patient encounter (#234).


Description:
A pool of like-type locations available for scheduling purposes.

Rationale: Currently in 2.3

OpenIssue:

Comments:
as a grouper for associated locations.  The grouped locations are associated through the Material_relationship of type part_of.  The Material.type_cd of the grouper could be an interoperably defined entry in a Material type code (material pool, location pool.)

BTW: the term "pool" makes the meaning much more clear, since grouping can have many purposes, but "pooling" is done in order to share resources more flexibly.


ModelElement:
Patient_service_location_group :: is_requested_by(0..n) :: Patient_service_location_request :: requests(0..1)

Comments:
of Target.type_cd = LOC, of a Service in mood_cd = SCH (scheduling request).


Description:
Unique identifier for the group

Rationale: Currently in 2.3

OpenIssue:


ModelElement:
Patient_service_location_slot :: is_scheduleable_unit_for(1..1) :: Master_patient_service_location :: is_scheduled_by(0..n)

Comments:
… as :: part_of(1..1) :: Service_list :: is_about(1) :: *Location :: is_a_role_of(1..1) :: Material.  The Service_list.type_cd is "schedule".  Booked slots are represented by List_items associated with a Service.  Available items are everything not booked.

Blocked slots could be represented as List_items not bound to a service. List item would need a time stamp for this.  A List_item status_cd could indicate whether a slot is booked or just held reserved for a service.


Description:
A therapeutic or diagnostic intervention employed in response to a patient condition.

OpenIssue:  We are not sure if the gen-spec relationship should be moved from Procedures is_specialization of Service_event to Procedure is_specialization of Care_event or not.  The data seems to be needed,  but it is not definite where in the model they should go.  It needs further work.  Many of these attributes have come from the UBforms, and have not yet been properly modeled.  More work by PAFM and OO is needed.


Description:
A code identifying the anesthesia used in a procedure.

OpenIssue:  Need example codes.

OpenIssue:  Should this be a relationship to Master_service?

Comments:
A surgical procedure with anesthesia is two, not one, procedure, scheduled differently, performed by different responsible actors, even different departments, different bills, different preparation and follow up care -- indeed, anesthesia is a completely separate service.   Surgery and anesthesia can be linked under a common super-service to coordinate (synchronize) these otherwise separate services.  There is thus no need to mention anesthesia attributes in the Procedure class.


Description:
The length of time that the anesthesia was administered.


Description:
The reason for delay of the surgery patient service.

OpenIssue:  Needs code value examples

Comments:
of the Service event.

First off: this attribute has no heritage in HL7 v2.3 and is not supported by a strong use case or a good definition. Why is a delay of a Procedure more noteworthy than the delay of any other event?  Why does one need a delay reason text without an indication about what kind of delay happened at all?

Let us rationalize this: 

1. A delay can be stated only between an event as planned or scheduled and the actual event.  Thus, there must be a Procedure in intent mood and the instantiation of the intent in event mood.  Thus, a system can compare the planned/intended time with the actual time of the even to establish a delay established.

2. How can the delay be explained? Obviously any derivation from the service as intended from the service as performed might deserve an explanation.  Since the explanation for the delay is free text, it can go into the Service.descr attribute of the Service event. 

Remember, the Service description is subject to the mood of the Service just as any other property of the Service is subject to the mood code.  In other words, the Service.descr of the event describes the event, tells what actually happened, not what was ordered, planned,  or defined in the master file.)
 
Therefore the Service.descr of the event only needs to mention what is different from the definition (master) or order or intent.  Hence the Service.descr is the logical home for any text explanations of variances between the defined, ordered, or planned service and the event. Q.E.D.


Description:
A code identifying the functional type of the procedure.  Functional types include:  Anesthesia; Procedure for treatment (therapeutic, including operations); Invasive procedure not classified elsewhere (e.g., IV, catheter, etc.); Diagnostic procedure.

OpenIssue:

Comments:
This is a categorization or classification that entirely depends on the purpose, and is thus subjective in nature. As such, this can never be an interopeable attribute, unless its use case and i's vocabulary is clearly and completely defined.  Classifications usually come with terminology systems and do not need to be communicated in attributes.  The list of examples is insufficient.

If a clear use case for such classification is presented, USAM will be able to accommodate it, just like any other model would.  However, we must keep the RIM clean from unexplained info junk.

Note that ad hoc local codes can all be sent as translations of the Service.type_cd, which is a Concept Descriptor that allows multiple translations of codes into different code systems to be sent.  To a certain extent this can be used to send classifiers (and it is not a hack to send classifiers that way, but is warranted by the logic of coding.)


Description:
The time range during which the incision was open for this surgery patient service.


Description:
Codes, typically defined by  regulatory agencies such as HCFA or the AMA, that modify the procedure code.

Rationale: Unless procedure modifiers are pre-coordinated in Master_service, the modifier must be specified at the service instance level.  It cannot be combined with the "procedure id" in the RIM, since that attribute is obtained from the master service class.

OpenIssue:  

OpenIssue:  Need code examples.

Comments:
Code modifiers are what the Code Phrase within the Concept Descriptor (CD) data type has been designed for.  So, there is no need for modifier code attributes, and such attributes would even be harmful, since they can not be used with multiple translations into different coding systems.


Description:
A number indicating the relative priority of the procedure to all other procedures provided in this encounter.

Comments:
on a Service_list maintained by a revenue optimization system (or an issue list maintained by a physician.)


Description:
The date/time that the procedure was performed and the length of time that the procedure took to complete.

Comments:
as an interval of point in time indicating start and end of the Procedure.


Description:
This participation class links a single producing person or organization or organization (stakeholder) to a single service that the stakeholder can provide.  Producers offering multiple services will have many  such link instances in this class.  Likewise, services offered by multiple producers will have a link instance in this class for each offering producer.

OpenIssue:  The following attributes should be defined and added to this class:  tmr; authorization status.  Also, the attributes of Master_service and its specializations should be reviewed to determine if any are producer-specific.  Any such attributes should be moved to this class.  Alternatively, a business rule may be put in place, stating that a new master_service instance will be established for each separate producer of a service (as identifidr by the universal service identifier).  This is the practice implied in V2.3. 

Rationale:  This class performs the same function as the Producer ID field in the V2.3 OM1 segment, but further allows several producers to be linked too the same master service (identified by a single universal service identifier) and likewise allows several services to be linked to the same producer.

Comments:
of actor type: performer, that links a Service in definition mood with the Stakeholder (individual person or organization) offering this service catalog item.


ModelElement:
Producer_of_master_service :: produces(1..1) :: Master_service :: is_produced_by(0..n)

Description:
Rationale:  No stakeholder can be registered as a producer of a master service without naming the master sercie to be produced.  Producer of Master Service is not a persistent role.  It is a participation for a specified time period with a particular master service.

OpenIssue:  It would appear that this role class should have a mandatory (1..1) cardinality to master_service.


Description:
field permits the sorting of observation orders and values by the providing service's department/section.  The codes for this field should be taken from ASTM Table 15 (Diagnostic Service Codes)

Rationale: 

OpenIssue:

Comments:
The classification of the department into "service section" codes should take place in the Organization class itself. This is clearly a static attribute of the provider organization rather than a dynamic attribute of the participation.

Proposal to move this attribute into the Healtcare_provider_organization class and named  "service_setion_cd".


Description:
Individual resource request information about various kinds of resources that are controlled by a schedule.

Rationale: Currently in 2.3

OpenIssue:

Comments:
of a Service in mood_cd "scheduling request" (SCH).

Rationale: all targets (and actors) of a service represent resources. For a service in scheduling request mood, the associated actors and targets are requested to be allocated for the service.


ModelElement:
Resource_request :: generalizes(1..1) :: Durable_medical_equipment_request :: specializes(1..1)

Comments:
the target of type "reuseable device" of a Service in scheduling request mood represents this association.


ModelElement:
Resource_request :: generalizes(1..1) :: Individual_healthcare_practitioner_request :: specializes(1..1)

Comments:
of a service in scheduling request (SCH) mood.


ModelElement:
Resource_request :: generalizes(1..1) :: Patient_appointment_request :: specializes(1..1)


ModelElement:
Resource_request :: generalizes(1..1) :: Patient_service_location_request :: specializes(1..1)

Comments:
the target of type "location" of a Service in scheduling request mood represents this association.


ModelElement:
Resource_request :: is_requested_by(1..1) :: Appointment_request :: requests(0..n)


Description:
A code indicating whether the identified resource can be substituted with an equivalent resource.

Rationale: Currently in 2.3

OpenIssue:  Need code examples.  Also, should this be a Boolean (_ind) rather than _cd?

Comments:
for a service in scheduling request mood.


Description:
The duration for which the resource is requested for this appointment, if it is different than the overall duration of the appointment

Rationale: Currently in 2.3

OpenIssue:

Comments:
of a service in scheduling request mood. The duration is the width of an occurrence interval.


Description:
Date and time this resource is requested for the appointment.

Rationale: Currently in 2.3

OpenIssue:

Comments:
of a service in schedule request mood. The starte_dttm is the low boundary of the occurrence interval.


Description:
The offset that this resource is requested for the appointment, expressed in units of time relative to the scheduled start date/time of the appointment.

Rationale: Currently in 2.3

OpenIssue:  How does this attribute work with the start_dttm for the request.  This offset is relative to the appointment and would appear to present a conflict with the other attribute.

Comments:
The offset means, that a certain resource is not needed for the entire service but only for a certain portion of the service.  If a Target (or Actor) participates only partly in the service, this is generally indicated through the Target.tmr (or Actor.tmr, respectively) attribute.  Alternatively it can be specified through breaking the service apart into sub-services as scheduling sub-requests.


Description:
A code that describes the request status of scheduling a resource or activity, from the point of view of the filler application.

Rationale: Currently in 2.3

OpenIssue:  Need code examples.

Comments:
of a Service in scheduling request mood.


ModelElement:
Resource_slot :: generalizes(1..1) :: Durable_medical_equipment_slot :: specializes(1..1)


Description:
The link that exists between a current or more molecular service event and a previous or more atomic service event that indicates simple set membership.  The source service event is the set name, while the target service event is the set member.  The attribute priority of the List_link class allows the set to become a list, with the value of the priority attrivbute specifying list order.  Thus, a value of NULL for prioity indicates that the source of the List_link is the "name" of the set (e.g., Chem-12) while each target of an instance of List_link will be a "member" of the set (e.g., Na, K, etc.).  If an instance of List_link has a non-NULL priiority value, an application may choose to display and/or process the list (i.e., the prioritized/order Set) according to application rules for interpreting the prioity that a given list member has been assigned (e.g., the Work List for Nursing has the following Work Tasks listed in order oof priority:  1. SE1, 2.  SE2, 3.  SE3, etc.

OpenIssue:  This may be superceded by the changes consequent to the USAMP-II proposal work being done summer 1999.


Description:
Used to doocument the relative ranking of a current service event to a previous or more atomic service event in a set (when the field is NULL) or in an ordered list of service events (when the field is an integer), e.g. items in a sequenced task list, prioritization of patient problems, etc.


Description:
The performance of a health related action provided by one or more active participants on behalf of one or more target participants.  This includes medical as well as non-medical services. A patient can be both target and active participant of the service: - a clinical test - an assessment of health condition (such as problems and diagnoses), - the setting of healthcare goals - the performance of treatment services, such as medication, surgery, physical and psychological therapy. - assisting, monitoring or attending - training and education services to patients and their next of kins - notary services, such as advanced directives or living will 
Examples of active participants are nurses, doctors, family members, notary publics, and service agencies. Target participants may include, the patient, the patient's spouse, family, or community, a specimen drawn from the patient or from any object of interest. As patients do play active roles in their own healthcare, the patient can be both an active participant and a target participant at the same time (self-administered or reflexive services.) A service_event can have multiple active participants and multiple target participants, their specific role is distinguished in the "type_cd" of the respective instance of the participation class. In particular, a service event involving coordination of care may involve two or more active participants playing different roles who interact on behalf of a patient, family, or aggregate in the role of target participant.  For example, a nurse (active participant) calls Meals on Wheels (active participant) on behalf of the patient (target participant).
The service_event is the documentation of a rendered service including its detailed context, as opposed to the formulation of an intended service. A service event includes the "results," "answers" or "procedure products" gained during the service. In this model, "results" do not exist without a service, and every clinical result, including those results gained accidentally, are service_events.

OpenIssue: Should there be an Observation Service Event specialization Patient Service Event?


ModelElement:
Service_event :: generalizes(1..1) :: Assessment :: specializes(1..1)

Description:
Rationale:  Since multiple kinds of assessments are delivered as a healthcare service, a class is needed to record the nature of those assessments and the resulting value(s) association with those assessments.  An assessment is a kind of service that describes the collection and interpretation of data from a data source and the nature of that data.  In this class, it also describes the value(s) associated with the action of data collection and interpretation.

Comments:
Assessment is deleted without replacement.  These Assessment and Care_event classes were an attempt at a taxonomy of Services which is not what a class diagram is used for.


ModelElement:
Service_event :: generalizes(1..1) :: Care_event :: specializes(1..1)

Comments:
Care_event is deleted without replacement.  These Assessment and Care_event classes were an attempt at a taxonomy of Services which is not what a class diagram is used for.


ModelElement:
Service_event :: generalizes(1..1) :: Consent :: specializes(1..1)


ModelElement:
Service_event :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..n)

Description:
Rationale: Optiional relationsip establishes independence of service events from encounters.

Mapping:
Service :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..*)

Comments:
Issue to PAFM: the name "assigned to" is very vague!


ModelElement:
Service_event :: is_associated_with(0..n) :: Financial_transaction :: pertains_to(1..1)

Mapping:
Service :: is_associated_with(0..*) :: Financial_transaction :: pertains_to (1..1)

Comments:
Issue to PAFM: the name is very vague!  Pertinence and association is certainly expressed by all associations.  Especially in this case "bills" and "is billed as" would be more expressive. Why shying away from clear language?


ModelElement:
Service_event :: is_documented_by(0..n) :: Clinical_document_header :: documents(0..n)

Description:
OpenIssue:  This many-to-many association should be resolved.

Mapping:
Service :: is_documented_by(0..*) :: Clinical_document_header :: documents(0..*)


ModelElement:
Service_event :: is_performed_at(0..1) :: Master_patient_service_location :: is_location_for(0..n)

Description:
Rationale: Support references to facilities in OBR.

Comments:
of type location linking a Servcie in event mood to a Material in the role of a Facility/Location.


ModelElement:
Service_event :: is_source_for(0..n) :: Service_event_relationship :: has_as_source(1..1)


ModelElement:
Service_event :: is_target_for(0..n) :: Service_event_relationship :: has_as_target(1..1)


Description:
The date the service provider attests that the patient service was delivered as documented.

Rationale:  

OpenIssue:  This attribute needs to be clarified between Orders, XML, and Medical Records since it seems to be involved with all three domain areas.

Comments:
of an Actor of type "attester" as the high boundary of the time interval.


Description:
A  number that allows a relative ranking for billing purposes of service events (usually billing diagnoses or procedures) on an ordered list, e.g. 1500 forms.

Rationale:  Used to differentiate purpose from other ranking attributes

Comments:
Billing priority is established on a Service_list :: owned_by :: a billing department.


Description:
Charge code for the charge to the ordering entity for the studies performed when applicable.

Rationale: 

OpenIssue:  This item related more to financial areas than the clinical areas.  (Note to PAFM)

OpenIssue:  Need code examples.

Comments:
This attribute is dysfunctional.  It needs proper analysis and modeling.  This is rather in the scope of PAFM.  Probably covered already somewhere in Financial_transaction.  Also may reconfirm the need for a general Account (not just a "patient billing account") so that departments and offices can bill and charge for each other's services independent from patients.


Description:
Monetary amount for the charge to the ordering entity for the studies performed when applicable.

Rationale:

OpenIssue:  Should move to financial section of model since  it is related more to financial areas than the clinical areas.  (Note to PAFM)

Comments:
This attribute also needs proper analysis and modeling.  This is rather in the scope of PAFM.  Probably covered already somewhere in Financial_transaction.  Also may reconfirm the need for a general Account (not just a "patient billing account") so that departments and offices can bill and charge for each other's services independent from patients.


Description:
An indication that the diagnosis is confidential.


Description:
A code depicting the type of consent that was obtained for permission to treat the patient.  May not represent consent from the patient.

OpenIssue:   Needs to be addressed in the analysis of consents .  This can cover declination as well.

OpenIssue:  Need code examples.

Comments:
of a Consent service associated with the consented-to service through a Service_relationship link.  Both, service and consent should be service plan components under a common super service.  Note that conset obtaining needs to be scheduled just as any other service.  A consent is thus not entirely different from a TRH challenge before a TRH test: timing is an issue.


Description:
Indicates the individual's family or significant other's comprehension of the service event.

OpenIssue:  Isn't this sometimes a coded entry?  If so, need to use the _cd attribute type to accommodate both code and test.

Comments:
of a target of type "proxy" linked with the family member or other significant party.  This attribute is strongly coded.  A free text note can be put into the Target.note_txt -- but such free text is not functional.  The code must be used to express awareness interoperably.


Description:
The patient service unique identifier   This is often assigned by the filler, but may be assigned by other processes.


Description:
Indicates the date and time that a status, as defined in Order Status, is entered or changed.  Note:  Order Status represents the status of order fulfillment by the filler.  This is different from Order Control Code, which reflects the status of the order from the placer's viewpoint.

Rationale: to represent the use of this V2.3 field as the date and time of change in ORC/ order status.

OpenIssue:

Comments:
of the service in event mood (linked to an order through service_relationship of type fulfills.) 

The timed life cycle can be communicated through the status code as a history item or the eentire life cycle as a history list.

Note:  "Filler order" is recognized as bad language.  It is the service intent or event generated through the order.  The order is always an order as placed (placer order.)  BTW: order control code is NOT a status code at all but a trigger event code.


Description:
This field contains the individual's comprehension of the service event (e.g., full, marginal, partial, etc.).

OpenIssue:  Is this code or text?  Should this be renamed to Patient_awareness_cd?

Comments:
of the Target linking to the patient as direct target (subject) or indirect target (beneficiary.)


Description:
Indicates whether patient considers this service to be confidential.  Current values are Yes and No.

Rationale:  Although currently described as an indicator, we have chosen to use the Code attribute type here to allow a more structured representation of confidentiality in the future. 
The use of the word "sensitivity" parallels usage in class the Problem arena.

Comments:
has been consolidated with confidentiality (where it belongs.)  "Sensitivity" is a distinguished concept in the new consolidated vocabulary for this field.


Description:
The date the patient service is scheduled to begin.

Comments:
… of a service in intent (!) mood.  Note that the service event describes the actual service as it is actually carried out.  As long as the service has not actually started, it is in intent mood. So, the planned begin date is the begin date of the service in intent mood.

Note: this attribute does not belong in the event class of RIM092 anyway.


Description:
Text that describes the service performed along with relevant details of the service.

Rationale:  To differentiate this attribute from Service_event: service_event_desc.

OpenIssue:  There needs to be a good way to show the necessary constraints on an attribute value in the description of the attribute somewhere.


Description:
The date and time the specimen was received for use in the service event.

Rationale:  Each service event uses only one specimen. Each collected_specimen_sample may be collected in several containers, or may be reallocated to several containers for use in multiple service events.  This attribute captures the time one of those containers was received by this service event.  It is not an atttribute of the sample alone.

Comments:
… of a transportation service event transporting the specimen to the service location.  The specimen is received at the end of the critical_time of the transportation. This arrival of the specimen in the lab is tracked, mostly with an eye on the transportation event that implicitly happened (e.g., as an excuse for the delayed test when the specimen didn't arrive in time.)  

Note that the rationale provided in RIM092 is arguably not true.  An observation may well act on multiple specimen (e.g., a cross-blood test).  Each specimen may then arrive at different times. True that this attribute is not an attribute of the specimen, since it talks about things being done with the specimen, rather than the nature and condition of the specimen itself.


Description:
A code indicating the lifecycle status of the  service event.  See state/transition model for an exhaustive list of lifecycle states.


Description:
Explanation of the reason for the status. examples: order entry error; patient refused, contraindicted

Comments:
Note that this code is not interoperable since it is not defined.  Note also that this needs more analysis work.   The suggested values are certainly admissible status codes for the status code itself, so why not defining these right in the status code?


Description:
The period of time during which the patient service occurred.

Comments:
as an interval ("range") of point in time.


Description:
Specifies the linkage among Service_events.  These relationship types include, but are not limited to, collections/batteries (e.g., CBC, Chem12), temporal and non-temporal decision paths (e.g., care plan, critical path, clinical trials, drug treatment protocols), and decision linkages (e.g., evidenced by, subsumes).

Rationale:  Routine order sets, clinical trials, and pathways require groupings of services such as panels or "batteries" of unlike tests delivered at one time, grouping of the same tests delivered along a timeline, or grouping of a combination of these concepts.  The same grouping relationships captured in the Master_service need to be maintained as the service is delivered.

OpenIssue:  Patient Care, PAFM, and Orders need to sit down and work out the attributes for the relationship classes.  Also should discuss whether this class needs to have sub-classes (gen/spec classes), e.g., should temporal be a sub-class under relationship class.  There is currently only a kluge way to relate Service_event and SIOO - the service reason link may not be sufficient.


ModelElement:
Service_event_relationship :: generalizes(1..1) :: Conditional_link :: specializes(1..1)

Comments:
The specialization class is re-united with its genus, so the relationship is gone.  See comment under the specialization class.


ModelElement:
Service_event_relationship :: generalizes(1..1) :: Judgement_link :: specializes(1..1)


ModelElement:
Service_event_relationship :: generalizes(1..1) :: Rule_link :: specializes(1..1)


Description:
Specifies the basis for the association of the source to the target.

Rationale:  Relationship management.

OpenIssue:  Need code examples.


Description:
The instantiation of the intent or request to perform a particular service as represented in Master_service particular date for a particular patient by a particular provider.

Rationale:  This class adds the ability to attach context information and modify default values as a plan for a particular target of service that is to receive a service itemized in the Master_service catalog.

OpenIssue:  This name does not conform to the style guide.


ModelElement:
Service_intent_or_order :: expects_patient_located_at(0..1) :: Master_patient_service_location :: expected_patient_location_for(

Description:
OpenIssue:  This may not cover all of the concepts around the connection between Service_intent_or_order and Location, including the requirement that there be a connection between Encounter and Location.  There may be other connections, and this needs further analysis.  This might also conflict with what is already done in Scheduling.

Comments:
of type location.  Note that a lab test has two services: (1) specimen collection, a clinical service at the bedside, and (2) laboratory test in the laboratory.  If the specimen collection is ordered at the bedisde (or any other place where the patient is expected to be) then that location becomes the primry location target of the ordered service (1).  The laboratory location is the primary location of the service (2). Of course, since location (1) and (2) are different (usually quite different) the transport of the specimen from (1) to (2) is a third service.


ModelElement:
Service_intent_or_order :: generalizes(1..1) :: Dietary_intent_or_order :: specializes(1..1)

Comments:
… with Supply being a specialization of Service.


ModelElement:
Service_intent_or_order :: generalizes(1..1) :: Observation_intent_or_order :: specializes(1..1)


ModelElement:
Service_intent_or_order :: generalizes(1..1) :: Referral :: specializes(1..1)

Comments:
… referral was left out of scope of the USAMP-II. Referral is about encounters and we tried to steer clear of dealing with encounters.

Proposal to reroute this generalization relationship to Service.


ModelElement:
Service_intent_or_order :: generalizes(1..1) :: Treatment_intent_or_order :: specializes(1..1)


ModelElement:
Service_intent_or_order :: is_an_instance_of(1..1) :: Master_service :: is_instantiated_as(0..n)

Comments:
of type "instantiates" linking the Service order as source and the Service definition as target.


ModelElement:
Service_intent_or_order :: is_fulfilled_by(0..n) :: Service_event :: fulfills(0..1)

Comments:
of type "fulfills" linking the Service event as source and the Service order as target.


ModelElement:
Service_intent_or_order :: is_referred_to_in(0..n) :: Clinical_document_header :: is_related_to(0..1)

Description:
Rationale: 

OpenIssue: If we have the linkage between patient service event and healthcare chart document header right, this might not be needed as it duplicates existing connections.  This is pending joint work between Information Management, Orders/Observations, and Patient Care committees.

Comments:
See the relationship between the Service event and Clinical document header. It is a many to many and the open issue is to resolve this many not many. Here we have a many to optionally one -- it is not obvious why a clinical document may at most refer to one intent or order.  Something is wrong here.

Since the many to many between Service_event and Clin. D.H. is best resolved through an associative class, that class would have a type code, and that type code could distinguish the various ways a service may be cited in a document.


ModelElement:
Service_intent_or_order :: is_source_for(0..n) :: Service_intent_or_order_relationship :: has_as_source(1..1)


ModelElement:
Service_intent_or_order :: is_target_for(0..n) :: Service_intent_or_order_relationship :: has_as_target(1..1)


Description:
A code identifying someone or something other than the patient to be billed for this service.

OpenIssue:  This attribute cannot meet the needs of the concept without violating the guidelines of the MDF and must be fixed somehow.  Coordination with PAFM is needed to be certain that the function and concept is captured somewhere for future messages.  This is a type of active participation.  "Entity to be billed" should be a participation type code in Class: Active_participation.

Comments:
This is a dysfunctional attribute that will never work. This literally cries for a link to a billing account that is not constrained to a "patient billing account."  It could be so simple!  Therefore the proposal is to delete this attribute that doesn't do what it promises to do, and thereby increasing pressure on the issue to be resolved.


Description:
Telephone number to call for clarification of request or other information regarding the order

Rationale: 

OpenIssue:

Comments:
either the phone or other contact of the orderer himself, or a specially identified "clarifier" Actor type, that can link to an organization or care team with its phone number (e.g. phone on the floor.)

It is unreasonable to mention a phone in isolation and specifically for one order!


Description:
Text sent by the placer that will be returned with the results. There will be no interpretation of this field by the filler.  This attribute should not be used to communicate information that should be communicated as an observation.

Rationale:

OpenIssue:  Should this attribute be abandoned to be more deterministic as to how echo back is reported.

Comments:
This is clearly info-junk: a field with no semantics that is a perfect hide-out for sanctioned abuse.  It better goes silently and only reconsidered if a strong case for it is made. This is at least 13 year old heritage from ASTM 1283 (was "placer text 1" and "placer text 2") … isn't it time now to revise it?


Description:
Identifier of the physical device (terminal,PC) used to enter the order

Rationale: 

OpenIssue:  This may need to be addressed by CQ and/or Vocab and/or Security to refine the syntax and semantics of this concept since this attribute definition seems to be bad.

Comments:
a very special target deserves a very speial type code: "order entry device".

Note that the use case for this thing rests on extremely shaky ground. What is it for? Can it even be known in the world of Web-based virtual cyber terminals?  What is it still useful for in the world of sophisticated (and by the way legally required) authentication and access control techniques?


Description:
An indicator that the patient needs to be escorted to the diagnostic service department.  Note:  The nature of the escort requirements is captured in another attribute.  Codes include Required; Not Required; Unknown.

Rationale: 

OpenIssue:  Do these three states make this a code, or is the state "Unknown" a flavor of null?

OpenIssue:

Comments:
of type "escort".  Usually an actor of a transportation service order.


Description:
Time expected to perform this service instance for the target.

Rationale: 

OpenIssue:

Comments:
of the ordered service. The width of the ordered occurrence inteval.


Description:
This is a permanent identifier for an order and its associated observations.  It is assigned by the order filling (receiving) application.  It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory).

Rationale: Filler and placer order id's are alternate keys to the class.

OpenIssue:  Filler and Placer numbers include the system responsible for placing and filling an order.  The TII is not as explicitly bound to these two concepts and these two data items may have to be added back into the SIOO class in some way.

Comments:
Note: why does RIM092 say "and it's associated observations" when observations are separate service event instances?


Description:
Distinguishes an intent from an order.

Rationale:  Attributue is designated as _cd in anticipation of future expansion in usage.

OpenIssue:  Need code examples.  Also, should this be a Boolean (_ind) rather than _cd?

Comments:
is either "intent" or "order". Even RIM092 did not escape without a mood code :-)  Future expansion in usage? Mood code again? :-)


Description:
Designates whether two or more succeeding intents_or_orders, as specified in Service_intent_or_order_relationship, are to be joined with and-logic or with or-logic.

OpenIssue:  This concept will be addressed in the project analysing timing/quantity.


Description:
Date/time that the changes to the order took effect or are supposed to take effect

Rationale: previously unmatched V2.3 field

OpenIssue:

Comments:
The use of this field has three different aspects,

(1) information about some time related to the Service. For example, usually it is the time the service is supposed to start but also the time the order is supposed to end (in context of a discontinue request.)

(2) information about the mood of the Service, that is, whether it is just a report when something took effect or it is a command when some action is supposed or planned to take effect.

(3)  information about a particular transaction request for the order (defaulting to the MSH-7-date/time of message) as opposed to a time that will affect the service actually carried out.

These different aspects are all factored into specific data elements that are consistent and uniform in their interpretation. In version 2 this data element had alternative data elements to carry the same information, such as in the MSH and in the TQ, and thus was redundant. Therefore this field will not be carried forth as such in version 3, but will be decomposed in its different meanings:

(1) The actual start and end times of a service action will be communicated in Service.total_time. 

(2) The mood is factored into the explicit mood code Service.mood_cd.  

(3)  Discontinuing a service immediately is done without mentioning any time at all, while a change in the planned end time of a service can be requested by the placer in the Service.total_time (or usually Service.critical_time) attribute. 

(4) The time of a particular service control transaction (message) will always and only be sent in the version 3 Message Header.


Description:
A unique identifier for the patient service order.


Description:
The date and time the order was placed.

Rationale:  To provide date-time precision required for representing pathways.

Comments:
wrapping the status in a history item and keeping past statuses in a history list.  That way any life cycle state can be kept with its time stamp rather than to clutter the model with slotted time-stamp attributes.


Description:
A composite identifier of a service order.  Including the order id and the ordering application.

Rationale: Filler and placer order id's are alternate keys to the class.

OpenIssue:


Description:
code or free text comments on special requirements for the transport of the patient to the diagnostic service department.  If coded requires a user-defined table.

Rationale: 

OpenIssue:  Need code examples.

Comments:
associated with the service order. Transportation is a service that deserves its own management, including ordering, scheduling, billing, etc.  The undefined code was non-interoperable, the explicit transport service will be interoperable.


Description:
A means of specifying when the service described by the order segment is to be performed and how frequently.  It is a complex multicomponent field that can have repeats.  If a specimen is required for the order, the Priority component contains specimen collection priority rather than processing priority)

Rationale: 

OpenIssue:

Comments:
to:

Service.total_time
Service.critical_time
Service.priority_cd
a number of attributes of Service_relationship

only to mention the most important of them.  Please see the USAMP-II specification on timed and conditioned care plans on how this is used.  USAMP-II part B also provides a view on the new approach from the TQ perspective.


Description:
A phone number to be used to report results from the service order.

Rationale: This attribute represents OBR-17-250 (Order Callback Phone Number) and must be differentiated from ORC-14-228 (Call Back phone number), which has a different meaning.

Comments:
Rather than free-floating phone numbers, we associate phone numbers with Stakeholders and include results recipients in the set of Actors on the order.  Usually the orderer will receive notification, but a tracker may be added as well.  Whether or not results should be reported through the phone depends on local business rules and on the attribute Service.priority_cd.


Description:
A code indicating the reporting priority of the patient service order when the reporting priority is specified independent of the processing priority.  Allowable reporting prioritieis are call back results; rush reporting.

OpenIssue:

Comments:
includes both: processing and reporting priority since both are highly interdependent.


Description:
A code used to allow the placer (sending) application to determine the amount of information to be returned from the filler.  Sometimes the requested level of response may not be possible immediately, but when it is possible, the filler (receiving) application must send theh information.  When the field is null, D is the default value of the field.

Coded entries include:  report exceptions only/report exceptions, replacement and parent-child/report exceptions, replacements, parent-child and associated segments/report exceptions, replacement, parent-child, associated segments and confirmations/return header only.

OpenIssue:

Comments:
This is message control information, not application-level information.  It's an interesting use-case to forward to Control/Query but should not be handled together with application domain data by a few domain committees.


Description:
A weak identifier assigned by the filler for internal use. Typcially used for the Accession Number.

Rationale:  To provide for communication of accession number-like identifiers, which are often communicated in the filler text field of a V2.3 message.

Open Issue: if this captures the accession number of a specimen, it should be moved to collected_specimen_sample.

Comments:
the non-uniqueness due to roll-overs is not a severe problem in the Service.id, as long as a good identifier is also available and preferrably used by the system that also issues these accession numbers.


Description:
Body site where service is to be performed.  Example sites are ears, arm, eye.

Rationale: 

OpenIssue:


Description:
Site modifier describing the site where the service should be performed.  For example, the site could be anticubital foss, and the site modifier "right." 

Rationale: 

OpenIssue:  There is some kind of problem with this approach to representing body site; this problem extends to other multi-attribute sets that must be addressed by CQ and Vocab.  See harm399 notes..  This is of interest to scheduling.  Need compositional grammar that makes semantic sense.

Comments:
modifiers is what the Code Phrase within the CD data type is for.


Description:
A code indicating the lifecycle status of the patient service intent or order.  See state/transition model for an exhaustive list of lifecycle states.

OpenIssue: should this name remain "status", or should the description be changed?  Do we have a naming convention for state attributes?


Description:
Indicates the date and time that a status, is entered or changed.

Comments:
as a history item on the most recent status, or as a complete timed life cycle history.


Description:
Explanation of the reason for the status. examples: order entry error; patient refused, contraindicted

Rationale: 

OpenIssue:


Description:
Indicator of whether transport arrangements are known to have been made.  Conded concepts are Arranged; Not Arranged; Unknown.

Rationale: 

OpenIssue:  Do these three states make this a code, or is the state "Unknown" a flavor of null?


Description:
An indicator of who is responsible for arranging transport of the patient to the planned diagnostic service.  Examples: Requester, Provider, Patient

Rationale: 

OpenIssue:


Description:
A code indicating how (or whether) to transport a patient.

Coded concepts include:  cart; examining devices goes to patient location; wheelchair; patient walks to diagnostic service.

OpenIssue:


Description:
A code determining the timing of billing the charges associated with the order service item. eg. On Discharge (D); On Receipt of Order (O); At time service is completed (R); At time service is started (S); At a designated date/time (T)

Rationale:

Comments:
This needs to be analyzed together with all other billing attributes. May be a better attribute for a Financial Transaction.  Deleting the attribute now will increase the pressure on resolving the issue.

As plan B we can have this as a Service attribute. It does fit nicely in the mood logic.


Description:
Date and time to charge for the ordered service.

Rationale: 

OpenIssue:

Comments:
This needs to be analyzed together with all other billing attributes. A better attribute for Financial Transaction.  Deleting the attribute now will increase the pressure on resolving the issue.

As plan B we can have this as a Service attribute (marked with 1000 open issues!)


Description:
Associates a composite or dependent intent or order (the target) with another intent or order (the source) which is related to the target in some way.  Allows specification of constraints for each association.

Rationale:  Routine order sets, clinical trials, and pathways require groupings of services such as panels or "batteries" of unlike tests delivered at one time, the same tests delivered along a timeline, or a combination of these concepts.  The same grouping relationships captured in the Master_service need to be maintained as the service is planned or ordered.


Description:
Textual description of any arbitrary constraint on the source when associated with the target.

Rationale:


Description:
A means of qualifying the relationship between a source and a target Service_intent_or_order, specifying when the source service is to be performed and how frequently.  It is a complex multicomponent field that can have repeats.  If a specimen is required for the source service, the Priority component contains specimencollection priority rather than processing priority.

Rationale:  This will be enhanced by the committee to cover all data items required by the quantity timing data type in Version 2.x.

Comments:
Comments
The Workflow capabilities of HL7 have been completely redesigned.  There are similarities, but no direct mapping to QT is possible.  Note that the QT has never been fit into the version 3 RIM.  Especially the promiscuous use in multiple places was intended more as a placeholder than as any functional design.  This particular situation came out of the Spring '98 Harmonization meeting, where it was felt that the timing capability proposed for USAMP-I was not sufficient.


Description:
A description of the rules that trigger reflex testing for an intended or ordered service.

Rationale:


Description:
Specifies the basis for the association of the source to the target.

Rationale:  
OpenIssue:  Need code examples.


Description:
A class which captures the reason(s) for a service when instantiated for a particular target of service by a particular participant in the service e.g., a free text reason, coded value(s), or associations with prior service_event(s).

Rationale:  Regulatory agencies demand reasons for services e.g., 1500 billing forms.  Frequently, a prior observation is the reason for a treatment or a prior treatment is the reason for an observation.


ModelElement:
Service_reason :: has_as_evidence(0..1) :: Service_event :: is_evidence_for(0..n)

Comments:
pointing to the other service (event) that is the reason for the source service.


ModelElement:
Service_reason :: is_reason_for(0..1) :: Service_event :: has_as_reason(0..n)

Comments:
to a Service_relationship of type "has reason"


ModelElement:
Service_reason :: is_reason_for(0..1) :: Service_intent_or_order :: has_as_reason(0..n)


Description:
The date and time at which the determination is made that the reason applies.

Rationale:

Comments:
Rationale: the service reason is assigned by the responsible originator of the source service.  The time of the reason thus defined is not practically distinguishable from the time of that source service.

If reasons are interpreted after the fact this must be represented differently (e.g., throught a mechanism similar (identical?) to the Condition_node.)

Note that this is a USAMP-I attribute that has no users yet, so it can be withdrawn by USAMP-II.


Description:
The date and time at which the applicability of the reason is document.

Rationale:


Description:
Capture free text for the reason for a service event when the connection to another service event is not known (connection as a reason).


Description:
Request information about various kinds of services that are controlled by a schedule.

Rationale: Currently in 2.3

OpenIssue: Should services be handled separately from resources?  Make certain that resource requests for scheduling are different from ordered service requests in Orders.

OpenIssue:  The definition does not encompass notifications (where it is not a request).


Description:
A code indicating whether the identified service can be substituted with an equivalent service.

Rationale: Currently in 2.3

OpenIssue:  Need code examples.  Also, should this be a Boolean (_ind) rather than _cd?


Description:
The duration for which the service is requested for this appointment, if it is different than the overall duration of the appointment

Rationale: Currently in 2.3

OpenIssue:

Comments:
the duration is the width of an occurrence interval in total_time.


Description:
Date and time this service is requested for the appointment.

Rationale: Currently in 2.3

OpenIssue:

Comments:
the low boundary of an occurrence interval specifies the start.


Description:
The offset that this service is requested for the appointment, expressed in units of time relative to the scheduled start date/time of the appointment.

Rationale: Currently in 2.3

OpenIssue:  How does this attribute work with the start_dttm for the request.  This offset is relative to the appointment and would apopear to present a conflict with the other attribute.

Comments:
A service that is part of a larger entity (service) is associated as a service_relationship of type plan-component.  Dependency can be expressed without having to refer to time by the sequence_nmb that establishes an ordering among plan components.  Alternatively the services may be given all the same sequence number so they start all together with the beginning of the super service DELAYED by the pause_qty.  This timing of services is less common than sequencing and should be used only when it is appropriate.


Description:
A code that describes the request status of scheduling a service, from the point of view of the filler application.

Rationale: Currently in 2.3

OpenIssue:


Description:
A person or organization that has an investment, share, or interest in healthcare.

OpenIssue:  The implications of declaring this an abstract class on the methodology are unclear.


Description:
A role class that captures the various roles played by the recipient(s) of a service (including people, organizations, things, animals, etc.).

Rationale:  Since multiple entities may participate in the reception of services as particular targets of a service, a role class is needed to capture the multiple roles these participants play in receiving a service from a provider of a service.


ModelElement:
Target_participation :: is_target_of(0..1) :: Service_event :: has_as_target(0..n)

Description:
Rationale:  The Target_participation class may identify a target for either a Service_intent_or_order or for a Service_event.  It therefore cannot have a mandatory connection to either of those classes.  We are lacking the formalism to indicate that one of these two relationships MUST be in effect for each Target Participation instance.

Mapping:
Target :: in(1..1) :: Service :: has(0..*)

Comments:
Refer to Actor for an explanation of these association names.


ModelElement:
Target_participation :: is_target_of(0..1) :: Service_intent_or_order :: has_as_target(1..n)


Description:
The nature of purpose of the target's participation.  Examples:  subject, beneficiary, receiver, user, specifier.

Rationale:


Description:
Any combination of the effective date and time of the target participation, the termination date and time for the target participation , and the elapsed time during which the target participation is in effect.

Rationale:


Description:
An authoritative direction or instruction concerning the dispensement of medication to a patient.

Rationale:  Conformance to new name for generalization.

Comments:
in "intent" or "order" mood.

Note that the renaming to Medication is because the generalization to Treatment is not entirely possible.  This class is clearly designed with pharmacologic treatment in mind, and all other uses for other treatment modalities are accidential or retro-fit.  The Medication paradigm to treatment fits well for the application of a therapeutic agent into the patient, via a certain route, and in a certain dose and dose form.  This paradigm is applicable for Medication using gases (oxygen treatment, anesthesia, ICU ventilator treatement) or for parenteral nutrition.  It might be applicable to nuclear medicine and radiotherapeutic services, but that has not been validated.

Certainly there is a host of treatments that do not fit very well into this medication paradigm. Most notably physiotherapy, ergotherapy, chiropraxis, with a slippery slope to surgical procedures. Not to mention psychotherapy at all.  Retrofitting these modalities to dose and route is not appropriate. 

In downsizing the term Treatment to Medication, the USAMP-II does not take away any functionality, it is just more humble in not pretending that it covers all kinds of treatments that neither HL7 v2.x nor RIM092 nor USAMP-I and II ever did cover.


ModelElement:
Treatment_intent_or_order :: has_parts(1..n) :: Treatment_intent_or_order_revision :: is_part_of(1..1)

Comments:
of type "is revision of" from a revision to a previous order(revision).


Description:
This field contains the identifier of the condition or problem for which the drug/treatment was prescribed.

Rationale: This attribute standards in for a relationship to an "indication" class, which does not currently exist in the RIM.

OpenIssue:

Comments:
Indication is linked through a Service realtionship of type "reason" to the observation or condition constituting the indication.

The RIM092 uses the term "identifier" which is unfortunate.  It does suggest a straight MDF violation by suggesting a forreign key (one attribute citing the identifier of another class.)  If what is meant is really a coded concept of the diagnosis constituting the indication, then the attribute type is wrong.

In any way this is once more an example where USAMP-II removes free-floating codes (or dysfunctional identifiers.)


Description:
Free form instructional text from the ordering provider for the treatment order.

Rationale:

Comments:
of the Service in order mood. Note that in an order, any attribute is meant in an imperative or instructional sense. Hence the description of an order is logically an instruction. No separate field for instructions is necessary.  This concurs with the policy that the Service.descr is the last catch-all attribute for all free text, whereby the USAMP-II proposal makes structured and coded information much more easy to construct (e.g., through removing free-floating codes.)


Description:
Specifies the strength of the medication as requested on the order, when it is not included in the Universal Service Identifier

Rationale: 

OpenIssue:


Description:
An indicator that a substitution medication is allowed.


Description:
The collection of characteristics for a pharmacy treatment order that can be revised during the course of processing the order.  Pharmacy encoding is an example of a process that may revise order characteristics.  This "revisions" class allows tracking of changes made to the order, and representation of the order at any stage in its processing.

Rationale:   Each instance of the class "Treatment_intent_or_order_revision" represents a revision of the original order.  There can be many revisions for a single order.  Pharmacy encoding is only one example of such a revision.  The class name conveys this multiplicity of specification.

OpenIssue: Note that this is used to surface the information carred in the Pharmacy Encoded segment of v2.3, and this name ‘revision’ may need to be changed to be more appropriate.

Comments:
in order or intent mood, linked through a relationship of type is-revision-of with a previous order.


Description:
the method by which treatment is dispensed, e.g., Traditional, unit-dose, floor stock, automatic dispensing

Rationale: 

OpenIssue:

Comments:
of a Supply service representing the dispensing.

The use of this attribute, however, is ill-defined in HL7 v2.3 as well as RIM092.  The roster of example values for this code read like a potpourie of interesting facts one might want to know, but is hardly cohesive?

We need to know what concepts to map before we can definitely map them anywhere.


Description:
This field contains the size of package to be dispensed

Rationale: 

OpenIssue:

Comments:
Dispense packages are modeled using the Material class.  The nesting of pills in packs and packs in cartons is handled very smoothly through the Material_relationship.


Description:
condition or problem for which the drug/treatment was prescribed

Rationale:  This attribute stands in for a relationship to an "indication" class, which does not currently exist in the RIM.

OpenIssue:

Comments:
of type "has-reason" pointing to the indication.


Description:
The duration of time over which the pharmaceutical is to be administered when the ordered substance is to be administered continuously at a prescribed rate (e,.g., certain IVs).  For example, if 300 ml are to be given, and the "give per time unit" is 2 hours, the rate is 150ml/hour (300ml/2 hr) and the duration of this dose is 2 hours.

Coded concepts include:  #days, #hours, #minutes (where # is any integer); total amount delivered - # units (where # is any integer, units as in min_giv_qty); indefinite.

This field is distinct from the "interval" component of the quantity/timing field, but it could be used in conjunction with it, as in give 150ml of NS per hr for 2 hours, repeat twice a day.

OpenIssue:  This should probably be a _qty attribute, but cannot be while the full set of coded concepts above is in effect.  Conisderations:  
1.  "give" until total amount delivered = # Units"; is a restatement or revision of min_giv_qty.  Total amount to give should be coded in give amounts, not here; when this code is used, a rate cannot be determined.  
2.  "indefinite": can be a flavor of "null"
3.  these two codes may be cut-and-paste holdovers from Q/T in the v2.3 spec.
4.  without these two codes, this attribute can be expressed as a simple_qty with units.


Description:
This field contains the rate at which to administer treatment.

Comments:
Note that this field is redundant with the give-per-time-unit field. A dose per time unit is a rate!


Description:
Date and time of most recent refill or dose dispensed.

OpenIssue:  Is this information known at the time of order revision or should this attribute be moved to Treatment_service_event?

Comments:
of the last dispense service.  Dispense services are Supply services for the therapeutic substance material.  All dispense services occur in fulfillment of the dispense-part of the prescription (and are linked to the prescription through fulfills relationships.) The dispense events are counted in the Service_relationship.sequence_nmb attribute.


Description:
In a variable dose order, this is the maximum ordered amount.  In a nonvarying dose order, this field is not used.

Comments:
may be states as a probability distribution to accommodate min/max doses in the semantically correct way.  Simple translations exist between a min/max form and a probability distribution.


Description:
This field is the ordered amount of substance to be administered in a single dose.  In a variable dose order, this is the minimum ordered amount.  In a nonvarying dose order, this is the exact amount of the order.


Description:
Indicates whether the pharmacist or non-pharmacist treatment supplier filling the order needs to pay special attention to the provider's pharmacy/treatment instructions.

Comments:
of type reviewer may ssign someone who should review the order.


Description:
Theprescription number as assigned by the pharmacy or treatment application.

OpenIssue:  Is this information known at the time of order revision, or should this attribute be moved to Treatment_service_event?


Description:
Specification for one component of the ordered medication or treatment

Rationale: 

OpenIssue:

Comments:
Material and Material_relationship allow the detailled construction of recipe orders through material relationship types "has-ingerdient" and subtypes thereof ("base", "additive", to be v2.3 compatible.)


Description:
Specification for one route of administration for the ordered medication or treatment.  Specification includes route, site, administration device and administration method.

Rationale: 

OpenIssue:

Comments:
plus Service.body_site_cd, Service.method_cd, and possibly Target of type device (that's what hides behind "PTrout".

Different routing options are given as associated Medication services in option mood.  That is, one can specify multiple doses, doseforms, routes, sites, all together (which is reasonable since an IV route will need a different dose than a PO route, something that Ptrout/RXR could never handle!)


Description:
A means of specifying when the service described by the give notice is to be performed and how frequently.  It is a complex multicomponent field that can have repeats.  The pharmacy or treatment department has the "authority" (and/or necessity) to schedule dispense/give events.  Hence, the pharmacy or treatment department has the responsibility to encode this scheduling information for the pharmacy service order item and pharmacy service give notice.  The quantity/timing for the patient service order does not change: it always specifies the requested give/dispense schedule of the original order 

Rationale: 

OpenIssue:

Comments:
in the full fledged form of a General Time Specification, allows repeated occurrence intervals to be specified calendar depenent or based on absolute time, or symbolically with time-like periodic events (e.g. HS at the hour of sleep).


Description:
The total original number of refills.  Outpatient only.

Comments:
of the Supply order that embodies the dispense part of the prescription.  Note, a medication order is first and foremost an order to administer a medication.  But it also includes dispense related instructions (e.g. pakcet size, refills, etc.) This is now separated by treating the dispensing as a Supply service for material.  A refill dispense order is a repeatable order for supplies.


Description:
The number of refills /doses dispensed.  This field is required when a prescription is dispensed to an outpatient.  It is not relevant to inpatient treatment orders.

OpenIssue:  1)  the name and description for this attribute, as extracted from v2.3, are very confusing.  Need to discuss difference between refills and doses, and clarify when this field refers to which.  2) is this information known at the time of order revision, or should this attribute be moved to Treatment_service_event?

Comments:
of the link between the Dispense/Supply order and the dispense events.

BTW: The v2.3 description is pretty clear: the RXD tracks refills while the RXA tracks doses administered.  These are different fields.


Description:
The number of refills remaining.  This field is required when a prescription is dispensed to an outpaint.  It is not relevant to inpatient treatment order.

OpenIssue:  This attribute also appears in the Treatment_service_event.  Is this information known at the time of order revision, or should this attribute appear only in the Treatment_service_event?

Comments:
This is a calculated value, the difference between refills allowed and the sequence_nmb of the most recent dispense.


Description:
Indicates whether the medication encoded is a substitution for the medication ordered.  In the case of substitutions, includes the nature and/or reason for the substitution.  Coded concepts include:  No substitute; generic substitution; therapeutic substitution; Substitution allowed - pharmacist selected product; Substitution allowed - patient requested product; Substitution not allowed - brand drug mandated by law.

OpenIssue:


Description:
the total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.

Rationale: 

OpenIssue:

Comments:
See USAMP-II specification on this attribute. This is a very special attribute for a special use case.


Description:
the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing/administering the order

Rationale: 

OpenIssue:  Need code examples.


Description:
Actual administration of medication as part of a pharmacy treatment.


Description:
The duration of time over which the phatmaceutical was administered when the ordered substance was administered continuously at a prescribed rate (e.g., certain IVs).  For example, if 300 ml were given, and te "give per time unit" is 2 hours, the rate is 150ml/hour (300ml/2 hr). and the duration of this dose is 2 hours.

Rationale:  The V2.3 RXA field "Administered per (time unit)" combines the meanings of "per_time_unti" and "rate," which are separate concepts with separate fields and separate definitiosn for the other RX segments in V2.3.  This is probably a cut-and-paste errors in the RXA.  For the RIM, two separate attributes have been established corresponding to RXA-12-354.  These attributes are “administered_per_timeunit_cd” and “ administered_rate_qty”, whose names and descriptions parallel attributes in the classes supporting treatment orders and treatment give notices.For the RIM, two separate attributes have been established corresponding to RXA-12-354.  These attributes are "administered_per_timeunit_cd" and  "administered_rate_qty", whose names and descriptions parallel attributes in the classes supporting treatment orders and treatment give notices.

OpenIssue:  Open Issue: This should probably be a _qty attribute, but cannot be while the full set of coded concepts above is in effect. 
Considerations: 
1. "give until total amount delivered = # units"; is a restatement or revision of min_give_amt_qty.  Total amount to give should be coded in give amounts, not here;  when this code is used, a rate cannot be determined.
2. "indefinite": can be a flavor of ‘null'
3. these two codes may be cut-and-paste holdovers from Q/T in the V2.3 spec.
4. without these two codes, this attribute can be expressed as a simple _qty with units.


Description:
The rate at which this medication was administered.

Rationale:  Rationale: the V2.3 RXA field "Administered per (time unit)" combines the meanings of "per_time_unit" and "rate", which are separate concepts with separate fields and separate definitions for the other RX segments in V2.3.  This is probably a cut-and-paste error in the RXA.  For the RIM, two separate attributes have been established corresponding to RXA-12-354.  These attributes are "administered_per_timeunit_cd" and  "administered_rate_qty", whose names and descriptions parallel attributes in the classes supporting treatment orders and treatment give notices.


Description:
The ordinal number of this administration in a sequence of administrations. This field starts with 1 the first time that medication is administered for this order.  Increments by one with each additional administration of medication.

Rationale:  

Open Issue:  This field was deleted under USAMP (U005), because it’s usage prior to USAMP was as a linking mechanism between dispenses, gives and administrations.  This functionality was taken over by the Service_event_relationship class.  The reinstatement in March99 does not give a rationale for this attribute’s existence, other than that it represents a V2.3 field.  Since it’s V2.3 usage is already supported in the RIM, this is not a sufficient rationale for reinstatement.  The steward should reconsider the need for this attribute, and provide a better rationale.

Comments:
of the "fulfills" relationship linking the Medication event with the order (or intent.)


Description:
This field contains notes from the provider administering the medication.  May describe a custom IV, mixture, or salve, for example.

Comments:
however, use the appropriate sturcture in the Material class for providing any functional information.


Description:
Status of treatment administration event

Rationale: 

OpenIssue:


Description:
This field contains the reason the patient refused the medical substance.  Any entry in the field indicates that the patient did not take the substance

Rationale: 

OpenIssue:

Comments:
with the patient being an dissenting Actor


Description:
Date/time the administration information was entered into the source system.  This field is used to detect instances where treatment administration information is inadvertently entered multiple times by providing a unique identification field.  Under usual circumstances, this field would be provided automatically by the computer system rather than being entered by a person

Rationale: 

OpenIssue:

Comments:
This is a hack in circumventing the obvious solution of unique identifiers.  Times have changed in the last 20 years and v3 may need to "raise the bar" (W. Rishel) in this case.


Description:
Notification of a pharmacy treatment dispense.


Description:
the method by which treatment is dispensed, e.g., Traditional, unit-dose, floor stock, automatic dispensing

Rationale: previously unmatched V2.3 field

OpenIssue:

Comments:
not clear what this is or does.  But can be mapped for sure once we know what to map.


Description:
An indicator that the pharmacist filling the order needs to pay special attention to provider instructions.

Comments:
of type reviewer allows to specify the requirement for review.

Alternatively we can put in the attribute Service.requires_review_ind.


Description:
Special instructions from the pharmacy or treatment supplier to the provider administering the order.

Rationale: 

OpenIssue:  If these are really special instructions as per the description, are they really coded?  If so, give examples.


Description:
This field contains the total daily dose being dispensed.

Rationale:


Description:
A type of service event in which a pharmacy or treatment service is performed.

Comments:
note that dispensing is excluded!!! Dispensing is not a medication service, it's a supply. Medication service is only the medically relevant administration of the substance, not the change of possessorship.


ModelElement:
Treatment_service_event :: generalizes(1..1) :: Treatment_service_administration :: specializes(1..1)

Description:
Rationale:  Alignment with new view of service event.


ModelElement:
Treatment_service_event :: generalizes(1..1) :: Treatment_service_dispense :: specializes(1..1)


ModelElement:
Treatment_service_event :: generalizes(1..1) :: Treatment_service_give :: specializes(1..1)


Description:
The amount of dose form items diispensed, scheduled or administered. The amount can be a dimensionless number for discrete dose forms such as tablets, in which case the amount is the number of tablets (Note that tablets can be broken into half.) For continuously divisible dosage forms (e.g., fluids), the amount is be a quantity convertible to the unit of the strength's denominator (e.g., 10 ml). In any way, the total dose (i.e. the amount of substance of a pharmaceutical agent) is calculated through dose = strength × amount. The total administered dose is not reported in any additional attribute, since this would lead to unnecessary redundancies.

Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was triggered by the needs of the Government SIG.

OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.

OpenIssue:  This attribute combines a pure number concept (# of dosage form units) with a measured quantity concept (quantity of therapeutic material).  This needs to be addressed in the treatment model revision effort.


Description:
Some routes, such as i.m. or i.v., may have different body sites (e.g. i.m.: m. deltoideus right or left arm, m. gluteus, m. quadriceps femoris left or right leg.)

Rationale:  May be required for some routes.  Since Summer 1997 it was hidden in a composite data type that does not exist.  Until we fully understand the model it is better to model this explicitly than to hide it in a data type.

OpenIssue:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.


Description:
The unit of administration, i.e. the kind of thing that is administered, or the form of the pharmaceutical substance. (e.g., things like: tablet, suppository, spray, vial, pre-filled syringe, etc.)

Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was triggered by the needs of the Government SIG.

OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.


Description:
This field contains the identifier of the condition or problem for which the treatment service was established.  

Rationale: This attribute stands in for a relationship to an "indication" class, which does not currently exist in the RIM.

OpenIssue:  Need code examples.


Description:
This field contains the prescription number as assigned by the pharmacy or treatment application   This field is equivalent in uniqueness to the pharmacy/treatment supplier filler order number.  At some sites, this may be the pharmacy/treatment supplier (internal) sequential form.  At other sites, this may be an external number.

Rationale:  This attribute is an alternate id for the class in which this attribute resides, but only if a prescription exists for the service.  Does not reference an instance in any other class.
Service_event.filler_id (from the generalization) is the primary id.


Description:
Specification for one component of the treatment service.  Specification includes treatment code & name, dosage form, strength, and amount to be administered (minimum and maximum).   A single treatment service may encompass multiple treatment components.  A common reason for multiple components is for specification of a compound medication such as a custom IV, mixture or salve.

Rationale: 

OpenIssue:


Description:
Specification for one route of administration for the treatment service. Specification includes route, site, administration device and administration method. A single treatment service may involve several routes of administration.

Rationale:  

OpenIssue:


Description:
The number of refills remaining.  this field is required when a prescription is dispensed to an outpatient.  It is not relevant to inpatient treatment orders.

Rationale:


Description:
The entry path by which the substance is incorporated or otherwise directed to the desired center of effect (e.g., per os, intra venous, rectal, nasal, per inhalationem, ...)

Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was triggered by the needs of the Government SIG.

OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.


Description:
The amount of substance in one item of dose form. Amount of substance can be a true amount of substance (e.g., 40 mmol), a mass (e.g., 250 mg), a volume (e.g., 10 ml), or some biochemical arbitrary quantity (e.g., arbitrary units, katal, U, i.U.) For all continuously divisible dose forms, such as fluids or gases, strength is a concentration (e.g., 10 mg/ml, 1 %, 20 mmol/l). A dimensionless strength 1 (one) means that the strength is undefined, and an undefined strength is equivalent to a strength of 1 (one).

Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was triggered by the needs of the Government SIG.

OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.


Description:
Expiration date of the medication.

Rationale:

Comments:
of Material associated as target … usually target of a dispense service.


Description:
This field contains the lot number of the medical substance.

Rationale:


Description:
This field contains the manufacturer of the medical substance.  Codes may come from NDC, MVX or some other coding system.

Rationale: 

OpenIssue:


Description:
A code indicating the medication was a substitution for the one ordered.

OpenIssue:  Need code examples.


Description:
The issuing of a pharmacy or treatment give notice.  The give notice establishes a datailed schedule of treatment for a specific period of time.


Description:
The duration of time over which the pharmaceutical is to be administered when the ordered substance is to be administered continuously at a prescribed rate (e.g., certain IVs).  For example, if 300 ml are to be given, and the "give per time unit" is 2 hours, the rate is 150ml/hour (300ml/2 hr) and the duration of this dose is 2 hours.

Coded concepts include: #days, #hours, #minutes (where # is any integer); total amount delivered = # units (where # is any integer, units as in min_give_qty); indefinite.

This field is distinct from the"“interval" component of the quantity/timing field, but it could be used in conjunction with it, as in give 150ml of NS per hr for 2 hour, repeat twice a day.

Rationale:

OpenIssue:  This should probably be a _qty attribute, but cannot be while the full set of coded concepts above is in effect. 
Considerations: 
1."“give until total amount delivered = # units"; is a restatement or revision of min_give_amt_qty.  Total amount to give should be coded in give amounts, not here;  when this code is used, a rate cannot be determined.
2. "indefinite": can be a flavor of ‘null'
3. these two codes may be cut-and-paste holdovers from Q/T in the V2.3 spec.
4. without these two codes, this attribute can be expressed as a simple _qty with units.


Description:
This attribute allows the rate of administration (quantity per unit of time) to be specified directly, rather than calculated using the give quantity and give per timeunit values.


Description:
An indication that the pharmacist filling the order needs to pay special attention to the order notes.


Description:
A means of specifying when the service described by the give notice is to be performed and how frequently.  It is a complex multicomponent field that can have repeats.  This field contains the quantity/timing specification that refers to either a single scheduled give instruction only.  The pharmacy or treatment department has the "authority" (and/or necessity) to schedule dispense/give events.  Hence, the pharmacy or treatment department has the responsibility to encode this scheduling information for the pharmacy service order item and pharmacy service give notice.  The quantity/timing for the patient service order does not change: it always specifies the requested give/dispense schedule of the original order.


# DISPOSITION_CD

Description:
An item that is mapped so that the mapping very obviously.  For example, if just the name is changed. This includes mappings of properties if the destination is in a consolidated or "merged" class (e.g. Master_service to Service, Service_event_relationship to Service_relationship etc.)  

That is, once a RIM092 class has been mapped, to some USAMP-II class, all properties of that class are eligible to clear mapping.

The mapping is not clear if immediate elements are mapped to some structure, e.g., involving the service_relationship class.


Description:
Dropping of formal elements without substantial functional impact.  E.g., the empty classes Assessment and Care_event including all relationships they caused.  This deletion should not be an issue of discussion.


Description:
Element is dissolved and preserved in structures of the USAMP-II. Close to "mapped", but may be more indirect.


Description:
Deleted because element is dysfunctional, in direct MDF violation, or insufficiently defined to allow “rescuing” it.  Mostly all three criteria apply.  Example: “action codes” are hidden trigger events.


Description:
Deleted for domain-logical reasons, mapped to some sort of different approach extenal to the RIM.  Suggests that these things should be handled differently. E.g., SI-units vs. conventional units and conversion “equation”.

The rationale for this is not style or taste, but because the current approach is proven to be insufficient, especially non-interoperable.


Description:
Deleted to sanitize HL7 v3 from mistakes of the past and from current malpractice in system design. What Wes Rishel calls  “raising the bar.”


Description:
Aggressive notion is intended.  No HL7 legacy is ever kicked out, but there is some pure info-junk in the model, mostly coded attributes that are completely foreign to HL7, and sneaked into the RIM with not the slightest attempt at a useful definition or code table.


Description:
Billing related items that are not mapped because they need serious revision first.  These items could be resolved and fit in nicely but that would require to involve substantial parts of the PAFM classes in the proposal.  This is simply not feasible at this time.

The proposal is to lock these items out from the RIM in order to force us to solving the associated use cases with the existing billing and charge infrastructure of PAFM, making changes as necessary.  

These items are considered deficient, so chaces are they do not work, at least not given the higher goals for interoperability that is in the charter of HL7 v3.

As a last resort, the items could stay (or be mapped wherever their class is mapped) and marked with an open issue.  However, experience shows that open issues are largely ignored, especially those open issues that deserve some more energy to be solved.  So locking these items out may increase the pressure to deal with the issues.


Description:
Items that need more thought by OO to fit in well.  

These are non-critical items that are conceptually problematic as defined now, but are (likely) not used very frequently. Therefore, these items are not mapped in this round.

A plan B is to keep them in the model as clearly marked, or even separated into their own class with a 1 --- 0..1 connection.


Description:
Items that are fully mapped.  This is not necessarily a one to one mapping of "data elements", but the semantics is clear and a representation is provided for it in the USAMP that is at least as functional as the item was in RIM092.


Description:
Items that are mapped to a large extent, often is a one to one mapping yet there are issues of semantics that would need attention.  Often times the issue raised is less a problem with the USAMP than a problem with the way the RIM092 element is defined.


Description:
Elements outside of the USAMP-II's scope to which USAMP-II  connects, i.e., items at the margin of USAMP-II.


Description:
Needs to be turned into a "move element" proposal.


Description:
Issues that we want to resolve before the final vote on them.


Description:
Elements that are left untouched from the RIM095.  E.g., atributes that stay in a class even though other attributes are taken out into a related class, or mapped out.  These items do not constitute harmonization proposal items because they won't change anything.


Description:
Elements that are left untouched from the RIM095.  E.g., atributes that stay in a class even though other attributes are taken out into a related class, or mapped out. Hovewer issues have been found that need to be recorded. These items will constitute harmonization proposals for opening issues.


