RIM 092 to USAMP-II mapping
	Active_participation
	Active_participation	C
	A role class that captures the multiple roles various entities play e.g., orderer, attending, witness, transcriber, etc., in delivering a service to a 
	target of service.
	
	Rationale:  Since multiple entities participate in the delivery of services to particular targets of service, a role class is needed to capture the 
	multiple roles these participants play in delivering a service to a target of service.
	
	OpenIssue:  There is as need to re-examine the manner in which attending physicians is representing because this will cause two different 
	ways of identifying it.
	clearly mapped	Actor
	C04-R091.03.00	2.3.1
	Active_participation :: has_as_participant(1..1) :: Stakeholder :: participates_in(0..n)	RAS
	Rationale:  replaces the following classes and connections - Service_event_provider, Order_healthcare_practitioner, 
	Advance_directive_witness, Notary_public notarizes 0..m Advance_directive.
	clearly mapped	Actor :: participation_of(1..1) :: Stakeholder :: participates_as(0..*)
	C04-R091.03.03
	Active_participation :: participates_in(0..1) :: Service_event :: has_as_active_participant(0..n)	RAS
	Rationale:  each Active_participation instance connects to either a Service_event or a Service_intent_or_order.  It therefore cannot have a 
	mandatory connection to either of those classes.  We are lacking the formalism to indicate that one of these two relationships MUST be in 
	effect for each Active Participating instance.
	clearly mapped	Actor :: for(1..1) :: Service :: has(0..*)
	C04-R091.03.02
	Active_participation :: participates_in(0..1) :: Service_intent_or_order :: has_as_participant(0..n)	RAS
	Rationale:  each Active_participation instance connects to either a Service_event or a Service_intent_or_order.  Therefore, there cannot be a 
	fully mandatory relationship between Active_participation and Service_intent_or_order.  We are lacking the formalism to indicate that one of 
	these two relationships MUST be in effect for each Active Participation  instance.
	clearly mapped	Actor :: for(1..1) :: Service :: has(0..*)
	C04-R091.03.02
	Active_participation.participation_type_cd	A
	The nature or purpose of the participant's participation.  Examples:  order healthcare practitioner, service event provider, advance directive 
	witness, notarizer.
	clearly mapped	Actor.type_cd
	C04-R091.03.11	2.3.1.1	SET<CV>
	Wednesday, October 13, 1999	Page 1 of 79

	Active_participation.tmr	A
	The effective and termination dates of the active participation.
	
	Rationale:  Manage active participations.
	clearly mapped	Actor.tmr
	C04-R091.03.12	2.3.1.2	IVL<TS>
	Advance_directive
	Advance_directive	C
	An authoritative instruction or direction from or on behalf of a patient regarding their healthcare or the disposition of their remains.
	mapped	Consent
	C04-R091.12.00	2.6.5
	Advance_directive.assessment_dttm	A
	The date and time the advance directive was identified.
	
	Rationale:  To replace attribute previously inherited from Patient_clinical_item.
	
	OpenIssue:  Amplify definition.  Is this when patient or rep made the directive?  When it was noted by a clinician?  When it got an official ID?
	mapped with issues	Service.total_time
	The high boundary of a time interval.
	
	However, note the interference with Advanced_directive.notarization_dttm
	C04-R091.01.16	2.2.1.6	GTS
	Advance_directive.competence_ind	A
	An indication as to whether the patient was mentally competent when completing the advance directive.
	mapped with issues	Target.awareness_cd
	Suggested mapping is tentative.  We can as well add the attribute Consent.competence_ind.
	C04-R091.04.13	2.3.2.3	CV
	Advance_directive.directive_cd	A
	A code depicting the nature of the advance directive.
	
	OpenIssue:  Amplify definition.  Provide indication of how the directive nature is typed.  That is what kind of discrimination is being made.
	clearly mapped	Service.type_cd
	C04-R091.01.13	2.2.1.3	CD
	Wednesday, October 13, 1999	Page 2 of 79

	Advance_directive.disclosure_level_cd	A
	The level of disclosure allowed for this advance directive.
	clearly mapped	Service.confidentiality_cd
	C04-R091.01.21	2.2.1.11	SET<CV>
	Advance_directive.life_quality_desc	A
	A free for text describing quality of life preference of the patient to be used in making intervention decisions.
	mapped with issues	Service.descr
	As a piece of free text it belongs into Service.descr, however, with a little more work this might be coded, and then can become interopeable.
	C04-R091.01.14	2.2.1.4	ED
	Advance_directive.mortuary_preference_nm	A
	The name of the patient's preferred mortuary.
	mapped with issues	Service.descr
	This should even be an association to an Organization that as the preferred Mortuary.  In this case, "mortuary" may become an Actor.type_cd 
	used in an acvanced directive.
	C04-R091.01.14	2.2.1.4	ED
	Advance_directive.notarization_dttm	A
	The date the advance directive was notarized.
	mapped with issues	Service.critical_time
	low boundary of interval
	
	this mapping is under the assumption that a notarization i required for this particular kind of advanced directive.  In most cases no notarization 
	is required, so that the critical_time.low would be the date signed by the author.
	
	This is one of the state history information captured as "slotted time stamps".
	C04-R091.01.17	2.2.1.7	GTS
	Clinical_observation
	Assessment :: generalizes(1..1) :: Clinical_observation :: specializes(1..1)	RGD
	mapped	Observation is specialization of Service
	C04-R091.05.01
	Wednesday, October 13, 1999	Page 3 of 79

	Clinical_observation	C
	The information or record secured by an act or instance of viewing or noting a fact or occurrence for some health related purpose.
	
	OpenIssue:  Consideration should be given to the identification that the Gen-Spec (clinical_observation is a specialization of Assessment) may
	 be flawed and that it may be replaced with a simple association.
	clearly mapped	Observation
	C04-R091.05.00	2.6.1
	Clinical_observation.abnormal_result_cd	A
	A code specifying the degree of abnormality of the observation value, e.g., Normal, Abnormal, Low, High, Critical.  This is NOT trying to 
	represent severity.
	
	OpenIssue:  The committee MUST address the issue of 
	how to represent severity of the result, both for clinical and for administrative type observations (for allergy severity representation).
	clearly mapped	Service.interpretation_cd
	C04-R091.01.20	2.2.1.10	SET<CV>
	Clinical_observation.clinically_relevant_tmr	A
	The clinically relevant begin and end dates/times for the observation.  In the case of observations taken directly from a subject, it represents 
	the actual dates and times of the observation.  In the case of a specimen-associated study, this field shall represent the dates and times of 
	specimen collection.
	
	Rationale: This is the definition that has been developed by the committee and balloted.  This is the field that is wanted in the message, not 
	separate fields for the specimen collection time and the time of the observation.  Often, an interim time is chosen as "clinically relevant".  There 
	would be too much overhead in maintaining separate fields for all the possible interim times.
	mapped	Service.critical_time
	Typically just some point in time (close to the specimen collection time), may be the intervl of the specimen collection service, but that is not 
	necessarily more clinically relevant than some point in time within the specimen collection service. 
	
	For direct observations, this is the time point or interval that the observation was made.
	C04-R091.01.17	2.2.1.7	GTS
	Clinical_observation.confirmation_status_cd	A
	A code depicting the level of verification for the patient problem (e.g., confirmed, differential, provisional, rule-out, . . .).
	mapped with issues	Service.type_cd
	As far as the confirmation status is coordinated into the code for diagnoses.
	C04-R091.01.13	2.2.1.3	CD
	Wednesday, October 13, 1999	Page 4 of 79

	Clinical_observation.last_observed_normal_values_dttm	A
	When a Method Code is specified for this observation, this field contains the date and time of changes in the specified method that would 
	make values obtained from a previous version of the method not comparable with those obtained from the current version.
	
	OpenIssue: This is being returned to committee to be reworked to remove the inconsistency between the name and the definition.
	
	Rationale: This information is required here, since by definition the master test file does not distinguish this method from others (see definition 
	of Method_cd attribute), and therefore cannot provide change dates at this level of detail. Such change information must be provided by the 
	observation provider.
	mapped	Service_relationship
	A the last normal observation can be linked with this observation rather than vaguely cited via a time stamp (that in fact functions as a forreign
	 key here!)
	
	The RIM092 definition of this attribute appears mismatched?
	C04-R091.02.00	2.4
	Clinical_observation.method_cd	A
	Used to transmit the method or procedure by which an observation was obtained when the sending system wishes to distinguish among one 
	measurement obtained by different methods and the distinction is not implicit in the test ID.  Chemistry laboratories do not usually distinguish 
	between two different methods used to measure a given serum constituent (e.g., serum pottassium) as part of the test name. See the LOINC 
	Users Manual for a more complete discussion of these distinctions.  If an observation producing service wanted to report the method used to 
	obtain a particular observation, and the method was NOT embedded in the test name, they can use this field.  The Centers for Disease Control 
	and Prevention (CDC) Method Code (CDCM) (see Figure 7-3) is one candidate code system for reporting methods/instruments.  EUCLIDES 
	method codes are another.  User-defined tables are an alternative.
	
	clearly mapped	Service.method_cd
	C04-R091.01.18	2.2.1.8	CD
	Clinical_observation.nature_of_abnormal_testing_cd	A
	When an abnormal result code is present, this attribute indicates the type of control population against which the observation was tested for 
	abnormalcy. Control population might be based on age, sex, race, etc., or a combination of these.  It may also be a generic normal range.  
	Combination control populations are expressed as  multiple individual codes (ie. this attribute must be of the Set datatype).
	
	OpenIssue:
	mapped	Observation.value
	… of an Observation in criterion mood linked to an observation in reference mood linked to the observation in event mood.  This is straight 
	forward mapping of the semantics of reference ranges! See discussion about reference ranges.
	C04-R091.05.11	2.6.1.1	ANY
	Clinical_observation.observation_sub_id	A
	This field is used to order multiple related clinical observations delivering the same master service.  
	
	The sub-identifier is also used to group related components in reports such as surgical pathology.  It is traditional for surgical pathology 
	reports to include all the tissues taken from one surgical procedure in one report.  
	
	It can be used to organize the reporting of some kinds of fluid intakes and outputs.  For example, when intake occurs through multiple 
	intravenous lines, a number of separate observations--the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, 
	etc. may be needed for each intravenous line.  If more than one IV line is running, we can logically link all of the observations that pertain to the
	 first IV line by assigning them an observation sub ID of 1.  We can do the same with the second IV line by assigning them a sub ID 2 and so 
	on.  The same would apply to the outputs of surgi al drains when there are multiple such drains.
	
	OpenIssue:  consider whether this should be accomplished in or through the Service_event_relationship.
	clearly mapped	Service_relationship
	If this (in)famous OBX.sub_id doesn't go away, what use is our modeling for? Of course the sub_id is represented through the 
	service_relationship!!!
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 5 of 79

	Clinical_observation.references_range_val	A
	When an abnormal result code is present, this attribute contains the high and low limits of the reference range for quantitative observations, or
	 the normal value for qualitative observations.  The range is taken to be inclusive (i.e., the range includes the end points).  
	
	When the reference range applies to the amount of a toxic substance, then the upper limit of the range identifies the toxic limit.  If the range 
	applies to  a drug, the lower limit identifies the lower therapeutic bound and the upper limit represents the upper therapeutic bound above 
	which toxic side effects are common.
	
	OpenIssue:
	mapped	Observation.value
	… of an associated observation in reference mood. See discussion of reference ranges.
	C04-R091.05.11	2.6.1.1	ANY
	Clinical_observation.status_cd	A
	A code indicating the lifecycle status of the clinical_observation.  See state/transition model for an exhaustive list of lifecycle states.
	
	OpenIssue:  Amplify definition.  Provide examples or explain how statuses are differentiated.
	clearly mapped	Service.status_cd
	C04-R091.01.15	2.2.1.5	CV
	Clinical_observation.status_dttm	A
	The effective date and time of the clinical result status.
	mapped	Service.status_cd
	The status code can be sent as a history item or a history list of status codes with a time range associated to either the most recent status or 
	more (all) statuses.  That way one can send time stamp information for the entire life-cycle, not just for the most recent status.  Also, that way
	 one can get rid of slotted time stamps whose primary purpose is to communicate status information.
	C04-R091.01.15	2.2.1.5	CV
	Clinical_observation.universal_service_identifier_suffix_txt	A
	Suffixes identify the common components of narrative reports.  Each type of narrative report is assigned a universal_service_id.  The actual 
	report components are reported in separate observation service events, all linked to the master service for the report.  The suffix test for the 
	observation further qualifies the observatuion as to which component of the narrative report it contains.
	
	The applicable three-character mnemonics given in ASTM Table 20 (or others appropriate to the application) should be used.  For example, a 
	chest X-ray may use the suffixes IMP, REC, DEV, or others.
	mapped with issues	Service.type_cd
	The subsections of reports are better fully precoordinated into the service.type_cd but canstill be sent as modifiers in the type_cd's code 
	phrase structure.  Remember that the u.s.id suffix was a modifier on the type_cd and modifiers is what the Code Phrase data type was 
	C04-R091.01.13	2.2.1.3	CD
	Wednesday, October 13, 1999	Page 6 of 79

	Clinical_observation.user_defined_access_check_cd	A
	Permits the producer to record results-dependent codes for classifying the observation at the receiving system.  This field should be needed 
	only rarely, because most classifications are fixed attributes of the observation ID and can be defined in the associated observation master 
	file.  However, there are a few cases when such controls vary with the value of the observation in a complex way that the receiving system 
	would not want to recalculate.  An example is an antimicrobial susceptibility result.  Some systems prefer to dispaly only the susceptibility 
	results of inexpensive antimicrobials depending upon the organism, the source of the specimen and the patient's allergy status.  The sending 
	service wants to send all of the susceptibilities so that certain privileged users (e.g., Infectious Disease specialists) can review all of the 
	results but nonprivileged users would see only the "preferred" antimicrobials to which the organism was susceptible.  We expect that other 
	cases also occur.
	
	mapped with issues	Service.confidentiality_cd
	(see this HL7 v2.3 field discussed in USAMP part B)
	C04-R091.01.21	2.2.1.11	SET<CV>
	Clinical_observation.val	A
	Value observed by the observation producer.
	
	Units of measure will be included as appropriate for the datatype of the value.  Also includes the degree of certainty in the observation.
	
	The appropriate generic datatype to represent probability will be bound to the observation value at instantiation, depending on the actual 
	datatype of the instantiated observation value (discrete or ordered), and the nature of the probability representation (narrative or numeric; 
	parametric or non-parametric).
	
	clearly mapped	Observation.value
	C04-R091.05.11	2.6.1.1	ANY
	Clinical_observation.value_datatype_cd	A
	HL7 datatype in which the observation value and any reference range are expressed. These must be represented according to a data type 
	defined for HL7.
	
	All HL7 data types are valid with certain exceptions (eg. need list from current datatypes).
	
	All data types are valid with certain exceptions (e.g., CM, CQ, SI, and ID).
	
	mapped	Observation.value
	The ANY data type implies the type information about the actual type. In other words, in an ANY data type, the value comes as a pair of data 
	type code and value.
	C04-R091.05.11	2.6.1.1	ANY
	Collected_specimen_sample
	Collected_specimen_sample	C
	A sample of a substance or material for examination or study (a urine specimen; a tissue specimen).
	mapped	Specimen
	as a role of Material.  Specimen and Container have been separated in USAMP (this time, the lumper-splitter theme is inverted :-)  See attribute 
	mapping about how this unfolds.  In general, a specimen is related to its container through the Material_relationship class (of type "contains".)
	C04-R091.23.00	2.8.1
	Wednesday, October 13, 1999	Page 7 of 79

	Collected_specimen_sample :: is_collected_during(0..1) :: Procedure :: collects(0..n)	RAS
	clearly mapped	Target
	The collected specimen is a Target of type "product" of a Service.  The collaction service may be a Procedure, Observation action, or some 
	not otherwise classified Service action.
	C04-R091.04.00	2.3.2
	Collected_specimen_sample :: is_sourced from(0..1) :: Living_subject :: is_source_for(0..n)	RAS
	mapped with issues	Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..*)
	In any case the Target (Target.type_cd = subject) of the specimen collection service is the source of the specimen.  However, the 
	specimen-material needs a direct link to its source.  The technique depends on the relationship of Living_subject to material.  At this time, a 
	direct association Specimen :: is_sourced_from(0..1) :: Living_subject :: is_source_for(0..n) is proposed.  However, the plan is to make 
	Living_subject a specialization (not a role!) of material.
	C04-R091.23.02
	Collected_specimen_sample :: is_sourced_from(0..1) :: Patient :: is_source_for(0..n)	RAS
	mapped with issues	Specimen :: is_sourced_from(0..1) :: Person :: is_source_for(0..*)
	In any case the Target (Target.type_cd = subject) of the specimen collection service is the source of the specimen.  However, the 
	specimen-material needs a direct link to its source.  The technique depends on the relationship of Living_subject to material.  At this time, a 
	direct association  is proposed.  However, the plan is to make Living_subject a specialization (not a role!) of material.
	
	See Target_participation for the issue with Person vs. Patient as the target.
	C04-R091.23.03
	Collected_specimen_sample.additive_desc	A
	Free text representation of additives to the specimen such as Heparin, EDTA, or Oxlate.
	mapped	Material_relationship
	of type "additive".  This allows properly coded/structured additive information to be sent, allows for multiple additives, allows to specify the 
	proportion of the additive to the specimen (important since additives dillute the specimen!)  If for compatibility with legacy systems the free text 
	description is all we want to require it still goes into the Material.descr of the Material related as additive.
	C04-R091.21.00	2.7.2
	Collected_specimen_sample.body_site_cd	A
	The body site from which the specimen was obtained.  Coded concepts include:  Ear, Chest Tube, Arm, Lower Forearm, Anterior Chest, 
	Vastus Lateralis, Nebulized.
	clearly mapped	Specimen.body_site_cd
	C04-R091.23.11	2.8.1.1	CD
	Wednesday, October 13, 1999	Page 8 of 79

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

	OpenIssue:
	mapped	Specimen.body_site_cd
	Code modifiers are sent in the Code Phrase data type along with the primary code.
	C04-R091.23.11	2.8.1.1	CD
	Collected_specimen_sample.collection_method_desc	A
	A description of the method used to collect the specimen.
	mapped	Service.descr
	… of the specimen collection service.
	C04-R091.01.14	2.2.1.4	ED
	Collected_specimen_sample.collection_method_modifier_cd	A
	Indicates whether the specimen is frozen as part of the collection method.  Coded concepts are frozen, refrigerated, room temperature.
	mapped	Service.method_cd
	… of the specimen collection Service.  Code modifiers are sent in a Code Phrase together with the primary code.
	
	Interestingly RIM092 has method_desc (free text) and method_modifier_cd, but not a primary method_cd.
	C04-R091.01.18	2.2.1.8	CD
	Collected_specimen_sample.collection_scheduled_dttm	A
	The date and time the analyzed object is scheduled to be collected.
	mapped	Service.total_time
	… of the Specimen collection service intent (mood_cd = intent.)  Usually an (estimated) point in time.
	
	Of course, in USAMP-II one can also order the specimen collection to happen at a specific time (e.g., important for a TRH test, or any kind of 
	lab test involving challenges.)
	C04-R091.01.16	2.2.1.6	GTS
	Collected_specimen_sample.collection_tmr	A
	The start and end dates and times of analyzed object collection.
	mapped	Service.total_time
	… of the specimen collection service.  Usually an interval of time, just as in RIM092.
	C04-R091.01.16	2.2.1.6	GTS
	Collected_specimen_sample.collection_volume_qty	A
	The amount of specimen collected.
	clearly mapped	Material.qty
	… of the specimen-material.
	C04-R091.20.20	2.7.1.10	SET<PQ>	{1}
	Wednesday, October 13, 1999	Page 9 of 79

	Collected_specimen_sample.collectors_comment_cd	A
	Coded or free text additional comments related to the collected specimen.  Example: difficult clotting after venipunctue and echymosis.
	mapped	Service.descr
	… of the specimen collection service.  
	
	Remember, in event mood the description is the description of what actually happened in the service, including (and foremost!) unusual 
	noteworthy things.
	C04-R091.01.14	2.2.1.4	ED
	Collected_specimen_sample.danger_cd	A
	Code and/or text indicating any known or suspected specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient.
	
	clearly mapped	Material.danger_cd
	C04-R091.20.19	2.7.1.9	CD
	Collected_specimen_sample.handling_cd	A
	A code indicating the action taken after collection of the sample (e.g., air-dried, refrigerated overnight, maintained at body heat, centrifuged 
	immediately, maintained on ice, . . .).
	clearly mapped	Material.handling_cd
	C04-R091.20.18	2.7.1.8	CD
	Collected_specimen_sample.id	A
	Unique identifier of the collected specimen sample.
	clearly mapped	Material.id
	C04-R091.20.11	2.7.1.1	SET<II>
	Collected_specimen_sample.number_of_sample_containers_qty	A
	Identifies the number of containers for a given sample.  For sample receipt verification purposes; may be different from the total number of 
	samples which accompany the order.
	
	OpenIssue:
	mapped	Material.qty
	… of the container-material.  If there are multiple containers one should enumerate all of them rather than just counting their number.  If, 
	however, the content of the containers is completely identical, and if there is no meaningful reason for having two containers (other than just 
	to have more of that specimen,) then, one can use the Material.qty as a number in the class that represents the multiple containers.  Note, the 
	containers are counted, not the (usually amorphic, uncoutable) specimen. Hence the Material instance representing the container is the one 
	whose qty attribute may indicate multiples.
	C04-R091.20.20	2.7.1.10	SET<PQ>	{1}
	Wednesday, October 13, 1999	Page 10 of 79

	Collected_specimen_sample.source_cd	A
	Contains the specimen source name or code.  Even in the case of tests whose name implies the source, a source may be required, e.g., blood
	 culture-heart blood.  Example sources are abscess, blood arterial, blood bag, burn, dose med or substance, ear, filter, gastric fluid, marrow, 
	patient, tissue, urine.
	clearly mapped	Material.type_cd
	… of the specimen-material.
	C04-R091.20.12	2.7.1.2	CD
	Collected_specimen_sample.transport_logistics_cd	A
	The means by which a sample reaches the diagnostic service provider.  This information is to aid the lab in scheduling or interpretation of 
	results.  Coded concepts include:  routine transport van, public postal service.
	mapped	Transportation
	If transportation of specimen (or anything else) is a noteworthy issue (often it is not), then the Transportation service class provides 
	everything needed to order, schedule, document, and bill for that transportation. The generic action management functionality of USAMP are to
	 be used, rather than a non-interoperable  ad-hoc code!
	C04-R091.11.00	2.6.6
	Collected_specimen_sample.type_cd	A
	A code identifying the type of sample collected (e.g., urine, blood, sputum, swab, synovial fluide, ...).
	
	OpenIssue:  committee needs to determine whether this attribute is redundant with Collected_specimen_sample.source_cd.
	
	Rationale:  This is a direct connection between Stakeholder and Collected_specimen_sample because there is no persistent role of "Specimen 
	collector" that a stakeholder can have.  There is no need to resolve a M:M.  There is no need to know effective dates for the stakeholder 
	collecting the specimen, beyond the actual collection dates themselves, which are attributes of the specimen.
	clearly mapped	Material.type_cd
	… of the specimen-material.
	
	Note that RIM092's specimen "source" and "type" were redundant indeed.
	C04-R091.20.12	2.7.1.2	CD
	Condition_node
	Condition_node	C
	A Condition_node is used to document the action of associating one or more Service_events through one or more 
	Service_event_relationships to a Condition.  As such, a Condition_node is used to document and name a judgment (e.g., clinical, 
	administrative, financial) as to the semantics of the association(s) between instances of service_events and the associated condition.  Over 
	time, multiple Condition_nodes and their associated Service_events and Service_event relationships form a network which represents a 
	judgment as to the existence, form, evolution, life-cycle, and/or priority of a condition.  This network is named by an instance of Condition.
	
	Examples OF CONDITIONS:
	Chromosomal anomaly, e.g. sickle cell--begins at conception, lasts for lifetime;
	Pregnancy - specific beginning and end, even if not identified until condition has existed for a period of time.
	
	OpenIssue:  Where do all these use cases belong?   Do we need them to make these definitions clear?  Definition needs further work.
	clearly mapped	Condition_node
	C04-R091.10.00	2.6.4
	Wednesday, October 13, 1999	Page 11 of 79

	Condition_node.life_cycle_start_dttm	A
	Indicates the beginning date/time of the current status as indicated in condition_node.lifecycle_status_cd.
	
	OpenIssue:  Description needs to be clearer.
	
	OpenIssue:  Should this be an interval.
	mapped	Service.status_cd
	The status code can be sent as a history item or a history list of status codes with a time range associated to either the most recent status or 
	more (all) statuses.  That way one can send time stamp information for the entire life-cycle, not just for the most recent status.  Also, that way
	 one can get rid of slotted time stamps whose primary purpose is to communicate status information.
	C04-R091.01.15	2.2.1.5	CV
	Condition_node.lifecycle_status_cd	A
	Indicates the current status of the condition.  eg. Active First, Active Baseline, Active Exacerbated, Inactive,
	
	OpenIssue:
	clearly mapped	Service.status_cd
	C04-R091.01.15	2.2.1.5	CV
	Condition_node.management_discipline_cd	A
	The categories of caregivers with interest in having this specific condition on their condition/problem list.  Examples include nursing, medicine, 
	respiratory therapy, dietary, etc.  The codelist for this should be consistent with the vocabulary list for individual healthcare practitioner type 
	code.

	Rationale:  2.3 definition was wrong.
	
	OpenIssue:  Has to be multiple, and how can we indicate when a particular category initiates or withdraws their indicated interest.
	
	OpenIssue:  Consider removing rationale.
	mapped	List_item
	A problem list is represented by a stakeholder owned Service list.  In inpatient and care team settings, that list will be owned by a team or 
	group (at this point an Organization stakeholder.)  Rather than a non-interoperable code, we use a direct relationship to the owner (group).
	C04-R091.31.00
	Condition_node.ranking_nbr	A
	A  number that allows a relative ranking of conditions on an ordered list.
	
	OpenIssue: Formalize use cases for this attribute.
	mapped	List_item.sequence_nmb
	A problem list is represented by a stakeholder owned Service list.  In inpatient and care team settings, that list will be owned by a team or 
	group (at this point an Organization stakeholder.)  Ranking is identified through the sequence number in the list
	C04-R091.31.11	2.9.2.1	REAL	1
	Conditional_link
	Wednesday, October 13, 1999	Page 12 of 79

	Conditional_link	C
	The link that exists between a current service event or source service event and a previous or target service event which defines a 
	predicate between the result or status of the target service event and the instantiation of the source service event, e.g., begin IV (source 
	service event) if Na was <130 (target service event); repeat medication administration (source service event) if > 1h since last medication 
	administration was completed (target service event).
	mapped	Service_relationship
	This has only recently been broken out of service_relationship (by some of the USAMP-II authors) for specific reasons (to teach the model.)  It
	 was always understood, that this particular action would yield to whatever the USAM-II would propose.
	C04-R091.02.00	2.4
	Consent
	Consent	C
	A subclass of Service_event that records the collection of consent signatures.
	
	Rationale:  Healthcare requires consents to be collected from various parties prior to some services.  This class allows recording of that 
	action.
	
	clearly mapped	Consent
	C04-R091.12.00	2.6.5
	Service_event :: generalizes(1..1) :: Consent :: specializes(1..1)	RGD
	clearly mapped	Consent is specialization of Service
	C04-R091.12.01
	Coverage_item
	Master_service :: is_covered_by(0..n) :: Coverage_item :: provides_coverage_for(1..n)	RAD
	mapped	Service :: is_covered_by(0..*) :: Coverage_item :: provides_coverage_for(1..*)
	C04-R091.01.06
	Dietary_intent_or_order
	Dietary_intent_or_order	C
	An authoritative direction or instruction concerning the system or course of diet for a patient.
	clearly mapped	Diet
	With mood_cd being "intent" or "order".
	C04-R091.09.00	2.6.8
	Wednesday, October 13, 1999	Page 13 of 79

	Dietary_intent_or_order.diet_type_cd	A
	A code identifying a special diet type for a patient.
	clearly mapped	Service.type_cd
	since a Die(ary service)t is a Service.
	C04-R091.01.13	2.2.1.3	CD
	Dietary_intent_or_order.instruction_desc	A
	This field defines the specific instructions for dietary.  These instructions may address specific patient needs, such as isolation, or contain 
	special instructions associated with a tray (e.g., "plastic silverware").  This field provides the ordering provider's dietary instructions as free 
	text.  It can represent the full dietary instruction or indicate supplemental information.
	mapped	Service.descr
	Note that logically the description in an order is an instruction!  (What else would one describe in an order?)
	C04-R091.01.14	2.2.1.4	ED
	Dietary_intent_or_order.service_period_cd	A
	A code identifying the service period for a diet order.  This field allows you to order a modification for one or more of the service periods 
	during a day.  Suggested service periods are:  Breakfast, mid-morning snack, lunch, mid-afternoon snack, dinner, bedtime snack.
	mapped with issues	Service.type_cd
	The time of serving and the food that is servced often depend on each other. E.g., a breakfast is a distinguished (though broad) class of 
	meals served in the morning.  Snack is a category of foods (e.g., yoghourt, crackers, etc.)  The time of serving should be specified in the 
	Service.critical_time attribute as a quantitative time or a "symbolic" time (e.g., HS for before the hour of sleep.)
	
	Why should there be an attribute that merges the two different dimensions of timing and food type into one non-interoperable code?
	C04-R091.01.13	2.2.1.3	CD
	Dietary_intent_or_order.tray_type_cd	A
	A code for the type of dietary tray.  Tray specifications are useful for early and late tray delivery in cases where a patient undergoes a 
	procedure during normal feeding times. Tray specifications can also be used for guest trays, no trays, and messages.  A tray message does 
	not specify the type of tray but provides additional information about an existing tray in the text instructions.  Allowed types are:  Early Tray, 
	Late Tray, Guest Tray, No Tray, Tray Message Only.
	mapped with issues	Material_relationship
	A tray is for food what a container is for specimen.  Thus, a tray is an associated material that holds the food.  May be a container.  Tray is 
	not currently modeled as a special role class.
	
	Note that the v2.3 definition of the Tray issues is very unclear.  This issue needs input from people interested and knowledgeable in diet 
	services.  From the v2.3 definition (that RIM092 recites here) it almost vaguely sounds as if the tray specification would be more about timing 
	or exceptional handling of the diet rather than about some kind of tray material.
	C04-R091.21.00	2.7.2
	Service_intent_or_order :: generalizes(1..1) :: Dietary_intent_or_order :: specializes(1..1)	RGD
	mapped	Diet is specialization of Supply
	… with Supply being a specialization of Service.
	C04-R091.09.01
	Durable_medical_equipment
	Wednesday, October 13, 1999	Page 14 of 79

	Durable_medical_equipment	C
	A tangible material item used to perform a Healthcare Service.
	mapped	Device
	C04-R091.27.00	2.8.4
	Durable_medical_equipment :: belongs_to(0..n) :: Durable_medical_equipment_group :: contains(1..n)	RAS
	mapped	Material_relationship
	A group of equipment is an equipment that contains parts.  The whole-part type of material relationship is used.  A specific material 
	relationship type may be defined if it is felt that grouping (group-member) and composing (whole-part) are different concepts to be 
	C04-R091.21.00	2.7.2
	Durable_medical_equipment.id	A
	A unique identifier for a specific piece of equipment.
	mapped	Material.id
	Note that an equipment group is a kind of composite material.
	C04-R091.20.11	2.7.1.1	SET<II>
	Durable_medical_equipment.slot_size_increment_qty	A
	Duration for a single schedulable unit in a schedule for a resource.
	
	Rationale: Provides visibility into scheduling details.
	clearly mapped	Device.slot_size_increment_qty
	For future consideration: this may be generalizeable into an attribute Material.increment_qty so as to specify what the smallest quantum is.  
	Material.qty itself is not strongly defined as the increment.
	C04-R091.27.12	~ 1 min
	Durable_medical_equipment.type_cd	A
	Identifies what kind of equipment the particular instance is.
	
	OpenIssue:
	clearly mapped	Material.id
	C04-R091.20.11	2.7.1.1	SET<II>
	Durable_medical_equipment_group
	Wednesday, October 13, 1999	Page 15 of 79

	Durable_medical_equipment_group	C
	A pool of like-type equipment available for scheduling purposes.
	
	Rationale: Currently in 2.3
	
	OpenIssue:  There are probably two concepts to be included in scheduling, both of which are vying for attention here.  The first is the ability to
	 establish a pool.  Give me one ventilator, but I do not care which one.  That is covered by the current definition.  The other is the ability to 
	aggregate resources and schedule them as a group or a team.  Schedule a surgical team or request a set of equipment needed for a 
	particular procedure.  This latter grouping is not represented in these classes.
	mapped	Material
	C04-R091.20.00	2.7
	Durable_medical_equipment_group.id	A
	Unique identifier for the group
	clearly mapped	Material.id
	C04-R091.20.11	2.7.1.1	SET<II>
	Durable_medical_equipment_request
	Durable_medical_equipment_request	C
	Request information about equipment that is controlled by a schedule
	
	Rationale: Specializes the request by type of resource
	
	OpenIssue:
	mapped	Service
	A resource is requested as because it is needed for a service.  Resource utilization of Services is uniformly modeled as a Target association 
	between Service and Material (in this case.)  The Service mood code used for scheduling requests is SCH.
	C04-R091.01.00	2.2
	Durable_medical_equipment_request :: requests(0..1) :: Durable_medical_equipment_group :: is_requested_by(0..n)	RAS
	mapped	Target
	… of a Service in scheduling request (SCH) mood. Target is of type "reuseable device".
	C04-R091.04.00	2.3.2
	Durable_medical_equipment_request :: requests(1..1) :: Durable_medical_equipment :: is_requested_by(0..n)	RAS
	mapped	Target
	… of a Service in scheduling request (SCH) mood. Target is of type "reuseable device".
	C04-R091.04.00	2.3.2
	Wednesday, October 13, 1999	Page 16 of 79

	Durable_medical_equipment_request.quantity_amt	A
	The quantity of the specified resource or resource type.
	
	Rationale: Currently in 2.3
	
	OpenIssue: The name quantity_amt is not communicating the meaning of the attribute.
	
	OpenIssue:  We would like better (more explanatory) names for attributes that are meaningful by themselves.
	clearly mapped	Material.qty
	C04-R091.20.20	2.7.1.10	SET<PQ>	{1}
	Durable_medical_equipment_request.type_cd	A
	Identifies what type of equipment or equipment group is being requested in this instance of request.
	mapped	Target
	… of a Service in scheduling request (SCH) mood. Target is of type "reuseable device".
	
	Note that this code in RIM092 appears to be redundant given the association between Durable_medical_equipment and D.m.e.request?
	C04-R091.04.00	2.3.2
	Durable_medical_equipment_slot
	Durable_medical_equipment_slot	C
	An allocation of time defined when a specific piece of medical equipment is available for use for a healthcare service.
	mapped with issues	List_item
	on a Service_list of type "schedule" which :: is_about(1..1) :: Material.
	
	The only issue (that is easyly resolved) is that the List_item does not have a Service bound to it in an open slot, and we may want a code in 
	the List_item indicating the slot status … a List_item.status_cd!
	C04-R091.31.00
	Durable_medical_equipment_slot :: is_scheduleable_unit_for(1..1) :: Durable_medical_equipment :: 	RAS
	Association links an item of medical equipment to the calendar slots in which it is scheduled.  A slot gives the starting date-time, and the length 
	of time the item is scheduled for.
	mapped	Service_list :: is_about(0..1) :: Material :: is_subject_of(0..*)
	C04-R091.30.04
	Resource_slot :: generalizes(1..1) :: Durable_medical_equipment_slot :: specializes(1..1)	RGD
	mapped	List_item
	on a Service_list of type schedule.
	C04-R091.31.00
	Episode_of_condition
	Wednesday, October 13, 1999	Page 17 of 79

	Condition_node :: defines_episode(0..1) :: Episode_of_condition :: links_condition(1..1)	RAD
	This association binds an episode to a Condition, whose root node is the associated condition node.
	
	Rationale:  Association to Encounter is determined by association through service_event.condition_node.
	clearly mapped	Condition_node :: defines(0..1) :: Episode_of_condition :: is_defined_by(1..1)
	C04-R091.10.02
	Goal
	Assessment :: generalizes(1..1) :: Goal :: specializes(1..1)	RGD
	mapped	Observation is specialization of Service
	Remember that "goal" is a mood of an Observation!
	C04-R091.05.01
	Goal	C
	This class represents the setting or modification of a goal.  Setting a goal includes a statement that a hoped-for observation value, value 
	range, or observation pattern will be the result of a particular observation on a specific date/time in the future. Specifically, goal setting is 
	made up of the following three components:  the value or value set, the target date, and the named observation that measures progress 
	towards the goal.

	Rationale:  For Goal is specialization of Assessment- this class captures the hope to meet a specific goal by a specific date.  Note that the 
	measurement of the gap between the "real observation" and the hope is itself a metaobservation and is captured under 
	Calculated_observation.  Also note that the measurement of the "real observation" is captured as well under Target_observation.
	
	OpenIssue:  Need to have vocabulary define a service name and value set for service_event.clinical_observation which covers "goal-gap 
	determination: A code depicting the progress towards achievement of the goal (e.g., achieved, ahead of schedule, delayed, ...)
	mapped	Observation
	in mood_cd = "goal".
	C04-R091.05.00	2.6.1
	Goal :: is_measured_by(1..1) :: Master_observation_service :: measures(1..n)	RAS
	The connection to the observation method that is needed to measure progress towards the goal, e.g., WBC for a WBC goal of 10,000; 
	ambulation assessment for an ambulation goal of 20 feet.
	
	Rationale:  Goal_set definition includes three needed elements:  date in the future, name of the observation method and hoped for observation 
	value.
	mapped	Service_relationship
	of type instantiates.  An observation in goal mood instantiates a master observation into goal mood, just as an observation in event mood 
	instantiates a master observation into event mood.
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 18 of 79

	Goal.expected_achievement_dttm	A
	Date goal is expected to be achieved
	
	Rationale: Conformance with v 2.3
	
	OpenIssue:
	clearly mapped	Service.critical_time
	same considerations as for Observation critical time.  The Observation critical time never catches the exact time of onset of the observed 
	physiolosgical state, but is merely a point within the interval for which the physiological state may be asserted as true (given some tolerance.)
	C04-R091.01.17	2.2.1.7	GTS
	Goal.goal_list_priority_nbr	A
	A number that allows a relative ranking of goals on an ordered list.
	mapped	List_item.priority_nmb
	A goal list is, like a problem list, a kind of Stakeholder owned Service_list.
	C04-R091.31.12	2.9.2.2	REAL
	Goal.goal_value_cd	A
	Value of goal-setting action which may be coded, numeric, or a range, e.g. "20 feet" for an ambulation goal; "successful" for a speech goal.
	
	Rationale:  Vocabulary reference
	
	OpenIssue:  See class definition requires complex datatype for value of goal_set.  Cd is not sufficient since the value of a goal may be a code 
	or may be numeric or a range.  This is a candidate for that funky "any" datatype.  Attribute name needs to be updated once MnM and CQ 
	resolve the "any" datatype issue.
	clearly mapped	Observation.value
	… of Observation in goal mood
	C04-R091.05.11	2.6.1.1	ANY
	Goal.management_discipline_cd	A
	A code indicating the caregiver disciplines responsible for managing a patient pathway goal.
	
	OpenIssue:  Definition not clear; not evaluated since USAM.
	
	OpenIssue:  Since this is a coded data type, it needs example codes.
	mapped	Actor
	… associated to the goal class.  Typically the Actor is a care team (an "Organization").  The actor who sets the goal takes on responsibility for
	 tracking it. 
	
	In addition, goals may live on different Stakeholder's Service_lists (of type "goal list", or more generally "issues" list.)
	
	Discipline_cd (just as the service_section code) is no longer a (non-interoperable) code but an explicit association to a stakeholder!
	C04-R091.03.00	2.3.1
	Wednesday, October 13, 1999	Page 19 of 79

	Goal.review_interval_cd	A
	A code indication the review interval for the patient pathway goal.
	
	OpenIssue:  Definition not clear; not evaluated since USAM.
	
	OpenIssue:  Since this is a coded data type, it needs example codes.
	mapped	Service.critical_time
	… of a service intent associated with a goal throug the Service_relationship of type "evaluates". Note that the review schedule is a service 
	intent, not the goal by itself.  These intents can then be instantiated into events, or ordered to somebody else.
	C04-R091.01.17	2.2.1.7	GTS
	Judgement_link
	Judgement_link	C
	The link that exists between a current service event or source service event and a previous or target service event which defines a semantic
	 relationship of another nature (besides set membership or predicate relationship) joining the two instances of service event (e.g., 
	"supportedBy;" "hasReason;" "pertainsTo;" "namedBy").  For example, "The diagnosis of Lupus is supported by the previous observations of 
	fever, butterfly rash and increased sed rate."
	mapped	Service_relationship
	This has only recently been broken out of service_relationship (by some of the USAMP-II authors) for specific reasons (to teach the model.)  It
	 was always understood, that this particular action would yield to whatever the USAM-II would propose.
	C04-R091.02.00	2.4
	Judgement_link.type_cd	A
	Used to document the nature of the relationship of a current service event to a previous service event(s) that carries a semantic other than 
	membership in a set or membership in a guidelines, e.g. subsumes, is support by, supports, etc.
	clearly mapped	Service_relationship.type_cd
	C04-R091.02.11	2.4.1.1	CV
	Master_numeric_range
	Wednesday, October 13, 1999	Page 20 of 79

	Master_numeric_range	C
	Predefined reference values to which results of quantitative observation services may be compared.  Values are identified for categories of 
	subjects according to age, sex, race, and other conditions.  Ranges include normal (reference), critical, and absolute.
	mapped	Observation
	… in reference mood. 
	
	Reference ranges are a short hand representation of a frequency distribution of a measured value over a population.  Usually the “normal” 
	healthy human is used as the reference population, but sometimes values are distributed differently in different populations, so that the 
	population on which reference ranges are based must be identified.  This used to be done in HL7 v2.3 in special fields or components using 
	special codes and conventions.  In USAMP we represent all population characteristics as observations.
	
	For example, if we want to specify reference ranges for Aldosterone (a test to help monitor hypertension) we have to distinguish different 
	age goups.  The USAMP specification, Figure 11, shows how Aldosterone normal values for age groups 1–10 years and 10–12 years are 
	specified.  It also shows how the applicable reference range is connected to a particular observation report.
	
	Figure 11's text sais:
	
	Reference ranges are frequency distributions of observations among populations.  The reference ranges (mood: REF) are associated with 
	the master observation (upper left, mood: DEF) through reference links. The reference value is usually an interval of physical quantity 
	(low–high) or, with nominal observations, a set of value codes.  If a reference range has no criterion, it is the typical “normal” range, based on
	 the not further specified healthy population.  If criteria are associated with the reference, the criteria can be any observation (mood: 
	EVN+CRT), but sex and age are the most common reference range criteria.  An actual observation (upper right, mood: EVN) may be linked 
	with the applicable reference range in order to specify which range has been applied to determine the interpretation (abnormal) flag “H” on the
	 service report.
	C04-R091.05.00	2.6.1
	Master_numeric_range :: applies_to(1..1) :: Master_quantitative_observation :: conforms_to(0..n)	RAS
	mapped	Service_relationship
	with relationship type being "has reference value" linking to a Servcie in reference mood.
	C04-R091.02.00	2.4
	Master_numeric_range.age_qty	A
	This attribute contains the age range, usually in years or fractions thereof, for which the value range is valid.  Ages of less than one should 
	be specified as a fraction (e.g., 1 month - 0.0830 year, 1 week = 0.01920 year, 1 day = 0.0027300 year).  However, for most purposes 
	involving infants, the gestational age (usually measured in weeks) is preferred.  Often only the upper end of the range is included to assure 
	that series or age ranges do not overlap.
	
	OpenIssue:
	mapped	Observation.value
	… of an observation in criterion mood, of type "AGE", associated as the target of a "has_precondition" relationship with an observation in 
	reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.
	
	It does require, though, that age be recognized as a clinical observation (independent from any administrative date of birth).  This is logically 
	correct and technically straight forward to implement.
	C04-R091.05.11	2.6.1.1	ANY
	Wednesday, October 13, 1999	Page 21 of 79

	Master_numeric_range.condition_desc	A
	This attribute allows for definition of ranges based on any arbitrary condition, e.g., phase of menstrual cycle or dose of a particular drug.  It is 
	provided as a way to communicate the benchmarks for special conditions.  It does not allow automatic checking of these text conditions.
	mapped	Observation.value
	… of an observation (of any type) in criterion mood", associated as the target of a "has_precondition" relationship with an observation in 
	reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.
	
	Note that the criterion appears in a very similar form as would appear actual observations, which makes this strategy technically easier to 
	handle than did the separate code. Note also that this gets rid of one more "free floating" code attribute.  Coded attributes are significant 
	pitfalls for introperability, reducing free standing codes to a minimum is part of the intention of USAMP-II.
	C04-R091.05.11	2.6.1.1	ANY
	Master_numeric_range.gestation_age_qty	A
	This attribute contains the gestational age (time from conception) for which the range is valid.  It is relevant only when the range is influenced 
	by the stage of pregnancy.  A range of values is required.  The gestational age is generally measured in weeks from conception.  Often only 
	the upper end of the range is included to assure that series of age ranges do not overlap.
	
	Rationale:  
	
	OpenIssue:
	mapped	Observation.value
	… of an observation in criterion mood, of type "GESTATIONAL AGE", associated as the target of a "has_precondition" relationship with an 
	observation in reference mood (containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges 
	and their use.
	C04-R091.05.11	2.6.1.1	ANY
	Master_numeric_range.race_subspecies_txt	A
	Specifies the race or subspecies for which the range is valid.  In the case of humans (the default), the race is specified when race influences
	 the range.  When ranges for animals are being described, this attribute can be used to describe subspecies or special breeds of animals.
	
	OpenIssue:
	mapped	Observation.value
	… see aforememntioned attributes.
	C04-R091.05.11	2.6.1.1	ANY
	Master_numeric_range.species_txt	A
	This attribute specifies the species for which the range is valid.  It is assumed to be human unless otherwise stated.  The species should be 
	represented as text.
	
	OpenIssue:
	mapped	Observation.value
	… see aforementioned attributes.
	C04-R091.05.11	2.6.1.1	ANY
	Master_numeric_range.type_cd	A
	Specifies the type of numeric range.  Types allowed are reference range, critical range, or absolute range.
	
	mapped	Service.type_cd
	… of an observation in criterion mood, associated as the target of a "has_precondition" relationship with an observation in reference mood 
	(containing the reference value range.)  This mapping reflects precisely the semantics of reference ranges and their use.
	C04-R091.01.13	2.2.1.3	CD
	Wednesday, October 13, 1999	Page 22 of 79

	Master_numeric_range.value_qty	A
	This attribute contains the high and low limits of the reference range.  The range is taken to be inclusive (i.e., the range includes the end 
	points).  
	
	When the reference range applies to the amount of a toxic substance, then the upper limit of the range identifies the toxic limit.  If the range 
	applies to  a drug, the lower limits identify the lower therapeutic bounds and the upper limits represent the upper therapeutic bounds above 
	which toxic side effects are common.
	
	OpenIssue:
	mapped	Observation.value
	… of an observation in reference mood.
	C04-R091.05.11	2.6.1.1	ANY
	Master_observation_service
	Master_observation_service	C
	A type of master service specific to observation services.
	mapped	Service
	… in definition mood.
	C04-R091.01.00	2.2
	Master_observation_service :: has(0..n) :: Master_specimen_requirement :: is_specified_for(1..1)	RAS
	Rationale:  Rarely can precisely the same set of specifications apply to specimens for two or more master services, and there is no business 
	case for tracking generic specimen specifications, separate from the services for which they are to be collected.   In the rare event when 
	specimen requirements for different master services coincide, each service will have separate, identical master_specimen_requirement 
	instances related to it.
	mapped	Target
	… of type specimen of a Service in definition mood.
	
	It has been asked (Jane Curry) whether we'll see mood codes for Material, distinguishing whether it's a potential or actual material, etc. Most 
	human languages do not distingusish moods of substantives, but only moods of verbs.  This is an indication for an underlying logic:  In 
	mentioning a material, we do not say anything about its existence. For example, if I say "Napoleon" I refer to an idea of a substance that may 
	or may not exist or have exited.  Only if I say "Napoleon lived in the early 19th century" or
	"I am Napoleon", or something like that, only then do we have knowledge about the mood of existence of Napoleon.
	C04-R091.04.00	2.3.2
	Master_observation_service :: has_as_basis(0..n) :: Master_observation_service :: is_basis_for(0..n)	RAD
	mapped	Service_relationship
	… since RIM092 does not say what this association is used for, we can not determine a relationship type code for it.  But we know that it 
	would be a relationship between two Services in definition mood, and that whatever semantics is intended with this association, we can map 
	onto existing concepts, or define a new concept in the service relationship type code.
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 23 of 79

	Master_observation_service.derivation_rule_desc	A
	This field is used when there are patient variables that are derived from one or more other patient variables (e.g., creatinine clearance, ideal 
	weight, maximum daily temperature, average glucse, framingham risk).  This field contains the rules for deriving the value of this variable.  
	These can be described in terms of humanly understandable formulas or descriptions.  When possible, however, they should be defined in 
	terms of the Arden Syntax for specifying selection and transcendative functions and algebraic operations, ASTM E1460-92.  Derivation rules 
	that are represented in Arden Syntax should be identified by the universal service identifier.  We recommend the use of the Arden Syntax 
	because it permits the unambiguous specification of most such derived values and is a published standard for medical logic modules.
	mapped	Observation.derivation_expr
	C04-R091.05.12	2.6.1.2	ST
	Master_observation_service.instrument_cd	A
	This field identifies the instrument or device that is used to generate this observation or battery;.  Examples are the automated instrument in the
	 laboratory, the imaging device and model number in  radiology, and the automatic blood pressure machine on the ward.
	
	Rationale:  This attribute stands in for a relationship to an "instrument_type" class, which does not currently exist in the RIM.
	mapped with issues	Target
	… of type device to Material.  The instrument code of RIM092 is an ambiguous concept: does it mean the kind of instrument or the instance of 
	an instrument?  Kind would be Material.type_cd and instance would be Material.id.
	
	Another free floating code is gone!
	C04-R091.04.00	2.3.2
	Master_observation_service.permitted_data_type_cd	A
	This field contains the allowed HL7 data type(s) for this observation.  A given observation may, under different circumstances, take on 
	different data types.  Some HL7 data types are not valid for any observations.  Consult the domain specification for the full list of data types 
	which are allowed to represent observation values.
	mapped	Observation.value
	The ANY type consists of a type tag and a value. No need to communicate the data type out of band.
	C04-R091.05.11	2.6.1.1	ANY
	Master_observation_service.processing_time_qty	A
	The usual length of time (generally in minutes) between the start of a test process and its completion.
	mapped	Service.total_time
	The width of an occurrence interval may still be specified even though the start and end are unknown.
	C04-R091.01.16	2.2.1.6	GTS
	Master_observation_service.typical_turnaround_time_qty	A
	The typical processing time for a single test/observation.  This field indicates the time from the delivery of a specimen or transport or a patient 
	to a diagnostic service and the completion of the study.  It includes the usual waiting time.  The units are generally measure in minutes.
	mapped	Service.total_time
	as the width of an interval of time.  This is the attribute of a super-service that includes transportation and everything that is required for the 
	support of a linical service.  See USAMP specification for discussion of this.
	
	As it stands, the RIM092 definition is not interoperable, since noone knows what really is included in this "turn around time".  So, site 
	negociation (or ideosyncratic assumptions) will have to take default.  The USAMP approach appears more complex, but it is much clearer.
	
	Open Issue: We don't have a good handle on waiting time yet, neither in RIM092 nor in USAMP. It is a very important concept in 
	customer-oriented service rendering, which will become an issue in health care if it isn't already.
	C04-R091.01.16	2.2.1.6	GTS
	Wednesday, October 13, 1999	Page 24 of 79

	Master_service :: generalizes(1..1) :: Master_observation_service :: specializes(1..1)	RGD
	clearly mapped	Observation is specialization of Service
	C04-R091.05.01
	Master_patient_service_location
	Master_patient_service_location	C
	A place where patient services are delivered.
	untouched	Master_patient_service_location :: is_a_role_of(1..1) :: Material :: takes_on_role(0..1)
	… but we associate it as a role of material, at this point without resolving the attributes (?)
	C04-R091.29.01	2.8.6
	Master_patient_service_location :: belongs_to(0..n) :: Patient_service_location_group :: contains(1..n)	RAS
	mapped	Material_relationship
	of type "has parts" linking the location group with the location.  Note that this vocabulary must distinguish between the locations contained in 
	each other (like room in building) vs. the locations grouped rather arbitrarily.
	C04-R091.21.00	2.7.2
	Master_patient_service_location :: includes(0..n) :: Master_patient_service_location :: is_included_in(0..1)	RAS
	mapped	Material_relationship
	… of type "has parts" linking the super-location with the sub-location.  Note that this vocabulary must distinguish between the locations 
	contained in each other (like room in building) vs. the locations grouped rather arbitrarily.
	C04-R091.21.00	2.7.2
	Master_patient_service_location :: is_entry_location_for(0..n) :: Service_intent_or_order :: is_entered_at(1..1)	RAS
	Rationale: 
	
	OpenIssue:
	mapped	Target
	… of type "entry location" … if this is really needed.  The use case of this "order entry location" is quite questionable.
	C04-R091.04.00	2.3.2
	Master_patient_service_location :: is_requested_by(0..n) :: Patient_service_location_request :: requests(1..1)	RAS
	mapped	Service
	C04-R091.01.00	2.2
	Wednesday, October 13, 1999	Page 25 of 79

	Master_patient_service_location.desc	A
	A description of the location to facilitate recognizing it and its characteristics.
	
	Rationale: 
	
	OpenIssue:
	mapped	Material.descr
	C04-R091.20.14	2.7.1.4	ED
	Master_patient_service_location.equipment_type_cd	A
	For room or bed locations, identifies what types of eqipment are built in, e.g., telemetry equipment.
	
	Rationale:  Currently in 2.3 as LOC-8-Location Equipment.
	
	OpenIssue:  Note that this is just a placeholder for a 2.3 item and needs more work with internationalization and Inter-Enterprise.
	mapped	Material_relationship
	Material that is "is present at" the location is linked through the material relationship of respective relationship type.  In USAM all material is 
	consistently referred to as instances of the class Material.  Conversely in RIM092 material was coded in various un-coordinated attributes: as 
	instrument_cd, as equipment_cd, etc.  The USAMP-II improves interoperability by reducing the amount of coded attributes that need 
	coordination!
	C04-R091.21.00	2.7.2
	Master_patient_service_location.id	A
	A unique identifier of a patient care location.
	clearly mapped	Material.id
	C04-R091.20.11	2.7.1.1	SET<II>
	Master_patient_service_location.nm	A
	The name by which the service location is known.
	mapped with issues	Material.id
	Names of instances are identifiers (though not always unique.)  The SET<II> data type assignment for all .id attributes allows for multiple 
	names, and attaches prefixes to the id that makes the id unique.
	
	The issue of location names is not free of complexity, but neither RIM092 nor USAMP has yet taken on the task to work through the issues of 
	location names.
	C04-R091.20.11	2.7.1.1	SET<II>
	Master_patient_service_location.type_cd	A
	A code indicating the type of patient care location (e.g., hospital, clinic, hospital ward, room, bed, . . .).
	mapped	Material.type_cd
	C04-R091.20.12	2.7.1.2	CD
	Wednesday, October 13, 1999	Page 26 of 79

	Patient_service_location_slot :: is_scheduleable_unit_for(1..1) :: Master_patient_service_location :: 	RAD
	mapped	List_item
	… as :: part_of(1..1) :: Service_list :: is_about(1) :: *Location :: is_a_role_of(1..1) :: Material.  The Service_list.type_cd is "schedule".  Booked 
	slots are represented by List_items associated with a Service.  Available items are everything not booked.
	
	Blocked slots could be represented as List_items not bound to a service. List item would need a time stamp for this.  A List_item status_cd 
	could indicate whether a slot is booked or just held reserved for a service.
	C04-R091.31.00
	Master_qualitative_observation
	Master_qualitative_observation.abnormal_result_cd	A
	A list of the text answers that are abnormal for the test.
	
	Rationale: Clarity, or better representation of V2.3 element name
	mapped with issues	Observation.value
	… of an observation in reference mood.  The set of normal result codes resides in a instance of the SET<CD> data type assigned to the 
	Observation.value.  For normal ranges, the Observation.interpretation_cd must be N - normal.  The abnormal results are derived as the set 
	difference between the set of possible codes and the set of normal codes.  The set of possible result codes is found right in the 
	Observation.value of the observation definition (master.) Thus, the set of abnormal results is:
	
	observation-definition.value - normal-reference.value
	
	it needs not be communicated explicitly.
	C04-R091.05.11	2.6.1.1	ANY
	Master_qualitative_observation.critical_result_cd	A
	A list of coded results that are critically abnormal for this observation.
	
	Rationale: Clarity, or better representation of V2.3 element name
	mapped with issues	Observation.value
	… of an observation in reference mood.  The set of critical result codes resides in a instance of the SET<CD> data type assigned to the 
	Observation.value. Where the Observation.interpretation_cd must be AA - abnormal alert.
	
	Note that critical ranges are really alert triggers.  If there is any specific action that should be taken upon a critically abnormal result, this 
	should be represented as an alert trigger that reminds the physician of a "recommended" service.
	C04-R091.05.11	2.6.1.1	ANY
	Master_qualitative_observation.normal_result_cd	A
	Normal text/codes for categorical observation.
	
	Rationale: Clarity, or better representation of V2.3 element name
	mapped	Observation.value
	… of an observation in reference mood.  The set of normal result codes resides in a instance of the SET<CD> data type assigned to the 
	Observation.value.  For normal ranges, the Observation.interpretation_cd must be N - normal.
	C04-R091.05.11	2.6.1.1	ANY
	Wednesday, October 13, 1999	Page 27 of 79

	Master_qualitative_observation.preferred_coding_system_cd	A
	Preferred coding system for observations whose categorical responses are taken from a specified table of codes.
	mapped	Observation.value
	When the observation value of a singleton result is of the Concept Descriptor (CD) data type, the Observation.value of a master service 
	definition contains a SET<CD> with all possible result values enumerated.  The coding system used in this enumeration is obviously the 
	preferred coding system.
	C04-R091.05.11	2.6.1.1	ANY
	Master_qualitative_observation.valid_answer_cd	A
	a list of valid coded answers
	
	Rationale: previously unmatched V2.3 field
	
	OpenIssue:
	mapped	Observation.value
	… of the Observation in definition mood (the master observation.)  This value is usually of data type SET<CD>, where the set enumerates all 
	the valid answers, just like the RIM095 attribute does.
	C04-R091.05.11	2.6.1.1	ANY
	Master_quantitative_observation
	Master_quantitative_observation.display_length_and_decimal_precision_cd	A
	Specifies the total length in characters of the field needed to display the observation, and the number of digits displayed to the right of the 
	decimal point.  This is coded as a single number in the format <length><decimal-digits>.  For example, a values of 6.2 implies 6 characters total 
	(including the sign and decimal poiont) with 2 digits after the decimal point.  For integer values, the period and <decimal-digits> portion may be 
	omitted (that is, 5.0 and 5 are equivalent).  More than one such mask may be specified when it is necessary to define multiple display formats 
	that are possible.
	mapped	Observation.value
	The observation.value of a master observation (mood_cd = definition) is an interval of Physical Quantity (IVL<PQ>).  This specifies:
	
	- the range of the value (through the interval)
	- the precision of the values (through the precision of the real numbers representing the boundaries)
	- the physical dimension of the quantity (through the unit)
	- the preferred unit (through the unit)
	
	There is thus no need for a special field with special syntax defining these things.
	C04-R091.05.11	2.6.1.1	ANY
	Master_quantitative_observation.unit_of_measure_cd	A
	The customary unit of measure for a tests/observation that has quantative values 
	
	Rationale:This field is not part of an anount/UOM combination, and is therefore not representable as a component of a quantity data type.
	
	OpenIssue:
	mapped	Observation.value
	The observation.value of a master observation (mood_cd = definition) is an interval of Physical Quantity (IVL<PQ>).  This specifies:
	
	- the range of the value (through the interval)
	- the precision of the values (through the precision of the real numbers representing the boundaries)
	- the physical dimension of the quantity (through the unit)
	- the preferred unit (through the unit)
	
	There is thus no need for a special field for units and conversions any more.
	C04-R091.05.11	2.6.1.1	ANY
	Wednesday, October 13, 1999	Page 28 of 79

	Master_service
	Master_service	C
	An individual test observation, test observation battery or panel, individual medication, diet, or procedure.
	mapped	Service
	with mood_cd = definition (DEF).
	C04-R091.01.00	2.2
	Master_service.allowable_processing_priority_cd	A
	This field contains one or more available priorities for performing the observation or test.  This is the priority that can be specified in the 
	order_qt attribute for a Service_intent_or_order.  When  a specimen is collected for the test, this attribute specifies the priority with which the 
	producer service will process the specimen, produce the observation, and return results.  Allowable processing priorities include stat; as 
	soon as possible; preoperative; routine; timing critical.
	clearly mapped	Service.priority_cd
	of a service in definition mood (master). Remember that the mood code modifies the entire service with all its ttributes in the same logical 
	manner: the priority of a master is the available priorities to choose from, the priority of the order is the priority requested for the service,  the 
	priority of the service event is the priority that was actually used (important because that makes a difference in billing.)
	C04-R091.01.25	2.2.1.15	SET<CV>	{R}
	Master_service.allowable_reporting_priority_cd	A
	The availablle priorities for reporting the test results when the user is asked to specify the reporting priority independent of the processing 
	priority.  Allowable reporting priorities are call back results; rush reporting.
	mapped	Service.priority_cd
	The Service.priority_cd specifies the priority of the service in every respect.  Performing and reporting priorities are very interdependent (e.g.,
	 it is unreasonable to request STAT priority but allow delayed reporting.)  The Service.priority_cd is a SET<CV> and allows to specify values 
	for both processing and reporting priorities.
	C04-R091.01.25	2.2.1.15	SET<CV>	{R}
	Master_service.alternate_id	A
	An alternate unique identifier for the master service.
	
	Rationale: 
	
	OpenIssue: Should this attribute be combined with universal_service_id as a set?  How can we specify that the first in the set is the 
	universal_service_id, but the order doesn't matter among the rest?
	mapped with issues	Service.id
	The RIM092 specification is vague here, given how the phrase "a unique identifier for …" is used elsewhere in the RIM092.  Two options exist:
	
	- alternate instance identifiers: are sent as on element in the Service.id SET<II>
	- alternate type code: is sent as one code translation in the CD value of the Service.type_cd
	C04-R091.01.11	2.2.1.1	SET<II>
	Wednesday, October 13, 1999	Page 29 of 79

	Master_service.alternate_name_use_cd	A
	use for which an alternate service name is created, e.g., long name, short name, name for reports, report subheader.
	
	Rationale: 
	
	OpenIssue:  More sorting out.
	
	OpenIssue:  Need ruling from CQ on whether we will be able to link a name with it's usage in a single data type (e.g., phone numbers with 
	home/office/daytime/evening; alternate service names with primary/report/short).  Otherwise, we need a separate Service_name class.
	mapped with issues	Service.type_cd
	see the discussion for the following mapping of Master_service.alternate_nm
	C04-R091.01.13	2.2.1.3	CD
	Master_service.alternate_nm	A
	An alternate name for the master service.
	
	Rationale: 
	
	OpenIssue:  Need ruling from CQ on whether we will be able to link a name with it's usage in a single data type (e.g., Phone numbers with 
	home/office/daytime/evening; alternate service  names with primary/report/short).  Otherwise, we need a separate Service_name class.
	mapped with issues	Service.type_cd
	A name of a test is basically a symbol for a concept.  It does not matter whether we refer to serum potassium as "sK", "K+", "POTASSIUM", or
	 "2823-3". All of these are symbols for the concept, understood by some convention.  Thus, there is no fundamental difference between name
	 and
	concept code.  All of these names are communicated in one attribute, the Service.type_cd as Code Translations within the Concept Descriptor
	 data type.
	
	Each code translation is from one code system.  There are standard code systems and local code systems, which both can be sent.  The 
	various kinds of names defined in the HL7 v2.3 OM1 thus map to various local codes.  Thus, an institution can define arbitrarily many names, 
	long and short, medium, 5-, 8-, 10-, 16-, 32-, characters in size, some all caps, some mixed caps, some plain US ASCII, some UNICODE, each 
	being used by a different application in different circumstances.  The static categories "long name" and "short name" do not hold any more in 
	today's variety of application systems installed at one site.
	
	Note that as of RIM092 it is no longer possible to have multiple special names, such as a long name and a short name, since there is only one 
	attribute left and the pair alternate_nm_use_cd and alternate_nm would require to be maintained as "parallel lists" to match a name and a 
	"use_code".
	C04-R091.01.13	2.2.1.3	CD
	Master_service.challenge_information_txt	A
	information for classifying observations by the challenge component of the test, if a challenge does speciate the observation, for example, 
	tests that include a glucose challenge.
	
	OpenIssue:
	mapped	Service_relationship
	A challenge (Medication) and a subsequent observation are linked as service plan components under one supe-service.  With USAM's 
	Workflow support, this allows detailled timing and condition information to be supplied in order to interoperably and clearly specify the 
	challenge-test procedure.
	
	If for backwards compatibility we decide that systems may stick to the "free text" manner  of sending this information, it can be done either in 
	the Servcie.descr of the super-service or in associated services that only fill in their descriptions.
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 30 of 79

	Master_service.confidentiality_cd	A
	This field contains the degree to which special confidentiality protection should be applied to the observation.  For example, a tighter control 
	may be applied to an HIV test than to a CBC.  Suggested confidentiality protections include very restricted; usual control; AIDS patient; 
	psychiatric patient; very important person.
	clearly mapped	Service.confidentiality_cd
	C04-R091.01.21	2.2.1.11	SET<CV>
	Master_service.consent_required_cd	A
	A code depicting the type of consent that must be obtained for permission to treat the patient. May not represent consent from the patient.
	
	Identifies whether or not an Informed Consent is required for this service.
	
	OpenIssue:   This should be investigated whether or not it may be more appropriately added as an indicator rather than a code.  And examples
	 are needed if it remains a code.
	mapped	Service_relationship
	linking a master service with a Consent definition.   Different consents in different circumstances can be expressed by attaching criteria to the
	 consent.
	C04-R091.02.00	2.4
	Master_service.contraindication_desc	A
	This field contains the diagnosis or problem for which the service is a contraindiction or of possible danger (e.g., pacemaker, pregnancy, 
	diabetes).  For example, if the service were an intravenous pyelogram, this field would include warnings about the use of contrast media in 
	diabetes.
	
	Most contraindication rules will be transmitted as free text.  In such ases, the contents serve only as information for human reading.  
	However, an alternative for machine readable contraindiction rules also exists.  The rule may be defined formally in the Arden Syntax (ASTM 
	1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on 
	patient information sorted in the computer record.  Contraindication rules that are written in Arden Syntax should begin and end with a double 
	semi-colog (;;), the Arden slot delimiter.
	
	Rationale: 
	
	OpenIssue:  Is there only one contraindication?  Either a set or a dependent class.
	mapped	Service_relationship
	of type "has contraindication" linking any Service (in moods definition, order, intent, event, …) with another Service in criterion mood. The 
	contraindication is usually an Observation, but can be a Procedure too.  The contraindication criterion can be a criterion in the moods definition 
	(to refer to a possible contraindication) or in event mood (to refer to an actually present contraindication.)
	C04-R091.02.00	2.4
	Master_service.desc	A
	A description of the master service.
	
	Rationale: 
	clearly mapped	Service.descr
	C04-R091.01.14	2.2.1.4	ED
	Wednesday, October 13, 1999	Page 31 of 79

	Master_service.effective_tmr	A
	The start and end dates for the interval during which the master service is active in the service catalog.
	mapped with issues	Service.status_cd
	using the history item to attach time stamps or intervals to any status.  Statuses of Services in definition mood include: under-specification --> 
	active --> retired.
	C04-R091.01.15	2.2.1.5	CV
	Master_service.factors_that_may_affect_observation_desc	A
	Text description of the foods, diagnosis, drugs, or other conditions that may influence the interpretation of the observation including 
	information about the direction of the effect, and any recommendation about altering the diet, conditions, or drugs before initiating the test 
	mapped	Service.descr
	C04-R091.01.14	2.2.1.4	ED
	Master_service.imaging_measurement_modality_cd	A
	the modality used to classify the observations, e.g., radiograph, ultrasound, CT scan, NMR, etc.  Especially important for imaging studies.  
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Service.type_cd
	Classifications should be part of terminology systems rather than sent explicitly.  If a system knows what a CAT scan is, it will also be able to 
	categorize this under "advanced radiologic studies" or whatever categorization it deems important.  Such a classifying code is not 
	interoperable and should not be sent this way.
	C04-R091.01.13	2.2.1.3	CD
	Master_service.interpretation_considerations_desc	A
	the clinical information about interpreting test results.  Examples are the conditions (drugs) that may cause false abnormals, and the 
	information about the sensitivity and specificity of the test for diagnoses
	
	Rationale: OM1/Interpretation of Observations and OM1 /Factors that may effect the Observation contain different information, and therefore 
	require different attributes.
	
	OpenIssue:
	mapped	Service.descr
	C04-R091.01.14	2.2.1.4	ED
	Master_service.join_cd	A
	Designates whether two or more succeeding master services, as specified in Master_service_relationship, are to be joined with and-logic or 
	with or-logic.
	clearly mapped	Service_relationship.join_cd
	This attribute was introduced into RIM087 by the USAMP-I.  It was meant to support Workflow specification, but the Workflow specification 
	has never been completed.  USAMP-II has taken this attribute into the Service_relationship class and has defined it completely so it is now the 
	first time that it's useable.  There are no issues of backwards compatibility.
	C04-R091.02.18	2.4.1.8	CV	W
	Wednesday, October 13, 1999	Page 32 of 79

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

	
	OpenIssue:
	clearly mapped	Observation.property_cd
	Note: this attribute (from HL7 v2.3 OM1) was always misplaced, it belongs into Master_observation.
	C04-R091.05.13	2.6.1.3	CV
	Master_service.last_update_dttm	A
	Contains the date and time that the last of any field change was made in the source record corresponding to the service catalog item.
	
	Rationale:
	
	OpenIssue:
	mapped with issues	Service.status_cd
	The timed life-cycle information can be supplied in the using the history item and history lists for the status code.  This is another case of the 
	"slotted time-stamp" issue.
	C04-R091.01.15	2.2.1.5	CV
	Master_service.method_cd	A
	This attribute contains the codes and narative for a method that may be used to produce the observation.  Bibliographic citations may be 
	included in the narrative.  More than one method may be listed for a master service, but only if they produce results that are clinically 
	indistinguishable.
	
	OpenIssue:  Need example values.
	clearly mapped	Service.method_cd
	C04-R091.01.18	2.2.1.8	CD
	Wednesday, October 13, 1999	Page 33 of 79

	Master_service.observation_id_suffix_txt	A
	This attribute applies to the tests or procedures that produce an observation which uses observation ID suffixes following the 
	test/observation ID code.  Suffixes identify the common components of narrative reports.  Each type of narrative report is assigned a 
	universal_service_id.  The actual report components are reported in separate observations, all linked to the universal service for the report.  
	The suffix text for the observation further qualifies the observation as to which component of the narrative report it contains.
	
	If this master service produces a narrative report, this field in the master service lists the allowed suffixes for this report.  All observations 
	containing components of this narrative report must be identified with one of these suffixes.  The applicable three character mnemonics given 
	in ASTM Table 20 (or others appropriate to the application) should be used.  For example, a chest X-ray may use the suffixes IMP, REC, DEV, 
	or others.  Each of the expected suffixes should be listed here.
	
	OpenIssue:  Looks like an implementation requirement in a logical attribute.  Resolvable by a code scheme structure? 
	
	OpenIssue:  The link from a specific service_event to the master_service identifies the "observation_id" for the service being delivered.  The 
	present attribute defines the sub-portions of the results from that master_service which may be reported in separate service events.  Should 
	this information be pre-coordinated in the master_service instead (i.e., an X-ray would become 3+ services)?  Or, should it be moved to the 
	Master_service_relationship, and specified as part of the link between the sub-service and the major service (e.g., impression is a subservice
	 of X-ray, and carries the suffix IMP.  Impression can also be a subservice of another service and have the same or a different suffix for that 
	other service).
	mapped with issues	Service.type_cd
	See discussion in Clinical_observation.universal_service_identifier_suffix_txt (BTW: this is the same concept modeled twice in RIM092 in 
	different places under different names.)
	
	The subsections of reports are better fully precoordinated into the service.type_cd but canstill be sent as modifiers in the type_cd's code 
	phrase structure.  Remember that the u.s.id suffix was a modifier on the type_cd and modifiers is what the Code Phrase data type was 
	C04-R091.01.13	2.2.1.3	CD
	Master_service.orderable_service_ind	A
	An indication that the service is an orderable service.
	clearly mapped	Service.orderable_ind
	C04-R091.01.26	2.2.1.16	BL	true
	Master_service.patient_preparation_desc	A
	A description of special patient preparation, diet, or medications for this service.
	mapped	Service_relationship
	Preparation for a service means that that service of interest is a plan component under a super-service with predecessors in the plan.  This is
	 how preparation can be clearly specified in the service /relationship structure using the "plan component" relationship type. Timing and 
	conditionals may be specified.
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 34 of 79

	Master_service.performance_schedule_cd	A
	This field applies to the diagnostic studies/tests that are performed only at certain times during the course of a work day or work week.  This 
	field indicates the maximum interval between successive test performances (the test may actually be performed more frequently).  If 
	necessary, multiple codes may be given.  The use of multiple codes indicates that the test is performed at multiple concurrent intervals.  For 
	example, Q6H indicates that the test is performed at least once every 6 hours around the clock.  QJ1 indicates that the test is performed at 
	least every week on Mondays.  QAM~QPM indicates that the test is performed at least once every morning and every evening. 
	
	QJ1~QJ3~QJ5 indicates that the test is performed at least every week on Mondays, Wednesdays, and Fridays.  C indicates that the test is 
	performed continuously, 7 days per week.
	
	Rationale: 
	
	OpenIssue:  
	mapped	Service.total_time
	In a master service (mood_cd = DEF) the timing specification expresses when the service can be performed.  This may be a precise listing of 
	office hours and business days, weekends, and holidays.
	C04-R091.01.16	2.2.1.6	GTS
	Master_service.portable_device_ind	A
	An indication that a portable device may be used for the test or observation service.
	mapped with issues	Device.portable_ind
	The device is linked with the service through a Target link of type "reuseable device."
	
	In resource scheduling, a system will search through all resources to find out whether there is a non-portable device among them.  The 
	location of this non-portable device is the location at which the service necessarily needs to take place.   However, the service location can 
	be specified simpler through the Target location (Target.type_cd = LOC).
	C04-R091.27.11	BL
	Master_service.primary_nm	A
	The primary or preferred name of the master service.
	
	Rationale: 
	
	OpenIssue:  Need ruling from CQ on whether we will be able to link a name with it's usage in a single data type (e.g., Phone numbers with 
	home/office/daytime/evening; alternate service names with primary/report./short).  Otherwise, we need a separate Service_name class.
	mapped with issues	Service.type_cd
	Same issue as for Master_service.alternate_nm:
	
	A name of a test is basically a symbol for a concept.  It does not matter whether we refer to serum potassium as "sK", "K+", "POTASSIUM", or
	 "2823-3". All of these are symbols for the concept, understood by some convention.  Thus, there is no fundamental difference between name
	 and
	concept code.  All of these names are communicated in one attribute, the Service.type_cd as Code Translations within the Concept Descriptor
	 data type.
	
	Each code translation is from one code system.  There are standard code systems and local code systems, which both can be sent.  The 
	various kinds of names defined in the HL7 v2.3 OM1 thus map to various local codes.  Thus, an institution can define arbitrarily many names, 
	long and short, medium, 5-, 8-, 10-, 16-, 32-, characters in size, some all caps, some mixed caps, some plain US ASCII, some UNICODE, each 
	being used by a different application in different circumstances.  The static categories "long name" and "short name" do not hold any more in 
	today's variety of application systems installed at one site.
	C04-R091.01.13	2.2.1.3	CD
	Wednesday, October 13, 1999	Page 35 of 79

	Master_service.qt	A
	A means of providing default or standard specifications for when the master service is to be performed and how frequently.  It is a complex 
	multicomponent field that can have repeats.  If a speciment is required for the service, the Priority component contains specimen collection 
	priority rather than processing priority.  The extent to which these specifications can be modified in the delivery of the master service to a 
	particular subject of service is regulated by business rules established by each institution.
	mapped with issues	Service_relationship
	Service plans can be constructed using the USAMP Workflow features.  
	
	Note: the QT is not a viable alternative for HL7 v3 since it violates modeling rules in many ways.  Notably QT relies on forreign keys. The 
	service plan construction functionality hardly fits into one attribute.
	C04-R091.02.00	2.4
	Master_service.report_display_order_txt	A
	defines the sort order in which this observation is presented in a standard report or display that contains the many observations
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Service_relationship
	The "report display order" is principally determined by the receiving system.  For a battery, the order can be specified through the 
	Service_relationship.priority_nmb.  However, display order is entirely dependent on the display.  This can never be sufficiently communicated 
	in one attribute.  As a possible alternative the stakeholder owned Service_lists can specify an ordering among services, e.g., for certain 
	reports.  However, common practice is to specify reports as Services in the service catalog.
	C04-R091.02.00	2.4
	Master_service.standard_time_to_perform_qty	A
	The normal time required for performing the service across organizational provider and client base.
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Service.total_time
	Needs to be better distinguished from Master_observation_service.typical_turn_around_time and .processing_time.  But will be mapped to an 
	interval width in the Servcie.total_time attribute.
	C04-R091.01.16	2.2.1.6	GTS
	Master_service.target_anatomic_site_cd	A
	Formally indicates the site of the observation (to make it easy for a system to find all tests related to one anatomic site). It can be used to 
	classify the observation by target site of the examination.  For example, "heart" might be recorded as the target of the electrocardiogram, 
	cardiac echo, and thallium exercise test.
	
	This attribute would be applicable to most imaging and electro-physiologic examinations.  The SNOMED topology axis is an example of a coding
	 system ofr anatomic sites.  User-defined tables may also apply here.
	
	Rationale: 
	
	OpenIssue:
	clearly mapped	Service.body_site_cd
	C04-R091.01.19	2.2.1.9	CD
	Wednesday, October 13, 1999	Page 36 of 79

	Master_service.universal_service_id	A
	The primary or preferred unique identifier for the service.
	
	Rationale: 
	
	OpenIssue:  Should this attribute be combined with service_alternate_id as a set?  How can we specify that the first in the set is the 
	universal_service_id, but the order doesn't matter among the rest?
	clearly mapped	Service.type_cd
	C04-R091.01.13	2.2.1.3	CD
	Producer_of_master_service :: produces(1..1) :: Master_service :: is_produced_by(0..n)	RAD
	Rationale:  No stakeholder can be registered as a producer of a master service without naming the master sercie to be produced.  Producer of
	 Master Service is not a persistent role.  It is a participation for a specified time period with a particular master service.
	
	OpenIssue:  It would appear that this role class should have a mandatory (1..1) cardinality to master_service.
	clearly mapped	Actor :: for(1..1) :: Service :: has(0..*)
	C04-R091.03.02
	Master_service_relationship
	Master_service :: is_source(0..n) :: Master_service_relationship :: has_source(1..1)	RAD
	clearly mapped	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)
	C04-R091.02.02
	Master_service :: is_target(0..n) :: Master_service_relationship :: has_target(1..1)	RAD
	clearly mapped	Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)
	C04-R091.02.03
	Master_service_relationship	C
	Associates a composite or dependent (target) master service with one of the multiple (source) services which participates in the composition 
	or dependency.  Allows specification of constraints for each association.
	
	Rationale:  Routine order sets, clinical trials, and pathways require groupings of services such as panels or "batteries" of unlike tests 
	delivered at one time, groupings of the same tests delivered along a timeline, or grouping combination of these concepts.
	
	Note:  Linda Quade must go over these details to make certain that the names are all correct, since there are some small errors on the 
	spreadsheet.
	clearly mapped	Service_relationship
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 37 of 79

	Master_service_relationship.constraint_txt	A
	Textual description of any arbitrary constraint on the source service when participating in the target service.
	
	Rationale:  Detail of a possible relationship between services.
	mapped	Service_relationship
	A constraint is a criterion linked to the service through a service relationship of type "has-precondition".   It can be fully coded for 
	interoperable automated communication. For backward compatibility the constraint can be represented just as free text in the Service.descr 
	attribute of the criterion service.
	C04-R091.02.00	2.4
	Master_service_relationship.reflex_testing_trigger_rules_desc	A
	A description of the rules that trigger reflex testing for a service catalog item.
	
	Rationale:
	mapped	Service
	in trigger mood, linked through a service relationship of type trigger with a master service that is invoked on that trigger.
	C04-R091.01.00	2.2
	Master_service_relationship.relationship_type_cd	A
	Specifies the basis for the association of the source to the target.
	
	Rationale:
	clearly mapped	Service_relationship.type_cd
	C04-R091.02.11	2.4.1.1	CV
	Master_specimen_requirement
	Master_specimen_requirement	C
	A specification of specimen requirements for test/observation service catalog items which require a specimen.
	mapped	Material
	… associated with the master service as a target of type specimen.
	
	It has been asked (Jane Curry) whether we'll see mood codes for Material, distinguishing whether it's a potential or actual material, etc. Most 
	human languages do not distingusish moods of substantives, but only moods of verbs.  This is an indication for an underlying logic:  In 
	mentioning a material, we do not say anything about its existence. For example, if I say "Napoleon" I refer to an idea of a substance that may 
	or may not exist or have exited.  Only if I say "Napoleon lived in the early 19th century" or
	"I am Napoleon", or something like that, only then do we have knowledge about the mood of existence of Napoleon.
	C04-R091.20.00	2.7
	Master_specimen_requirement.additive_cd	A
	A code for the additive required for the collected specimen used in the associated observation service type.
	mapped	Material_relationship
	of type additive.   Additives to specimen are material mixed with the specimen-material.  This allows to specify the proportion, which is 
	important to account for dilluting effects and effects of other physico-chemical properties of the specimen-additive mixture.
	C04-R091.21.00	2.7.2
	Wednesday, October 13, 1999	Page 38 of 79

	Master_specimen_requirement.container_desc	A
	A description of the container requirements for a specimen collected for the observation service type.  The description includes specification 
	of the physical appearance, including color of tube tops, shape, and material composition (e.g., red top glass tube).
	clearly mapped	Material.descr
	for the container-material associated with the specimen-material.
	C04-R091.20.14	2.7.1.4	ED
	Master_specimen_requirement.container_volume_qty	A
	A specification of the containers volume capacity.
	clearly mapped	Container.capacity_qty
	C04-R091.24.11	2.8.2.1	PQ	~ 1 cm
	Master_specimen_requirement.derived_specimen_cd	A
	This field contains the codes that distinguish the parent and children for diagnostic studies--especially
	 in microbiology--where the initial specimen (e.g., blood) is processed to produce results (e.g., the identity of the bacteria grown out of the 
	culture).  The process also produces new "specimens" (e.g., pure culture of staphylococcus, and E. Coli), and these are studied by a second 
	order process (bacterial sensitivities).  The parents (e.g., blood culture) and children (e.g., penicillin MIC) are identified in such cases.
	
	OpenIssue:  Do these codes apply to the specimen, or to the Master_service requiring the specimen?
	
	OpenIssue:  This should be an indicator if only 2 possible states (parent and child) exist.
	mapped	Material_relationship
	A derived specimen is called an "aliquot".  The derivation can be fully specified through a specimen derivation action (Service) with the source
	 specimen as target of type consumable and aliquot as a target of type product.  If only the relationship bewteen the parent and aliquot is to be
	 captured, the Material_relationship can be used as well (type_cd = "is_aliquot")
	C04-R091.21.00	2.7.2
	Master_specimen_requirement.minimum_collection_volume_qty	A
	The amount of specimen needed by the most specimen sparing method.
	mapped	Material.qty
	Specified as a probability distribution (uniform, normal, or "guess") with mean and standard deviation. Simple mathmatical transformations exist
	 between a min-max representation and a probability distribution.
	C04-R091.20.20	2.7.1.10	SET<PQ>	{1}
	Master_specimen_requirement.normal_collection_volume_qty	A
	A specification of the normal specimen volume required.  This is the amount used by the normal methods and provides enough specimens to 
	repeat the procedure at least once.
	mapped	Material.qty
	The quantity can be specified as a probability distribution (uniform, normal, or "guess") with mean (the "normal collection volume" value) and 
	standard deviation (describing minimum, and, theoretically, a maximum.) Simple mathmatical transformations exist between a min-max 
	representation and a probability distribution.
	C04-R091.20.20	2.7.1.10	SET<PQ>	{1}
	Wednesday, October 13, 1999	Page 39 of 79

	Master_specimen_requirement.priority_cd	A
	The allowed priorities for obtaining the specimen.
	
	Valid priorities are:  Stat, As Soon As Possible, Routine, Pre-operative, Timing Critical.
	
	The specimen priority for an order is communicated in the quantity-timing attribute of the service intent or order.
	
	OpenIssue:  
	mapped	Service.priority_cd
	This attribute is about a specimen collection service, not about the material specimen.  USAMP-II puts it where it logically belongs. Thus, we 
	can reuse an existing attribute rather than making a new one. (BTW: this has nothing to do with the "merger", but it's in the same spirit: 
	"rationalize and reuse.")
	C04-R091.01.25	2.2.1.15	SET<CV>	{R}
	Master_specimen_requirement.retention_time_qty	A
	The usual time that this specimen is retained after the observation is completed.
	mapped	Material.extent_tmr
	The "extent" is the time a material is in distinguished existence.  It is an interval of time. For a specimen used as a requirement description, the 
	extent_tmr will be specified only as the width of that interval.
	C04-R091.20.16	2.7.1.6	IVL<TS>
	Master_specimen_requirement.special_handling_desc	A
	Special handling requirements for the collected specimen.
	clearly mapped	Material.handling_cd
	C04-R091.20.18	2.7.1.8	CD
	Master_specimen_requirement.type_cd	A
	A code identifying the specimen required by the observation service type.  Codes should be drawn from ASTM Table 14 of 1238-91.
	
	Rationale: 
	
	OpenIssue:  
	clearly mapped	Material.type_cd
	C04-R091.20.12	2.7.1.2	CD
	Master_treatment_service
	Master_service :: generalizes(1..1) :: Master_treatment_service :: specializes(1..1)	RGD
	mapped	Medication is specialization of Service
	C04-R091.06.01
	Wednesday, October 13, 1999	Page 40 of 79

	Master_treatment_service	C
	An item in the formulary.
	mapped	Medication
	in definition mood (mood_cd = DEF)
	C04-R091.06.00	2.6.3
	Master_treatment_service :: is_ordered_on(0..n) :: Treatment_intent_or_order_revision :: orders(0..1)	RAS
	Rationale: 
	
	OpenIssue:
	mapped	Service_relationship
	of type "instantiates" source is a service in order or intent mood, target is a service in definition mood.
	C04-R091.02.00	2.4
	Master_treatment_service.medication_form_cd	A
	A code depicting the form of the medication comprising the pharmacy treatment service.
	
	OpenIssue:  Need example values.
	clearly mapped	Material.form_cd
	Note: this is one of those shallow definitions …anyway, the name suggest the mapping is correct.  The talk is about doseform, e.g., tablet, 
	suppository, spray, vial, etc.
	C04-R091.20.13	2.7.1.3	CV
	Master_treatment_service.route_cd	A
	A code depicting the administration route for the pharmacy treatment service.
	
	OpenIssue:  Need example values.
	clearly mapped	Medication.route_cd
	Note: this is one of those shallow definitions …anyway, the name suggest the mapping is correct.  The talk is about medication route, e.g., 
	oral, rectal, inhalation, i.v., etc.
	C04-R091.06.12	2.6.3.2	CD
	Observation_intent_or_order
	Observation_intent_or_order	C
	An authoritative direction or instruction concerning an observation service for a patient.
	
	Rationale:
	mapped	Observation
	in mood code "intent" or "order"
	C04-R091.05.00	2.6.1
	Wednesday, October 13, 1999	Page 41 of 79

	Observation_intent_or_order.patient_hazard_cd	A
	Code and/or text indicating any known or suspected patient or specimen hazards e.g., patient with active tuberculosis or blood from a 
	hepatitis patient.
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Material.danger_cd
	this takes care of hazards emerging from a specimen.  A patient hazard should be noted in the Patient or Person class, where it can be 
	tracked an reused, it certainly is not exclusively pertinent to an order.
	Living subjects, if modeled as a specialization of material, would inherit the danger_cd from Material.
	C04-R091.20.19	2.7.1.9	CD
	Observation_intent_or_order.relevant_clinical_information_txt	A
	Additional clinical information about the patient or specimen, such as the suspected diagnosis and clinical findings on requests for interpreted 
	diagnostic studies.
	
	Rationale: :
	mapped with issues	Service_relationship
	… to the relevant clinical information in structured form, rather than in a free text field.  No need for another free text attribute.
	C04-R091.02.00	2.4
	Service_intent_or_order :: generalizes(1..1) :: Observation_intent_or_order :: specializes(1..1)	RGD
	mapped	Observation is specialization of Service
	C04-R091.05.01
	Patient
	Patient :: is_scheduled_by(0..n) :: Patient_slot :: is_a_scheduleable_unit_for(1..1)	RAS
	mapped	List_item
	of a stakeholder owned Service_list of type "schedule". The Service_list :: is_about(1..1) :: the patient (Person). The booked slots are 
	represented by list_items with associated Service for which the slots are booked. A receiver of a message containing such a service list can 
	find the open slots as being everything that is not booked.
	
	Issue: We may want to allos List_items not bound to any Service, but with a time range to indicate blocked slots that are not available but also 
	not booked with any service.  In addition the List_item could specify (in a status_cd) whether it is held reserved for a service or whether it is 
	actually booked.
	C04-R091.31.00
	Patient_service_location_group
	Wednesday, October 13, 1999	Page 42 of 79

	Patient_service_location_group	C
	A pool of like-type locations available for scheduling purposes.
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	mapped	Material
	as a grouper for associated locations.  The grouped locations are associated through the Material_relationship of type part_of.  The 
	Material.type_cd of the grouper could be an interoperably defined entry in a Material type code (material pool, location pool.)
	
	BTW: the term "pool" makes the meaning much more clear, since grouping can have many purposes, but "pooling" is done in order to share 
	resources more flexibly.
	C04-R091.20.00	2.7
	Patient_service_location_group :: is_requested_by(0..n) :: Patient_service_location_request :: requests(0..1)	RAS
	mapped with issues	Target
	of Target.type_cd = LOC, of a Service in mood_cd = SCH (scheduling request).
	C04-R091.04.00	2.3.2
	Patient_service_location_group.id	A
	Unique identifier for the group
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	clearly mapped	Material.id
	C04-R091.20.11	2.7.1.1	SET<II>
	Procedure
	Care_event :: generalizes(1..1) :: Procedure :: specializes(1..1)	RGD
	Rationale:  Allows interrelationship with other service events.
	mapped	Procedure is specialization of Service
	C04-R091.07.01
	Procedure	C
	A therapeutic or diagnostic intervention employed in response to a patient condition.
	
	OpenIssue:  We are not sure if the gen-spec relationship should be moved from Procedures is_specialization of Service_event to Procedure 
	is_specialization of Care_event or not.  The data seems to be needed,  but it is not definite where in the model they should go.  It needs further
	 work.  Many of these attributes have come from the UBforms, and have not yet been properly modeled.  More work by PAFM and OO is 
	needed.
	clearly mapped	Procedure
	… in event mood.
	C04-R091.07.00	2.6.2
	Wednesday, October 13, 1999	Page 43 of 79

	Procedure.anesthesia_cd	A
	A code identifying the anesthesia used in a procedure.
	
	OpenIssue:  Need example codes.
	
	OpenIssue:  Should this be a relationship to Master_service?
	mapped with issues	Service_relationship
	A surgical procedure with anesthesia is two, not one, procedure, scheduled differently, performed by different responsible actors, even 
	different departments, different bills, different preparation and follow up care -- indeed, anesthesia is a completely separate service.   Surgery
	 and anesthesia can be linked under a common super-service to coordinate (synchronize) these otherwise separate services.  There is thus 
	no need to mention anesthesia attributes in the Procedure class.
	C04-R091.02.00	2.4
	Procedure.anesthesia_tmr	A
	The length of time that the anesthesia was administered.
	mapped with issues	Service_relationship
	A surgical procedure with anesthesia is two, not one, procedure, scheduled differently, performed by different responsible actors, even 
	different departments, different bills, different preparation and follow up care -- indeed, anesthesia is a completely separate service.   Surgery
	 and anesthesia can be linked under a common super-service to coordinate (synchronize) these otherwise separate services.  There is thus 
	no need to mention anesthesia attributes in the Procedure class.
	C04-R091.02.00	2.4
	Procedure.delay_reason_txt	A
	The reason for delay of the surgery patient service.
	
	OpenIssue:  Needs code value examples
	mapped	Service.descr
	of the Service event.
	
	First off: this attribute has no heritage in HL7 v2.3 and is not supported by a strong use case or a good definition. Why is a delay of a 
	Procedure more noteworthy than the delay of any other event?  Why does one need a delay reason text without an indication about what kind
	 of delay happened at all?
	
	Let us rationalize this: 
	
	1. A delay can be stated only between an event as planned or scheduled and the actual event.  Thus, there must be a Procedure in intent 
	mood and the instantiation of the intent in event mood.  Thus, a system can compare the planned/intended time with the actual time of the even 
	to establish a delay established.
	
	2. How can the delay be explained? Obviously any derivation from the service as intended from the service as performed might deserve an 
	explanation.  Since the explanation for the delay is free text, it can go into the Service.descr attribute of the Service event. 
	
	Remember, the Service description is subject to the mood of the Service just as any other property of the Service is subject to the mood code.
	  In other words, the Service.descr of the event describes the event, tells what actually happened, not what was ordered, planned,  or 
	defined in the master file.)
	 
	Therefore the Service.descr of the event only needs to mention what is different from the definition (master) or order or intent.  Hence the 
	Service.descr is the logical home for any text explanations of variances between the defined, ordered, or planned service and the event. 
	Q.E.D.
	C04-R091.01.14	2.2.1.4	ED
	Wednesday, October 13, 1999	Page 44 of 79

	Procedure.functional_type_cd	A
	A code identifying the functional type of the procedure.  Functional types include:  Anesthesia; Procedure for treatment (therapeutic, including 
	operations); Invasive procedure not classified elsewhere (e.g., IV, catheter, etc.); Diagnostic procedure.
	
	OpenIssue:   
	mapped with issues	Service.type_cd
	This is a categorization or classification that entirely depends on the purpose, and is thus subjective in nature. As such, this can never be an 
	interopeable attribute, unless its use case and i's vocabulary is clearly and completely defined.  Classifications usually come with terminology 
	systems and do not need to be communicated in attributes.  The list of examples is insufficient.
	
	If a clear use case for such classification is presented, USAM will be able to accommodate it, just like any other model would.  However, we 
	must keep the RIM clean from unexplained info junk.
	
	Note that ad hoc local codes can all be sent as translations of the Service.type_cd, which is a Concept Descriptor that allows multiple 
	translations of codes into different code systems to be sent.  To a certain extent this can be used to send classifiers (and it is not a hack to 
	send classifiers that way, but is warranted by the logic of coding.)
	C04-R091.01.13	2.2.1.3	CD
	Procedure.incision_open_tmr	A
	The time range during which the incision was open for this surgery patient service.
	clearly mapped	Service.critical_time
	as an interval ("range") of time.
	C04-R091.01.17	2.2.1.7	GTS
	Procedure.modifier_cd	A
	Codes, typically defined by  regulatory agencies such as HCFA or the AMA, that modify the procedure code.
	
	Rationale: Unless procedure modifiers are pre-coordinated in Master_service, the modifier must be specified at the service instance level.  It 
	cannot be combined with the "procedure id" in the RIM, since that attribute is obtained from the master service class.
	
	OpenIssue:  
	
	OpenIssue:  Need code examples.
	mapped	Service.type_cd
	Code modifiers are what the Code Phrase within the Concept Descriptor (CD) data type has been designed for.  So, there is no need for 
	modifier code attributes, and such attributes would even be harmful, since they can not be used with multiple translations into different coding 
	systems.
	C04-R091.01.13	2.2.1.3	CD
	Procedure.priority_nbr	A
	A number indicating the relative priority of the procedure to all other procedures provided in this encounter.
	mapped	List_item.priority_nmb
	on a Service_list maintained by a revenue optimization system (or an issue list maintained by a physician.)
	C04-R091.31.12	2.9.2.2	REAL
	Procedure.procedure_tmr	A
	The date/time that the procedure was performed and the length of time that the procedure took to complete.
	mapped	Service.total_time
	as an interval of point in time indicating start and end of the Procedure.
	C04-R091.01.16	2.2.1.6	GTS
	Wednesday, October 13, 1999	Page 45 of 79

	Producer_of_master_service
	Healthcare_service_provider :: participates_as(0..n) :: Producer_of_master_service :: has_as_participant(1..1)	RAD
	mapped	Actor
	The actor of a Service in definition mood (master) is the provider that provides the service.
	C04-R091.03.00	2.3.1
	Producer_of_master_service	C
	This participation class links a single producing person or organization or organization (stakeholder) to a single service that the stakeholder 
	can provide.  Producers offering multiple services will have many  such link instances in this class.  Likewise, services offered by multiple 
	producers will have a link instance in this class for each offering producer.
	
	OpenIssue:  The following attributes should be defined and added to this class:  tmr; authorization status.  Also, the attributes of 
	Master_service and its specializations should be reviewed to determine if any are producer-specific.  Any such attributes should be moved to
	 this class.  Alternatively, a business rule may be put in place, stating that a new master_service instance will be established for each 
	separate producer of a service (as identifidr by the universal service identifier).  This is the practice implied in V2.3. 
	
	Rationale:  This class performs the same function as the Producer ID field in the V2.3 OM1 segment, but further allows several producers to 
	be linked too the same master service (identified by a single universal service identifier) and likewise allows several services to be linked to 
	the same producer.
	clearly mapped	Actor
	of actor type: performer, that links a Service in definition mood with the Stakeholder (individual person or organization) offering this service 
	catalog item.
	C04-R091.03.00	2.3.1
	Resource_request
	Resource_request	C
	Individual resource request information about various kinds of resources that are controlled by a schedule.
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	mapped	Target
	of a Service in mood_cd "scheduling request" (SCH).
	
	Rationale: all targets (and actors) of a service represent resources. For a service in scheduling request mood, the associated actors and 
	targets are requested to be allocated for the service.
	C04-R091.04.00	2.3.2
	Resource_request :: generalizes(1..1) :: Durable_medical_equipment_request :: specializes(1..1)	RGS
	mapped	Target
	the target of type "reuseable device" of a Service in scheduling request mood represents this association.
	C04-R091.04.00	2.3.2
	Wednesday, October 13, 1999	Page 46 of 79

	Resource_request :: generalizes(1..1) :: Individual_healthcare_practitioner_request :: specializes(1..1)	RGS
	mapped	Actor
	of a service in scheduling request (SCH) mood.
	C04-R091.03.00	2.3.1
	Resource_request :: generalizes(1..1) :: Patient_service_location_request :: specializes(1..1)	RGS
	mapped	Target
	the target of type "location" of a Service in scheduling request mood represents this association.
	C04-R091.04.00	2.3.2
	Resource_request.allowable_substitutions_cd	A
	A code indicating whether the identified resource can be substituted with an equivalent resource.
	
	Rationale: Currently in 2.3
	
	OpenIssue:  Need code examples.  Also, should this be a Boolean (_ind) rather than _cd?
	mapped	Service.substitution_cd
	for a service in scheduling request mood.
	C04-R091.01.24	2.2.1.14	CV	N
	Resource_request.duration_qty	A
	The duration for which the resource is requested for this appointment, if it is different than the overall duration of the appointment
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	mapped	Service.total_time
	of a service in scheduling request mood. The duration is the width of an occurrence interval.
	C04-R091.01.16	2.2.1.6	GTS
	Resource_request.start_dttm	A
	Date and time this resource is requested for the appointment.
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	mapped	Service.total_time
	of a service in schedule request mood. The starte_dttm is the low boundary of the occurrence interval.
	C04-R091.01.16	2.2.1.6	GTS
	Wednesday, October 13, 1999	Page 47 of 79

	Resource_request.start_offset_qty	A
	The offset that this resource is requested for the appointment, expressed in units of time relative to the scheduled start date/time of the 
	appointment.
	
	Rationale: Currently in 2.3
	
	OpenIssue:  How does this attribute work with the start_dttm for the request.  This offset is relative to the appointment and would appear to 
	present a conflict with the other attribute.
	mapped	Target.tmr
	The offset means, that a certain resource is not needed for the entire service but only for a certain portion of the service.  If a Target (or 
	Actor) participates only partly in the service, this is generally indicated through the Target.tmr (or Actor.tmr, respectively) attribute.  
	Alternatively it can be specified through breaking the service apart into sub-services as scheduling sub-requests.
	C04-R091.04.12	2.3.2.2	SET<CV>
	Resource_request.status_cd	A
	A code that describes the request status of scheduling a resource or activity, from the point of view of the filler application.
	
	Rationale: Currently in 2.3
	
	OpenIssue:  Need code examples.
	clearly mapped	Service.status_cd
	of a Service in scheduling request mood.
	C04-R091.01.15	2.2.1.5	CV
	Rule_link
	Rule_link	C
	The link that exists between a current or more molecular service event and a previous or more atomic service event that indicates simple set 
	membership.  The source service event is the set name, while the target service event is the set member.  The attribute priority of the List_link 
	class allows the set to become a list, with the value of the priority attrivbute specifying list order.  Thus, a value of NULL for prioity indicates 
	that the source of the List_link is the "name" of the set (e.g., Chem-12) while each target of an instance of List_link will be a "member" of the 
	set (e.g., Na, K, etc.).  If an instance of List_link has a non-NULL priiority value, an application may choose to display and/or process the list 
	(i.e., the prioritized/order Set) according to application rules for interpreting the prioity that a given list member has been assigned (e.g., the 
	Work List for Nursing has the following Work Tasks listed in order oof priority:  1. SE1, 2.  SE2, 3.  SE3, etc.
	
	OpenIssue:  This may be superceded by the changes consequent to the USAMP-II proposal work being done summer 1999.
	mapped	Service_relationship
	This has only recently been broken out of service_relationship (by some of the USAMP-II authors) for specific reasons (to teach the model.)  It
	 was always understood, that this particular action would yield to whatever the USAM-II would propose.
	C04-R091.02.00	2.4
	Rule_link.priority_nbr	A
	Used to doocument the relative ranking of a current service event to a previous or more atomic service event in a set (when the field is NULL) 
	or in an ordered list of service events (when the field is an integer), e.g. items in a sequenced task list, prioritization of patient problems, etc.
	clearly mapped	Service_relationship.priority_nmb
	C04-R091.02.14	2.4.1.4	INT	1
	Service_event
	Wednesday, October 13, 1999	Page 48 of 79

	Master_service :: is_delivered_during(0..n) :: Service_event :: delivers(1..1)	RAD
	mapped	Service_relationship
	of type_cd "fulfills" linking the Service in event mood as source with the Service in definition mood as target of the Service_relationship.
	C04-R091.02.00	2.4
	Patient_billing_account :: has_charges_for(0..n) :: Service_event :: is_charged_to(0..1)	RAD
	OpenIssue:  What is the difference between charging to and billing to a patient account?  Service_events and_service_intent_or_orders are 
	different.
	clearly mapped	Service :: is_charged_to(0..1) :: Patient_billing_account :: has_charges_for (0..*)
	C04-R091.01.04
	Service_event	C
	The performance of a health related action provided by one or more active participants on behalf of one or more target participants.  This 
	includes medical as well as non-medical services. A patient can be both target and active participant of the service: - a clinical test - an 
	assessment of health condition (such as problems and diagnoses), - the setting of healthcare goals - the performance of treatment services, 
	such as medication, surgery, physical and psychological therapy. - assisting, monitoring or attending - training and education services to 
	patients and their next of kins - notary services, such as advanced directives or living will 
	Examples of active participants are nurses, doctors, family members, notary publics, and service agencies. Target participants may include, 
	the patient, the patient's spouse, family, or community, a specimen drawn from the patient or from any object of interest. As patients do play 
	active roles in their own healthcare, the patient can be both an active participant and a target participant at the same time (self-administered or
	 reflexive services.) A service_event can have multiple active participants and multiple target participants, their specific role is distinguished in 
	the "type_cd" of the respective instance of the participation class. In particular, a service event involving coordination of care may involve two
	 or more active participants playing different roles who interact on behalf of a patient, family, or aggregate in the role of target participant.  For 
	example, a nurse (active participant) calls Meals on Wheels (active participant) on behalf of the patient (target participant).
	The service_event is the documentation of a rendered service including its detailed context, as opposed to the formulation of an intended 
	service. A service event includes the "results," "answers" or "procedure products" gained during the service. In this model, "results" do not 
	exist without a service, and every clinical result, including those results gained accidentally, are service_events.
	
	OpenIssue: Should there be an Observation Service Event specialization Patient Service Event?
	mapped	Service
	in event mood.
	C04-R091.01.00	2.2
	Service_event :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..n)	RAS
	Rationale: Optiional relationsip establishes independence of service events from encounters.
	mapped	Service :: is_assigned_to(0..1) :: Patient_encounter :: has_assigned_to_it(0..*)
	Issue to PAFM: the name "assigned to" is very vague!
	C04-R091.01.02
	Service_event :: is_associated_with(0..n) :: Financial_transaction :: pertains_to(1..1)	RAS
	clearly mapped	Service :: is_associated_with(0..*) :: Financial_transaction :: pertains_to (1..1)
	Issue to PAFM: the name is very vague!  Pertinence and association is certainly expressed by all associations.  Especially in this case "bills" 
	and "is billed as" would be more expressive. Why shying away from clear language?
	C04-R091.01.03
	Wednesday, October 13, 1999	Page 49 of 79

	Service_event :: is_documented_by(0..n) :: Clinical_document_header :: documents(0..n)	RAS
	OpenIssue:  This many-to-many association should be resolved.
	clearly mapped	Service :: is_documented_by(0..*) :: Clinical_document_header :: documents(0..*)
	C04-R091.01.05
	Service_event :: is_performed_at(0..1) :: Master_patient_service_location :: is_location_for(0..n)	RAS
	Rationale: Support references to facilities in OBR.
	mapped	Target
	of type location linking a Servcie in event mood to a Material in the role of a Facility/Location.
	C04-R091.04.00	2.3.2
	Service_event.attestation_dttm	A
	The date the service provider attests that the patient service was delivered as documented.
	
	Rationale:  
	
	OpenIssue:  This attribute needs to be clarified between Orders, XML, and Medical Records since it seems to be involved with all three domain
	 areas.
	mapped	Actor.tmr
	of an Actor of type "attester" as the high boundary of the time interval.
	C04-R091.03.12	2.3.1.2	IVL<TS>
	Service_event.billing_priority_nbr	A
	A  number that allows a relative ranking for billing purposes of service events (usually billing diagnoses or procedures) on an ordered list, e.g.
	 1500 forms.
	
	Rationale:  Used to differentiate purpose from other ranking attributes
	mapped	List_item.priority_nmb
	Billing priority is established on a Service_list :: owned_by :: a billing department.
	C04-R091.31.12	2.9.2.2	REAL
	Service_event.confidential_ind	A
	An indication that the diagnosis is confidential.
	clearly mapped	Service.confidentiality_cd
	C04-R091.01.21	2.2.1.11	SET<CV>
	Wednesday, October 13, 1999	Page 50 of 79

	Service_event.consent_cd	A
	A code depicting the type of consent that was obtained for permission to treat the patient.  May not represent consent from the patient.
	
	OpenIssue:   Needs to be addressed in the analysis of consents .  This can cover declination as well.
	
	OpenIssue:  Need code examples.
	mapped	Service.type_cd
	of a Consent service associated with the consented-to service through a Service_relationship link.  Both, service and consent should be 
	service plan components under a common super service.  Note that conset obtaining needs to be scheduled just as any other service.  A 
	consent is thus not entirely different from a TRH challenge before a TRH test: timing is an issue.
	C04-R091.01.13	2.2.1.3	CD
	Service_event.family_awareness_txt	A
	Indicates the individual's family or significant other's comprehension of the service event.
	
	OpenIssue:  Isn't this sometimes a coded entry?  If so, need to use the _cd attribute type to accommodate both code and test.
	mapped	Target.awareness_cd
	of a target of type "proxy" linked with the family member or other significant party.  This attribute is strongly coded.  A free text note can be 
	put into the Target.note_txt -- but such free text is not functional.  The code must be used to express awareness interoperably.
	C04-R091.04.13	2.3.2.3	CV
	Service_event.filler_id	A
	The patient service unique identifier   This is often assigned by the filler, but may be assigned by other processes.
	mapped	Service.id
	C04-R091.01.11	2.2.1.1	SET<II>
	Service_event.filler_order_status_dttm	A
	Indicates the date and time that a status, as defined in Order Status, is entered or changed.  Note:  Order Status represents the status of 
	order fulfillment by the filler.  This is different from Order Control Code, which reflects the status of the order from the placer's viewpoint.
	
	Rationale: to represent the use of this V2.3 field as the date and time of change in ORC/ order status.
	
	OpenIssue:
	mapped	Service.status_cd
	of the service in event mood (linked to an order through service_relationship of type fulfills.) 
	
	The timed life cycle can be communicated through the status code as a history item or the eentire life cycle as a history list.
	
	Note:  "Filler order" is recognized as bad language.  It is the service intent or event generated through the order.  The order is always an order
	 as placed (placer order.)  BTW: order control code is NOT a status code at all but a trigger event code.
	C04-R091.01.15	2.2.1.5	CV
	Service_event.individual_awareness_cd	A
	This field contains the individual's comprehension of the service event (e.g., full, marginal, partial, etc.).
	
	OpenIssue:  Is this code or text?  Should this be renamed to Patient_awareness_cd?
	mapped	Target.awareness_cd
	of the Target linking to the patient as direct target (subject) or indirect target (beneficiary.)
	C04-R091.04.13	2.3.2.3	CV
	Wednesday, October 13, 1999	Page 51 of 79

	Service_event.patient_sensitivity_cd	A
	Indicates whether patient considers this service to be confidential.  Current values are Yes and No.
	
	Rationale:  Although currently described as an indicator, we have chosen to use the Code attribute type here to allow a more structured 
	representation of confidentiality in the future. 
	The use of the word "sensitivity" parallels usage in class the Problem arena.
	mapped	Service.confidentiality_cd
	has been consolidated with confidentiality (where it belongs.)  "Sensitivity" is a distinguished concept in the new consolidated vocabulary for 
	this field.
	C04-R091.01.21	2.2.1.11	SET<CV>
	Service_event.scheduled_start_dttm	A
	The date the patient service is scheduled to begin.
	mapped with issues	Service.total_time
	… of a service in intent (!) mood.  Note that the service event describes the actual service as it is actually carried out.  As long as the service 
	has not actually started, it is in intent mood. So, the planned begin date is the begin date of the service in intent mood.
	
	Note: this attribute does not belong in the event class of RIM092 anyway.
	C04-R091.01.16	2.2.1.6	GTS
	Service_event.service_desc	A
	Text that describes the service performed along with relevant details of the service.
	
	Rationale:  To differentiate this attribute from Service_event: service_event_desc.
	
	OpenIssue:  There needs to be a good way to show the necessary constraints on an attribute value in the description of the attribute 
	somewhere.
	clearly mapped	Service.descr
	C04-R091.01.14	2.2.1.4	ED
	Service_event.specimen_received_dttm	A
	The date and time the specimen was received for use in the service event.
	
	Rationale:  Each service event uses only one specimen. Each collected_specimen_sample may be collected in several containers, or may be 
	reallocated to several containers for use in multiple service events.  This attribute captures the time one of those containers was received by 
	this service event.  It is not an atttribute of the sample alone.
	mapped with issues	Service.critical_time
	… of a transportation service event transporting the specimen to the service location.  The specimen is received at the end of the critical_time 
	of the transportation. This arrival of the specimen in the lab is tracked, mostly with an eye on the transportation event that implicitly happened 
	(e.g., as an excuse for the delayed test when the specimen didn't arrive in time.)  
	
	Note that the rationale provided in RIM092 is arguably not true.  An observation may well act on multiple specimen (e.g., a cross-blood test).  
	Each specimen may then arrive at different times. True that this attribute is not an attribute of the specimen, since it talks about things being 
	done with the specimen, rather than the nature and condition of the specimen itself.
	C04-R091.01.17	2.2.1.7	GTS
	Wednesday, October 13, 1999	Page 52 of 79

	Service_event.status_cd	A
	A code indicating the lifecycle status of the  service event.  See state/transition model for an exhaustive list of lifecycle states.
	clearly mapped	Service.status_cd
	C04-R091.01.15	2.2.1.5	CV
	Service_event.status_reason_cd	A
	Explanation of the reason for the status. examples: order entry error; patient refused, contraindicted
	mapped with issues	Service.status_cd
	Note that this code is not interoperable since it is not defined.  Note also that this needs more analysis work.   The suggested values are 
	certainly admissible status codes for the status code itself, so why not defining these right in the status code?
	C04-R091.01.15	2.2.1.5	CV
	Service_event.tmr	A
	The period of time during which the patient service occurred.
	clearly mapped	Service.total_time
	as an interval ("range") of point in time.
	C04-R091.01.16	2.2.1.6	GTS
	Service_intent_or_order :: is_fulfilled_by(0..n) :: Service_event :: fulfills(0..1)	RAD
	mapped	Service_relationship
	of type "fulfills" linking the Service event as source and the Service order as target.
	C04-R091.02.00	2.4
	Service_event_relationship
	Service_event :: is_source_for(0..n) :: Service_event_relationship :: has_as_source(1..1)	RAD
	clearly mapped	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)
	C04-R091.02.02
	Service_event :: is_target_for(0..n) :: Service_event_relationship :: has_as_target(1..1)	RAD
	clearly mapped	Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)
	C04-R091.02.03
	Wednesday, October 13, 1999	Page 53 of 79

	Service_event_relationship	C
	Specifies the linkage among Service_events.  These relationship types include, but are not limited to, collections/batteries (e.g., CBC, Chem12),
	 temporal and non-temporal decision paths (e.g., care plan, critical path, clinical trials, drug treatment protocols), and decision linkages (e.g., 
	evidenced by, subsumes).
	
	Rationale:  Routine order sets, clinical trials, and pathways require groupings of services such as panels or "batteries" of unlike tests 
	delivered at one time, grouping of the same tests delivered along a timeline, or grouping of a combination of these concepts.  The same 
	grouping relationships captured in the Master_service need to be maintained as the service is delivered.
	
	OpenIssue:  Patient Care, PAFM, and Orders need to sit down and work out the attributes for the relationship classes.  Also should discuss 
	whether this class needs to have sub-classes (gen/spec classes), e.g., should temporal be a sub-class under relationship class.  There is 
	currently only a kluge way to relate Service_event and SIOO - the service reason link may not be sufficient.
	clearly mapped	Service_relationship
	C04-R091.02.00	2.4
	Service_event_relationship.relationship_type_cd	A
	Specifies the basis for the association of the source to the target.
	
	Rationale:  Relationship management.
	
	OpenIssue:  Need code examples.
	clearly mapped	Service_relationship.type_cd
	C04-R091.02.11	2.4.1.1	CV
	Service_intent_or_order
	Patient_billing_account :: is_billed_from(0..n) :: Service_intent_or_order :: is_billed_to(0..1)	RAD

	Rationale: supports use of BLG segment in the ORM message
	
	OpenIssue: Open issue: needs joint work with OO-PAFM
	mapped	Service :: is_charged_to(0..1) :: Patient_billing_account :: has_charges_for (0..*)
	Note that the mood code modifies the meaning of ALL properties of the Service class in a consistent logical way. This is true for attributes and
	 associations alike:
	
	event: I have done something.
	order: Please, do something.
	event: I have charged this account.
	order: Please, charge this account.
	
	Open Issue to PAFM: Why does the account need to be constrained to "Patient billing"? Why could one not have a general class for Account 
	that allows us to bill to clinical study account, special budgets, bill organizations for maintenance and supply services, etc.? What do we gain 
	by such overspecification?
	C04-R091.01.04
	Wednesday, October 13, 1999	Page 54 of 79

	Service_intent_or_order	C
	The instantiation of the intent or request to perform a particular service as represented in Master_service particular date for a particular 
	patient by a particular provider.
	
	Rationale:  This class adds the ability to attach context information and modify default values as a plan for a particular target of service that is 
	to receive a service itemized in the Master_service catalog.
	
	OpenIssue:  This name does not conform to the style guide.
	mapped	Service
	in "intent" or "order" mood.
	C04-R091.01.00	2.2
	Service_intent_or_order :: expects_patient_located_at(0..1) :: Master_patient_service_location :: 	RAS
	OpenIssue:  This may not cover all of the concepts around the connection between Service_intent_or_order and Location, including the 
	requirement that there be a connection between Encounter and Location.  There may be other connections, and this needs further analysis.  
	This might also conflict with what is already done in Scheduling.
	mapped	Target
	of type location.  Note that a lab test has two services: (1) specimen collection, a clinical service at the bedside, and (2) laboratory test in the 
	laboratory.  If the specimen collection is ordered at the bedisde (or any other place where the patient is expected to be) then that location 
	becomes the primry location target of the ordered service (1).  The laboratory location is the primary location of the service (2). Of course, 
	since location (1) and (2) are different (usually quite different) the transport of the specimen from (1) to (2) is a third service.
	C04-R091.04.00	2.3.2
	Service_intent_or_order :: is_an_instance_of(1..1) :: Master_service :: is_instantiated_as(0..n)	RAS
	mapped	Service_relationship
	of type "instantiates" linking the Service order as source and the Service definition as target.
	C04-R091.02.00	2.4
	Service_intent_or_order :: is_referred_to_in(0..n) :: Clinical_document_header :: is_related_to(0..1)	RAS

	Rationale: 
	
	OpenIssue: If we have the linkage between patient service event and healthcare chart document header right, this might not be needed as it 
	duplicates existing connections.  This is pending joint work between Information Management, Orders/Observations, and Patient Care 
	committees.
	mapped with issues	Service :: is_documented_by(0..*) :: Clinical_document_header :: documents(0..*)
	See the relationship between the Service event and Clinical document header. It is a many to many and the open issue is to resolve this many 
	not many. Here we have a many to optionally one -- it is not obvious why a clinical document may at most refer to one intent or order.  
	Something is wrong here.
	
	Since the many to many between Service_event and Clin. D.H. is best resolved through an associative class, that class would have a type 
	code, and that type code could distinguish the various ways a service may be cited in a document.
	C04-R091.01.05
	Wednesday, October 13, 1999	Page 55 of 79

	Service_intent_or_order.clarification_phon	A
	Telephone number to call for clarification of request or other information regarding the order
	
	Rationale: 
	
	OpenIssue:
	mapped	Actor
	either the phone or other contact of the orderer himself, or a specially identified "clarifier" Actor type, that can link to an organization or care 
	team with its phone number (e.g. phone on the floor.)
	
	It is unreasonable to mention a phone in isolation and specifically for one order!
	C04-R091.03.00	2.3.1
	Service_intent_or_order.entering_device_cd	A
	Identifier of the physical device (terminal,PC) used to enter the order
	
	Rationale: 
	
	OpenIssue:  This may need to be addressed by CQ and/or Vocab and/or Security to refine the syntax and semantics of this concept since this
	 attribute definition seems to be bad.
	mapped with issues	Target
	a very special target deserves a very speial type code: "order entry device".
	
	Note that the use case for this thing rests on extremely shaky ground. What is it for? Can it even be known in the world of Web-based virtual 
	cyber terminals?  What is it still useful for in the world of sophisticated (and by the way legally required) authentication and access control 
	techniques?
	C04-R091.04.00	2.3.2
	Service_intent_or_order.escort_required_ind	A
	An indicator that the patient needs to be escorted to the diagnostic service department.  Note:  The nature of the escort requirements is 
	captured in another attribute.  Codes include Required; Not Required; Unknown.
	
	Rationale: 
	
	OpenIssue:  Do these three states make this a code, or is the state "Unknown" a flavor of null?
	
	OpenIssue:
	mapped	Actor
	of type "escort".  Usually an actor of a transportation service order.
	C04-R091.03.00	2.3.1
	Service_intent_or_order.expected_performance_time_qty	A
	Time expected to perform this service instance for the target.
	
	Rationale: 
	
	OpenIssue:
	mapped	Service.total_time
	of the ordered service. The width of the ordered occurrence inteval.
	C04-R091.01.16	2.2.1.6	GTS
	Wednesday, October 13, 1999	Page 56 of 79

	Service_intent_or_order.filler_order_id	A
	This is a permanent identifier for an order and its associated observations.  It is assigned by the order filling (receiving) application.  It identifies
	 an order uniquely among all orders from a particular filling application (e.g., clinical laboratory).
	
	Rationale: Filler and placer order id's are alternate keys to the class.
	
	OpenIssue:  Filler and Placer numbers include the system responsible for placing and filling an order.  The TII is not as explicitly bound to these 
	two concepts and these two data items may have to be added back into the SIOO class in some way.
	clearly mapped	Service.id
	
	Note: why does RIM092 say "and it's associated observations" when observations are separate service event instances?
	C04-R091.01.11	2.2.1.1	SET<II>
	Service_intent_or_order.intent_or_order_cd	A
	Distinguishes an intent from an order.
	
	Rationale:  Attributue is designated as _cd in anticipation of future expansion in usage.
	
	OpenIssue:  Need code examples.  Also, should this be a Boolean (_ind) rather than _cd?
	mapped	Service.mood_cd
	is either "intent" or "order". Even RIM092 did not escape without a mood code :-)  Future expansion in usage? Mood code again? :-)
	C04-R091.01.12	2.2.1.2	SET<CV>
	Service_intent_or_order.join_cd	A
	Designates whether two or more succeeding intents_or_orders, as specified in Service_intent_or_order_relationship, are to be joined with 
	and-logic or with or-logic.
	
	OpenIssue:  This concept will be addressed in the project analysing timing/quantity.
	clearly mapped	Service_relationship.join_cd
	This attribute was introduced into RIM087 by the USAMP-I.  It was meant to support Workflow specification, but the Workflow specification 
	has never been completed.  USAMP-II has taken this attribute into the Service_relationship class and has defined it completely so it is now the 
	first time that it's useable.  There are no issues of backwards compatibility.
	C04-R091.02.18	2.4.1.8	CV	W
	Service_intent_or_order.order_id	A
	A unique identifier for the patient service order.
	clearly mapped	Service.id
	C04-R091.01.11	2.2.1.1	SET<II>
	Service_intent_or_order.order_placed_dttm	A
	The date and time the order was placed.
	
	Rationale:  To provide date-time precision required for representing pathways.
	mapped with issues	Service.status_cd
	wrapping the status in a history item and keeping past statuses in a history list.  That way any life cycle state can be kept with its time stamp 
	rather than to clutter the model with slotted time-stamp attributes.
	C04-R091.01.15	2.2.1.5	CV
	Wednesday, October 13, 1999	Page 57 of 79

	Service_intent_or_order.placer_order_id	A
	A composite identifier of a service order.  Including the order id and the ordering application.
	
	Rationale: Filler and placer order id's are alternate keys to the class.
	
	OpenIssue:
	mapped	Service.id
	C04-R091.01.11	2.2.1.1	SET<II>
	Service_intent_or_order.planned_patient_transport_cd	A
	code or free text comments on special requirements for the transport of the patient to the diagnostic service department.  If coded requires a 
	user-defined table.
	
	Rationale: 
	
	OpenIssue:  Need code examples.
	mapped	Transportation
	associated with the service order. Transportation is a service that deserves its own management, including ordering, scheduling, billing, etc.  
	The undefined code was non-interoperable, the explicit transport service will be interoperable.
	C04-R091.11.00	2.6.6
	Service_intent_or_order.report_results_to_phon	A
	A phone number to be used to report results from the service order.
	
	Rationale: This attribute represents OBR-17-250 (Order Callback Phone Number) and must be differentiated from ORC-14-228 (Call Back 
	phone number), which has a different meaning.
	mapped with issues	Actor
	Rather than free-floating phone numbers, we associate phone numbers with Stakeholders and include results recipients in the set of Actors 
	on the order.  Usually the orderer will receive notification, but a tracker may be added as well.  Whether or not results should be reported 
	through the phone depends on local business rules and on the attribute Service.priority_cd.
	C04-R091.03.00	2.3.1
	Service_intent_or_order.reporting_priority_cd	A
	A code indicating the reporting priority of the patient service order when the reporting priority is specified independent of the processing 
	priority.  Allowable reporting prioritieis are call back results; rush reporting.
	
	OpenIssue:  
	mapped	Service.priority_cd
	includes both: processing and reporting priority since both are highly interdependent.
	C04-R091.01.25	2.2.1.15	SET<CV>	{R}
	Wednesday, October 13, 1999	Page 58 of 79

	Service_intent_or_order.secondary_identification_txt	A
	A weak identifier assigned by the filler for internal use. Typcially used for the Accession Number.
	
	Rationale:  To provide for communication of accession number-like identifiers, which are often communicated in the filler text field of a V2.3 
	message.
	
	Open Issue: if this captures the accession number of a specimen, it should be moved to collected_specimen_sample.
	mapped	Service.id
	the non-uniqueness due to roll-overs is not a severe problem in the Service.id, as long as a good identifier is also available and preferrably 
	used by the system that also issues these accession numbers.
	C04-R091.01.11	2.2.1.1	SET<II>
	Service_intent_or_order.service_body_site_cd	A
	Body site where service is to be performed.  Example sites are ears, arm, eye.
	
	Rationale: 
	
	OpenIssue:
	clearly mapped	Service.body_site_cd
	C04-R091.01.19	2.2.1.9	CD
	Service_intent_or_order.service_body_site_modifier_cd	A
	Site modifier describing the site where the service should be performed.  For example, the site could be anticubital foss, and the site modifier 
	"right." 
	
	Rationale: 
	
	OpenIssue:  There is some kind of problem with this approach to representing body site; this problem extends to other multi-attribute sets that 
	must be addressed by CQ and Vocab.  See harm399 notes..  This is of interest to scheduling.  Need compositional grammar that makes 
	semantic sense.
	mapped	Service.body_site_cd
	modifiers is what the Code Phrase within the CD data type is for.
	C04-R091.01.19	2.2.1.9	CD
	Service_intent_or_order.status_cd	A
	A code indicating the lifecycle status of the patient service intent or order.  See state/transition model for an exhaustive list of lifecycle states.

	clearly mapped	Service.status_cd
	C04-R091.01.15	2.2.1.5	CV
	Service_intent_or_order.status_dttm	A
	Indicates the date and time that a status, is entered or changed.
	mapped with issues	Service.status_cd
	as a history item on the most recent status, or as a complete timed life cycle history.
	C04-R091.01.15	2.2.1.5	CV
	Wednesday, October 13, 1999	Page 59 of 79

	Service_intent_or_order.status_reason_cd	A
	Explanation of the reason for the status. examples: order entry error; patient refused, contraindicted
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Service.status_cd
	Note that this code is not interoperable since it is not defined.  Note also that this needs more analysis work.   The suggested values are 
	certainly admissible status codes for the status code itself, so why not defining these right in the status code?
	C04-R091.01.15	2.2.1.5	CV
	Service_intent_or_order.transport_arranged_ind	A
	Indicator of whether transport arrangements are known to have been made.  Conded concepts are Arranged; Not Arranged; Unknown.
	
	Rationale: 
	
	OpenIssue:  Do these three states make this a code, or is the state "Unknown" a flavor of null?
	mapped	Service.status_cd
	of an associated Transport service.
	C04-R091.01.15	2.2.1.5	CV
	Service_intent_or_order.transport_arrangement_responsibility_cd	A
	An indicator of who is responsible for arranging transport of the patient to the planned diagnostic service.  Examples: Requester, Provider, 
	Patient
	
	Rationale: 
	
	OpenIssue:
	mapped	Actor
	of an associated Transport service.
	C04-R091.03.00	2.3.1
	Service_intent_or_order.transport_mode_cd	A
	A code indicating how (or whether) to transport a patient.
	
	Coded concepts include:  cart; examining devices goes to patient location; wheelchair; patient walks to diagnostic service.
	
	OpenIssue:
	mapped	Service.type_cd
	of an associated Transport service.
	C04-R091.01.13	2.2.1.3	CD
	Service_intent_or_order_relationship
	Service_intent_or_order :: is_source_for(0..n) :: Service_intent_or_order_relationship :: has_as_source(1..1)	RAD
	clearly mapped	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)
	C04-R091.02.02
	Wednesday, October 13, 1999	Page 60 of 79

	Service_intent_or_order :: is_target_for(0..n) :: Service_intent_or_order_relationship :: has_as_target(1..1)	RAD
	clearly mapped	Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)
	C04-R091.02.03
	Service_intent_or_order_relationship	C
	Associates a composite or dependent intent or order (the target) with another intent or order (the source) which is related to the target in 
	some way.  Allows specification of constraints for each association.
	
	Rationale:  Routine order sets, clinical trials, and pathways require groupings of services such as panels or "batteries" of unlike tests 
	delivered at one time, the same tests delivered along a timeline, or a combination of these concepts.  The same grouping relationships captured
	 in the Master_service need to be maintained as the service is planned or ordered.
	mapped	Service_relationship
	C04-R091.02.00	2.4
	Service_intent_or_order_relationship.constraint_txt	A
	Textual description of any arbitrary constraint on the source when associated with the target.
	
	Rationale:
	mapped	Service_relationship
	A constraint is a criterion linked to the service through a service relationship of type "has-precondition".   It can be fully coded for 
	interoperable automated communication. For backward compatibility the constraint can be represented just as free text in the Service.descr 
	attribute of the criterion service.
	C04-R091.02.00	2.4
	Service_intent_or_order_relationship.reflex_testing_trigger_rules_desc	A
	A description of the rules that trigger reflex testing for an intended or ordered service.
	
	Rationale:
	mapped	Service
	in trigger mood, linked through a service relationship of type trigger with a master service that is invoked on that trigger.
	C04-R091.01.00	2.2
	Service_intent_or_order_relationship.relationship_type_cd	A
	Specifies the basis for the association of the source to the target.
	
	Rationale:  
	OpenIssue:  Need code examples.
	clearly mapped	Service_relationship.type_cd
	C04-R091.02.11	2.4.1.1	CV
	Service_reason
	Wednesday, October 13, 1999	Page 61 of 79

	Service_reason	C
	A class which captures the reason(s) for a service when instantiated for a particular target of service by a particular participant in the 
	service e.g., a free text reason, coded value(s), or associations with prior service_event(s).
	
	Rationale:  Regulatory agencies demand reasons for services e.g., 1500 billing forms.  Frequently, a prior observation is the reason for a 
	treatment or a prior treatment is the reason for an observation.
	mapped	Service_relationship
	of type "has_reason"
	C04-R091.02.00	2.4
	Service_reason :: has_as_evidence(0..1) :: Service_event :: is_evidence_for(0..n)	RAS
	Rationale:
	mapped	Service_relationship :: has_target(1..1) :: Service :: is_target_for(0..*)
	pointing to the other service (event) that is the reason for the source service.
	C04-R091.02.03
	Service_reason :: is_reason_for(0..1) :: Service_event :: has_as_reason(0..n)	RAS
	mapped	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)
	to a Service_relationship of type "has reason"
	C04-R091.02.02
	Service_reason :: is_reason_for(0..1) :: Service_intent_or_order :: has_as_reason(0..n)	RAS
	Rationale:
	mapped	Service_relationship :: has_source(1..1) :: Service :: is_source_for(0..*)
	to a Service_relationship of type "has reason"
	C04-R091.02.02
	Service_reason.reason_txt	A
	Capture free text for the reason for a service event when the connection to another service event is not known (connection as a reason).
	mapped	Service.descr
	of the target of the has-reason link.
	C04-R091.01.14	2.2.1.4	ED
	Service_scheduling_request
	Master_service :: is_requested_by(0..n) :: Service_scheduling_request :: requests(1..1)	RAD
	mapped	Service_relationship
	of type_cd "instantiates" linking the Service in schedule request mood (SCH) as source with the Service in definition mood as target of the 
	Service_relationship.
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 62 of 79

	Service_scheduling_request	C
	Request information about various kinds of services that are controlled by a schedule.
	
	Rationale: Currently in 2.3
	
	OpenIssue: Should services be handled separately from resources?  Make certain that resource requests for scheduling are different from 
	ordered service requests in Orders.
	
	OpenIssue:  The definition does not encompass notifications (where it is not a request).
	mapped	Service
	in scheduling request mood.
	C04-R091.01.00	2.2
	Service_scheduling_request.allowable_substitutions_cd	A
	A code indicating whether the identified service can be substituted with an equivalent service.
	
	Rationale: Currently in 2.3
	
	OpenIssue:  Need code examples.  Also, should this be a Boolean (_ind) rather than _cd?
	clearly mapped	Service.substitution_cd
	C04-R091.01.24	2.2.1.14	CV	N
	Service_scheduling_request.duration_qty	A
	The duration for which the service is requested for this appointment, if it is different than the overall duration of the appointment
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	mapped	Service.total_time
	the duration is the width of an occurrence interval in total_time.
	C04-R091.01.16	2.2.1.6	GTS
	Service_scheduling_request.start_dttm	A
	Date and time this service is requested for the appointment.
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	mapped	Service.total_time
	the low boundary of an occurrence interval specifies the start.
	C04-R091.01.16	2.2.1.6	GTS
	Wednesday, October 13, 1999	Page 63 of 79

	Service_scheduling_request.start_offset_qty	A
	The offset that this service is requested for the appointment, expressed in units of time relative to the scheduled start date/time of the 
	appointment.
	
	Rationale: Currently in 2.3
	
	OpenIssue:  How does this attribute work with the start_dttm for the request.  This offset is relative to the appointment and would apopear to 
	present a conflict with the other attribute.
	mapped	Service_relationship.pause_qty
	A service that is part of a larger entity (service) is associated as a service_relationship of type plan-component.  Dependency can be 
	expressed without having to refer to time by the sequence_nmb that establishes an ordering among plan components.  Alternatively the 
	services may be given all the same sequence number so they start all together with the beginning of the super service DELAYED by the 
	pause_qty.  This timing of services is less common than sequencing and should be used only when it is appropriate.
	C04-R091.02.15	2.4.1.5	PQ	0 s	~ 1 s
	Service_scheduling_request.status_cd	A
	A code that describes the request status of scheduling a service, from the point of view of the filler application.
	
	Rationale: Currently in 2.3
	
	OpenIssue:
	clearly mapped	Service.status_cd
	C04-R091.01.15	2.2.1.5	CV
	Target_participation
	Collected_specimen_sample :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)	RAD
	Rationale:  Replaces association Collected_specimen_sample is_used_during Service_event.
	clearly mapped	Target :: participation_of(0..1) :: Material :: participates_as(0..*)
	C04-R091.04.04
	Living_subject :: is_target_of(0..n) :: Target_participation :: has_as_target(0..1)	RAD
	Rationale:  The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each 
	Target_participation instance to select the appropriate target from among the possible targets.
	clearly mapped	Target :: participation_of(0..1) :: Living_subject :: participates_as(0..*)
	C04-R091.04.05
	Master_patient_service_location :: is_target_for(0..n) :: Target_participation :: has_as_target(0..1)	RAD
	Rationale:  replaces associations:  Patient_service_location receives Treatment_service_dispense - Patient_service_location 
	receives_medication_dispense_recorded_on Treatment_service_give - Patient_service_location receives_medication_delivery_specified_on 
	Treatment_intent_or_order_revision.
	
	Rationale:  The Target_participation class cannot be subject to a mandatory connection to any particular target, in order to allow each 
	Target_participation instance to select the appropriate target from among the possible targets.
	mapped	Target :: participation_of(0..1) :: Material :: participates_as(0..*)
	… since service location is a role of material.
	C04-R091.04.04
	Wednesday, October 13, 1999	Page 64 of 79

	Target_participation	C
	A role class that captures the various roles played by the recipient(s) of a service (including people, organizations, things, animals, etc.).
	
	Rationale:  Since multiple entities may participate in the reception of services as particular targets of a service, a role class is needed to 
	capture the multiple roles these participants play in receiving a service from a provider of a service.
	clearly mapped	Target
	C04-R091.04.00	2.3.2
	Target_participation :: is_target_of(0..1) :: Service_event :: has_as_target(0..n)	RAS
	Rationale:  The Target_participation class may identify a target for either a Service_intent_or_order or for a Service_event.  It therefore cannot
	 have a mandatory connection to either of those classes.  We are lacking the formalism to indicate that one of these two relationships MUST 
	be in effect for each Target Participation instance.
	clearly mapped	Target :: in(1..1) :: Service :: has(0..*)
	Refer to Actor for an explanation of these association names.
	C04-R091.04.02
	Target_participation :: is_target_of(0..1) :: Service_intent_or_order :: has_as_target(1..n)	RAS
	Rationale:  The Target_participation class may identify a target for either a Service_intent_or_order or for a Service_event.  It therefore cannot
	 have a mandatory connection to either of those classes.  We are lacking the formalism to indicate that one of these two relationships MUST 
	be in effect for each Target Participation instance.
	clearly mapped	Target :: in(1..1) :: Service :: has(0..*)
	Refer to Actor for an explanation of these association names.
	C04-R091.04.02
	Target_participation.participation_type_cd	A
	The nature of purpose of the target's participation.  Examples:  subject, beneficiary, receiver, user, specifier.
	
	Rationale:
	clearly mapped	Target.type_cd
	C04-R091.04.11	2.3.2.1	SET<CV>
	Target_participation.tmr	A
	Any combination of the effective date and time of the target participation, the termination date and time for the target participation , and the 
	elapsed time during which the target participation is in effect.
	
	Rationale:  
	clearly mapped	Target.tmr
	C04-R091.04.12	2.3.2.2	SET<CV>
	Treatment_intent_or_order
	Wednesday, October 13, 1999	Page 65 of 79

	Service_intent_or_order :: generalizes(1..1) :: Treatment_intent_or_order :: specializes(1..1)	RGD
	mapped	Medication is specialization of Service
	C04-R091.06.01
	Treatment_intent_or_order	C
	An authoritative direction or instruction concerning the dispensement of medication to a patient.
	
	Rationale:  Conformance to new name for generalization.
	mapped	Medication
	in "intent" or "order" mood.
	
	Note that the renaming to Medication is because the generalization to Treatment is not entirely possible.  This class is clearly designed with 
	pharmacologic treatment in mind, and all other uses for other treatment modalities are accidential or retro-fit.  The Medication paradigm to 
	treatment fits well for the application of a therapeutic agent into the patient, via a certain route, and in a certain dose and dose form.  This 
	paradigm is applicable for Medication using gases (oxygen treatment, anesthesia, ICU ventilator treatement) or for parenteral nutrition.  It might 
	be applicable to nuclear medicine and radiotherapeutic services, but that has not been validated.
	
	Certainly there is a host of treatments that do not fit very well into this medication paradigm. Most notably physiotherapy, ergotherapy, 
	chiropraxis, with a slippery slope to surgical procedures. Not to mention psychotherapy at all.  Retrofitting these modalities to dose and route 
	is not appropriate. 
	
	In downsizing the term Treatment to Medication, the USAMP-II does not take away any functionality, it is just more humble in not pretending that
	 it covers all kinds of treatments that neither HL7 v2.x nor RIM092 nor USAMP-I and II ever did cover.
	C04-R091.06.00	2.6.3
	Treatment_intent_or_order :: has_parts(1..n) :: Treatment_intent_or_order_revision :: is_part_of(1..1)	RCS
	mapped	Service_relationship
	of type "is revision of" from a revision to a previous order(revision).
	C04-R091.02.00	2.4
	Treatment_intent_or_order.indication_id	A
	This field contains the identifier of the condition or problem for which the drug/treatment was prescribed.
	
	Rationale: This attribute standards in for a relationship to an "indication" class, which does not currently exist in the RIM.
	
	OpenIssue:  
	mapped with issues	Service_relationship
	Indication is linked through a Service realtionship of type "reason" to the observation or condition constituting the indication.
	
	The RIM092 uses the term "identifier" which is unfortunate.  It does suggest a straight MDF violation by suggesting a forreign key (one attribute
	 citing the identifier of another class.)  If what is meant is really a coded concept of the diagnosis constituting the indication, then the attribute 
	type is wrong.
	
	In any way this is once more an example where USAMP-II removes free-floating codes (or dysfunctional identifiers.)
	C04-R091.02.00	2.4
	Wednesday, October 13, 1999	Page 66 of 79

	Treatment_intent_or_order.ordering_providers_instruction_txt	A
	Free form instructional text from the ordering provider for the treatment order.
	
	Rationale: 
	mapped	Service.descr
	of the Service in order mood. Note that in an order, any attribute is meant in an imperative or instructional sense. Hence the description of an 
	order is logically an instruction. No separate field for instructions is necessary.  This concurs with the policy that the Service.descr is the last 
	catch-all attribute for all free text, whereby the USAMP-II proposal makes structured and coded information much more easy to construct (e.g.,
	 through removing free-floating codes.)
	C04-R091.01.14	2.2.1.4	ED
	Treatment_intent_or_order.requested_give_strength_qty	A
	Specifies the strength of the medication as requested on the order, when it is not included in the Universal Service Identifier
	
	Rationale: 
	
	OpenIssue:
	clearly mapped	Medication.strength_qty
	C04-R091.06.14	2.6.3.4	PQ	1
	Treatment_intent_or_order.substitution_allowed_ind	A
	An indicator that a substitution medication is allowed.
	clearly mapped	Service.substitution_cd
	C04-R091.01.24	2.2.1.14	CV	N
	Treatment_intent_or_order_revision
	Treatment_intent_or_order_revision	C
	The collection of characteristics for a pharmacy treatment order that can be revised during the course of processing the order.  Pharmacy 
	encoding is an example of a process that may revise order characteristics.  This "revisions" class allows tracking of changes made to the 
	order, and representation of the order at any stage in its processing.
	
	Rationale:   Each instance of the class "Treatment_intent_or_order_revision" represents a revision of the original order.  There can be many 
	revisions for a single order.  Pharmacy encoding is only one example of such a revision.  The class name conveys this multiplicity of 
	specification.
	
	OpenIssue: Note that this is used to surface the information carred in the Pharmacy Encoded segment of v2.3, and this name ‘revision’ may 
	need to be changed to be more appropriate.
	mapped	Medication
	in order or intent mood, linked through a relationship of type is-revision-of with a previous order.
	C04-R091.06.00	2.6.3
	Wednesday, October 13, 1999	Page 67 of 79

	Treatment_intent_or_order_revision.dispense_package_method_cd	A
	the method by which treatment is dispensed, e.g., Traditional, unit-dose, floor stock, automatic dispensing
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Service.method_cd
	of a Supply service representing the dispensing.
	
	The use of this attribute, however, is ill-defined in HL7 v2.3 as well as RIM092.  The roster of example values for this code read like a 
	potpourie of interesting facts one might want to know, but is hardly cohesive?
	
	We need to know what concepts to map before we can definitely map them anywhere.
	C04-R091.01.18	2.2.1.8	CD
	Treatment_intent_or_order_revision.dispense_package_size_qty	A
	This field contains the size of package to be dispensed
	
	Rationale: 
	
	OpenIssue:
	mapped	Material_relationship.qty
	Dispense packages are modeled using the Material class.  The nesting of pills in packs and packs in cartons is handled very smoothly through 
	the Material_relationship.
	C04-R091.21.15	2.7.2.5	PQ
	Treatment_intent_or_order_revision.give_indication_id	A
	condition or problem for which the drug/treatment was prescribed
	
	Rationale:  This attribute stands in for a relationship to an "indication" class, which does not currently exist in the RIM.
	
	OpenIssue:  
	mapped	Service_relationship
	of type "has-reason" pointing to the indication.
	C04-R091.02.00	2.4
	Treatment_intent_or_order_revision.give_per_timeunit_cd	A
	The duration of time over which the pharmaceutical is to be administered when the ordered substance is to be administered continuously at a 
	prescribed rate (e,.g., certain IVs).  For example, if 300 ml are to be given, and the "give per time unit" is 2 hours, the rate is 150ml/hour 
	(300ml/2 hr) and the duration of this dose is 2 hours.
	
	Coded concepts include:  #days, #hours, #minutes (where # is any integer); total amount delivered - # units (where # is any integer, units as 
	in min_giv_qty); indefinite.
	
	This field is distinct from the "interval" component of the quantity/timing field, but it could be used in conjunction with it, as in give 150ml of NS 
	per hr for 2 hours, repeat twice a day.
	
	OpenIssue:  This should probably be a _qty attribute, but cannot be while the full set of coded concepts above is in effect.  Conisderations:  
	1.  "give" until total amount delivered = # Units"; is a restatement or revision of min_giv_qty.  Total amount to give should be coded in give 
	amounts, not here; when this code is used, a rate cannot be determined.  
	2.  "indefinite": can be a flavor of "null"
	3.  these two codes may be cut-and-paste holdovers from Q/T in the v2.3 spec.
	4.  without these two codes, this attribute can be expressed as a simple_qty with units.
	clearly mapped	Medication.rate_qty
	C04-R091.06.15	2.6.3.5	PQ	~ 1s
	Wednesday, October 13, 1999	Page 68 of 79

	Treatment_intent_or_order_revision.give_rate_qty	A
	This field contains the rate at which to administer treatment.
	mapped with issues	Medication.rate_qty
	Note that this field is redundant with the give-per-time-unit field. A dose per time unit is a rate!
	C04-R091.06.15	2.6.3.5	PQ	~ 1s
	Treatment_intent_or_order_revision.last_refilled_dttm	A
	Date and time of most recent refill or dose dispensed.
	
	OpenIssue:  Is this information known at the time of order revision or should this attribute be moved to Treatment_service_event?
	mapped	Service.total_time
	of the last dispense service.  Dispense services are Supply services for the therapeutic substance material.  All dispense services occur in 
	fulfillment of the dispense-part of the prescription (and are linked to the prescription through fulfills relationships.) The dispense events are 
	counted in the Service_relationship.sequence_nmb attribute.
	C04-R091.01.16	2.2.1.6	GTS
	Treatment_intent_or_order_revision.max_give_qty	A
	In a variable dose order, this is the maximum ordered amount.  In a nonvarying dose order, this field is not used.
	mapped	Medication.dose_qty
	may be states as a probability distribution to accommodate min/max doses in the semantically correct way.  Simple translations exist between 
	a min/max form and a probability distribution.
	C04-R091.06.13	2.6.3.3	PQ
	Treatment_intent_or_order_revision.min_give_qty	A
	This field is the ordered amount of substance to be administered in a single dose.  In a variable dose order, this is the minimum ordered 
	amount.  In a nonvarying dose order, this is the exact amount of the order.
	mapped	Medication.dose_qty
	may be states as a probability distribution to accommodate min/max doses in the semantically correct way.  Simple translations exist between 
	a min/max form and a probability distribution.
	C04-R091.06.13	2.6.3.3	PQ
	Treatment_intent_or_order_revision.needs_human_review_ind	A
	Indicates whether the pharmacist or non-pharmacist treatment supplier filling the order needs to pay special attention to the provider's 
	pharmacy/treatment instructions.
	mapped	Actor
	of type reviewer may ssign someone who should review the order.
	C04-R091.03.00	2.3.1
	Treatment_intent_or_order_revision.prescription_id	A
	Theprescription number as assigned by the pharmacy or treatment application.
	
	OpenIssue:  Is this information known at the time of order revision, or should this attribute be moved to Treatment_service_event?
	mapped	Service.id
	C04-R091.01.11	2.2.1.1	SET<II>
	Wednesday, October 13, 1999	Page 69 of 79

	Treatment_intent_or_order_revision.PTcomp	A
	Specification for one component of the ordered medication or treatment
	
	Rationale: 
	
	OpenIssue:
	mapped	Material
	Material and Material_relationship allow the detailled construction of recipe orders through material relationship types "has-ingerdient" and 
	subtypes thereof ("base", "additive", to be v2.3 compatible.)
	C04-R091.20.00	2.7
	Treatment_intent_or_order_revision.PTrout	A
	Specification for one route of administration for the ordered medication or treatment.  Specification includes route, site, administration device 
	and administration method.
	
	Rationale: 
	
	OpenIssue:
	mapped	Medication.route_cd
	plus Service.body_site_cd, Service.method_cd, and possibly Target of type device (that's what hides behind "PTrout".
	
	Different routing options are given as associated Medication services in option mood.  That is, one can specify multiple doses, doseforms, 
	routes, sites, all together (which is reasonable since an IV route will need a different dose than a PO route, something that Ptrout/RXR could 
	never handle!)
	C04-R091.06.12	2.6.3.2	CD
	Treatment_intent_or_order_revision.qt	A
	A means of specifying when the service described by the give notice is to be performed and how frequently.  It is a complex multicomponent 
	field that can have repeats.  The pharmacy or treatment department has the "authority" (and/or necessity) to schedule dispense/give events.  
	Hence, the pharmacy or treatment department has the responsibility to encode this scheduling information for the pharmacy service order item
	 and pharmacy service give notice.  The quantity/timing for the patient service order does not change: it always specifies the requested 
	give/dispense schedule of the original order 
	
	Rationale: 
	
	OpenIssue:
	mapped	Service.critical_time
	in the full fledged form of a General Time Specification, allows repeated occurrence intervals to be specified calendar depenent or based on 
	absolute time, or symbolically with time-like periodic events (e.g. HS at the hour of sleep).
	C04-R091.01.17	2.2.1.7	GTS
	Treatment_intent_or_order_revision.refills_allowed_nbr	A
	The total original number of refills.  Outpatient only.
	mapped	Service.max_repeat_nmb
	of the Supply order that embodies the dispense part of the prescription.  Note, a medication order is first and foremost an order to administer a
	 medication.  But it also includes dispense related instructions (e.g. pakcet size, refills, etc.) This is now separated by treating the dispensing 
	as a Supply service for material.  A refill dispense order is a repeatable order for supplies.
	C04-R091.01.22	2.2.1.12	INT	1
	Wednesday, October 13, 1999	Page 70 of 79

	Treatment_intent_or_order_revision.refills_doses_dispensed_nbr	A
	The number of refills /doses dispensed.  This field is required when a prescription is dispensed to an outpatient.  It is not relevant to inpatient 
	treatment orders.
	
	OpenIssue:  1)  the name and description for this attribute, as extracted from v2.3, are very confusing.  Need to discuss difference between 
	refills and doses, and clarify when this field refers to which.  2) is this information known at the time of order revision, or should this attribute 
	be moved to Treatment_service_event?
	mapped	Service_relationship.sequence_nmb
	of the link between the Dispense/Supply order and the dispense events.
	
	BTW: The v2.3 description is pretty clear: the RXD tracks refills while the RXA tracks doses administered.  These are different fields.
	C04-R091.02.13	2.4.1.3	INT	1
	Treatment_intent_or_order_revision.substitution_status_cd	A
	Indicates whether the medication encoded is a substitution for the medication ordered.  In the case of substitutions, includes the nature and/or 
	reason for the substitution.  Coded concepts include:  No substitute; generic substitution; therapeutic substitution; Substitution allowed - 
	pharmacist selected product; Substitution allowed - patient requested product; Substitution not allowed - brand drug mandated by law.
	
	OpenIssue:
	mapped	Service.substitution_cd
	C04-R091.01.24	2.2.1.14	CV	N
	Treatment_intent_or_order_revision.total_daily_dose_qty	A
	the total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.
	
	Rationale: 
	
	OpenIssue:
	mapped with issues	Medication.dose_check_qty
	See USAMP-II specification on this attribute. This is a very special attribute for a special use case.
	C04-R091.06.16	2.6.3.6	PQ
	Treatment_intent_or_order_revision.treatment_suppliers_instruction_cd	A
	the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing/administering the order
	
	Rationale: 
	
	OpenIssue:  Need code examples.
	mapped	Service.descr
	or Actor.note_txt
	C04-R091.01.14	2.2.1.4	ED
	Treatment_service_administration
	Treatment_service_administration	C
	Actual administration of medication as part of a pharmacy treatment.
	mapped	Medication
	in event mood
	C04-R091.06.00	2.6.3
	Wednesday, October 13, 1999	Page 71 of 79

	Treatment_service_administration.administered_per_timeunit_cd	A
	The duration of time over which the phatmaceutical was administered when the ordered substance was administered continuously at a 
	prescribed rate (e.g., certain IVs).  For example, if 300 ml were given, and te "give per time unit" is 2 hours, the rate is 150ml/hour (300ml/2 hr).
	 and the duration of this dose is 2 hours.
	
	Rationale:  The V2.3 RXA field "Administered per (time unit)" combines the meanings of "per_time_unti" and "rate," which are separate 
	concepts with separate fields and separate definitiosn for the other RX segments in V2.3.  This is probably a cut-and-paste errors in the RXA.
	  For the RIM, two separate attributes have been established corresponding to RXA-12-354.  These attributes are 
	“administered_per_timeunit_cd” and “ administered_rate_qty”, whose names and descriptions parallel attributes in the classes supporting 
	treatment orders and treatment give notices.For the RIM, two separate attributes have been established corresponding to RXA-12-354.  These
	 attributes are "administered_per_timeunit_cd" and  "administered_rate_qty", whose names and descriptions parallel attributes in the classes 
	supporting treatment orders and treatment give notices.
	
	OpenIssue:  Open Issue: This should probably be a _qty attribute, but cannot be while the full set of coded concepts above is in effect. 
	Considerations: 
	1. "give until total amount delivered = # units"; is a restatement or revision of min_give_amt_qty.  Total amount to give should be coded in give 
	amounts, not here;  when this code is used, a rate cannot be determined.
	2. "indefinite": can be a flavor of ‘null'
	3. these two codes may be cut-and-paste holdovers from Q/T in the V2.3 spec.
	4. without these two codes, this attribute can be expressed as a simple _qty with units.
	mapped	Medication.rate_qty
	C04-R091.06.15	2.6.3.5	PQ	~ 1s
	Treatment_service_administration.administered_rate_qty	A
	The rate at which this medication was administered.
	
	Rationale:  Rationale: the V2.3 RXA field "Administered per (time unit)" combines the meanings of "per_time_unit" and "rate", which are 
	separate concepts with separate fields and separate definitions for the other RX segments in V2.3.  This is probably a cut-and-paste error in 
	the RXA.  For the RIM, two separate attributes have been established corresponding to RXA-12-354.  These attributes are 
	"administered_per_timeunit_cd" and  "administered_rate_qty", whose names and descriptions parallel attributes in the classes supporting 
	treatment orders and treatment give notices.
	mapped	Medication.rate_qty
	see above …
	C04-R091.06.15	2.6.3.5	PQ	~ 1s
	Treatment_service_administration.administration_nbr	A
	The ordinal number of this administration in a sequence of administrations. This field starts with 1 the first time that medication is administered 
	for this order.  Increments by one with each additional administration of medication.
	
	Rationale:  
	
	Open Issue:  This field was deleted under USAMP (U005), because it’s usage prior to USAMP was as a linking mechanism between 
	dispenses, gives and administrations.  This functionality was taken over by the Service_event_relationship class.  The reinstatement in 
	March99 does not give a rationale for this attribute’s existence, other than that it represents a V2.3 field.  Since it’s V2.3 usage is already 
	supported in the RIM, this is not a sufficient rationale for reinstatement.  The steward should reconsider the need for this attribute, and provide
	 a better rationale.
	mapped	Service_relationship.sequence_nmb
	of the "fulfills" relationship linking the Medication event with the order (or intent.)
	C04-R091.02.13	2.4.1.3	INT	1
	Wednesday, October 13, 1999	Page 72 of 79

	Treatment_service_administration.administrators_notes_cd	A
	This field contains notes from the provider administering the medication.  May describe a custom IV, mixture, or salve, for example.
	mapped	Actor.note_txt
	however, use the appropriate sturcture in the Material class for providing any functional information.
	C04-R091.03.13	2.3.1.3	ED
	Treatment_service_administration.completion_status_cd	A
	Status of treatment administration event
	
	Rationale: 
	
	OpenIssue:
	clearly mapped	Service.status_cd
	C04-R091.01.15	2.2.1.5	CV
	Treatment_service_administration.substance_refusal_reason_cd	A
	This field contains the reason the patient refused the medical substance.  Any entry in the field indicates that the patient did not take the 
	substance
	
	Rationale: 
	
	OpenIssue:
	mapped	Actor.note_txt
	with the patient being an dissenting Actor
	C04-R091.03.13	2.3.1.3	ED
	Treatment_service_dispense
	Treatment_service_dispense	C
	Notification of a pharmacy treatment dispense.
	mapped	Supply
	C04-R091.08.00	2.6.7
	Treatment_service_dispense.dispense_package_method_cd	A
	the method by which treatment is dispensed, e.g., Traditional, unit-dose, floor stock, automatic dispensing
	
	Rationale: previously unmatched V2.3 field
	
	OpenIssue:
	mapped with issues	Service.method_cd
	not clear what this is or does.  But can be mapped for sure once we know what to map.
	C04-R091.01.18	2.2.1.8	CD
	Wednesday, October 13, 1999	Page 73 of 79

	Treatment_service_dispense.dispense_package_size_qty	A
	This field contains the size of package to be dispensed
	
	Rationale: 
	
	OpenIssue:
	mapped	Material_relationship.qty
	linking a package with its content.
	C04-R091.21.15	2.7.2.5	PQ
	Treatment_service_dispense.needs_human_review_ind	A
	An indicator that the pharmacist filling the order needs to pay special attention to provider instructions.
	mapped with issues	Actor
	of type reviewer allows to specify the requirement for review.
	
	Alternatively we can put in the attribute Service.requires_review_ind.
	C04-R091.03.00	2.3.1
	Treatment_service_dispense.suppliers_special_dispensing_instruction_cd	A
	Special instructions from the pharmacy or treatment supplier to the provider administering the order.
	
	Rationale: 
	
	OpenIssue:  If these are really special instructions as per the description, are they really coded?  If so, give examples.
	mapped	Service.descr
	C04-R091.01.14	2.2.1.4	ED
	Treatment_service_dispense.total_daily_dose_qty	A
	This field contains the total daily dose being dispensed.
	
	Rationale: 
	mapped	Medication.dose_check_qty
	C04-R091.06.16	2.6.3.6	PQ
	Treatment_service_event
	Care_event :: generalizes(1..1) :: Treatment_service_event :: specializes(1..1)	RGD
	Rationale:  Allows interrelationship with other service events.
	mapped	Medication is specialization of Service
	C04-R091.06.01
	Wednesday, October 13, 1999	Page 74 of 79

	Treatment_service_event	C
	A type of service event in which a pharmacy or treatment service is performed.
	mapped	Medication
	note that dispensing is excluded!!! Dispensing is not a medication service, it's a supply. Medication service is only the medically relevant 
	administration of the substance, not the change of possessorship.
	C04-R091.06.00	2.6.3
	Treatment_service_event.amount_qty	A
	The amount of dose form items diispensed, scheduled or administered. The amount can be a dimensionless number for discrete dose forms 
	such as tablets, in which case the amount is the number of tablets (Note that tablets can be broken into half.) For continuously divisible 
	dosage forms (e.g., fluids), the amount is be a quantity convertible to the unit of the strength's denominator (e.g., 10 ml). In any way, the total 
	dose (i.e. the amount of substance of a pharmaceutical agent) is calculated through dose = strength × amount. The total administered dose is 
	not reported in any additional attribute, since this would lead to unnecessary redundancies.
	
	Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type 
	that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was 
	triggered by the needs of the Government SIG.
	
	OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.
	
	OpenIssue:  This attribute combines a pure number concept (# of dosage form units) with a measured quantity concept (quantity of 
	therapeutic material).  This needs to be addressed in the treatment model revision effort.
	mapped	Medication.dose_qty
	C04-R091.06.13	2.6.3.3	PQ
	Treatment_service_event.body_site_cd	A
	Some routes, such as i.m. or i.v., may have different body sites (e.g. i.m.: m. deltoideus right or left arm, m. gluteus, m. quadriceps femoris left 
	or right leg.)
	
	Rationale:  May be required for some routes.  Since Summer 1997 it was hidden in a composite data type that does not exist.  Until we fully 
	understand the model it is better to model this explicitly than to hide it in a data type.
	
	OpenIssue:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.
	mapped	Service.body_site_cd
	C04-R091.01.19	2.2.1.9	CD
	Treatment_service_event.dosage_form_cd	A
	The unit of administration, i.e. the kind of thing that is administered, or the form of the pharmaceutical substance. (e.g., things like: tablet, 
	suppository, spray, vial, pre-filled syringe, etc.)
	
	Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type 
	that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was 
	triggered by the needs of the Government SIG.
	
	OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.
	mapped	Medication.form_cd
	C04-R091.06.11	2.6.3.1	CD
	Wednesday, October 13, 1999	Page 75 of 79

	Treatment_service_event.indication_id	A
	This field contains the identifier of the condition or problem for which the treatment service was established.  
	
	Rationale: This attribute stands in for a relationship to an "indication" class, which does not currently exist in the RIM.
	
	OpenIssue:  Need code examples.
	mapped	Service_relationship
	see indication above …
	C04-R091.02.00	2.4
	Treatment_service_event.prescription_id	A
	This field contains the prescription number as assigned by the pharmacy or treatment application   This field is equivalent in uniqueness to the 
	pharmacy/treatment supplier filler order number.  At some sites, this may be the pharmacy/treatment supplier (internal) sequential form.  At 
	other sites, this may be an external number.
	
	Rationale:  This attribute is an alternate id for the class in which this attribute resides, but only if a prescription exists for the service.  Does not
	 reference an instance in any other class.
	Service_event.filler_id (from the generalization) is the primary id.
	mapped	Service.id
	C04-R091.01.11	2.2.1.1	SET<II>
	Treatment_service_event.PTcomp	A
	Specification for one component of the treatment service.  Specification includes treatment code & name, dosage form, strength, and amount 
	to be administered (minimum and maximum).   A single treatment service may encompass multiple treatment components.  A common reason 
	for multiple components is for specification of a compound medication such as a custom IV, mixture or salve.
	
	Rationale: 
	
	OpenIssue:
	mapped	Material
	see above
	C04-R091.20.00	2.7
	Treatment_service_event.PTrout	A
	Specification for one route of administration for the treatment service. Specification includes route, site, administration device and 
	administration method. A single treatment service may involve several routes of administration.
	
	Rationale:  
	
	OpenIssue:
	mapped	Medication.route_cd
	plus others, see above
	C04-R091.06.12	2.6.3.2	CD
	Wednesday, October 13, 1999	Page 76 of 79

	Treatment_service_event.route_cd	A
	The entry path by which the substance is incorporated or otherwise directed to the desired center of effect (e.g., per os, intra venous, rectal,
	 nasal, per inhalationem, ...)
	
	Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type 
	that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was 
	triggered by the needs of the Government SIG.
	
	OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.
	mapped	Medication.route_cd
	C04-R091.06.12	2.6.3.2	CD
	Treatment_service_event.strength_qty	A
	The amount of substance in one item of dose form. Amount of substance can be a true amount of substance (e.g., 40 mmol), a mass (e.g., 
	250 mg), a volume (e.g., 10 ml), or some biochemical arbitrary quantity (e.g., arbitrary units, katal, U, i.U.) For all continuously divisible dose 
	forms, such as fluids or gases, strength is a concentration (e.g., 10 mg/ml, 1 %, 20 mmol/l). A dimensionless strength 1 (one) means that the 
	strength is undefined, and an undefined strength is equivalent to a strength of 1 (one).
	
	Rationale:  This is an essential attribute of any model that deals with medications. Since Summer 1997 it was hidden in a composite data type 
	that does not exist. Until we fully understand the model it is better to model this explicitly than to hide it in a data type. This change was 
	triggered by the needs of the Government SIG.
	
	OpenIssues:  The entire treatment model will be revised in cooperation with Orders, Vocabulary, and the Control TC. Due by the end of 1999.
	mapped	Medication.strength_qty
	C04-R091.06.14	2.6.3.4	PQ	1
	Treatment_service_event.substance_expiration_dttm	A
	Expiration date of the medication.
	
	Rationale: 
	mapped	Material.extent_tmr
	of Material associated as target … usually target of a dispense service.
	C04-R091.20.16	2.7.1.6	IVL<TS>
	Treatment_service_event.substance_lot_number_txt	A
	This field contains the lot number of the medical substance.
	
	Rationale:
	mapped	Material.lot_nmb
	C04-R091.20.17	2.7.1.7	ST
	Wednesday, October 13, 1999	Page 77 of 79

	Treatment_service_event.substance_manufacturer_cd	A
	This field contains the manufacturer of the medical substance.  Codes may come from NDC, MVX or some other coding system.
	
	Rationale: 
	
	OpenIssue:
	mapped	Responsibility
	of type manufacturer
	C04-R091.22.00	2.7.3
	Treatment_service_event.substitution_cd	A
	A code indicating the medication was a substitution for the one ordered.
	
	OpenIssue:  Need code examples.
	mapped	Service.substitution_cd
	C04-R091.01.24	2.2.1.14	CV	N
	Treatment_service_give
	Treatment_service_give	C
	The issuing of a pharmacy or treatment give notice.  The give notice establishes a datailed schedule of treatment for a specific period of time.
	mapped	Medication
	of special mood "give notice"
	C04-R091.06.00	2.6.3
	Treatment_service_give.give_per_timeunit_cd	A
	The duration of time over which the pharmaceutical is to be administered when the ordered substance is to be administered continuously at a 
	prescribed rate (e.g., certain IVs).  For example, if 300 ml are to be given, and the "give per time unit" is 2 hours, the rate is 150ml/hour 
	(300ml/2 hr) and the duration of this dose is 2 hours.
	
	Coded concepts include: #days, #hours, #minutes (where # is any integer); total amount delivered = # units (where # is any integer, units as 
	in min_give_qty); indefinite.
	
	This field is distinct from the"“interval" component of the quantity/timing field, but it could be used in conjunction with it, as in give 150ml of NS 
	per hr for 2 hour, repeat twice a day.
	
	Rationale:
	
	OpenIssue:  This should probably be a _qty attribute, but cannot be while the full set of coded concepts above is in effect. 
	Considerations: 
	1."“give until total amount delivered = # units"; is a restatement or revision of min_give_amt_qty.  Total amount to give should be coded in give 
	amounts, not here;  when this code is used, a rate cannot be determined.
	2. "indefinite": can be a flavor of ‘null'
	3. these two codes may be cut-and-paste holdovers from Q/T in the V2.3 spec.
	4. without these two codes, this attribute can be expressed as a simple _qty with units.
	mapped	Medication.rate_qty
	C04-R091.06.15	2.6.3.5	PQ	~ 1s
	Wednesday, October 13, 1999	Page 78 of 79

	Treatment_service_give.give_rate_qty	A
	This attribute allows the rate of administration (quantity per unit of time) to be specified directly, rather than calculated using the give quantity 
	and give per timeunit values.
	mapped	Medication.rate_qty
	C04-R091.06.15	2.6.3.5	PQ	~ 1s
	Treatment_service_give.needs_human_review_ind	A
	An indication that the pharmacist filling the order needs to pay special attention to the order notes.
	mapped with issues	Actor
	see above
	C04-R091.03.00	2.3.1
	Wednesday, October 13, 1999	Page 79 of 79