Affected RIM092 elements that are not mapped
	Advance_directive
	RIM092	Advance_directive.employment_related_ind
	An indication that the advance directive is employment related.
	
	To replace attribute previously inherited from Patient_clinical_item.
	
	OpenIssue:  Amplify definition.  Explain why directives would be employment related.
	USAMP-II	unmapped
	Alternatives are:
	a) a code in Service.interpretation_cd 
	b) an attribute in Service
	
	note that employment-relatedness may be assumed of observations as well.
	Assessment
	RIM092	Assessment
	A subclass of Service_event and a superclass that captures the data related to a kind of service that represents abstraction and interpretation of 
	data from a data source and includes observations, metaobservations, assignment of an observation or metaobservation to a problem list of allergy
	 list or goal e.g. lab results, question results, physical exam results, impressions problem list entry, allergy list entry, goal assignment, etc.  This 
	class is orthogonal to Care_event
	
	Rational:  Since multiple kinds of assessments are delivered as a healthcare service, a class is needed to record the nature of those assessments 
	and the resulting values(s) associated with those assessments.  An assessment is a kind of service that describes the collection and 
	interpretation of data from a data source and the nature of that data.  In this class, it also describes the value(s) associated with the action of data 
	collection and interpretation.  
	
	USAMP-II	dropped 
	Delete without replacement.  This class was an attempt at a taxonomy of Services which is not what a class diagram is used for.
	RIM092	Service_event :: generalizes(1..1) :: Assessment :: specializes(1..1)
	Rationale:  Since multiple kinds of assessments are delivered as a healthcare service, a class is needed to record the nature of those 
	assessments and the resulting value(s) association with those assessments.  An assessment is a kind of service that describes the collection and
	 interpretation of data from a data source and the nature of that data.  In this class, it also describes the value(s) associated with the action of data
	USAMP-II	dropped 
	Assessment is deleted without replacement.  These Assessment and Care_event classes were an attempt at a taxonomy of Services which is not
	 what a class diagram is used for.
	Care_event
	RIM092	Care_event
	A subclass of Service_event and a superclass that captures the data related to a kind of service that produces a change in the target of service 
	and includes medication administration, surgeries, teaching, dressing changes, therapeutic listening, etc.  This class is orthogonal to 
	Assessment_event.
	
	Rationale:  Since some healthcare services produce changes in the target of service, these actions need to be captured and statused with their 
	USAMP-II	dropped 
	This was an attempt at a taxonomy of Services in the class diagram, which is not what a class diagram is for.
	RIM092	Service_event :: generalizes(1..1) :: Care_event :: specializes(1..1)
	Rationale:  Allows interrelationship with other service events.
	USAMP-II	dropped 
	Care_event is deleted without replacement.  These Assessment and Care_event classes were an attempt at a taxonomy of Services which is not 
	what a class diagram is used for.
	Wednesday, October 13, 1999	Page 1 of 9

	Collected_specimen_sample
	RIM092	Collected_specimen_sample.action_cd
	Action to be taken with respect to the specimens that accompany or precede this order.  Allowable values: Add ordered tests to the existing 
	specimen (A); Generated order; reflex order (G); Lab to obtain specimen from patient (L); Specimen
	
	USAMP-II	abolished
	This modeling style is at odds with the MDF. An "action code" of HL7 v2.x is a hidden trigger event (sometimes overloaded with the meaning of a 
	state attribute.)  The code values suggest that this attribute manages the ordering of a specimen collection service, which has a straightforward 
	representation in USAMP -- even in the RIM092! Other uses seem to be the addition of services to an existing specimen, which also has a 
	straightforward representation in USAM and RIM092 alike.  This attribute is superflous in either model!
	Condition_node
	RIM092	Condition_node.employment_related_ind
	An indication that the condition under evaluation is employment related.
	
	Rationale:  To replace attribute previously inherited by Diagnosis from Patient_clinical_item
	
	OpenIssue:  Should this be handled as an explicit diagnosis  in Health_issue or should it be deleted completely, or does this require longitudinal 
	linkage through Condition_node?  
	
	OpenIssue:  This is a candidate for moving or complete removal.
	USAMP-II	unmapped
	Alternatives are:
	a) a code in Service.interpretation_cd 
	b) an attribute in Service
	
	note that employment-relatedness may be assumed of observations as well.
	Conditional_link
	RIM092	Service_event_relationship :: generalizes(1..1) :: Conditional_link :: specializes(1..1)
	USAMP-II	dropped 
	The specialization class is re-united with its genus, so the relationship is gone.  See comment under the specialization class.
	Consent
	RIM092	Consent :: generalizes(1..1) :: Advance_directive :: specializes(1..1)
	USAMP-II	dropped 
	Advanced directive is a concept in the vocabulary domain of Consent.type_cd.
	Judgement_link
	RIM092	Service_event_relationship :: generalizes(1..1) :: Judgement_link :: specializes(1..1)
	USAMP-II	dropped 
	The specialization class is re-united with its genus, so the relationship is gone.  See comment under the specialization class.
	Wednesday, October 13, 1999	Page 2 of 9

	Master_observation_service
	RIM092	Master_observation_service :: generalizes(1..1) :: Master_qualitative_observation :: specializes(1..1)
	USAMP-II	dropped 
	The peculiarities of the nature of observation values is contained in the Observation.value attribute of type ANY.  So, a descriptive class is not 
	needed (as we shall see below.)
	RIM092	Master_observation_service :: generalizes(1..1) :: Master_quantitative_observation :: specializes(1..1)
	USAMP-II	dropped 
	The peculiarities of the nature of observation values is contained in the Observation.value attribute of type ANY.  So, a descriptive class is not 
	needed (as we shall see below.)
	Master_quantitative_observation
	RIM092	Master_quantitative_observation.corresponding_SI_unit_of_measure_cd
	The SI units of measure, when these differ from the customary units of measure
	
	Rationale: 
	
	OpenIssue:
	USAMP-II	out-scoped
	Unit conversion is defined externally by the semantics of units.  The Unified Code for Units of Measure that is the preferred code for units to be 
	used in the data type Physical Quantities defines a methodology and the necessary constants for conversion between all convertible units.  
	
	The issue between SI and customary units is not as simple than it is implied by RIM092 here, since SI is an entire class of units, that still need to be 
	converted.
	RIM092	Master_quantitative_observation.delta_check_change_computation_method_cd
	Specifies whether the change for triggering a delta check warning is computed as a percent change or an absolute change.  Allowable methods 
	are:  "as percent" and "as absolute change."
	
	OpenIssue:
	USAMP-II	action for OO
	Delta checks are not yet mapped in detail.  Delta checks are derived observations that are used in some laboratories, and are only very rarely  
	used in clinical systems.  As derived observations, delta checks will map to Observation structures built by the service relationship class.
	RIM092	Master_quantitative_observation.delta_check_change_threshold_qty
	Specifies the minimum change that will trigger a delta check warning.
	
	Rationale: 
	
	OpenIssue:
	USAMP-II	action for OO
	as of yet. See above.
	RIM092	Master_quantitative_observation.delta_check_numeric_low_value_amt
	Specifies the low value information for controlling delta check warnings.  More than one delta check rule can apply.
	
	Rationale: required by components of V2.3 field
	
	OpenIssue:
	USAMP-II	action for OO
	as of yet. See above.
	Wednesday, October 13, 1999	Page 3 of 9

	RIM092	Master_quantitative_observation.delta_check_retention_period_qty
	The length of time that the service retains a V2.3 language value fr computing delta checks.
	
	OpenIssue:
	USAMP-II	action for OO
	as of yet. See above.
	RIM092	Master_quantitative_observation.delta_check_value_range_qty
	The range of values for which delta check warnings can be generated.  If no value range is given, the check applies to all values.
	
	OpenIssue:  The RIM090 descriptions lead one to believe that delta_check ranges, delta_check thresholds, and delta_check methods occur in sets 
	("more than one rule can apply").  If that is so, then delta check should be a separate class that associates with the continuous observation.
	USAMP-II	action for OO
	as of yet. See above.
	RIM092	Master_quantitative_observation.minimum_meaningful_increment_nbr
	The smallest meaningful difference between reported values (the effective resolution of the measuring instrument or technique for continuous 
	data, or the smallest discrete interval that can occur for discrete data).  This is a pure number.
	
	USAMP-II	action for OO
	as of yet, this concept is not mapped.  Few clinical systems specify such a value, and it is medically questionable how such a concept of minimal 
	meaningfulness could be defined.  Thjs issue is to be addressed together with the delta checks.
	RIM092	Master_quantitative_observation.si_conversion_factor_expr
	This is a factor for converting the customary units to SI units.
	
	In the case that the observation units are not SI units, this field provides the formula needed to convert from the reported units to SI units, this shall 
	include the equation needed to coonvert from the reporting to the SI units.
	
	In the case that the relation is simply multiplicative, this field shall include only the conversion factor.  For example, if (results SI units) = c* (results 
	reporting units), then only c would be stored in this field.  In the case of any other functional relationship, the entire equation would be stored for a 
	USAMP-II	out-scoped
	Unit conversion is defined externally by the semantics of units.  The Unified Code for Units of Measure that is the preferred code for units to be 
	used in the data type Physical Quantities defines a methodology and the necessary constants for conversion between all convertible units.  
	
	The issue between SI and customary units is not as simple than it is implied by RIM092 here, since SI is an entire class of units, that still need to be 
	converted.  
	
	The "equation" suggested by RIM092 is not interoperable without significant further work to solve a problem that is already solved elsewhere (in 
	the units coding scheme.)
	Master_service
	RIM092	Master_service.fixed_canned_message_cd
	The codes and a fixed text message that is always associated with the test described by this master service.
	
	Most rules about patient testing will be transmitted as free text.  In such cases, the contents serve only as information for human reading.  
	However, an alternative for machine readable rules also exists.  The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which 
	has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information 
	stored in the computer record.  Rules about patient preparation and written in Arden Syntax should being and end with a double semi-colon (;;) the 
	Arden slot delimiter.
	
	Rationale: The EXPR attribute type is not used here because a) it does not accommodate both codes and text; and b) at times this text must be 
	human-readable.  This attribute will use the CD data type.
	
	OpenIssue:  Need example values.  Probably overlap of concepts.
	
	OpenIssue:  It is not clear from the definition what differentiates "fixed canned messages" from other standard text - e.g., 
	patient_preparation_desc, procedure_medication_cd.
	USAMP-II	sanitized
	There is no understandible definition of this attribute anywhere in the RIM nor in HL7 v2.3.  This field must go, nobody can use it in an interoperable 
	Wednesday, October 13, 1999	Page 4 of 9

	RIM092	Master_service.incompatible_change_dttm
	The date and time of the last change in the test procedure that would make previous results incompatible with new results, e.g., the last time that 
	normal reference range or units changed for a numeric test/observation.
	
	We strongly suggest that observation producers never use the same observation ID when the measurement procedures change in such a way 
	that results produced under the new procedure are clinically different from those produced with the old procedure.  Rather, the producer should 
	try to adjust the new procedure so that its values are clinically indistinguishable from the old.  Failing that, one should create a new observation ID 
	for the observation produced under the new procedure.
	
	In the rare circumstances when a procedure change occurs and neither of the above two options is viable, this field shall be used to transmit the 
	effective date/time of the new procedure.  The receiving systems shall assume that any values that come across under this observation ID are 
	under the new procedure after this date and take appropriate  steps to distinguish the old from the new observations.  
	
	This number is included to provide a means of communicating with the observation producing service when they have questions about particular 
	observations or results.
	
	Rationale:
	
	OpenIssue:
	USAMP-II	sanitized
	Just as no service event should be overwritten, no service definition should be overwritten incompatibly.  This would render any attempt at 
	interpreting old observations useless.  There is no need to support such malpractice.
	RIM092	Master_service.point_versus_interval_cd
	classifies this service as measuring the patient's state either at a point in time (e.g., spot urines, random urines, serum potassium), or averaged 
	over a interval of time (e.g., concentration, total amount, or clearance over a 24-hour collection).  
	
	OpenIssue:  This may be converted to an indicator.
	USAMP-II	out-scoped
	This atribute is a LOINC specific classification of tests.  It is not necessary to imply procedural requirements, as the service plan may be specified 
	in all necessary detail anyway.  The implication for interpreting the observation is not clear.  By no means is thie code a modifier, since there is no 
	choice for any given test.  Thus, this attribute better stays precoordinated in the LOINC code.
	RIM092	Master_service.when_to_charge_cd
	Specifies the standard timing of billing the charges associated with the service, and determines the master template for the timing of billing the 
	charges associated with the order service item.  eg.: On Discharge (D); On Receipt of Order (O); At time service is completed (R); At time service 
	is started (S); At a designated date/time (T)
	USAMP-II	action for PAFM
	The relationshjp between a service and its charge needs to be improved on.  Only as a last resort should this attribute admitted into the Service 
	class.  It is not a problem to put this attribute into the service class, notably, it is applicable to all moods (especially definition, order, and event.) 
	
	Instead of distributing charge-relevant attributes over multiple classes in the RIM, wouldn't it be possible to consolidate them all in one class, 
	representing charges.  The class Financial_transaction seems to be the best class for that purpose.  It could represent the charges (with fee 
	schedule) one would incur when ordering the service, as well as the actual bill, and billing transaction.
	Master_treatment_service
	RIM092	Master_treatment_service.drug_category_cd
	The drug category code of the pharmacy treatment service.
	USAMP-II	kicked out
	Attributes for classification an categorization should not be admitted into the RIM without a detailed rationale and use cases.  Coded attributes 
	should not be admitted into the RIM without a full interoperable specification of what the domain is (if only by external reference.)  This attribute is in
	 the RIM without heritage in HL7 v2.x and whithout any helpful definition. It must go until the a proper use case and definition is made.  Once we 
	know what it is, we will be able to find an appropriate disposition in USAMP-II.
	Wednesday, October 13, 1999	Page 5 of 9

	RIM092	Master_treatment_service.formulary_status_cd
	A code depicting the formulary status of a dispensed medication.
	
	Rationale:
	
	OpenIssue:  Need example values.
	USAMP-II	kicked out
	Again, this attribute exists in the RIM without heritage in HL7 v2.x and without any sensible definition that would make it useable.  It must therefore 
	go until a proper use case and definition is made.  Once this is properly defined, the USAM will find a good disposition for it.
	RIM092	Master_treatment_service.pharmaceutical_class_cd
	The pharmaceutical class of the pharmacy treatment service.
	
	OpenIssue:  Need example values.
	USAMP-II	kicked out
	Attributes for classification an categorization should not be admitted into the RIM without a detailed rationale and use cases.  Coded attributes 
	should not be admitted into the RIM without a full interoperable specification of what the domain is (if only by external reference.)  This attribute is in
	 the RIM without heritage in HL7 v2.x and whithout any helpful definition. It must go until the a proper use case and definition is made.  Once we 
	know what it is, we will be able to find an appropriate disposition in USAMP-II.
	RIM092	Master_treatment_service.therapeutic_class_cd
	A code depicting the therapeutic class of the pharmacy treatment service.
	
	OpenIssue:  Need example values and clarification of description.
	USAMP-II	kicked out
	Attributes for classification an categorization should not be admitted into the RIM without a detailed rationale and use cases.  Coded attributes 
	should not be admitted into the RIM without a full interoperable specification of what the domain is (if only by external reference.)  This attribute is in
	 the RIM without heritage in HL7 v2.x and whithout any helpful definition. It must go until the a proper use case and definition is made.  Once we 
	know what it is, we will be able to find an appropriate disposition in USAMP-II.
	Observation_intent_or_order
	RIM092	Observation_intent_or_order.specimen_action_cd
	A code identifying the action to be taken with respect to the specimen which precedes or accompanies the order.  Actions include:  Add ordered 
	tests to the existing specimen; Lab to obtain specimen from patient; Pending specimen - Order sent prior to delivery.
	
	OpenIssue:
	USAMP-II	abolished
	This modeling style is at odds with the MDF. An "action code" of HL7 v2.x is a hidden trigger event (sometimes overloaded with the meaning of a 
	state attribute.)  The code values suggest that this attribute manages the ordering of a specimen collection service, which has a straightforward 
	representation in USAMP -- even in the RIM092! Other uses seem to be the addition of services to an existing specimen, which also has a 
	straightforward representation in USAM and RIM092 alike.  This attribute is superflous in either model!
	Rule_link
	RIM092	Service_event_relationship :: generalizes(1..1) :: Rule_link :: specializes(1..1)
	USAMP-II	dropped 
	The specialization class is re-united with its genus, so the relationship is gone.  See comment under the specialization class.
	Wednesday, October 13, 1999	Page 6 of 9

	Service_event
	RIM092	Service_event.charge_to_practice_cd
	Charge code for the charge to the ordering entity for the studies performed when applicable.
	
	Rationale: 
	
	OpenIssue:  This item related more to financial areas than the clinical areas.  (Note to PAFM)
	
	OpenIssue:  Need code examples.
	USAMP-II	action for PAFM
	This attribute is dysfunctional.  It needs proper analysis and modeling.  This is rather in the scope of PAFM.  Probably covered already somewhere 
	in Financial_transaction.  Also may reconfirm the need for a general Account (not just a "patient billing account") so that departments and offices 
	can bill and charge for each other's services independent from patients.
	RIM092	Service_event.charge_to_practice_qty
	Monetary amount for the charge to the ordering entity for the studies performed when applicable.
	
	Rationale:
	
	OpenIssue:  Should move to financial section of model since  it is related more to financial areas than the clinical areas.  (Note to PAFM)
	USAMP-II	action for PAFM
	This attribute also needs proper analysis and modeling.  This is rather in the scope of PAFM.  Probably covered already somewhere in 
	Financial_transaction.  Also may reconfirm the need for a general Account (not just a "patient billing account") so that departments and offices can 
	bill and charge for each other's services independent from patients.
	Service_intent_or_order
	RIM092	Service_intent_or_order.charge_type_cd
	A code identifying someone or something other than the patient to be billed for this service.
	
	OpenIssue:  This attribute cannot meet the needs of the concept without violating the guidelines of the MDF and must be fixed somehow.  
	Coordination with PAFM is needed to be certain that the function and concept is captured somewhere for future messages.  This is a type of active
	 participation.  "Entity to be billed" should be a participation type code in Class: Active_participation.
	USAMP-II	action for PAFM
	This is a dysfunctional attribute that will never work. This literally cries for a link to a billing account that is not constrained to a "patient billing 
	account."  It could be so simple!  Therefore the proposal is to delete this attribute that doesn't do what it promises to do, and thereby increasing 
	pressure on the issue to be resolved.
	RIM092	Service_intent_or_order.echo_back_txt
	Text sent by the placer that will be returned with the results. There will be no interpretation of this field by the filler.  This attribute should not be 
	used to communicate information that should be communicated as an observation.
	
	Rationale:
	
	OpenIssue:  Should this attribute be abandoned to be more deterministic as to how echo back is reported.
	USAMP-II	sanitized
	This is clearly info-junk: a field with no semantics that is a perfect hide-out for sanctioned abuse.  It better goes silently and only reconsidered if a 
	strong case for it is made. This is at least 13 year old heritage from ASTM 1283 (was "placer text 1" and "placer text 2") … isn't it time now to 
	Wednesday, October 13, 1999	Page 7 of 9

	RIM092	Service_intent_or_order.order_effective_dttm
	Date/time that the changes to the order took effect or are supposed to take effect
	
	Rationale: previously unmatched V2.3 field
	
	OpenIssue:
	USAMP-II	abolished
	The use of this field has three different aspects,
	
	(1) information about some time related to the Service. For example, usually it is the time the service is supposed to start but also the time the order 
	is supposed to end (in context of a discontinue request.)
	
	(2) information about the mood of the Service, that is, whether it is just a report when something took effect or it is a command when some action 
	is supposed or planned to take effect.
	
	(3)  information about a particular transaction request for the order (defaulting to the MSH-7-date/time of message) as opposed to a time that will 
	affect the service actually carried out.
	
	These different aspects are all factored into specific data elements that are consistent and uniform in their interpretation. In version 2 this data 
	element had alternative data elements to carry the same information, such as in the MSH and in the TQ, and thus was redundant. Therefore this 
	field will not be carried forth as such in version 3, but will be decomposed in its different meanings:
	
	(1) The actual start and end times of a service action will be communicated in Service.total_time. 
	
	(2) The mood is factored into the explicit mood code Service.mood_cd.  
	
	(3)  Discontinuing a service immediately is done without mentioning any time at all, while a change in the planned end time of a service can be 
	requested by the placer in the Service.total_time (or usually Service.critical_time) attribute. 
	
	(4) The time of a particular service control transaction (message) will always and only be sent in the version 3 Message Header.
	RIM092	Service_intent_or_order.response_requested_cd
	A code used to allow the placer (sending) application to determine the amount of information to be returned from the filler.  Sometimes the 
	requested level of response may not be possible immediately, but when it is possible, the filler (receiving) application must send theh information.  
	When the field is null, D is the default value of the field.
	
	Coded entries include:  report exceptions only/report exceptions, replacement and parent-child/report exceptions, replacements, parent-child and 
	associated segments/report exceptions, replacement, parent-child, associated segments and confirmations/return header only.
	
	OpenIssue:
	USAMP-II	abolished
	This is message control information, not application-level information.  It's an interesting use-case to forward to Control/Query but should not be 
	handled together with application domain data by a few domain committees.
	RIM092	Service_intent_or_order.when_to_charge_cd
	A code determining the timing of billing the charges associated with the order service item. eg. On Discharge (D); On Receipt of Order (O); At time 
	service is completed (R); At time service is started (S); At a designated date/time (T)
	
	Rationale:
	USAMP-II	action for PAFM
	This needs to be analyzed together with all other billing attributes. May be a better attribute for a Financial Transaction.  Deleting the attribute now 
	will increase the pressure on resolving the issue.
	
	As plan B we can have this as a Service attribute. It does fit nicely in the mood logic.
	Wednesday, October 13, 1999	Page 8 of 9

	RIM092	Service_intent_or_order.when_to_charge_dttm
	Date and time to charge for the ordered service.
	
	Rationale: 
	
	OpenIssue:
	USAMP-II	action for PAFM
	This needs to be analyzed together with all other billing attributes. A better attribute for Financial Transaction.  Deleting the attribute now will 
	increase the pressure on resolving the issue.
	
	As plan B we can have this as a Service attribute (marked with 1000 open issues!)
	Service_reason
	RIM092	Service_reason.determination_dttm
	The date and time at which the determination is made that the reason applies.
	
	Rationale:
	USAMP-II	abolished
	Rationale: the service reason is assigned by the responsible originator of the source service.  The time of the reason thus defined is not practically 
	distinguishable from the time of that source service.
	
	If reasons are interpreted after the fact this must be represented differently (e.g., throught a mechanism similar (identical?) to the Condition_node.)

	RIM092	Service_reason.documentation_dttm
	The date and time at which the applicability of the reason is document.
	
	Rationale:
	USAMP-II	abolished
	Rationale: the service reason is assigned by the responsible originator of the source service.  The time of the reason thus defined is not practically 
	distinguishable from the time of that source service.
	
	If reasons are interpreted after the fact this must be represented differently (e.g., throught a mechanism similar (identical?) to the Condition_node.)

	Treatment_service_administration
	RIM092	Treatment_service_administration.system_entry_dttm
	Date/time the administration information was entered into the source system.  This field is used to detect instances where treatment administration 
	information is inadvertently entered multiple times by providing a unique identification field.  Under usual circumstances, this field would be provided 
	automatically by the computer system rather than being entered by a person
	
	Rationale: 
	
	OpenIssue:
	USAMP-II	abolished
	This is a hack in circumventing the obvious solution of unique identifiers.  Times have changed in the last 20 years and v3 may need to "raise the 
	bar" (W. Rishel) in this case.
	Wednesday, October 13, 1999	Page 9 of 9