USAMP-II to RIM 092 mapping
	Actor	C04-R091.03.00
	2.3.1
	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.
	Active_participation	clearly mapped
	Goal.management_discipline_cd	mapped
	Healthcare_service_provider :: participates_as(0..n) :: Producer_of_master_service :: 	mapped
	Producer_of_master_service	clearly mapped
	Resource_request :: generalizes(1..1) :: Individual_healthcare_practitioner_request :: 	mapped
	Service_intent_or_order.clarification_phon	mapped
	Service_intent_or_order.escort_required_ind	mapped
	Service_intent_or_order.report_results_to_phon	mapped with issues
	Wednesday, October 13, 1999	Page 1 of 30

	Service_intent_or_order.transport_arrangement_responsibility_cd	mapped
	Treatment_intent_or_order_revision.needs_human_review_ind	mapped
	Treatment_service_dispense.needs_human_review_ind	mapped with issues
	Treatment_service_give.needs_human_review_ind	mapped with issues
	Actor :: for(1..1) :: Service :: has(0..*)	C04-R091.03.02
	Active_participation :: participates_in(0..1) :: Service_event :: has_as_active_participant(0..n)	clearly mapped
	Active_participation :: participates_in(0..1) :: Service_intent_or_order :: has_as_participant(0..n)	clearly mapped
	Producer_of_master_service :: produces(1..1) :: Master_service :: is_produced_by(0..n)	clearly mapped
	Actor :: participation_of(1..1) :: Stakeholder :: participates_as(0..*)	C04-R091.03.03
	Active_participation :: has_as_participant(1..1) :: Stakeholder :: participates_in(0..n)	clearly mapped
	Actor.note_txt	C04-R091.03.13
	2.3.1.3	ED
	An actor can make a comment about this service item in the note attribute.
	Treatment_service_administration.administrators_notes_cd	mapped
	Treatment_service_administration.substance_refusal_reason_cd	mapped
	Actor.tmr	C04-R091.03.12
	2.3.1.2	IVL<TS>
	This attribute can specify the time range during which the associated person was an actor of the specified Actor.type_cd in the associated 
	service.  This may be needed when the actor’s involvement spans only part of the service, and if this fact is worth mentioning.  The Actor.tmr
	 does not need to be used in cases where this detail is irrelevant.
	Active_participation.tmr	clearly mapped
	Service_event.attestation_dttm	mapped
	Wednesday, October 13, 1999	Page 2 of 30

	Actor.type_cd	C04-R091.03.11
	2.3.1.1	SET<CV>
	Identifies a particular function or a set of functions that a person performs in the Service. 
	
	Note that the Actor.type_cd designates the actual function performed in the service.  This is quite different from a role associated with a 
	person or a profession- or specialty-code, although, some of the Actor.type_cd values may suggest that they are the same.  While a 
	person’s role, a profession code, or a specialty code may signify a general capability and authority of that person, an Actor.type_cd rather 
	represents a part or sub-task of the associated Service activity. 
	
	Most notably the role “performing surgeon” is not necessarily played by a certified surgeon, but in many cases by a resident (in which case 
	an attending surgeon is designated as the “responsible” actor.)  The same is true for the “anesthesist” which doesn’t have to be an 
	“anesthesiologist” and will in most cases be a resident or sometimes even a nurse.
	
	An actor can do multiple of such functions identified by the Actor.type_cd at the same time.  This can be represented in two ways: either the 
	same Actor instance can be used with multiple Actor.type_cd values (hence, it’s a set of code values).  Alternatively, one can use multiple 
	Actor-instances with just one Actor.type_cd value relating to the same Stakeholder.  A mixture of both approaches is also possible.  The 
	rationale when to use just one or the other approach can be, e.g., an actor playing three roles two of which are closely related whereas the 
	third role may have a different time range.  A more concrete ruling on a standardized use may follow in the future.
	Active_participation.participation_type_cd	clearly mapped
	Condition_node	C04-R091.10.00
	2.6.4
	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.
	Condition_node	clearly mapped
	Condition_node :: defines(0..1) :: Episode_of_condition :: 	C04-R091.10.02
	This association binds an episode of condition to a condition thread that defines that episode.
	Condition_node :: defines_episode(0..1) :: Episode_of_condition :: links_condition(1..1)	clearly mapped
	Wednesday, October 13, 1999	Page 3 of 30

	Consent	C04-R091.12.00
	2.6.5
	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.
	Advance_directive	mapped
	Consent	clearly mapped
	Consent is specialization of Service	C04-R091.12.01
	Service_event :: generalizes(1..1) :: Consent :: specializes(1..1)	clearly mapped
	Container.capacity_qty	C04-R091.24.11
	2.8.2.1	PQ	~ 1 cm
	From NCCLS, a geometric property of the container.
	Master_specimen_requirement.container_volume_qty	clearly mapped
	Device	C04-R091.27.00
	2.8.4
	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
	Durable_medical_equipment	mapped
	Wednesday, October 13, 1999	Page 4 of 30

	Device.portable_ind	C04-R091.27.11
	BL
	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.
	Master_service.portable_device_ind	mapped with issues
	Device.slot_size_increment_qty	C04-R091.27.12
	~ 1 min
	Duration for a single schedulable unit in a schedule for a resource.
	Durable_medical_equipment.slot_size_increment_qty	clearly mapped
	Diet	C04-R091.09.00
	2.6.8
	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.
	Dietary_intent_or_order	clearly mapped
	Diet is specialization of Supply	C04-R091.09.01
	Service_intent_or_order :: generalizes(1..1) :: Dietary_intent_or_order :: specializes(1..1)	mapped
	List_item	C04-R091.31.00
	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.
	Condition_node.management_discipline_cd	mapped
	Durable_medical_equipment_slot	mapped with issues
	Resource_slot :: generalizes(1..1) :: Durable_medical_equipment_slot :: specializes(1..1)	mapped
	Patient_service_location_slot :: is_scheduleable_unit_for(1..1) :: Master_patient_service_location :: 	mapped
	Patient :: is_scheduled_by(0..n) :: Patient_slot :: is_a_scheduleable_unit_for(1..1)	mapped
	List_item.priority_nmb	C04-R091.31.12
	2.9.2.2	REAL
	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.
	Goal.goal_list_priority_nbr	mapped
	Procedure.priority_nbr	mapped
	Service_event.billing_priority_nbr	mapped
	Wednesday, October 13, 1999	Page 5 of 30

	List_item.sequence_nmb	C04-R091.31.11
	2.9.2.1	REAL	1
	The items of the list can be sequenced using this attribute.  It is a real number in order to allow dynamic insertion without having to renumber 
	all the items every time an insertion or deletion is made.
	Condition_node.ranking_nbr	mapped
	Master_patient_service_location :: is_a_role_of(1..1) :: Material :: 	C04-R091.29.01
	2.8.6
	Master_patient_service_location	untouched
	Material	C04-R091.20.00
	2.7
	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.
	Durable_medical_equipment_group	mapped
	Master_specimen_requirement	mapped
	Patient_service_location_group	mapped
	Treatment_intent_or_order_revision.PTcomp	mapped
	Treatment_service_event.PTcomp	mapped
	Material.danger_cd	C04-R091.20.19
	2.7.1.9	CD
	A code signaling whether there are certain dangers or hazards associated with this material.
	
	Concept	Implies	Code	Definition
	tissue		TIS	The normal dangers associated with normal human or animal tissue. I.e. potential risk of unknown infections.  Routine blood or 
	excretions of humans and animals.
	infectious		INF	Material known to be infectious with human pathogenic microorganisms.  Those who handle this material must take 
	precautions for their protection.
	biohazard	infectious	BHZ	Material contains microorganisms that is an environmental hazard.  Must be handled with special care.
	radioactive		RAD	Material is a source for ionizing radiation and must be handled with special care to avoid injury of those who handle it 
	and to avoid environmental hazards.
	poison		POI	Material is poisonous to humans.  Special care must be taken to avoid incorporation, even of small amounts.
	acid		ACI	Material is acid and may cause severe injury to human skin and eyes. Avoid any unprotected contact.
	inflammable		IFL	Material is highly inflammable and in certain mixtures (with air) may lead to explosions.  Keep away from fire, sparks and 
	excessive heat.
	explosive	inflammable	EXP	Material is an explosive mixture. Keep away from fire, sparks, and heat.
	Collected_specimen_sample.danger_cd	clearly mapped
	Observation_intent_or_order.patient_hazard_cd	mapped with issues
	Material.descr	C04-R091.20.14
	2.7.1.4	ED
	A free text description of the material.  May contain multimedia, such as a drawing or image depicting the material.
	Wednesday, October 13, 1999	Page 6 of 30

	Master_patient_service_location.desc	mapped
	Master_specimen_requirement.container_desc	clearly mapped
	Material.extent_tmr	C04-R091.20.16
	2.7.1.6	IVL<TS>
	The time interval a certain material is in existence.  The high boundary of this interval is the expiration date if it is defined for the material.
	
	Expiration dates does not always have a “day” component; therefore, such a date may be transmitted as YYYYMM.
	Master_specimen_requirement.retention_time_qty	mapped
	Treatment_service_event.substance_expiration_dttm	mapped
	Material.form_cd	C04-R091.20.13
	2.7.1.3	CV
	This is a classifier describing the form of the material.  This includes the typical state of matter (solid, liquid, gas) and, for therapeutic 
	substances, the dose form.
	Master_treatment_service.medication_form_cd	clearly mapped
	Material.handling_cd	C04-R091.20.18
	2.7.1.8	CD
	A code to describe how the material needs to be handled to avoid damage.  
	
	Concept	Implies	Code	Definition
	room temperature		RMT	Keep at room temperature, about 20 ?C
	body temperature		BDT	Keep at body temperature, about 36 to 37 ?C
	cool		COO	Keep cool at about 5 to 8 ?C
	frozen		FRZ	Keep frozen below 0 ?C
	deep frozen		DFR	Keep deep frozen, below  – 16 ?C
	nitrogen		NTR	Keep in liquid nitrogen
	dry		DRY	Keep in a dry environment
	dark		DRK	Protect against light
	no shock		PSO	Protect against shock
	upright		UPR	Keep upright, do not turn upside down
	no shake		PSA	Do not shake
	… more …
	Collected_specimen_sample.handling_cd	clearly mapped
	Master_specimen_requirement.special_handling_desc	clearly mapped
	Material.id	C04-R091.20.11
	2.7.1.1	SET<II>
	As a substantive class reflecting physical entities, material has instance identifiers.  Note that an instance identifier is a pure identifier and not
	 a classifier.  That means, this identifier is not used to store information about what kind or type of material this is.  Ideally each entity will have
	 only one identifier assigned to it, however, since different systems will maintain different material data bases, there may be different 
	instance identifiers assigned by different systems.
	
	Note that for serial numbers assigned by specific manufacturers, catalog numbers of specific distributors,  or for inventory numbers issued 
	by owners, the attribute Responsibility.material_id : SET<II> can also be used.  This allows to more clearly express the fact that such a code 
	is assigned by a specific party associated with that material.  In any case, all values of Responsibility.material_id may occur in Material.id just 
	as well.
	Collected_specimen_sample.id	clearly mapped
	Durable_medical_equipment.id	mapped
	Wednesday, October 13, 1999	Page 7 of 30

	Durable_medical_equipment.type_cd	clearly mapped
	Durable_medical_equipment_group.id	clearly mapped
	Master_patient_service_location.id	clearly mapped
	Master_patient_service_location.nm	mapped with issues
	Patient_service_location_group.id	clearly mapped
	Material.lot_nmb	C04-R091.20.17
	2.7.1.7	ST
	The lot number is the number printed on the label attached to the container holding the substance and on the packaging which houses the 
	container.  A “lot” is a collection of products produced in one cycle.  This means, for instance, if one bottle of a lot is spoiled, chances are 
	high that the entire lot is spoiled.  Conversely, product defects that occur in routine production are likely to be contained in one lot. 
	
	Note that a lot number is not meant to be a unique identifier, but is meaningful only when the product kind is identified.
	Treatment_service_event.substance_lot_number_txt	mapped
	Material.qty	C04-R091.20.20
	2.7.1.10	SET<PQ>	{1}
	For many materials, the individual thing has no relevance.  Especially continuously divisible forms come only in “amounts” rather than as 
	individuals.  There is a specific class of physical quantities that can be used for amounts, count (number), amount of substance, mass, and 
	volume.  This class of physical quantities is called “extensive” quantities.  A quantity is called extensive if it can be added up (if it is additive.)  
	For example, if you have 1 gallon of water and you add another gallon of water, you wave two gallons of water, since volume is an additive 
	quantity.  By contrast, if you have one gallon of Glucose 5% and add to it another gallon of Glucose 5% you still have Glucose 5%, thus, 
	mass fraction is not an additive (extensive) kind of quantity.  
	
	Only extensive quantities are permitted as elements of the Material.qty set.  Typically the kinds of quantities shown in Table 34 will occur.  
	Extensive quantities are simpler to deal with than intensive quantities.  Extensive quantities are never fractions or ratios, no denominator can 
	cancel out the units of a numerator, and therefore, with extensive quantities we can conclude the kind of quantity from the unit of measure.
	
	Table 34: Kinds of quantities for amounts of material
	Kind of quantity	Typical Unit	Forms	Examples
	Number	1	solid	Material that is large enough that is can be counted (“eaches”)
	Mass	1 g	liquid, solid	Tissue, chemical substances, food.
	Amount of substance	1 mol	all	Chemical substances, small particles.
	Volume	1 L	liquid, gas	Chemical substances in liquid and gas state. Amorphic tissue.
	Length	1 m	solid	Long material measured in length, e.g., tape, pipes, hose, etc.
	Area	1 m2	solid	Flat material measured in area, e.g., covers, foils, etc.
	Energy	1 J, 1 kcal	solid, liquid	Chemical substances, especially food.
	Catalytic amount	1 kat, 1 U, 1 i.U.	all	Enzymes and other chemical substances having catalytic activity.
	Radioactivity	1 Bq, 1 Cu	all	Radioactive substances.
	Reaction equivalent	1 Eq	all	Ionized chemical substances measured through titration. Deprecated, use proper amount of substance 
	instead.
	
	The Material.qty attribute permits to convey a collection of physical quantities.  This collection feature must be used in the following way.  
	When the set contains more than one quantity, the quantities must have different units.  Furthermore, all quantities in the set must denote an 
	equivalent amount.  For example, for the material Glucose, we may specify an amount as the mass of 1 g.  If we also want to specify the 
	amount in amount of substance (moles) we must specify the equivalent of 1 g Glucose in mole, which is 5.556 mmol.  For another example, if 
	we specify the amount of a material Water as 1 L, and we want to provide a mass, the mass must be the mass of 1 L water, which is 1 kg.
	Collected_specimen_sample.collection_volume_qty	clearly mapped
	Collected_specimen_sample.number_of_sample_containers_qty	mapped
	Durable_medical_equipment_request.quantity_amt	clearly mapped
	Master_specimen_requirement.minimum_collection_volume_qty	mapped
	Master_specimen_requirement.normal_collection_volume_qty	mapped
	Wednesday, October 13, 1999	Page 8 of 30

	Material.type_cd	C04-R091.20.12
	2.7.1.2	CD
	This code describes what kind of material this is.  It is an arbitrarily precise classification.  We do not expect any single terminology to provide
	 all concepts that are types of material, since it is simply too broad a domain. Instead of limiting the Material.type_cd to a single domain, we 
	allow various code systems to be used, and thus, the actual domain of Material.type_cd becomes the union of all the possible code systems 
	for material.
	
	For example, specimen types (e.g., whole blood, serum, urine) can be used in this attribute.  For chemicals, IUPAC codes might be used here.
	  For arbitrary products one can use the Universal Product Code (UPC) code or a particular manufacturer’s serial number.  For 
	pharmacological substances yet another coding system may be applicable such as the U.S. National Drug Code (NDC.)  The concept 
	descriptor data type allows for multiple codes used as synonyms for each other, thus, one can specify an UPC code next to an NDC code 
	and an IUPAC code.
	Collected_specimen_sample.source_cd	clearly mapped
	Collected_specimen_sample.type_cd	clearly mapped
	Master_patient_service_location.type_cd	mapped
	Master_specimen_requirement.type_cd	clearly mapped
	Material_relationship	C04-R091.21.00
	2.7.2
	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.
	Collected_specimen_sample.additive_desc	mapped
	Dietary_intent_or_order.tray_type_cd	mapped with issues
	Durable_medical_equipment :: belongs_to(0..n) :: Durable_medical_equipment_group :: 	mapped
	Master_patient_service_location :: belongs_to(0..n) :: Patient_service_location_group :: 	mapped
	Master_patient_service_location :: includes(0..n) :: Master_patient_service_location :: 	mapped
	Master_patient_service_location.equipment_type_cd	mapped
	Master_specimen_requirement.additive_cd	mapped
	Master_specimen_requirement.derived_specimen_cd	mapped
	Material_relationship.qty	C04-R091.21.15
	2.7.2.5	PQ
	This attribute specifies how much of the target material is contained in the source material of a relationship.  For example, if a box contains 10
	 eggs, the box is the relationship source is the box and the relationship target is the egg, where the relationship quantity is 10.   For mixtures 
	with multiple ingredients, the relationship quantities specify the relative amounts of the ingredients in the mixture (proportion.)  
	
	The quantity must be a quantity that specifies an “amount” (refer to Table 34 in Section 2.7.1.10).  The amounts specified as the proportion 
	quantity for each ingredient are taken to be numerators over the same denominator.  For example, D5W is a mixture consisting Water (H2O) 
	and 5% (= 50 g/L) Glucose (Glc.) The proportions can be either of the following pairs: H2O:1 g + Glc:50 mg; H2O:1 L + Glc:50 g; H2O:500 mL 
	+ Glc:25 g; or any combination that amounts to the same concentration of Glucose in Water.
	
	Note that the value of the proportion quantity does not matter as long as the proportion between the ingredients of a substance is kept 
	invariant.  If, for example, we specify D5W as having ingredients 500 mL of H2O and 25 g of Glucose this does not mean that D5W could only
	 be dispensed in multiples of 500 mL.
	Wednesday, October 13, 1999	Page 9 of 30

	Treatment_intent_or_order_revision.dispense_package_size_qty	mapped
	Treatment_service_dispense.dispense_package_size_qty	mapped
	Medication	C04-R091.06.00
	2.6.3
	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.
	Master_treatment_service	mapped
	Treatment_intent_or_order	mapped
	Treatment_intent_or_order_revision	mapped
	Treatment_service_administration	mapped
	Treatment_service_event	mapped
	Treatment_service_give	mapped
	Medication is specialization of Service	C04-R091.06.01
	Master_service :: generalizes(1..1) :: Master_treatment_service :: specializes(1..1)	mapped
	Service_intent_or_order :: generalizes(1..1) :: Treatment_intent_or_order :: specializes(1..1)	mapped
	Care_event :: generalizes(1..1) :: Treatment_service_event :: specializes(1..1)	mapped
	Wednesday, October 13, 1999	Page 10 of 30

	Medication.dose_check_qty	C04-R091.06.16
	2.6.3.6	PQ
	This attribute should not generally be used, it is only provided for a special purpose.  In some countries, especially Japan, there is a 
	regulatory requirement to note the total daily dose on the prescription and associated documentation.   The purpose of this requirement 
	obviously is to encourage and facilitate reviewing the total dose prescribed to avoid over- (or under-) dosage.  Rather than to define a “total 
	daily dose” attribute as HL7 v2.3 did, we define this general purpose dose_check_qty attribute that can be used in various ways as required 
	by local business rules or regulations.  For example, in Japan one would use this field as a total daily dose by calculating the “real” dose as 
	noted above and then adjusting the denominator to 1 d.   For example, with Erythromycin 250 mg 1 tablet 3 times a day one can calculate the 
	total daily dose as
	
	dosis_check_qty = dosis_qty (1) * strength_qty (250 mg) * frequency (3 /d) = 750 mg/d.
	
	For the i.v. example above this term would be
	
	dosis_check_qty = dosis_qty (100 ml) * strength_qty (1) / rate_qty (1 h) = 100 mL/h
	
	which can be calculated on a daily basis as
	
	dosis_check_qty = 100 mL/h * 24 h/d = 2400 mL/d = 2.4 L/d.
	
	So, in Japan, the denominator of the dosis_check_qty unit must always be 1 /d.  In other countries the constraints on the dosis_check_qty 
	may be different or, most likely, the attribute would not be used at all.  In any case this dosis_check_qty attribute must not be used to carry 
	any functional information.
	Treatment_intent_or_order_revision.total_daily_dose_qty	mapped with issues
	Treatment_service_dispense.total_daily_dose_qty	mapped
	Medication.dose_qty	C04-R091.06.13
	2.6.3.3	PQ
	The dose is the amount of the therapeutic agent given at one administration event. This attribute can be used all by itself, or in combination 
	with a strength.  In theory, a physician’s prescription could suffice with just the dose specification.  For example, if Azythromycin is to be 
	given at 80 mg once a day for three days, there is no need to specify a strength.  The pharmacist can figure out the right preparation given 
	what is available in stock or on the marketplace.  When the pharmacist dispenses a particular preparation with a particular strength and 
	packet size from a particular manufacturer, etc., this detail should be communicated using the Material class.
	Treatment_intent_or_order_revision.max_give_qty	mapped
	Treatment_intent_or_order_revision.min_give_qty	mapped
	Treatment_service_event.amount_qty	mapped
	Medication.form_cd	C04-R091.06.11
	2.6.3.1	CD
	The dose form of the therapeutic substance. Examples are tablet, capsule, suppository, etc.
	Treatment_service_event.dosage_form_cd	mapped
	Wednesday, October 13, 1999	Page 11 of 30

	Medication.rate_qty	C04-R091.06.15
	2.6.3.5	PQ	~ 1s
	With continuously divisible dose forms (e.g., liquids, gases) a dose rate can be specified.  The Medication.rate_qty is specified as a physical 
	quantity in time (a duration.) Hence, the rate_qty is really the denominator of the dose rate.  For example, if an Ringer solution is to be given at 
	100 mL/h i.v., the dosis_qty would be 100 mL and the rate_qty would be 1 h.  Note that there is no difference in the actual values of 
	dosis_qty and rate_qty as long as the quotient of both has the same value.  In this example, we could just as well specify dosis_qty as 50 mL
	 and rate_qty as 30 min, or 200 mL and 2 h or any other combination where the quotient equals 100 mL/h.
	
	Note that in principle one could again suffice with just the dosis_qty attribute specifying the rate right in that one attribute (e.g., dosis_qty = 
	100 mL/h.)  However this practice is not allowed.  Systems that implement the semantics of units according to the Unified Code for Units of 
	Measure would have no problem noting the fact that a dose_qty is really a rate.  Other system however will have difficulties to tell an at-once
	 dose from a dose rate from just looking at the units.  If a system wishes to deal only with a single quantity describing the dosage, it can 
	always calculate such a quantity as
	
	real_dosis_qty = dosis_qty x strength_qty / rate_qty.
	Treatment_intent_or_order_revision.give_per_timeunit_cd	clearly mapped
	Treatment_intent_or_order_revision.give_rate_qty	mapped with issues
	Treatment_service_administration.administered_per_timeunit_cd	mapped
	Treatment_service_administration.administered_rate_qty	mapped
	Treatment_service_give.give_per_timeunit_cd	mapped
	Treatment_service_give.give_rate_qty	mapped
	Medication.route_cd	C04-R091.06.12
	2.6.3.2	CD
	The route of the medication.  Medication route is similar to an anatomic body site through which the therapeutic agent is incorporated or 
	otherwise applied to the body.  It is an open issue whether a specialized route_cd could be replaced by a general anatomic site code.  The 
	typical routes are per os (PO), sublingual (SL), rectal (PR), per inhalationem (IH), ophtalmic (OP), nasal (NS), otic (OT), vaginal (VG) , 
	intra-dermal (ID), subcutaneous (SC), intra-venous (IV), and intra-cardial (IC).  
	
	However, as the table below suggests there are other routes and there are many variations as to how to access a specific route.  For 
	instance, an oral administration with the patient swallowing will usually have the same effect as if the same substance is given through a 
	gastric tube.  A more systematic approach to analyze the route into components such as site of primary entry (e.g. oral, nasal), site/system 
	of  substance uptake (e.g. gastrointestinal, bronchial, nasal mucosa), method (e.g., swallow, inhale), and device (e.g., gastric tube, tracheal 
	tube) should be considered.  At this point the version 2.x code table is used.
	Master_treatment_service.route_cd	clearly mapped
	Treatment_intent_or_order_revision.PTrout	mapped
	Treatment_service_event.PTrout	mapped
	Treatment_service_event.route_cd	mapped
	Medication.strength_qty	C04-R091.06.14
	2.6.3.4	PQ	1
	The strength of a medication is the amount of therapeutic agent per each unit of administration (entitic mass, amount of substance, etc.)  If the
	 dose form is continuously divisible (e.g., liquid, gas), the strength is a concentration (volumic mass, amount of substance, etc.)
	
	We generally discourage using this attribute, because in theory, a physician’s prescription could suffice with just the dose specification.  For 
	example, if Azythromycin is to be given at 80 mg once a day for three days, there is no need to specify a strength.  The pharmacist can 
	figure out the right preparation given what is available in stock or on the marketplace.  When the pharmacist dispenses a particular 
	preparation with a particular strength and packet size from a particular manufacturer, etc., this detail should be communicated using the 
	Material class.
	
	Treatment_intent_or_order.requested_give_strength_qty	clearly mapped
	Wednesday, October 13, 1999	Page 12 of 30

	Treatment_service_event.strength_qty	mapped
	Observation	C04-R091.05.00
	2.6.1
	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.
	Clinical_observation	clearly mapped
	Goal	mapped
	Master_numeric_range	mapped
	Observation_intent_or_order	mapped
	Observation is specialization of Service	C04-R091.05.01
	Assessment :: generalizes(1..1) :: Clinical_observation :: specializes(1..1)	mapped
	Assessment :: generalizes(1..1) :: Goal :: specializes(1..1)	mapped
	Master_service :: generalizes(1..1) :: Master_observation_service :: specializes(1..1)	clearly mapped
	Service_intent_or_order :: generalizes(1..1) :: Observation_intent_or_order :: specializes(1..1)	mapped
	Observation.derivation_expr	C04-R091.05.12
	2.6.1.2	ST
	Derived observations can be defined through association with other observations using relationships of derivation type 
	(Service_relationship.type_cd = derivation.)  For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will 
	associate the MCH observation with an Hemoglobin (HGB) observation (Service_relationship.sequence_nmb = 1) and a Red Blood cell Count 
	(RBC) observation (Service_relationship.sequence_nmb = 2)  Since  MCH = HGB / RBC, the value of the derivation expression would be “$1 / 
	$2”.
	
	The derivation expression is a character string with a simple syntax similar to that of the UNIX “expr” utility, or the expression subset of the 
	PERL or TCL language.   All observations that are cited in the formula must be associated with the derived observation through links of type 
	derivation with a  unique Service_relationship.sequence_nmb.  Such observation values are referred to by that sequence number preceded 
	by a dollar sign ($).
	
	Defined operators are addition (+), subtraction (?), multiplication (*) and division (/).  Parentheses can be used to overcome the usual 
	precedence (left to right, multiplication before addition.)  In addition to the basic arithmetic operations the usual mathematical functions are 
	defined.
	Master_observation_service.derivation_rule_desc	mapped
	Observation.property_cd	C04-R091.05.13
	2.6.1.3	CV
	This attribute describes the scientific property of the observation value.  For quantitative observations, this is the kind of quantity.  The code 
	table to be used will represent all the concepts defined in the IUPAC Compendium of Terminology and Nomenclature of Properties in Clinical 
	Laboratory Sciences (“Silver Book”.)  This concept has a large intersection with the LOINC “Kind of Property” table, which is also featured by
	 HL7 v2.3.1 as Table 0254.
	Wednesday, October 13, 1999	Page 13 of 30

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

	Master_qualitative_observation.preferred_coding_system_cd	mapped
	Master_qualitative_observation.valid_answer_cd	mapped
	Master_quantitative_observation.display_length_and_decimal_precision_cd	mapped
	Master_quantitative_observation.unit_of_measure_cd	mapped
	Procedure	C04-R091.07.00
	2.6.2
	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.
	Procedure	clearly mapped
	Procedure is specialization of Service	C04-R091.07.01
	Care_event :: generalizes(1..1) :: Procedure :: specializes(1..1)	mapped
	Responsibility	C04-R091.22.00
	2.7.3
	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.
	Treatment_service_event.substance_manufacturer_cd	mapped
	Wednesday, October 13, 1999	Page 15 of 30

	Service	C04-R091.01.00
	2.2
	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.
	Durable_medical_equipment_request	mapped
	Master_observation_service	mapped
	Master_patient_service_location :: is_requested_by(0..n) :: Patient_service_location_request :: 	mapped
	Master_service	mapped
	Master_service_relationship.reflex_testing_trigger_rules_desc	mapped
	Service_event	mapped
	Service_intent_or_order	mapped
	Service_intent_or_order_relationship.reflex_testing_trigger_rules_desc	mapped
	Service_scheduling_request	mapped
	Service :: is_assigned_to(0..1) :: Patient_encounter :: 	C04-R091.01.02
	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.
	Service_event :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..n)	mapped
	Wednesday, October 13, 1999	Page 16 of 30

	Service :: is_associated_with(0..*) :: Financial_transaction :: pertains_to 	C04-R091.01.03
	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.
	Service_event :: is_associated_with(0..n) :: Financial_transaction :: pertains_to(1..1)	clearly mapped
	Service :: is_charged_to(0..1) :: Patient_billing_account :: 	C04-R091.01.04
	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.
	Patient_billing_account :: has_charges_for(0..n) :: Service_event :: is_charged_to(0..1)	clearly mapped
	Patient_billing_account :: is_billed_from(0..n) :: Service_intent_or_order :: is_billed_to(0..1)	mapped
	Service :: is_covered_by(0..*) :: Coverage_item :: 	C04-R091.01.06
	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.
	Master_service :: is_covered_by(0..n) :: Coverage_item :: provides_coverage_for(1..n)	mapped
	Service :: is_documented_by(0..*) :: Clinical_document_header :: 	C04-R091.01.05
	This association stands for any documentation of Services in clinical documents.
	Service_event :: is_documented_by(0..n) :: Clinical_document_header :: documents(0..n)	clearly mapped
	Service_intent_or_order :: is_referred_to_in(0..n) :: Clinical_document_header :: is_related_to(0..1)	mapped with issues
	Service.body_site_cd	C04-R091.01.19
	2.2.1.9	CD
	Most health care services have a focus on a particular anatomic structure of the patient (the “target” of service.)  This information is found in 
	body_site_cd.  The coding system to be used for anatomic site is not specified in detail.  Anatomic sites, body parts, and functional body 
	systems are huge and highly complex domains that require a very sophisticated terminology system.  Candidates are Galen, SNOMED, or 
	Read codes.  Alternatively, a simple local coding system can be used to identify exactly the common body sites used. 
	
	Some body sites can also be “pre-coordinated” in the Service definition, so that there is never an option to select different body sites.  The 
	same information structure can handle both the pre-coordinated and the post-coordinated approach.
	
	For administrative body sites (i.e. where medications are administered) HL7 used to define a table (0163) that must be used as defined in 
	Table 4 below.
	Master_service.target_anatomic_site_cd	clearly mapped
	Service_intent_or_order.service_body_site_cd	clearly mapped
	Service_intent_or_order.service_body_site_modifier_cd	mapped
	Treatment_service_event.body_site_cd	mapped
	Wednesday, October 13, 1999	Page 17 of 30

	Service.confidentiality_cd	C04-R091.01.21
	2.2.1.11	SET<CV>
	This is a code that limits the disclosure of information about this service.  The codes refer to confidentiality policies as listed in the normative 
	table [see USAMP-II document]
	
	Confidentiality policies may vary from institution to institution and not all systems are capable of abiding by all details of the confidentiality 
	policies suggested in the above table.  However, these are the items that are being used in some institutions and which implementers may 
	want to consider supporting.
	
	It is important to note that good confidentiality of the medical record can not be achieved through confidentiality codes only to filter out 
	individual record items to certain types of users.  There are two important problems with per-item confidentiality: one is inference and the 
	other is the danger of holding back information that may be critical in a certain care situation.  Inference means that filtered sensitive 
	information can still be assumed given the other information not filtered. The simplest form of inference is that even the existence of a test 
	order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not 
	known.  Very often, diagnoses can be inferred from medication, such as Zidovudin for treatment of HIV infections.  The problem of hiding 
	individual items becomes especially difficult with current medications, since the continuing administration of the medication must be assured.
	
	A similar confidentiality code attribute is therefore required in the Patient class to cover the entire patient record.  But this is outside the scope
	 of the present proposal.
	
	The flags HIV, PSY, ETH, and SDV may only be used on service items that are not patient related.  Typically, they are used in the service 
	definition object (“master” service) to indicate a generic disclosure policy of any actual service item of that type.
	
	Aggregations of data should assume the privacy level of the most private action in the aggregation.
	Advance_directive.disclosure_level_cd	clearly mapped
	Clinical_observation.user_defined_access_check_cd	mapped with issues
	Master_service.confidentiality_cd	clearly mapped
	Service_event.confidential_ind	clearly mapped
	Service_event.patient_sensitivity_cd	mapped
	Service.critical_time	C04-R091.01.17
	2.2.1.7	GTS
	This is the “biologically relevant” time of an action.  The concept is best understood with observations, where the time of the observation 
	action may be much later than the time of the observed feature.  For instance, in a Blood Gas Analysis (BGA), a result will always come up 
	several minutes after the specimen was taken, meanwhile the patient’s physiological state may have changed significantly.  Even more so in 
	history taking, when the doctor records an episode of Hepatitis A under which the patient suffered last year for several weeks.  For surgical
	 procedures the time between first cut and last suture is taken as the critical time of the procedure.  For transport and supply services the 
	critical time is the time en route or time of delivery respectively.  Critical time and total time of a service may often be related in a certain way, 
	which will be discussed in USAMP-II Part A, Figure 10.
	Advance_directive.notarization_dttm	mapped with issues
	Clinical_observation.clinically_relevant_tmr	mapped
	Goal.expected_achievement_dttm	clearly mapped
	Goal.review_interval_cd	mapped
	Procedure.incision_open_tmr	clearly mapped
	Service_event.specimen_received_dttm	mapped with issues
	Treatment_intent_or_order_revision.qt	mapped
	Wednesday, October 13, 1999	Page 18 of 30

	Service.descr	C04-R091.01.14
	2.2.1.4	ED
	The description of a service is a piece of free text or multimedia data that describes the service in all necessary detail.  There is no restriction
	 on length or content imposed on the description attribute.  However, the content of the description is not considered part of the functional 
	information communicated between systems.  Descriptions are meant to be shown to specially interested human individuals.  All information 
	relevant for automated functions must be communicated using the proper attributes and associated objects.
	Note that the description attribute is not a service “name.”  All names of the service can be communicated in the Service.type_cd attribute as 
	codes together with readable print-names.
	
	As with any attribute of class Service, the meaning of the description attribute is subject to the Service.mood_cd.  For service definitions, the 
	description can contain textbook like information about that service.  For service orders, the description will contain particular instructions 
	pertaining only to that order.  Filler order systems must show the description field to a performing provider.
	
	For Service records of actual services  (Service.mood_cd = actual,) the description is an important part of the documentation.  The 
	description will contain textual reports on the service.  This is true for any service, in particular for surgical procedures, where the 
	description attribute is the place to put the entire surgery report.  If the surgical procedure is reported as multiple interrelated Service 
	instances, each instance may contain the part of the report pertinent to that step of the procedure.  However, there is no need to break a 
	service report apart into sub-services only to break the textual report apart into multiple sections.  The Encapsulated Data type is capable of 
	handling formatted textual reports in HTML, PDF, or word processor  formats.  In addition, the HL7 PRA working group defines standards to 
	use XML as a markup language for report documents. 
	Note that textual reports should always be sent in the Service.descr; this includes reports of observation services.  The Observation.value 
	field is reserved for information that is processed automatically and that is accessible to automated processes.  Human authored free text 
	reports are not easily accessible to automated processing, which is why they should be communicated in the Service description attribute.  
	Of course, free text documents can be analyzed by natural language parsers and similar tools.  We encourage that any output of such 
	natural language parsers be communicated in the Observation.value attribute in the form of structured machine accessible data.  Since 
	narrative text and observation value are in different attributes, they can be communicated together, without interfering with each other.
	Advance_directive.life_quality_desc	mapped with issues
	Advance_directive.mortuary_preference_nm	mapped with issues
	Collected_specimen_sample.collection_method_desc	mapped
	Collected_specimen_sample.collectors_comment_cd	mapped
	Dietary_intent_or_order.instruction_desc	mapped
	Master_service.desc	clearly mapped
	Master_service.factors_that_may_affect_observation_desc	mapped
	Master_service.interpretation_considerations_desc	mapped
	Procedure.delay_reason_txt	mapped
	Service_event.service_desc	clearly mapped
	Service_reason.reason_txt	mapped
	Treatment_intent_or_order.ordering_providers_instruction_txt	mapped
	Treatment_intent_or_order_revision.treatment_suppliers_instruction_cd	mapped
	Treatment_service_dispense.suppliers_special_dispensing_instruction_cd	mapped
	Service.id	C04-R091.01.11
	2.2.1.1	SET<II>
	This is an instance identifier of a particular Service object. For example, whenever a service is carried out, there is a new service object 
	instantiated with an identifier that uniquely distinguishes this service object from every other service object.
	Master_service.alternate_id	mapped with issues
	Service_event.filler_id	mapped
	Wednesday, October 13, 1999	Page 19 of 30

	Service_intent_or_order.filler_order_id	clearly mapped
	Service_intent_or_order.order_id	clearly mapped
	Service_intent_or_order.placer_order_id	mapped
	Service_intent_or_order.secondary_identification_txt	mapped
	Treatment_intent_or_order_revision.prescription_id	mapped
	Treatment_service_event.prescription_id	mapped
	Service.interpretation_cd	C04-R091.01.20
	2.2.1.10	SET<CV>
	This attribute allows for a very rough interpretation of the course or outcome of a service action.  This is sometimes called “abnormal flags”, 
	however, the judgement of normalcy is just one of the common rough interpretations, and is often not relevant.  For example, for the 
	observation of a pathologic condition, it doesn’t make sense to state the normalcy, since pathologic conditions are never considered “normal.”
	Clinical_observation.abnormal_result_cd	clearly mapped
	Service.max_repeat_nmb	C04-R091.01.22
	2.2.1.12	INT	1
	This is the maximum number of repetitions of a service.  Typical values are 1, some other finite number, and the infinity (a specific null value 
	for numbers.)  See the discussion on service plans in the USAMP-II specification, part A, on how specifically this is used.
	Treatment_intent_or_order_revision.refills_allowed_nbr	mapped
	Service.method_cd	C04-R091.01.18
	2.2.1.8	CD
	For any service there may be several different methods to achieve by and large the same result, but may be important to know when 
	interpreting a report more thorroughly (e.g., blood pressure method: arterial puncture vs. Riva-Rocci, sitting vs. supine position, etc.) 
	 
	Method concepts can be “pre-coordinated” in the Service definition, so that there is never an option to select different methods.  
	Pre-coordinating methods into the service code (type_cd) avoids having to standardize on method codes.  There are so many possible 
	methods which all depend heavily on certain kinds of services, so that defining a vocabulary domain of all methods is close to impossible.  
	The pre-coordinated approach avoids relying on the impossible to be done.
	
	However, a code system might be designed such that it specifies a set of available methods for each defined service concept. Thus, a user 
	ordering a service could select one of several variances of the service by means of the method code.  Available method variances may also 
	be defined in a master service catalog for each defined service.  In service definition records (Service.mood_cd = DEF) the method_cd 
	attribute is a set of all available method codes that a user may select while ordering, or expect while receiving results.
	
	Although the authors of this proposal believe that the pre-coordinated approach to methods goes a long way and should be followed as far 
	as possible, the same information structure can handle both the pre-coordinated and the post-coordinated approach.
	Clinical_observation.method_cd	clearly mapped
	Collected_specimen_sample.collection_method_modifier_cd	mapped
	Master_service.method_cd	clearly mapped
	Treatment_intent_or_order_revision.dispense_package_method_cd	mapped with issues
	Treatment_service_dispense.dispense_package_method_cd	mapped with issues
	Wednesday, October 13, 1999	Page 20 of 30

	Service.mood_cd	C04-R091.01.12
	2.2.1.2	SET<CV>
	Webster’s dictionary defines mood as a “distinction of form […] of a verb to express whether the action or state it denotes is conceived as 
	fact or in some other manner (as command, possibility, or wish)”  This definition of mood can be directly applied to the USAMP-II model, where
	 the service action (corresponding to a verb in natural language) may be conceived as an event that happened (fact), an ordered service 
	(command), a possible service (master), and a goal (wish) of health care.  The mood code is critical to the design of this model.  Without the 
	mood_cd, the model above would be at least three times as big, in order to distinguish service events, from orders, schedules, goals, and 
	master service items.
	
	One of the “infinitive” moods is used for describing potential services that can have actual services associated with them.  Common use of 
	the infinitive mood is for dictionary entries (so called “master service”) and all “knowledge” links (e.g., possible reason, cause, manifestation, 
	etc.) Other special infinitives are goal and trigger mood.  A goal describes a wish for a certain outcome (typically an observation) to be 
	achieved in the future. An observation in goal mood is not actually made, thus is an infinitive. Goals are evaluated later.  Triggers are service 
	descriptions that can match actual services (like a query.)  When a trigger matches, it enables, suggests, or demands the associated action 
	to be performed. Triggers are most often used to fully describe PRN medication orders, but can serve to build reminder systems too.
	Service_intent_or_order.intent_or_order_cd	mapped
	Service.orderable_ind	C04-R091.01.26
	2.2.1.16	BL	true
	This attribute indicates whether this service can be requested independently from other services.  Some services can only occur as 
	subordinate to a super-service; others are abstractions of services or service groups that should not be ordered in one piece.  Since in 
	principle everything that can be done can potentially be requested, this attribute is true by default.  It is usually only used for master file 
	definitions.
	Master_service.orderable_service_ind	clearly mapped
	Service.priority_cd	C04-R091.01.25
	2.2.1.15	SET<CV>	{R}
	This attribute encodes the urgency under which the service is to be scheduled and performed, or was performed.  This attribute is used in 
	orders to indicate the ordered priority.  It is also used in the service event documentation to indicate the actual priority used to perform the 
	service, which is used to determine the charge.  In master service definitions it indicates the available priorities.
	Master_service.allowable_processing_priority_cd	clearly mapped
	Master_service.allowable_reporting_priority_cd	mapped
	Master_specimen_requirement.priority_cd	mapped
	Service_intent_or_order.reporting_priority_cd	mapped
	Service.status_cd	C04-R091.01.15
	2.2.1.5	CV
	The state of the action (e.g., newly ordered, in process, completed.)  The state is communicated in coded form.  The codes are strictly 
	defined by the state-transition model of a service class.  No alternative coding system can be used for the status_cd attribute (CNE, coded no
	 exceptions.)
	Clinical_observation.status_cd	clearly mapped
	Clinical_observation.status_dttm	mapped
	Condition_node.life_cycle_start_dttm	mapped
	Condition_node.lifecycle_status_cd	clearly mapped
	Master_service.effective_tmr	mapped with issues
	Master_service.last_update_dttm	mapped with issues
	Wednesday, October 13, 1999	Page 21 of 30

	Resource_request.status_cd	clearly mapped
	Service_event.filler_order_status_dttm	mapped
	Service_event.status_cd	clearly mapped
	Service_event.status_reason_cd	mapped with issues
	Service_intent_or_order.order_placed_dttm	mapped with issues
	Service_intent_or_order.status_cd	clearly mapped
	Service_intent_or_order.status_dttm	mapped with issues
	Service_intent_or_order.status_reason_cd	mapped with issues
	Service_intent_or_order.transport_arranged_ind	mapped
	Service_scheduling_request.status_cd	clearly mapped
	Treatment_service_administration.completion_status_cd	clearly mapped
	Service.substitution_cd	C04-R091.01.24
	2.2.1.14	CV	N
	Indicates whether an ordered or intended service may be or has been substituted for a different service. The fact that the actual service 
	differs from the planned or ordered service, and the details of the variance can be seen by comparing the service as planned or ordered 
	from the service as performed.  Both service records should be sent in a message where this difference is important.  The 
	Service.substitution_cd attribute is mainly used in an order, to specify whether an ordered service may be substituted and in what way it 
	Resource_request.allowable_substitutions_cd	mapped
	Service_scheduling_request.allowable_substitutions_cd	clearly mapped
	Treatment_intent_or_order.substitution_allowed_ind	clearly mapped
	Treatment_intent_or_order_revision.substitution_status_cd	mapped
	Treatment_service_event.substitution_cd	mapped
	Service.total_time	C04-R091.01.16
	2.2.1.6	GTS
	This is the time when the action happened, is ordered or scheduled to happen, or when it can possibly happen (depending on the mood of 
	the Service object.)  The timing of actions is a very important concept that is explained in greater detail in USAMP-II part A, Section 2.5.3.
	Advance_directive.assessment_dttm	mapped with issues
	Collected_specimen_sample.collection_scheduled_dttm	mapped
	Collected_specimen_sample.collection_tmr	mapped
	Master_observation_service.processing_time_qty	mapped
	Master_observation_service.typical_turnaround_time_qty	mapped
	Master_service.performance_schedule_cd	mapped
	Master_service.standard_time_to_perform_qty	mapped with issues
	Procedure.procedure_tmr	mapped
	Resource_request.duration_qty	mapped
	Wednesday, October 13, 1999	Page 22 of 30

	Resource_request.start_dttm	mapped
	Service_event.scheduled_start_dttm	mapped with issues
	Service_event.tmr	clearly mapped
	Service_intent_or_order.expected_performance_time_qty	mapped
	Service_scheduling_request.duration_qty	mapped
	Service_scheduling_request.start_dttm	mapped
	Treatment_intent_or_order_revision.last_refilled_dttm	mapped
	Service.type_cd	C04-R091.01.13
	2.2.1.3	CD
	A code for the kind of action (e.g., physical examination, serum potassium, etc.), used to be called “universal service identifier”.  The 
	Service.type_cd specifies the service conceptually by using a code from a code system.  We often refer to the Service.type_cd as the 
	“name” of the Service.  In any case, the type_cd or “name” is a handle on the concept of the action, not on the individual action instance.
	
	Different code systems cover different kinds of services, which is why there is not one single code system to be used for the 
	Servcie.type_cd.  Furthermore, the data type Concept Descriptor (CD) allows the action to be named by multiple code systems at the same 
	time, whereby each term from a coding system is assumed to be a synonym.  For example, a Thrombectomy service may be named “34001” 
	using the CPT-4 code, “P1-30322” in SNOMED, or “38.00” in ICD-10-PCS.
	Advance_directive.directive_cd	clearly mapped
	Clinical_observation.confirmation_status_cd	mapped with issues
	Clinical_observation.universal_service_identifier_suffix_txt	mapped with issues
	Dietary_intent_or_order.diet_type_cd	clearly mapped
	Dietary_intent_or_order.service_period_cd	mapped with issues
	Master_numeric_range.type_cd	mapped
	Master_service.alternate_name_use_cd	mapped with issues
	Master_service.alternate_nm	mapped with issues
	Master_service.imaging_measurement_modality_cd	mapped with issues
	Master_service.observation_id_suffix_txt	mapped with issues
	Master_service.primary_nm	mapped with issues
	Master_service.universal_service_id	clearly mapped
	Procedure.functional_type_cd	mapped with issues
	Procedure.modifier_cd	mapped
	Service_event.consent_cd	mapped
	Service_intent_or_order.transport_mode_cd	mapped
	Wednesday, October 13, 1999	Page 23 of 30

	Service_list :: is_about(0..1) :: Material :: is_subject_of(0..*)	C04-R091.30.04
	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.
	Durable_medical_equipment_slot :: is_scheduleable_unit_for(1..1) :: Durable_medical_equipment 	mapped
	Service_relationship	C04-R091.02.00
	2.4
	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.
	Clinical_observation.last_observed_normal_values_dttm	mapped
	Clinical_observation.observation_sub_id	clearly mapped
	Conditional_link	mapped
	Goal :: is_measured_by(1..1) :: Master_observation_service :: measures(1..n)	mapped
	Judgement_link	mapped
	Master_numeric_range :: applies_to(1..1) :: Master_quantitative_observation :: conforms_to(0..n)	mapped
	Master_observation_service :: has_as_basis(0..n) :: Master_observation_service :: 	mapped
	Master_service.challenge_information_txt	mapped
	Master_service.consent_required_cd	mapped
	Master_service.contraindication_desc	mapped
	Master_service.patient_preparation_desc	mapped
	Master_service.qt	mapped with issues
	Wednesday, October 13, 1999	Page 24 of 30

	Master_service.report_display_order_txt	mapped with issues
	Master_service_relationship	clearly mapped
	Master_service_relationship.constraint_txt	mapped
	Master_treatment_service :: is_ordered_on(0..n) :: Treatment_intent_or_order_revision :: 	mapped
	Observation_intent_or_order.relevant_clinical_information_txt	mapped with issues
	Procedure.anesthesia_cd	mapped with issues
	Procedure.anesthesia_tmr	mapped with issues
	Rule_link	mapped
	Master_service :: is_delivered_during(0..n) :: Service_event :: delivers(1..1)	mapped
	Service_intent_or_order :: is_fulfilled_by(0..n) :: Service_event :: fulfills(0..1)	mapped
	Service_event_relationship	clearly mapped
	Service_intent_or_order :: is_an_instance_of(1..1) :: Master_service :: is_instantiated_as(0..n)	mapped
	Service_intent_or_order_relationship	mapped
	Service_intent_or_order_relationship.constraint_txt	mapped
	Service_reason	mapped
	Master_service :: is_requested_by(0..n) :: Service_scheduling_request :: requests(1..1)	mapped
	Treatment_intent_or_order :: has_parts(1..n) :: Treatment_intent_or_order_revision :: 	mapped
	Treatment_intent_or_order.indication_id	mapped with issues
	Treatment_intent_or_order_revision.give_indication_id	mapped
	Treatment_service_event.indication_id	mapped
	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)	C04-R091.02.02
	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.
	Master_service :: is_source(0..n) :: Master_service_relationship :: has_source(1..1)	clearly mapped
	Service_event :: is_source_for(0..n) :: Service_event_relationship :: has_as_source(1..1)	clearly mapped
	Service_intent_or_order :: is_source_for(0..n) :: Service_intent_or_order_relationship :: 	clearly mapped
	Service_reason :: is_reason_for(0..1) :: Service_event :: has_as_reason(0..n)	mapped
	Service_reason :: is_reason_for(0..1) :: Service_intent_or_order :: has_as_reason(0..n)	mapped
	Wednesday, October 13, 1999	Page 25 of 30

	Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)	C04-R091.02.03
	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.
	Master_service :: is_target(0..n) :: Master_service_relationship :: has_target(1..1)	clearly mapped
	Service_event :: is_target_for(0..n) :: Service_event_relationship :: has_as_target(1..1)	clearly mapped
	Service_intent_or_order :: is_target_for(0..n) :: Service_intent_or_order_relationship :: 	clearly mapped
	Service_reason :: has_as_evidence(0..1) :: Service_event :: is_evidence_for(0..n)	mapped
	Service_relationship.join_cd	C04-R091.02.18
	2.4.1.8	CV	W
	In a parallel branch construct the join code indicates how the concurrent activities are resynchronized.
	
	Concept	Code	Definition
	wait	W	Wait for this branch to terminate.
	kill	K	When all other concurrent branches are terminated, interrupt and discontinue this branch.
	exclusive wait	X	Wait for any one of the branches in the set of exclusive wait branches to terminate, then discontinue all the other 
	exclusive wait branches.
	detached	D	Detach this branch from the other branches so it will not be resynchronized with the other branches.
	
	A kill branch will only be executed if there is at least one active wait (or exclusive wait) branch.  If there is no other wait branch active, a kill 
	branch is not started at all (rather than being discontinued shortly after it is started.)  A detached branch will be unrelated to all other 
	branches, thus a kill branch will be discontinued no matter whether there are detached branches still running.
	Master_service.join_cd	clearly mapped
	Service_intent_or_order.join_cd	clearly mapped
	Service_relationship.pause_qty	C04-R091.02.15
	2.4.1.5	PQ	0 s	~ 1 s
	The time that should elapse after this activity has got clearance to execute and the actual begin of execution. Any entering pre-conditions are
	 tested before the slot is entered, so the pause specifies a minimal waiting time before the service is executed after its pre-conditions 
	become true.
	Service_scheduling_request.start_offset_qty	mapped
	Service_relationship.priority_nmb	C04-R091.02.14
	2.4.1.4	INT	1
	This integer number allows to specify another kind of ordering amongst the outgoing relationships of a service.  This is used to represent the 
	priority ordering of conditional branches in service execution plans, or priority ranking in pre-condition, outcome or support links, and 
	preferences among options.  
	
	The ordering may be total or partial.  A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of 
	the relationships originating in the same service instance and usually having the same relationship type) has a distinct priority number.  If, 
	however, some relationships in the bundle share the same priority number, we have a partial ordering.  Those links with the same priority will 
	have undefined ordering of consideration.
	Rule_link.priority_nbr	clearly mapped
	Wednesday, October 13, 1999	Page 26 of 30

	Service_relationship.sequence_nmb	C04-R091.02.13
	2.4.1.3	INT	1
	This integer number allows one to specify an ordering amongst the outgoing relationships of a service. This is used to represent sequences 
	of actions in execution plans.
	  
	The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle has a distinct sequence number.  (A 
	relationship “bundle” is a sub-set of the relationships originating in the same service instance and usually having the same relationship type).  
	If, however, some relationships in the bundle share the same sequence number, we have a partial ordering.  In such a case the services 
	with the same sequence number are concurrent.
	Treatment_intent_or_order_revision.refills_doses_dispensed_nbr	mapped
	Treatment_service_administration.administration_nbr	mapped
	Service_relationship.type_cd	C04-R091.02.11
	2.4.1.1	CV
	Determines the meaning of a relationship between two Services.  This attribute is probably the most important attribute in this entire model 
	besides the Service.mood_cd.  It is a “structural” attribute inasmuch as each of its values implies specific constraints to what kinds of 
	Service objects can be related and in which way.  Refer to the USAM specification document for defined service relationship types and 
	examples of their use.
	Judgement_link.type_cd	clearly mapped
	Master_service_relationship.relationship_type_cd	clearly mapped
	Service_event_relationship.relationship_type_cd	clearly mapped
	Service_intent_or_order_relationship.relationship_type_cd	clearly mapped
	Specimen	C04-R091.23.00
	2.8.1
	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 
	Collected_specimen_sample	mapped
	Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..*)	C04-R091.23.02
	Collected_specimen_sample :: is_sourced from(0..1) :: Living_subject :: is_source_for(0..n)	mapped with issues
	Specimen :: is_sourced_from(0..1) :: Person :: is_source_for(0..*)	C04-R091.23.03
	Collected_specimen_sample :: is_sourced_from(0..1) :: Patient :: is_source_for(0..n)	mapped with issues
	Wednesday, October 13, 1999	Page 27 of 30

	Specimen.body_site_cd	C04-R091.23.11
	2.8.1.1	CD
	Body site has been retained as an attribute of the specimen, since it may be relevant in some cases, e.g., if multiple liver needle biopsies are 
	taken from different lobes and locations of the liver.  The value of the Specimen.body_site_cd should be identical to the value of the 
	Service.body_site_cd of an associated specimen collection service.  This attribute therefore is used only if such an associated specimen 
	collection service is not communicated.  When the rule is to always send a specimen along with a record of the specimen collection service, 
	this attribute needs not be valued.
	Collected_specimen_sample.body_site_cd	clearly mapped
	Collected_specimen_sample.collection_body_site_modifier_cd	mapped
	Supply	C04-R091.08.00
	2.6.7
	Supply orders and deliveries are very simple services that mainly focus on the delivered product.  The product is associated with the supply 
	service as a Material target of type product (PRD).  Just as with Medication services there are in principle two ways to represent the type 
	and identity of supplied material, i.e. as the Supply.type_cd or as the Material.type_cd of the target material (Target.type_cd = product.)  With 
	general supply orders the precise identification of the Material, its manufacturer, serial numbers, etc. is important, and supply services are 
	only very marginal parts of the electronic patient record.  Therefore, most of the detail information about the supply should be represented 
	using the Material class. 
	
	Note that if delivery needs to be scheduled, tracked, and billed separately, one can associate Transportation services with the supply.
	
	Pharmacy dispense services are represented as supply services, associated with a medication service.  The medication class represents 
	the administration of medication, while dispensing is supply.
	Treatment_service_dispense	mapped
	Target	C04-R091.04.00
	2.3.2
	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.
	Collected_specimen_sample :: is_collected_during(0..1) :: Procedure :: collects(0..n)	clearly mapped
	Durable_medical_equipment_request :: requests(0..1) :: Durable_medical_equipment_group :: 	mapped
	Durable_medical_equipment_request :: requests(1..1) :: Durable_medical_equipment :: 	mapped
	Durable_medical_equipment_request.type_cd	mapped
	Master_observation_service :: has(0..n) :: Master_specimen_requirement :: is_specified_for(1..1)	mapped
	Master_observation_service.instrument_cd	mapped with issues
	Master_patient_service_location :: is_entry_location_for(0..n) :: Service_intent_or_order :: 	mapped
	Patient_service_location_group :: is_requested_by(0..n) :: Patient_service_location_request :: 	mapped with issues
	Resource_request	mapped
	Resource_request :: generalizes(1..1) :: Durable_medical_equipment_request :: specializes(1..1)	mapped
	Resource_request :: generalizes(1..1) :: Patient_service_location_request :: specializes(1..1)	mapped
	Wednesday, October 13, 1999	Page 28 of 30

	Service_event :: is_performed_at(0..1) :: Master_patient_service_location :: is_location_for(0..n)	mapped
	Service_intent_or_order :: expects_patient_located_at(0..1) :: Master_patient_service_location :: 	mapped
	Service_intent_or_order.entering_device_cd	mapped with issues
	Target_participation	clearly mapped
	Target :: in(1..1) :: Service :: has(0..*)	C04-R091.04.02
	Target_participation :: is_target_of(0..1) :: Service_event :: has_as_target(0..n)	clearly mapped
	Target_participation :: is_target_of(0..1) :: Service_intent_or_order :: has_as_target(1..n)	clearly mapped
	Target :: participation_of(0..1) :: Living_subject :: participates_as(0..*)	C04-R091.04.05
	Any one Target instance connects one Service to either a Person or a Material but not both.
	Living_subject :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)	clearly mapped
	Target :: participation_of(0..1) :: Material :: participates_as(0..*)	C04-R091.04.04
	Any one Target instance connects one Service to either a Person or a Material but not both.
	Collected_specimen_sample :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)	clearly mapped
	Master_patient_service_location :: is_target_for(0..n) :: Target_participation :: has_as_target(0..1)	mapped
	Target.awareness_cd	C04-R091.04.13
	2.3.2.3	CV
	For person targets indicates whether the associated patient or family member is aware of the service, and especially of the observation 
	made.  For example, a patient (or his next family members) may not be aware of a malignancy diagnosis, the patient and family may be aware
	 at different times, and some patients may go through a phase of denial.  For other than person targets this attribute is not applicable and shall
	 not be valued.
	Advance_directive.competence_ind	mapped with issues
	Service_event.family_awareness_txt	mapped
	Service_event.individual_awareness_cd	mapped
	Target.tmr	C04-R091.04.12
	2.3.2.2	SET<CV>
	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.
	Resource_request.start_offset_qty	mapped
	Target_participation.tmr	clearly mapped
	Wednesday, October 13, 1999	Page 29 of 30

	Target.type_cd	C04-R091.04.11
	2.3.2.1	SET<CV>
	Just as with actors, different participation types can be identified for targets.  By “target” of an action we basically mean objects of a verb. 
	Objects appear in different cases: direct objects, indirect objects or adverbial objects according to their roles in a sentence. Target 
	participation type codes distinguish those different roles. For instance, patient, guarantor, custodian, or family members are examples of 
	target participation types. These are in the role of direct target on whom (accusative) or the indirect beneficiary (on behalf of whom) the 
	service action is performed.  In addition any material, specimen, device, or location used or produced by a service is a target of the service.
	Target_participation.participation_type_cd	clearly mapped
	Transportation	C04-R091.11.00
	2.6.6
	Transportation is the moving of a payload (people or material) from a location of origin to a destination location.  Thus, any transport service 
	has the three target instances of type payload, origin, and destination, besides the targets that are generally used for any service (i.e., 
	performer, device, etc.)
	Collected_specimen_sample.transport_logistics_cd	mapped
	Service_intent_or_order.planned_patient_transport_cd	mapped
	Wednesday, October 13, 1999	Page 30 of 30