Disposition names and their meaning
	clearly mapped
	An item that is mapped so that the mapping very obviously.  For example, if just the name is changed. This includes 
	mappings of properties if the destination is in a consolidated or "merged" class (e.g. Master_service to Service, 
	Service_event_relationship to Service_relationship etc.)  
	
	That is, once a RIM092 class has been mapped, to some USAMP-II class, all properties of that class are eligible to 
	clear mapping.
	
	The mapping is not clear if immediate elements are mapped to some structure, e.g., involving the service_relationship
	 class.
	dropped (uncritical)
	Dropping of formal elements without substantial functional impact.  E.g., the empty classes Assessment and 
	Care_event including all relationships they caused.  This deletion should not be an issue of discussion.
	transcended
	Element is dissolved and preserved in structures of the USAMP-II. Close to "mapped", but may be more indirect.
	abolished
	Deleted because element is dysfunctional, in direct MDF violation, or insufficiently defined to allow “rescuing” it.  
	Mostly all three criteria apply.  Example: “action codes” are hidden trigger events.
	out-scoped
	Deleted for domain-logical reasons, mapped to some sort of different approach extenal to the RIM.  Suggests that 
	these things should be handled differently. E.g., SI-units vs. conventional units and conversion “equation”.
	
	The rationale for this is not style or taste, but because the current approach is proven to be insufficient, especially 
	non-interoperable.
	sanitized
	Deleted to sanitize HL7 v3 from mistakes of the past and from current malpractice in system design. What Wes 
	Rishel calls  “raising the bar.”
	kicked out
	Aggressive notion is intended.  No HL7 legacy is ever kicked out, but there is some pure info-junk in the model, 
	mostly coded attributes that are completely foreign to HL7, and sneaked into the RIM with not the slightest attempt at 
	a useful definition or code table.
	Wednesday, October 13, 1999	Page 1 of 2

	action for PAFM
	Billing related items that are not mapped because they need serious revision first.  These items could be resolved 
	and fit in nicely but that would require to involve substantial parts of the PAFM classes in the proposal.  This is 
	simply not feasible at this time.
	
	The proposal is to lock these items out from the RIM in order to force us to solving the associated use cases with the
	 existing billing and charge infrastructure of PAFM, making changes as necessary.  
	
	These items are considered deficient, so chaces are they do not work, at least not given the higher goals for 
	interoperability that is in the charter of HL7 v3.
	
	As a last resort, the items could stay (or be mapped wherever their class is mapped) and marked with an open 
	issue.  However, experience shows that open issues are largely ignored, especially those open issues that 
	deserve some more energy to be solved.  So locking these items out may increase the pressure to deal with the 
	issues.
	action for OO
	Items that need more thought by OO to fit in well.  
	
	These are non-critical items that are conceptually problematic as defined now, but are (likely) not used very 
	frequently. Therefore, these items are not mapped in this round.
	
	A plan B is to keep them in the model as clearly marked, or even separated into their own class with a 1 --- 0..1 
	mapped
	Items that are fully mapped.  This is not necessarily a one to one mapping of "data elements", but the semantics is 
	clear and a representation is provided for it in the USAMP that is at least as functional as the item was in RIM092.
	mapped with issues
	Items that are mapped to a large extent, often is a one to one mapping yet there are issues of semantics that would 
	need attention.  Often times the issue raised is less a problem with the USAMP than a problem with the way the 
	RIM092 element is defined.
	marginal
	Elements outside of the USAMP-II's scope to which USAMP-II  connects, i.e., items at the margin of USAMP-II.
	moved
	Needs to be turned into a "move element" proposal.
	unmapped
	Issues that we want to resolve before the final vote on them.
	untouched
	Elements that are left untouched from the RIM095.  E.g., atributes that stay in a class even though other attributes 
	are taken out into a related class, or mapped out.  These items do not constitute harmonization proposal items 
	because they won't change anything.
	untouched with issue
	Elements that are left untouched from the RIM095.  E.g., atributes that stay in a class even though other attributes 
	are taken out into a related class, or mapped out. Hovewer issues have been found that need to be recorded. These
	 items will constitute harmonization proposals for opening issues.
	Wednesday, October 13, 1999	Page 2 of 2