USAMP-II RIM changes	Submitter:	Gunther Schadow and Dan Russler
	Committees:	C04 (OO) and C12 (PC)
	ChngID	ChngType	Changed Model Element
	C04-R091.01.00	Add class	Service	USAMP-II Section:	2.2
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 1 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.02	Add association	Service :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:	From RIM092 (Service_event)
	Issue:	Association naming is very broad: "has assigned to" does not say what this assignment means.
	Remarks:	 
	C04-R091.01.03	Add association	Service :: is_associated_with(0..*) :: Financial_transaction :: pertains_to (1..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:	From RIM092 (Service_event)
	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?
	Remarks:
	C04-R091.01.04	Add association	Service :: is_charged_to(0..1) :: Patient_billing_account :: has_charges_for (0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:	From RIM092 (Service_event)
	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?
	Remarks:
	C04-R091.01.05	Add association	Service :: is_documented_by(0..*) :: Clinical_document_header :: documents(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	This association stands for any documentation of Services in clinical documents.
	Rationale:	From RIM092 (Service_event)
	Issue:	This many-to-many association should be resolved.
	Remarks:	 The open issue is preexisting in RIM092
	Wednesday, October 13, 1999	Page 2 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.06	Add association	Service :: is_covered_by(0..*) :: Coverage_item :: provides_coverage_for(1..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:	From RIM092 (Master_service)
	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?
	Remarks:
	C04-R091.01.11	Add attribute	Service.id	USAMP-II Section:	2.2.1.1
	Data type	Constraint	Default	New Info:	This is an instance identifier of a particular Service object. For example, whenever a service is carried out, there is a new service object 
	SET<II>	instantiated with an identifier that uniquely distinguishes this service object from every other service object.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.11bis	Assign data type	Service.id	USAMP-II Section:	2.2.1.1
	Data type	Constraint	Default	New Info:	SET<II>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.12	Add attribute	Service.mood_cd	USAMP-II Section:	2.2.1.2
	Data type	Constraint	Default	New Info:	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 
	SET<CV>	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 3 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.12bis	Assign data type	Service.mood_cd	USAMP-II Section:	2.2.1.2
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.13	Add attribute	Service.type_cd	USAMP-II Section:	2.2.1.3
	Data type	Constraint	Default	New Info:	A code for the kind of action (e.g., physical examination, serum potassium, etc.), used to be called “universal service identifier”.  The 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.13bis	Assign data type	Service.type_cd	USAMP-II Section:	2.2.1.3
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 4 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.14	Add attribute	Service.descr	USAMP-II Section:	2.2.1.4
	Data type	Constraint	Default	New Info:	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 
	ED	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.14bis	Assign data type	Service.descr	USAMP-II Section:	2.2.1.4
	Data type	Constraint	Default	New Info:	ED
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 5 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.15	Add attribute	Service.status_cd	USAMP-II Section:	2.2.1.5
	Data type	Constraint	Default	New Info:	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 
	CV	the state-transition model of a service class.  No alternative coding system can be used for the status_cd attribute (CNE, coded no exceptions.)
	Rationale:
	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.
	Remarks:	 
	C04-R091.01.15bis	Assign data type	Service.status_cd	USAMP-II Section:	2.2.1.5
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.16	Add attribute	Service.total_time	USAMP-II Section:	2.2.1.6
	Data type	Constraint	Default	New Info:	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 
	GTS	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.16bis	Assign data type	Service.total_time	USAMP-II Section:	2.2.1.6
	Data type	Constraint	Default	New Info:	GTS
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 6 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.17	Add attribute	Service.critical_time	USAMP-II Section:	2.2.1.7
	Data type	Constraint	Default	New Info:	This is the “biologically relevant” time of an action.  The concept is best understood with observations, where the time of the observation action may
	GTS	 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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.17bis	Assign data type	Service.critical_time	USAMP-II Section:	2.2.1.7
	Data type	Constraint	Default	New Info:	GTS
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.18	Add attribute	Service.method_cd	USAMP-II Section:	2.2.1.8
	Data type	Constraint	Default	New Info:	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 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 7 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.18bis	Assign data type	Service.method_cd	USAMP-II Section:	2.2.1.8
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.19	Add attribute	Service.body_site_cd	USAMP-II Section:	2.2.1.9
	Data type	Constraint	Default	New Info:	Most health care services have a focus on a particular anatomic structure of the patient (the “target” of service.)  This information is found in 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.19bis	Assign data type	Service.body_site_cd	USAMP-II Section:	2.2.1.9
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.20	Add attribute	Service.interpretation_cd	USAMP-II Section:	2.2.1.10
	Data type	Constraint	Default	New Info:	This attribute allows for a very rough interpretation of the course or outcome of a service action.  This is sometimes called “abnormal flags”, 
	SET<CV>	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.”
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 8 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.20bis	Assign data type	Service.interpretation_cd	USAMP-II Section:	2.2.1.10
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.21	Add attribute	Service.confidentiality_cd	USAMP-II Section:	2.2.1.11
	Data type	Constraint	Default	New Info:	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 
	SET<CV>	[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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.21bis	Assign data type	Service.confidentiality_cd	USAMP-II Section:	2.2.1.11
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 9 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.22	Add attribute	Service.max_repeat_nmb	USAMP-II Section:	2.2.1.12
	Data type	Constraint	Default	New Info:	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 
	INT	1	numbers.)  See the discussion on service plans in the USAMP-II specification, part A, on how specifically this is used.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.22bis	Assign data type	Service.max_repeat_nmb	USAMP-II Section:	2.2.1.12
	Data type	Constraint	Default	New Info:	INT
	1	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.23	Add attribute	Service.interruptible_ind	USAMP-II Section:	2.2.1.13
	Data type	Constraint	Default	New Info:	Indicates whether a service is interruptible by asynchronous events (such as “through”-conditions to turn false, or time running up.) See discussion
	BL	true	 on activity plans in the USAMP-II document, part A.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.23bis	Assign data type	Service.interruptible_ind	USAMP-II Section:	2.2.1.13
	Data type	Constraint	Default	New Info:	BL
	true	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.24	Add attribute	Service.substitution_cd	USAMP-II Section:	2.2.1.14
	Data type	Constraint	Default	New Info:	Indicates whether an ordered or intended service may be or has been substituted for a different service. The fact that the actual service differs 
	CV	N	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 10 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.01.24bis	Assign data type	Service.substitution_cd	USAMP-II Section:	2.2.1.14
	Data type	Constraint	Default	New Info:	CV
	N	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.25	Add attribute	Service.priority_cd	USAMP-II Section:	2.2.1.15
	Data type	Constraint	Default	New Info:	This attribute encodes the urgency under which the service is to be scheduled and performed, or was performed.  This attribute is used in orders 
	SET<CV>	{R}	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.25bis	Assign data type	Service.priority_cd	USAMP-II Section:	2.2.1.15
	Data type	Constraint	Default	New Info:	SET<CV>
	{R}	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.26	Add attribute	Service.orderable_ind	USAMP-II Section:	2.2.1.16
	Data type	Constraint	Default	New Info:	This attribute indicates whether this service can be requested independently from other services.  Some services can only occur as subordinate to 
	BL	true	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.01.26bis	Assign data type	Service.orderable_ind	USAMP-II Section:	2.2.1.16
	Data type	Constraint	Default	New Info:	BL
	true	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 11 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.00	Add class	Service_relationship	USAMP-II Section:	2.4
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.02	Add association	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 12 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.03	Add association	Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.11	Add attribute	Service_relationship.type_cd	USAMP-II Section:	2.4.1.1
	Data type	Constraint	Default	New Info:	Determines the meaning of a relationship between two Services.  This attribute is probably the most important attribute in this entire model besides 
	CV	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.11bis	Assign data type	Service_relationship.type_cd	USAMP-II Section:	2.4.1.1
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 13 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.12	Add attribute	Service_relationship.inversion_ind	USAMP-II Section:	2.4.1.2
	Data type	Constraint	Default	New Info:	The inversion indicator is used when the meaning of the relationship type must be reversed.  For example, we define a relationship type reason to 
	BL	false	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.12bis	Assign data type	Service_relationship.inversion_ind	USAMP-II Section:	2.4.1.2
	Data type	Constraint	Default	New Info:	BL
	false	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 14 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.13	Add attribute	Service_relationship.sequence_nmb	USAMP-II Section:	2.4.1.3
	Data type	Constraint	Default	New Info:	This integer number allows one to specify an ordering amongst the outgoing relationships of a service. This is used to represent sequences of 
	INT	1	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.13bis	Assign data type	Service_relationship.sequence_nmb	USAMP-II Section:	2.4.1.3
	Data type	Constraint	Default	New Info:	INT
	1	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.14	Add attribute	Service_relationship.priority_nmb	USAMP-II Section:	2.4.1.4
	Data type	Constraint	Default	New Info:	This integer number allows to specify another kind of ordering amongst the outgoing relationships of a service.  This is used to represent the priority
	INT	1	 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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.14bis	Assign data type	Service_relationship.priority_nmb	USAMP-II Section:	2.4.1.4
	Data type	Constraint	Default	New Info:	INT
	1	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 15 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.15	Add attribute	Service_relationship.pause_qty	USAMP-II Section:	2.4.1.5
	Data type	Constraint	Default	New Info:	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
	PQ	~ 1 s	0 s	 before the slot is entered, so the pause specifies a minimal waiting time before the service is executed after its pre-conditions become true.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.15bis	Assign data type	Service_relationship.pause_qty	USAMP-II Section:	2.4.1.5
	Data type	Constraint	Default	New Info:	PQ
	~ 1 s	0 s	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.16	Add attribute	Service_relationship.checkpoint_cd	USAMP-II Section:	2.4.1.6
	Data type	Constraint	Default	New Info:	Indicates when associated pre-conditions are to be tested. The following values are defined:
	CV	B	
	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.16bis	Assign data type	Service_relationship.checkpoint_cd	USAMP-II Section:	2.4.1.6
	Data type	Constraint	Default	New Info:	CV
	B	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 16 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.17	Add attribute	Service_relationship.split_cd	USAMP-II Section:	2.4.1.7
	Data type	Constraint	Default	New Info:	When an activity plan has a branch (indicated through multiple steps with the same item number) the split code specifies how branches are 
	CV	I1	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.)
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.17bis	Assign data type	Service_relationship.split_cd	USAMP-II Section:	2.4.1.7
	Data type	Constraint	Default	New Info:	CV
	I1	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 17 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.18	Add attribute	Service_relationship.join_cd	USAMP-II Section:	2.4.1.8
	Data type	Constraint	Default	New Info:	In a parallel branch construct the join code indicates how the concurrent activities are resynchronized.
	CV	W	
	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.18bis	Assign data type	Service_relationship.join_cd	USAMP-II Section:	2.4.1.8
	Data type	Constraint	Default	New Info:	CV
	W	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.19	Add attribute	Service_relationship.negation_ind	USAMP-II Section:	2.4.1.9
	Data type	Constraint	Default	New Info:	For conditions and criteria links indicates whether the meaning is negative (condition must not be true.) Normally all conditions are interpreted as 
	BL	false	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.19bis	Assign data type	Service_relationship.negation_ind	USAMP-II Section:	2.4.1.9
	Data type	Constraint	Default	New Info:	BL
	false	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 18 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.02.20	Add attribute	Service_relationship.conjunction_cd	USAMP-II Section:	2.4.1.10
	Data type	Constraint	Default	New Info:	In a bundle of precondition or outcome relationships, this code indicates the logical conjunctions of the criteria.
	BL	AND	
	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.)
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.02.20bis	Assign data type	Service_relationship.conjunction_cd	USAMP-II Section:	2.4.1.10
	Data type	Constraint	Default	New Info:	BL
	AND	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 19 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.03.00	Add class	Actor	USAMP-II Section:	2.3.1
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 20 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.03.02	Add association	Actor :: for(1..1) :: Service :: has(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	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"
	Issue:
	Remarks:	 
	C04-R091.03.03	Add association	Actor :: participation_of(1..1) :: Stakeholder :: participates_as(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	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"
	Issue:
	Remarks:	 
	C04-R091.03.11	Add attribute	Actor.type_cd	USAMP-II Section:	2.3.1.1
	Data type	Constraint	Default	New Info:	Identifies a particular function or a set of functions that a person performs in the Service. 
	SET<CV>	
	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 21 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.03.11bis	Assign data type	Actor.type_cd	USAMP-II Section:	2.3.1.1
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.03.12	Add attribute	Actor.tmr	USAMP-II Section:	2.3.1.2
	Data type	Constraint	Default	New Info:	This attribute can specify the time range during which the associated person was an actor of the specified Actor.type_cd in the associated 
	IVL<TS>	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.03.12bis	Assign data type	Actor.tmr	USAMP-II Section:	2.3.1.2
	Data type	Constraint	Default	New Info:	IVL<TS>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.03.13	Add attribute	Actor.note_txt	USAMP-II Section:	2.3.1.3
	Data type	Constraint	Default	New Info:	An actor can make a comment about this service item in the note attribute.
	ED	Rationale:
	Issue:
	Remarks:	 
	C04-R091.03.13bis	Assign data type	Actor.note_txt	USAMP-II Section:	2.3.1.3
	Data type	Constraint	Default	New Info:	ED
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 22 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.03.14	Add attribute	Actor.signature_cd	USAMP-II Section:	2.3.1.4
	Data type	Constraint	Default	New Info:	Some Actors must provide a signature on the service instance.  For example, a procedure report requires a signature of the performing and 
	CV	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.03.14bis	Assign data type	Actor.signature_cd	USAMP-II Section:	2.3.1.4
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.04.00	Add class	Target	USAMP-II Section:	2.3.2
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 23 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.04.02	Add association	Target :: in(1..1) :: Service :: has(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	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"
	Issue:
	Remarks:	 
	C04-R091.04.03	Add association	Target :: participation_of(0..1) :: Person :: participates_as(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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"
	Issue:
	Remarks:	 
	C04-R091.04.04	Add association	Target :: participation_of(0..1) :: Material :: participates_as(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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 Material" and "Material participates_as 0..* Target in 1..1 Service"
	Issue:
	Remarks:	 
	C04-R091.04.05	Add association	Target :: participation_of(0..1) :: Living_subject :: participates_as(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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 Material" and "Material participates_as 0..* Target in 1..1 Service"
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 24 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.04.11	Add attribute	Target.type_cd	USAMP-II Section:	2.3.2.1
	Data type	Constraint	Default	New Info:	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 
	SET<CV>	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.04.11bis	Assign data type	Target.type_cd	USAMP-II Section:	2.3.2.1
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.04.12	Add attribute	Target.tmr	USAMP-II Section:	2.3.2.2
	Data type	Constraint	Default	New Info:	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.
	SET<CV>	Rationale:
	Issue:
	Remarks:	 
	C04-R091.04.12bis	Assign data type	Target.tmr	USAMP-II Section:	2.3.2.2
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.04.13	Add attribute	Target.awareness_cd	USAMP-II Section:	2.3.2.3
	Data type	Constraint	Default	New Info:	For person targets indicates whether the associated patient or family member is aware of the service, and especially of the observation made.  For 
	CV	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 25 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.04.13bis	Assign data type	Target.awareness_cd	USAMP-II Section:	2.3.2.3
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.05.00	Add class	Observation	USAMP-II Section:	2.6.1
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.05.01	Add generalization link	Observation is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 26 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.05.11	Add attribute	Observation.value	USAMP-II Section:	2.6.1.1
	Data type	Constraint	Default	New Info:	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 
	ANY	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.05.11bis	Assign data type	Observation.value	USAMP-II Section:	2.6.1.1
	Data type	Constraint	Default	New Info:	ANY
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 27 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.05.12	Add attribute	Observation.derivation_expr	USAMP-II Section:	2.6.1.2
	Data type	Constraint	Default	New Info:	Derived observations can be defined through association with other observations using relationships of derivation type 
	ST	(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.
	Rationale:
	Issue:	The definition of this field's syntax needs to be completed.
	Remarks:	 
	C04-R091.05.12bis	Assign data type	Observation.derivation_expr	USAMP-II Section:	2.6.1.2
	Data type	Constraint	Default	New Info:	ST
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.05.13	Add attribute	Observation.property_cd	USAMP-II Section:	2.6.1.3
	Data type	Constraint	Default	New Info:	This attribute describes the scientific property of the observation value.  For quantitative observations, this is the kind of quantity.  The code table to 
	CV	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.
	Rationale:
	Issue:	Table needs to be defined (significantly revised from LOINC)
	Remarks:	 
	C04-R091.05.13bis	Assign data type	Observation.property_cd	USAMP-II Section:	2.6.1.3
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 28 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.06.00	Add class	Medication	USAMP-II Section:	2.6.3
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.01	Add generalization link	Medication is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.11	Add attribute	Medication.form_cd	USAMP-II Section:	2.6.3.1
	Data type	Constraint	Default	New Info:	The dose form of the therapeutic substance. Examples are tablet, capsule, suppository, etc.
	CD	Rationale:
	Issue:	This field must have a mandatory HL7 table for interoperability purpose.  Such a table could cover at least 90% of all cases.
	Remarks:	 
	C04-R091.06.11bis	Assign data type	Medication.form_cd	USAMP-II Section:	2.6.3.1
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 29 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.06.12	Add attribute	Medication.route_cd	USAMP-II Section:	2.6.3.2
	Data type	Constraint	Default	New Info:	The route of the medication.  Medication route is similar to an anatomic body site through which the therapeutic agent is incorporated or otherwise 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.12bis	Assign data type	Medication.route_cd	USAMP-II Section:	2.6.3.2
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.13	Add attribute	Medication.dose_qty	USAMP-II Section:	2.6.3.3
	Data type	Constraint	Default	New Info:	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 
	PQ	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.13bis	Assign data type	Medication.dose_qty	USAMP-II Section:	2.6.3.3
	Data type	Constraint	Default	New Info:	PQ
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 30 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.06.14	Add attribute	Medication.strength_qty	USAMP-II Section:	2.6.3.4
	Data type	Constraint	Default	New Info:	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 
	PQ	1	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.14bis	Assign data type	Medication.strength_qty	USAMP-II Section:	2.6.3.4
	Data type	Constraint	Default	New Info:	PQ
	1	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.15	Add attribute	Medication.rate_qty	USAMP-II Section:	2.6.3.5
	Data type	Constraint	Default	New Info:	With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified.  The Medication.rate_qty is specified as a physical 
	PQ	~ 1s	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 31 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.06.15bis	Assign data type	Medication.rate_qty	USAMP-II Section:	2.6.3.5
	Data type	Constraint	Default	New Info:	PQ
	~ 1 s	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.16	Add attribute	Medication.dose_check_qty	USAMP-II Section:	2.6.3.6
	Data type	Constraint	Default	New Info:	This attribute should not generally be used, it is only provided for a special purpose.  In some countries, especially Japan, there is a regulatory 
	PQ	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.06.16bis	Assign data type	Medication.dose_check_qty	USAMP-II Section:	2.6.3.6
	Data type	Constraint	Default	New Info:	PQ
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 32 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.07.00	Add class	Procedure	USAMP-II Section:	2.6.2
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.07.01	Add generalization link	Procedure is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.07.11	Add attribute	Procedure.entry_site_cd	USAMP-II Section:	2.6.2.1
	Data type	Constraint	Default	New Info:	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 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.07.11bis	Assign data type	Procedure.entry_site_cd	USAMP-II Section:	2.6.2.1
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 33 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.08.00	Add class	Supply	USAMP-II Section:	2.6.7
	Data type	Constraint	Default	New Info:	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 
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.08.01	Add generalization link	Supply is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.08.11	Add attribute	Supply.qty	USAMP-II Section:	2.6.7.1
	Data type	Constraint	Default	New Info:	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 
	PQ	extensive “amount” kind of quantities. Refer to Section 2.7.1.10 for a definition of such “amount” quantities.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.08.11bis	Assign data type	Supply.qty	USAMP-II Section:	2.6.7.1
	Data type	Constraint	Default	New Info:	PQ
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 34 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.09.00	Add class	Diet	USAMP-II Section:	2.6.8
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.09.01	Add generalization link	Diet is specialization of Supply	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.09.11	Add attribute	Diet.energy_qty	USAMP-II Section:	2.6.8.1
	Data type	Constraint	Default	New Info:	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
	PQ	~ 1 kcal/d	 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”.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.09.11bis	Assign data type	Diet.energy_qty	USAMP-II Section:	2.6.8.1
	Data type	Constraint	Default	New Info:	PQ
	~ 1 kcal/d	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 35 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.09.12	Add attribute	Diet.carbohydrate_qty	USAMP-II Section:	2.6.8.2
	Data type	Constraint	Default	New Info:	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 
	PQ	~ 1 g/d	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.)
	Remarks:	 
	C04-R091.09.12bis	Assign data type	Diet.carbohydrate_qty	USAMP-II Section:	2.6.8.2
	Data type	Constraint	Default	New Info:	PQ
	~ 1 g/d	Rationale:
	Issue:
	Remarks:	 
	C04-R091.10.00	Add class	Condition_node	USAMP-II Section:	2.6.4
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.10.01	Add generalization link	Condition_node is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 36 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.10.02	Add association	Condition_node :: defines(0..1) :: Episode_of_condition :: is_defined_by(1..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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".)
	Issue:
	Remarks:
	C04-R091.11.00	Add class	Transportation	USAMP-II Section:	2.6.6
	Data type	Constraint	Default	New Info:	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, 
	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.
	Issue:
	Remarks:	 
	C04-R091.11.01	Add generalization link	Transportation is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 37 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.12.00	Add class	Consent	USAMP-II Section:	2.6.5
	Data type	Constraint	Default	New Info:	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.
	Issue:
	Remarks:	 
	C04-R091.12.01	Add generalization link	Consent is specialization of Service	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.00	Add class	Material	USAMP-II Section:	2.7
	Data type	Constraint	Default	New Info:	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.)
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 38 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.20.11	Add attribute	Material.id	USAMP-II Section:	2.7.1.1
	Data type	Constraint	Default	New Info:	As a substantive class reflecting physical entities, material has instance identifiers.  Note that an instance identifier is a pure identifier and not a 
	SET<II>	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.11bis	Assign data type	Material.id	USAMP-II Section:	2.7.1.1
	Data type	Constraint	Default	New Info:	SET<II>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.12	Add attribute	Material.type_cd	USAMP-II Section:	2.7.1.2
	Data type	Constraint	Default	New Info:	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 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.12bis	Assign data type	Material.type_cd	USAMP-II Section:	2.7.1.2
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 39 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.20.13	Add attribute	Material.form_cd	USAMP-II Section:	2.7.1.3
	Data type	Constraint	Default	New Info:	This is a classifier describing the form of the material.  This includes the typical state of matter (solid, liquid, gas) and, for therapeutic substances, 
	CV	the dose form.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.13bis	Assign data type	Material.form_cd	USAMP-II Section:	2.7.1.3
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.14	Add attribute	Material.descr	USAMP-II Section:	2.7.1.4
	Data type	Constraint	Default	New Info:	A free text description of the material.  May contain multimedia, such as a drawing or image depicting the material.
	ED	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.14bis	Assign data type	Material.descr	USAMP-II Section:	2.7.1.4
	Data type	Constraint	Default	New Info:	ED
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.15	Add attribute	Material.status_cd	USAMP-II Section:	2.7.1.5
	Data type	Constraint	Default	New Info:	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 
	SET<CV>	concrete and detailed state-transition models may be assigned to the material role classes.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 40 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.20.15bis	Assign data type	Material.status_cd	USAMP-II Section:	2.7.1.5
	Data type	Constraint	Default	New Info:	SET<CV>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.16	Add attribute	Material.extent_tmr	USAMP-II Section:	2.7.1.6
	Data type	Constraint	Default	New Info:	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.
	IVL<TS>	
	Expiration dates does not always have a “day” component; therefore, such a date may be transmitted as YYYYMM.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.16bis	Assign data type	Material.extent_tmr	USAMP-II Section:	2.7.1.6
	Data type	Constraint	Default	New Info:	IVL<TS>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.17	Add attribute	Material.lot_nmb	USAMP-II Section:	2.7.1.7
	Data type	Constraint	Default	New Info:	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.
	ST	  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:
	Issue:
	Remarks:	 
	C04-R091.20.17bis	Assign data type	Material.lot_nmb	USAMP-II Section:	2.7.1.7
	Data type	Constraint	Default	New Info:	ST
	Rationale:	A lot number is not meant to be a unique identifier, but is meaningful only when the product kind is identified.
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 41 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.20.18	Add attribute	Material.handling_cd	USAMP-II Section:	2.7.1.8
	Data type	Constraint	Default	New Info:	A code to describe how the material needs to be handled to avoid damage.  
	CD	
	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 …
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.18bis	Assign data type	Material.handling_cd	USAMP-II Section:	2.7.1.8
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 42 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.20.19	Add attribute	Material.danger_cd	USAMP-II Section:	2.7.1.9
	Data type	Constraint	Default	New Info:	A code signaling whether there are certain dangers or hazards associated with this material.
	CD	
	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.20.19bis	Assign data type	Material.danger_cd	USAMP-II Section:	2.7.1.9
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 43 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.20.20	Add attribute	Material.qty	USAMP-II Section:	2.7.1.10
	Data type	Constraint	Default	New Info:	For many materials, the individual thing has no relevance.  Especially continuously divisible forms come only in “amounts” rather than as individuals.  
	SET<PQ>	{1}	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.
	Issue:
	Remarks:	 
	C04-R091.20.20bis	Assign data type	Material.qty	USAMP-II Section:	2.7.1.10
	Data type	Constraint	Default	New Info:	SET<PQ>
	{1}	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 44 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.21.00	Add class	Material_relationship	USAMP-II Section:	2.7.2
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.02	Add association	Material_relationship :: has_source(1..1) :: Material :: is_target_for(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.03	Add association	Material_relationship :: has_target(1..1) :: Material :: is_target_for(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 45 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.21.11	Add attribute	Material_relationship.type_cd	USAMP-II Section:	2.7.2.1
	Data type	Constraint	Default	New Info:	Material relationships can be of different types, i.e., may express different kinds of relationships.  The relationship concepts are exhaustively 
	CV	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.11bis	Assign data type	Material_relationship.type_cd	USAMP-II Section:	2.7.2.1
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.12	Add attribute	Material_relationship.inversion_ind	USAMP-II Section:	2.7.2.2
	Data type	Constraint	Default	New Info:	The role type may be used in the opposite direction.
	BL	false	
	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 46 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.21.12bis	Assign data type	Material_relationship.inversion_ind	USAMP-II Section:	2.7.2.2
	Data type	Constraint	Default	New Info:	BL
	false	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.13	Add attribute	Material_relationship.tmr	USAMP-II Section:	2.7.2.3
	Data type	Constraint	Default	New Info:	For some transient relationships between material one can specify a time in which the relationship is valid using the Material_relationship.tmr 
	IVL<TS>	attribute.  As with any interval of points in time, a start time, an end time, or a just a duration may be specified.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.13bis	Assign data type	Material_relationship.tmr	USAMP-II Section:	2.7.2.3
	Data type	Constraint	Default	New Info:	IVL<TS>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.14	Add attribute	Material_relationship.position_nmb	USAMP-II Section:	2.7.2.4
	Data type	Constraint	Default	New Info:	Some containers have discrete positions in which content may be located.  Depending on the geometry of the container, the position may be 
	LIST<NM>	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.)
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 47 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.21.14bis	Assign data type	Material_relationship.position_nmb	USAMP-II Section:	2.7.2.4
	Data type	Constraint	Default	New Info:	LIST<NM>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.21.15	Add attribute	Material_relationship.qty	USAMP-II Section:	2.7.2.5
	Data type	Constraint	Default	New Info:	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, 
	PQ	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 
	Issue:
	Remarks:	 
	C04-R091.21.15bis	Assign data type	Material_relationship.qty	USAMP-II Section:	2.7.2.5
	Data type	Constraint	Default	New Info:	PQ
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 48 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.22.00	Add class	Responsibility	USAMP-II Section:	2.7.3
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.22.02	Add association	Responsibility :: for(1..1) :: Material :: is_the(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	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".
	Issue:
	Remarks:	 
	C04-R091.22.03	Add association	Responsibility :: of(1..1) :: Stakeholder :: has(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	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".
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 49 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.22.11	Add attribute	Responsibility.type_cd	USAMP-II Section:	2.7.3.1
	Data type	Constraint	Default	New Info:	Specifies the kind of responsibility of the Stakeholder to the Material.
	CV	
	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.22.11bis	Assign data type	Responsibility.type_cd	USAMP-II Section:	2.7.3.1
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.22.12	Add attribute	Responsibility.tmr	USAMP-II Section:	2.7.3.2
	Data type	Constraint	Default	New Info:	Allows to specify a limitation in time during which the responsibility holds.
	IVL<TS>	Rationale:
	Issue:
	Remarks:	 
	C04-R091.22.12bis	Assign data type	Responsibility.tmr	USAMP-II Section:	2.7.3.2
	Data type	Constraint	Default	New Info:	IVL<TS>
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 50 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.22.13	Add attribute	Responsibility.material_id	USAMP-II Section:	2.7.3.3
	Data type	Constraint	Default	New Info:	The same piece of material may be given different identifiers by different responsible parties.  For example, a manufacturer may assign a 
	SET<II>	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.22.13bis	Assign data type	Responsibility.material_id	USAMP-II Section:	2.7.3.3
	Data type	Constraint	Default	New Info:	SET<II>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.23.00	Add class	Specimen	USAMP-II Section:	2.8.1
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.23.01	Add association	Specimen :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 51 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.23.02	Add association	Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.23.03	Add association	Specimen :: is_sourced_from(0..1) :: Person :: is_source_for(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.23.11	Add attribute	Specimen.body_site_cd	USAMP-II Section:	2.8.1.1
	Data type	Constraint	Default	New Info:	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 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.23.11bis	Assign data type	Specimen.body_site_cd	USAMP-II Section:	2.8.1.1
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 52 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.24.00	Add class	Container	USAMP-II Section:	2.8.2
	Data type	Constraint	Default	New Info:	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 
	The 	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.01	Add association	Container :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.11	Add attribute	Container.capacity_qty	USAMP-II Section:	2.8.2.1
	Data type	Constraint	Default	New Info:	From NCCLS, a geometric property of the container.
	PQ	~ 1 cm	Rationale:
	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?
	Remarks:	 
	C04-R091.24.11bis	Assign data type	Container.capacity_qty	USAMP-II Section:	2.8.2.1
	Data type	Constraint	Default	New Info:	PQ
	~ 1 cm	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.12	Add attribute	Container.height_qty	USAMP-II Section:	2.8.2.2
	Data type	Constraint	Default	New Info:	From NCCLS, a geometric property of the container.
	PQ	~ 1 cm	Rationale:
	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?
	Remarks:	 
	Wednesday, October 13, 1999	Page 53 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.24.12bis	Assign data type	Container.height_qty	USAMP-II Section:	2.8.2.2
	Data type	Constraint	Default	New Info:	PQ
	~ 1 cm	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.13	Add attribute	Container.diameter_qty	USAMP-II Section:	2.8.2.3
	Data type	Constraint	Default	New Info:	From NCCLS, a geometric property of the container.
	PQ	~ 1 cm	Rationale:
	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?
	Remarks:	 
	C04-R091.24.13bis	Assign data type	Container.diameter_qty	USAMP-II Section:	2.8.2.3
	Data type	Constraint	Default	New Info:	PQ
	~ 1 cm	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.14	Add attribute	Container.barrier_delta_qty	USAMP-II Section:	2.8.2.4
	Data type	Constraint	Default	New Info:	From NCCLS, a geometric property of the container.
	PQ	~ 1 cm	Rationale:
	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?
	Remarks:	 
	C04-R091.24.14bis	Assign data type	Container.barrier_delta_qty	USAMP-II Section:	2.8.2.4
	Data type	Constraint	Default	New Info:	PQ
	~ 1 cm	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 54 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.24.15	Add attribute	Container.bottom_delta_qty	USAMP-II Section:	2.8.2.5
	Data type	Constraint	Default	New Info:	From NCCLS, a geometric property of the container.
	PQ	~ 1 cm	Rationale:
	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?
	Remarks:	 
	C04-R091.24.15bis	Assign data type	Container.bottom_delta_qty	USAMP-II Section:	2.8.2.5
	Data type	Constraint	Default	New Info:	PQ
	~ 1 cm	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.16	Add attribute	Container.separator_type_cd	USAMP-II Section:	2.8.2.6
	Data type	Constraint	Default	New Info:	From NCCLS, the kind of separator material.
	CD	Rationale:
	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.
	Remarks:	 
	C04-R091.24.16bis	Assign data type	Container.separator_type_cd	USAMP-II Section:	2.8.2.6
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.24.17	Add attribute	Container.cap_type_cd	USAMP-II Section:	2.8.2.7
	Data type	Constraint	Default	New Info:	From NCCLS, the kind of cover cap (?)
	CD	Rationale:
	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.
	Remarks:	 
	Wednesday, October 13, 1999	Page 55 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.24.17bis	Assign data type	Container.cap_type_cd	USAMP-II Section:	2.8.2.7
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.25.00	Add class	Access	USAMP-II Section:	2.8.5
	Data type	Constraint	Default	New Info:	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.
	Issue:
	Remarks:	 
	C04-R091.25.01	Add association	Access :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.25.11	Add attribute	Access.gauge_qty	USAMP-II Section:	2.8.5.1
	Data type	Constraint	Default	New Info:	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 
	PQ	seen elsewhere.  Those units are defined in the Unified Code for Units of Measure.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 56 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.25.11bis	Assign data type	Access.gauge_qty	USAMP-II Section:	2.8.5.1
	Data type	Constraint	Default	New Info:	PQ
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.25.12	Add attribute	Access.entry_site_cd	USAMP-II Section:	2.8.5.2
	Data type	Constraint	Default	New Info:	The Access.entry_site_cd specifies the anatomic site where the access first enters the body.   For example in a arteria pulmonalis catheter targets 
	CD	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.25.12bis	Assign data type	Access.entry_site_cd	USAMP-II Section:	2.8.5.2
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 57 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.25.13	Add attribute	Access.body_site_cd	USAMP-II Section:	2.8.5.3
	Data type	Constraint	Default	New Info:	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 
	CD	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.)
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.25.13bis	Assign data type	Access.body_site_cd	USAMP-II Section:	2.8.5.3
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.26.00	Add class	Food	USAMP-II Section:	2.8.7
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.26.01	Add association	Food :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 58 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.26.11	Add attribute	Food.preference_cd	USAMP-II Section:	2.8.7.1
	Data type	Constraint	Default	New Info:	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 
	CD	NVEG	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
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.26.11bis	Assign data type	Food.preference_cd	USAMP-II Section:	2.8.7.1
	Data type	Constraint	Default	New Info:	CD
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 59 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.27.00	Add class	Device	USAMP-II Section:	2.8.4
	Data type	Constraint	Default	New Info:	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
	Rationale:
	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.
	Remarks:	 
	C04-R091.27.01	Add association	Device :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.27.11	Add attribute	Device.portable_ind	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	BL	Rationale:
	Issue:
	Remarks:	 
	C04-R091.27.11bis	Assign data type	Device.portable_ind	USAMP-II Section:
	Data type	Constraint	Default	New Info:	BL
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 60 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.27.12	Add attribute	Device.slot_size_increment_qty	USAMP-II Section:
	Data type	Constraint	Default	New Info:	Duration for a single schedulable unit in a schedule for a resource.
	~ 1 min	Rationale:	From RIM092 Durable_medical_equipment
	Issue:
	Remarks:	 
	C04-R091.27.12bis	Assign data type	Device.slot_size_increment_qty	USAMP-II Section:
	Data type	Constraint	Default	New Info:	PQ
	~ 1 min	Rationale:
	Issue:
	Remarks:	 
	C04-R091.28.00	Add class	Therapeutic_agent	USAMP-II Section:	2.8.3
	Data type	Constraint	Default	New Info:	A therapeutic agent is anything that is brought to interact with the human body in order to achieve therapeutic effects.
	Rationale:
	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.
	Remarks:	 
	C04-R091.28.01	Add association	Therapeutic_agent :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.29.01	Add association	Master_patient_service_location :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)	USAMP-II Section:	2.8.6
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 61 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.30.00	Add class	Service_list	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.02	Add association	Service_list :: owned_by(1..1) :: Stakeholder :: owns(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	Each service list is owned by one Stakeholder, which may be an individual practitioner (Person,) or a department or care team (Organization.)
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.03	Add association	Service_list :: is_about(0..1) :: Person :: is_subject_of(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Issue:
	Remarks:	 
	C04-R091.30.04	Add association	Service_list :: is_about(0..1) :: Material :: is_subject_of(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:	The "about" link establishes the subject of the service list even before a single service has been entered on the list.
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 62 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.30.05	Add association	Service_list :: has_parts(0..*) :: List_item :: is_part_of(1..1)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.11	Add attribute	Service_list.id	USAMP-II Section:	2.9.1.1
	Data type	Constraint	Default	New Info:	Identifiers for the service lists.
	SET<II>	Rationale:	As with all identifiers, this is needed to address the same service lists in multiple transactions.
	Issue:
	Remarks:	 
	C04-R091.30.11bis	Assign data type	Service_list.id	USAMP-II Section:	2.9.1.1
	Data type	Constraint	Default	New Info:	SET<II>
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.12	Add attribute	Service_list.type_cd	USAMP-II Section:	2.9.1.2
	Data type	Constraint	Default	New Info:	Code identifying the kind of service list.  Refer to the following Table for defined list types.
	CV	
	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.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.12bis	Assign data type	Service_list.type_cd	USAMP-II Section:	2.9.1.2
	Data type	Constraint	Default	New Info:	CV
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 63 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.30.13	Add attribute	Service_list.name	USAMP-II Section:	2.9.1.3
	Data type	Constraint	Default	New Info:	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 
	ST	owns.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.13bis	Assign data type	Service_list.name	USAMP-II Section:	2.9.1.3
	Data type	Constraint	Default	New Info:	ST
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.14	Add attribute	Service_list.descr	USAMP-II Section:	2.9.1.4
	Data type	Constraint	Default	New Info:	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 
	ED	the owner is an organization or work group.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.30.14bis	Assign data type	Service_list.descr	USAMP-II Section:	2.9.1.4
	Data type	Constraint	Default	New Info:	ED
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.31.00	Add class	List_item	USAMP-II Section:
	Data type	Constraint	Default	New Info:	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.
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 64 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.31.02	Add association	List_item :: represents(1..1) :: Service :: represented_as(0..*)	USAMP-II Section:
	Data type	Constraint	Default	New Info:
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.31.11	Add attribute	List_item.sequence_nmb	USAMP-II Section:	2.9.2.1
	Data type	Constraint	Default	New Info:	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 
	REAL	1	items every time an insertion or deletion is made.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.31.11bis	Assign data type	List_item.sequence_nmb	USAMP-II Section:	2.9.2.1
	Data type	Constraint	Default	New Info:	REAL
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.31.12	Add attribute	List_item.priority_nmb	USAMP-II Section:	2.9.2.2
	Data type	Constraint	Default	New Info:	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.
	REAL	Rationale:
	Issue:
	Remarks:	 
	C04-R091.31.12bis	Assign data type	List_item.priority_nmb	USAMP-II Section:	2.9.2.2
	Data type	Constraint	Default	New Info:	REAL
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 65 of 66

	ChngID	ChngType	Changed Model Element
	C04-R091.31.13	Add attribute	List_item.note_txt	USAMP-II Section:	2.9.2.3
	Data type	Constraint	Default	New Info:	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 
	ED	owner and are not subject to the rules of auditing and archiving that apply to medical record items.
	Rationale:
	Issue:
	Remarks:	 
	C04-R091.31.13bis	Assign data type	List_item.note_txt	USAMP-II Section:	2.9.2.3
	Data type	Constraint	Default	New Info:	ED
	Rationale:
	Issue:
	Remarks:	 
	Wednesday, October 13, 1999	Page 66 of 66