This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Reference Information Model Artifact Definition"

From HL7Wiki
Jump to navigation Jump to search
 
(45 intermediate revisions by 2 users not shown)
Line 8: Line 8:
 
<!-- At a high level, what is this artifact and why is it needed?  Should ideally be only a few sentences -->
 
<!-- At a high level, what is this artifact and why is it needed?  Should ideally be only a few sentences -->
  
The HL7 Reference Information Model (RIM) is the foundation from which all SAIF logical and implementable information models SHALL be derived.  It serves to unify the information content of HL7 V3 standards, affording more consistent representation of models and simpler implementation of models from multiple topics. The RIM SHALL be bound to formally-approved [[Abstract Data Types Artifact Definition|Data Types]] and [[Vocabulary Model Artifact Definition|Vocabulary Models]].
+
The HL7 Reference Information Model (RIM) is single artifact that is the foundation from which all V3 and SAIF logical and implementable information models SHALL be derived.  It serves to unify the information content of HL7 V3 standards, affording more consistent representation of models and simpler implementation of models from multiple topics. The RIM is a class model that includes the state machines, associations and attributes of those classes.
 
 
:The HL7 Reference Information Model is managed under the ANSI "continuous maintenance" process, currently (April, 2011) as '''''HL7 Version 3 Standard: Reference Information Model, Release 4 [HL7 V3 RIM, R4]'''''
 
  
 
== SAIF Matrix Location ==
 
== SAIF Matrix Location ==
 
'''Row(s)'''
 
'''Row(s)'''
 
* Logical (PIM)
 
* Logical (PIM)
* Implementable (PSM) ''(RIMBAA)''
 
  
 
'''Column(s)'''
 
'''Column(s)'''
Line 21: Line 18:
  
 
== Audience ==
 
== Audience ==
 +
<!-- Who will be the consumers of this artifact type and what will they do with it? Select from following lists.-->
 +
Health care Information Technology (IT) Audiences:
 +
*Standards developers and standards development organizations
 +
*System designers and architects
 +
*Programmers/implementers
  
<!-- Who will be the consumers of this artifact type and what will they do with it? -->
+
Designers, modelers and implementers of v3 solutions being created under HL7 SAIF, which are required to be RIM-derived. 
Text
+
 
 +
The RIM should be accessible and understandable for domain experts seeking to verify, map or align their [[Analysis Information Model Artifact Definition |analysis information models]] to the RIM.
  
 
== Applicability ==
 
== Applicability ==
 +
As a single, foundation, "reference" source for SAIF, the RIM is required for use by all v3 projects, but it does not need to be "created" by those projects.
  
<!-- Under what circumstances does this artifact type need to be created?  Are there circumstances where this artifact should not exist?  Why? -->
+
== Requirements, Relationships and Content ==
Text
+
# Include the set of information classes that '''fully represent the information needed to support interoperability in''' the clinical and administrative functions of '''health care'''.
 
+
## <i>Rationale</i> As the foundation of HL7 SAIF, it must be able to represent the full spectrum of likely HL7 applicability.
<i>Rationale</i>: More text
+
# Include selected information classes that '''represent the computational and contractual information''' needed to implement health care interoperability.
 
+
## <i>Rationale</i> Must support the necessary communication artifacts (wrappers and the like) needed to establish information interoperability.
== Requirements ==
+
# Maintain a degree of '''abstraction in the RIM model''' such that there is, ideally, only one way to represent a data structure using RIM classes.
 +
## <i>Rationale</i> Large models with myriad associations lead to ambiguity in selecting the preferred representation of a particular concept. A controlled abstract model eliminates or greatly reduces such ambiguity.
 +
# '''Manage the abstraction in the RIM model''' using controlled terminologies (code systems) that are formally approved as an integral part of the RIM.
 +
## <i>Rationale</i> Controlling terminologies determine the meaning of the concrete expression RIM abstractions, and must, themselves be part of the RIM.
 +
=== Relationships and traceability ===
 +
<!-- What are the other artifacts to which this artifact must or may be required to relate?  (Express those relationships that are "many-to-one" - that is where many of this artifact type will usually relate to one of the other artifact type.) How do they relate?  Why is the relationship important?
  
<!-- What are the needs that this particular artifact was created to satisfy and why are those needs important.   (Should not be more than 10-15.) -->
+
Follow with a bullet list of artifacts that may or must relate to this artifact, where many of the listed artifact type will relate to one of this artifact type. 
# Some requirement
+
-->
## <i>Rationale</i>Some reason
+
* '''Bind''' the data types of the RIM attributes '''to a specific [[Abstract Data Types Artifact Definition| "abstract" data type representation]]''' formally adopted by HL7.
 +
**<i>Rationale</i> The data structures that derive from the RIM will draw much of their "type" information from data types assigned to RIM attributes. Thus these attributes have a data type representation that is fully as consistent and tightly managed as the RIM itself.
 +
*Establish a '''terminology binding for each "coded" attribute''' of the RIM to a specific [[Concept Domain Artifact Definition|Concept Domain]] that is drawn from an HL7-managed [[Vocabulary Model Artifact Definition|Vocabulary Model]].  
 +
**<i>Rationale</i> Over 40 per-cent of RIM attributes carry encoded values.  The expected terminology binding for those attributes must be carefully defined and managed by HL7
 +
*Where a RIM class has a defined state machine, this SHALL conform to the [[Logical State Machine Artifact Definition]]
  
# Some other requirement
+
<b>Artifact types that may or must relate to this artifact types:</b>
## <i>Rationale</i>Some other reason
+
* [[Analysis Information Model Artifact Definition|Analysis Information Model]]
 +
* [[Domain Information Model Artifact Definition|Domain Information Model]]
 +
* [[Serializable Information Model Artifact Definition|Serializable Information Model]]
 +
* [[Loose Information Model Artifact Definition|Loose Information Model]]
 +
* [[Simplified Information Model Artifact Definition|Simplified Information Model]]
 +
* Semantic Profile
  
== Relationships and traceability ==
+
=== Content ===
 
+
<!-- What elements or components are required to be part of this artifact, and what is their hierarchical structure?  How?  Why is the content important? (These can be expresses as a hierarchical set of content element names, with a brief phrase to describe each.) -->
<!-- What are the other artifacts that are related to this artifact?  How?  Why is the relationship important? -->
+
{{Template:SAIF Generic IM and RIM Content}}
* Some relationship
+
**<b>State Machine <i>optional</i></b> -  Identifies the states and transitions for a class
** <i>Rationale</i>: Reason for relationship
+
* <i>Subject area - (<b>Non-normative</b>)</i> Element to collect classes into logical groupings.
 
 
* Some other relationship
 
** <i>Rationale</i>: Reason for other relationship
 
  
 
== Artifact Technology ==
 
== Artifact Technology ==
 
+
The RIM is a UML Class model with extensions needed to document more specific content properties than are encompassed in UML and to define and manage terminology bindings.
<!-- What technological/standard solution has been selected for use in creating this artifact and why? -->
 
Text here
 
  
 
=== Rationale ===
 
=== Rationale ===
 
+
UML provides the key constructs of classes, attributes, associations & state machines and has the extensibility necessary to support the remaining requirements.
<!-- What's the justification for selecting the chosen technology? -->
 
* Some reason
 
* Some other reason
 
  
 
=== Alternatives ===
 
=== Alternatives ===
 +
None.  The MIF was defined for this purpose, and the RIM has been maintained in this fashion for several years.
  
<!-- What other technical solutions might have been possible that were discarded, what did they offer and why were they not chosen? -->
+
== Content Constraints ==
 +
The following constraints are based on long-established HL7 policies and practices.  The rationale, therefore, is to maintain consistency with the established RIMs and published HL7 standards.
 +
# Once a RIM element (class, attribute, state, controlling code) has been included in a version of the RIM released for ballot, and that element has been used in a normative specification, the element cannot be removed from the RIM except by a '''process of Deprecation and delayed removal'''. 
 +
##Once an element has been '''deprecated''' it SHALL NOT be used in development of further derived models. 
 +
##:
 +
## <i>Rationale</i>: Established policy
 +
# RIM UML content must include the following elements:
 +
#:# Classes
 +
#:# Associations (including generalizations, but excluding compositions and association classes)
 +
#:# Attributes
 +
#:# State machines for selected classes
 +
#:# Definitive text for every element
 +
## <i>Rationale</i>: Provide a RIM that is lean and understandable using standard modeling paradigm
  
<b>Some technology</b>
+
# RIM Classes:
* Some pro or con
+
##Class names SHALL be "upper-camel-case" with no spaces and only alphabetic characters
* Some other pro or con
+
##Classes may have the following HL7-defined properties.
 +
##:The properties are only listed here.  Their [http://www.hl7.org/v3ballot/html/infrastructure/rim/rim.html#rimUnderClsRep formal definition and rules] are in the RIM Normative specification.
 +
### Property: classCode
 +
### Property: stateAttribute
 +
## <i>Rationale</i>: Properites to express constraints not directly represented in UML, and follow established style guides
  
== Content Constraints ==
+
# Associations:
 +
##Association ends will include names and cardinalities (limited to 0..1, 0..*, 1..1 and 1..*).  Association end names SHALL be "lower-camel-case" with no spaces and only alphabetic characters
 +
##Association ends must have the following HL7-defined property.
 +
##:The property is only listed here.  Its [http://www.hl7.org/v3ballot/html/infrastructure/rim/rim.html#rimUnderAssnRep formal definition and rules] are in the RIM Normative specification.
 +
###Property: allowedUpdateMode
 +
###Property: availableUpdateModes
 +
###Property: conformance
 +
###Property: mandatoryInclusion
 +
## <i>Rationale</i>: Properites to express constraints not directly represented in UML, and follow established style guides
  
<!-- What are the formal rules about how the artifact can be constructed, including any extensions and constraints for the selected technology as well as the rationale for those rulesThese are rules that can reasonably be enforced or validated by tools. -->
+
# RIM attributes:
# Some rule
+
##Attributes shall include names, cardinalities (limited to 0..1, 0..*, 1..1 and 1..*) and a data type drawn from a single, specified, HL7-approved [[Abstract Data Types Artifact Definition|Abstract Data Types Model]]. Attribute names SHALL be "lower-camel-case" with no spaces and only alphabetic characters and will follow a convention to identify the approximate data type (coded, boolean, name, etc.)
## <i>Rationale</i>: Some reason
+
##Coded attributes must include the "vocabDomain" property. (see below)
 +
##Attribute may have the following HL7-defined properties.
 +
##:The properties are only listed hereTheir [http://www.hl7.org/v3ballot/html/infrastructure/rim/rim.html#rimUnderAttRep formal definition and rules] are in the RIM Normative specification.
 +
###Property: allowedUpdateMode
 +
###Property: availableUpdateModes
 +
###Property: conductible
 +
###Property: conformance
 +
###Property: defaultValue
 +
###Property: isDocumentCharacteristic
 +
###Property: isImmutable
 +
###Property: mandatoryInclusion
 +
###Property: vocabularyAssertion
 +
## <i>Rationale</i>: Properites to express constraints not directly represented in UML, and follow established style guides
  
# Some other rule
+
# Additional MIF-defined annotations such as rationale, usage not4es, etc. may be included in the documentation of any RIM element.
## <i>Rationale</i>: Some other reason
+
## <i>Rationale</i>: Allow a rich set of annotations to make RIM content more readily understood.
  
 
== Content Guidelines ==
 
== Content Guidelines ==
 
+
Since the RIM is a formal specification that has been approved internationally and is in active use within the HL7 International communities, these guidelines are not designed to explain the current content, but rather to reflect guidelines for proposed changes.
<!-- What are the informal guidelines about how the artifact content. I.e. What constitutes good practice?  These guidelines should be used in the evaluation of artifact instances but generally can't be enforced or validated by tools. -->
+
# New content or changes to existing content should be designed for universal use in HL7 International.
# Some rule
+
## <i>Rationale</i>: The RIM is a consensus model that is required for use in all HL7 realms.
## <i>Rationale</i>: Some reason
+
# New content should be added only when there is no reasonable way to represent the same content with existing RIM structures.
 
+
## <i>Rationale</i>: See requirement #3 and the objective of having only one way to express a given concept in the RIM.
# Some other rule
+
# New attributes should not be added if the same information can be more appropriately represented as an "observation."
## <i>Rationale</i>: Some other reason
+
## <i>Rationale</i>: See requirement #3 and the objective of having only one way to express a given concept in the RIM.
 +
# The definition of new RIM elements should not overlap with existing elements and the names for new elements (including controlling codes) should have universal applicability (as opposed to realm-specific).
 +
## <i>Rationale</i>: Retain the abstract nature of the RIM and its ability to satisfy a broad range of needs.
  
 
== Publishing Representation(s) ==
 
== Publishing Representation(s) ==
 
+
#The '''primary distribution''' of the RIM is in the form of a file formatted according to the [http://www.hl7.org/v3ballot/html/infrastructure/mif/mif.html HL7 Model Interchange Format] (MIF).
<!-- How will this artifact be shared and published as part of specifications? -->
+
#* Provides the computable representation needed by implementers
# Some text
+
# HTML representation for the ballot is MIF-based, and includes UML Class Diagrams of the content
## <i>Rationale</i>: Some rationale
+
#* The RIM is balloted in its HTML representation, which uses the MIF representation as its source. The HTML format is familiar to most HL7 participants.
 
+
#* UML graphic representation is universal and familiar.
# Some other text
+
# Near-term (2011-12) distribution of the RIM in an Access data base format is used to support selected tools, notably the HL7 RMIM Designer (in Visio) and vocabulary management software.
## <i>Rationale</i>: Some other rationale
+
#*'''Rationale:''' Support existing tool base.
  
 
== Publishing Constraints ==
 
== Publishing Constraints ==
 +
# Content is provided in two MIF files and a number of graphic files:
 +
#*RIM "core" MIF containing the "technical content" (classes, attributes, etc.)
 +
#*RIM "publication" MIF containing the balloting rules and definitions for the core properties and principles for the RIM.  This also "structures" the presentation of the technical and graphic content.
 +
#*RIM graphics in GIF and PDF (for very large diagram) formats
 +
## <i>Rationale</i>: Formats required by publishing process
 +
#Content publication is dependent upon of the joint publication of RIM with the Abstract Data Types and Vocabulary Model to which the RIM is bound.
 +
## <i>Rationale</i>: These models are mutually inter-dependent
  
<!-- What are the constraints imposed by the publishing process on how artifacts are constructed and submitted to HL7and what are the reasons behind such constraints? -->
+
== Tooling Considerations ==
# Some rule
+
The current RIM-tooling was first used 15 years ago.  Although its technology is archaic, it is robust and replacement is not simple.  Some of the features of the current RIM tools include:
## <i>Rationale</i>: Some reason
+
# '''2011 Technology Base''':
 
+
#*Fundamental storage is in the Access data base known as a [http://gforge.hl7.org/gf/project/design-repos/ RIM Repository]
# Some other rule
+
#*:
## <i>Rationale</i>: Some other reason
+
#*Content management of the Access content is handled by DLLs from the [http://gforge.hl7.org/gf/project/rose-tree/ RoseTree family] maintained in Visual Basic 6.
 +
#**Source code is on SVN
 +
#*:
 +
#*Model content is documented and updated in Rational Modeler (199x release) with HL7 properties defined.  The content is then read and "synched" with the RIM repository using RoseTree invocations of the APIs provided by Rational Modeler, and a set of Access VBA software in [http://gforge.hl7.org/gf/project/rose-tree/frs/?action=FrsReleaseBrowse&frs_package_id=53 HL7 "Access tools"].
 +
#*:
 +
#*Extraction of RIM content and its expression in the primary MIF format is done as:
 +
#*#Content is assembled in the RoseTree application (and manually reviewed, if needed)
 +
#*#:
 +
#*#RoseTree expresses the full content in an idiosyncratic XML format
 +
#*#:
 +
#*#The [http://gforge.hl7.org/gf/project/v3-generator/ V3 Generator] is used to convert the "RIM-XML" content into a correct MIF representation.
 +
#*:
 +
#*Complete RIM archival content (all releases back through 0.86 in 1997) is retained in an Access data base archive. 
 +
#*:
 +
#*Migration of data to-from the archive is managed by a set of [http://gforge.hl7.org/gf/project/rose-tree/frs/?action=FrsReleaseBrowse&frs_package_id=53 HL7 "Access tools"] encoded in VBA in an Access data base.  They permit the retrieval of older versions into a current repository.
 +
#*:
 +
#*'''Trained users:''' Although at one time Karen vanHentenryck was trained in the RIM update process, only G. Beeler has used this process in recent years.  Although this may sound risky, the risk is ameliorated by the avialable of full content in MIF (excepting only the graphics).
 +
# '''Nice-to-have - A RIM model management based on a UML tool'''
 +
#* Clearly it would be desirable to manage the RIM content from a '''UML model tool that could read and write MIF''' either directly or through MIF to XMI transforms. '''Notes:'''
 +
#**This is an easier task for the RIM than it would be for the generalized Static Model Designer because RIM content is not "constrained" by the RIM, does not need access to code systems, and has a '''very low''' rate of change.
 +
#**:
 +
#**A UML modeler would not need to read the RIM MIF provided that a means of robustly verifying that the modeler representation of the RIM and the MIF representation are identical. (The current RIM maintenance process uses this strategy to maintain alignment between the RIM repository and the Rose Modeler files.)
 +
#**:
 +
#**The archived RIM content should be extracted and converted to MIF format to provide a MIF archive of past RIMs, albeit absent the graphics, which would have to be archived separately in GIF and PDF files.
 +
#**:
 +
#**HL7 has the technical resources to make this conversion, but not the manpower resources to undertake it.
  
== Tooling Considerations ==
+
== Artifact Exchange and Version Management ==
 +
The '''primary distribution''' of the RIM is in the form of a file formatted according to the [http://www.hl7.org/v3ballot/html/infrastructure/mif/mif.html HL7 Model Interchange Format] (MIF).
  
<!-- What tooling features are required or "nice to have" to allow successful development, publication or other use of the artifact? -->
+
<i>Rationale</i>The RIM is a core technology for HL7 endeavors.  As such it is a necessary element of most HL7 design tools, and must be available in a processable, MIF format.
# Nice-to-have|Required: Some feature
 
## <i>Rationale</i>: Some rationale
 
  
# Nice-to-have|Required: Some other feature
+
== Authoring and Maintenance Tools ==
## <i>Rationale</i>: Some other rationale
 
  
 
== Development Process Considerations ==
 
== Development Process Considerations ==
 +
There is one and only one RIM artifact (though it will be versioned)
  
 +
The complete development process for the RIM is documented in HL7 [[Vocabulary and RIM Harmonization Process]], and subsequent GOM-defined Normative ballots.
  
<!-- This section is optional.  It identifies thoughts or guidance around how the artifact will be used.  This may include development process, guidance on how many of this type of artifact are likely to exist within a domain or topic, etc. -->
+
The process for updating the RIM that results from these processes is considered in [[#Tooling Considerations|Tooling Considerations]] above.
  
# Some text
+
== Governance Process Considerations ==
## <i>Rationale</i>: Some rationale
+
<!-- This section is optional.  It identifies anticipated or existing governance processes that control or impact this type of artifact.  -->
 
+
The HL7 Reference Information Model is managed under the ANSI "continuous maintenance" process, currently (April, 2011) as '''''HL7 Version 3 Standard: Reference Information Model, Release 4 [HL7 V3 RIM, R4]'''''
# Some other text
 
## <i>Rationale</i>: Some other rationale
 
  
 +
# All changes to RIM content SHALL be adopted through the HL7 [[Vocabulary and RIM Harmonization Process]], and subsequently approved through Normative ballot.
 +
## <i>Rationale</i>: Established governance
 +
#For elements of the RIM, both the '''action of deprecation''' and '''the final removal''' must be approved in [[Vocabulary and RIM Harmonization Process|harmonization]], and are subject to review in the next Normative ballot.
 +
## <i>Rationale</i>: Established governance
 +
# New content or changes to existing content should be widely reviewed within the affected HL7 Work Groups and with both Modeling and Methodology and Vocabulary before a change proposal is submitted for harmonization.
 +
## <i>Rationale</i>: The RIM is a consensus model that supports the entire HL7 community.  Therefore changes should have as broad a consensus as possible before they are brought forward.
 +
# Proposals for new or changed content should include a strong, readily understood use case that provides the requirements for that proposal.
 +
## <i>Rationale</i>: Necessary to justify and gain the approval from the harmonization meeting.
 +
# Each project SHALL be designed to derive from the release and version of the RIM that is current at the time that the project deliverables become a standard.
 +
## <i>Rationale</i>:
 +
# As such, the RIM definition and distribution SHALL be in a file that conforms to the [http://www.hl7.org/v3ballot/html/infrastructure/mif/mif.html HL7 Model Interchange Format] (MIF).
 +
## <i>Rationale</i>:
  
 
== Issues ==
 
== Issues ==
 
+
* Need approval and adoption of a "Deprecation" rule set that is more clear than I have
 
 
<!-- This section is optional. It identifies any outstanding issues (methodology or otherwise) that need to be resolved/answered as part of the guidelines -->
 
 
 
* Some issue
 
* Some other issue
 

Latest revision as of 16:20, 16 May 2011

Return to Artifact List

Reference Information Model (RIM)

Definition and Purpose

The HL7 Reference Information Model (RIM) is single artifact that is the foundation from which all V3 and SAIF logical and implementable information models SHALL be derived. It serves to unify the information content of HL7 V3 standards, affording more consistent representation of models and simpler implementation of models from multiple topics. The RIM is a class model that includes the state machines, associations and attributes of those classes.

SAIF Matrix Location

Row(s)

  • Logical (PIM)

Column(s)

  • Information

Audience

Health care Information Technology (IT) Audiences:

  • Standards developers and standards development organizations
  • System designers and architects
  • Programmers/implementers

Designers, modelers and implementers of v3 solutions being created under HL7 SAIF, which are required to be RIM-derived.

The RIM should be accessible and understandable for domain experts seeking to verify, map or align their analysis information models to the RIM.

Applicability

As a single, foundation, "reference" source for SAIF, the RIM is required for use by all v3 projects, but it does not need to be "created" by those projects.

Requirements, Relationships and Content

  1. Include the set of information classes that fully represent the information needed to support interoperability in the clinical and administrative functions of health care.
    1. Rationale As the foundation of HL7 SAIF, it must be able to represent the full spectrum of likely HL7 applicability.
  2. Include selected information classes that represent the computational and contractual information needed to implement health care interoperability.
    1. Rationale Must support the necessary communication artifacts (wrappers and the like) needed to establish information interoperability.
  3. Maintain a degree of abstraction in the RIM model such that there is, ideally, only one way to represent a data structure using RIM classes.
    1. Rationale Large models with myriad associations lead to ambiguity in selecting the preferred representation of a particular concept. A controlled abstract model eliminates or greatly reduces such ambiguity.
  4. Manage the abstraction in the RIM model using controlled terminologies (code systems) that are formally approved as an integral part of the RIM.
    1. Rationale Controlling terminologies determine the meaning of the concrete expression RIM abstractions, and must, themselves be part of the RIM.

Relationships and traceability

  • Bind the data types of the RIM attributes to a specific "abstract" data type representation formally adopted by HL7.
    • Rationale The data structures that derive from the RIM will draw much of their "type" information from data types assigned to RIM attributes. Thus these attributes have a data type representation that is fully as consistent and tightly managed as the RIM itself.
  • Establish a terminology binding for each "coded" attribute of the RIM to a specific Concept Domain that is drawn from an HL7-managed Vocabulary Model.
    • Rationale Over 40 per-cent of RIM attributes carry encoded values. The expected terminology binding for those attributes must be carefully defined and managed by HL7
  • Where a RIM class has a defined state machine, this SHALL conform to the Logical State Machine Artifact Definition

Artifact types that may or must relate to this artifact types:

Content

  • Model data - Defining data (including name, version, responsible party, and description) captured at the model level.
    • HL7-defined properties - Properties that formally extend the definition of a model beyond the UML specifications.
  • Association - UML element expressing relationships between classes with UML-specified characteristics such as descriptions, name, association ends, cardinalities, navigability, etc.
    • HL7-defined properties - Properties that formally extend the definition of an association beyond the UML specifications.
  • Class - UML element with UML-specified characteristics such as descriptions, name, etc.
    • Attribute - UML element with UML-specified characteristics such as descriptions, name, cardinality, etc.
      • Data type - Type assignment from HL7 data types specification.
      • HL7-defined properties - Properties that formally extend the definition of an attribute beyond the UML specifications.
    • HL7-defined properties - Properties that formally extend the definition of a class beyond the UML specifications.
    • State Machine optional - Identifies the states and transitions for a class
  • Subject area - (Non-normative) Element to collect classes into logical groupings.

Artifact Technology

The RIM is a UML Class model with extensions needed to document more specific content properties than are encompassed in UML and to define and manage terminology bindings.

Rationale

UML provides the key constructs of classes, attributes, associations & state machines and has the extensibility necessary to support the remaining requirements.

Alternatives

None. The MIF was defined for this purpose, and the RIM has been maintained in this fashion for several years.

Content Constraints

The following constraints are based on long-established HL7 policies and practices. The rationale, therefore, is to maintain consistency with the established RIMs and published HL7 standards.

  1. Once a RIM element (class, attribute, state, controlling code) has been included in a version of the RIM released for ballot, and that element has been used in a normative specification, the element cannot be removed from the RIM except by a process of Deprecation and delayed removal.
    1. Once an element has been deprecated it SHALL NOT be used in development of further derived models.
    2. Rationale: Established policy
  2. RIM UML content must include the following elements:
    1. Classes
    2. Associations (including generalizations, but excluding compositions and association classes)
    3. Attributes
    4. State machines for selected classes
    5. Definitive text for every element
    1. Rationale: Provide a RIM that is lean and understandable using standard modeling paradigm
  1. RIM Classes:
    1. Class names SHALL be "upper-camel-case" with no spaces and only alphabetic characters
    2. Classes may have the following HL7-defined properties.
      The properties are only listed here. Their formal definition and rules are in the RIM Normative specification.
      1. Property: classCode
      2. Property: stateAttribute
    3. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides
  1. Associations:
    1. Association ends will include names and cardinalities (limited to 0..1, 0..*, 1..1 and 1..*). Association end names SHALL be "lower-camel-case" with no spaces and only alphabetic characters
    2. Association ends must have the following HL7-defined property.
      The property is only listed here. Its formal definition and rules are in the RIM Normative specification.
      1. Property: allowedUpdateMode
      2. Property: availableUpdateModes
      3. Property: conformance
      4. Property: mandatoryInclusion
    3. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides
  1. RIM attributes:
    1. Attributes shall include names, cardinalities (limited to 0..1, 0..*, 1..1 and 1..*) and a data type drawn from a single, specified, HL7-approved Abstract Data Types Model. Attribute names SHALL be "lower-camel-case" with no spaces and only alphabetic characters and will follow a convention to identify the approximate data type (coded, boolean, name, etc.)
    2. Coded attributes must include the "vocabDomain" property. (see below)
    3. Attribute may have the following HL7-defined properties.
      The properties are only listed here. Their formal definition and rules are in the RIM Normative specification.
      1. Property: allowedUpdateMode
      2. Property: availableUpdateModes
      3. Property: conductible
      4. Property: conformance
      5. Property: defaultValue
      6. Property: isDocumentCharacteristic
      7. Property: isImmutable
      8. Property: mandatoryInclusion
      9. Property: vocabularyAssertion
    4. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides
  1. Additional MIF-defined annotations such as rationale, usage not4es, etc. may be included in the documentation of any RIM element.
    1. Rationale: Allow a rich set of annotations to make RIM content more readily understood.

Content Guidelines

Since the RIM is a formal specification that has been approved internationally and is in active use within the HL7 International communities, these guidelines are not designed to explain the current content, but rather to reflect guidelines for proposed changes.

  1. New content or changes to existing content should be designed for universal use in HL7 International.
    1. Rationale: The RIM is a consensus model that is required for use in all HL7 realms.
  2. New content should be added only when there is no reasonable way to represent the same content with existing RIM structures.
    1. Rationale: See requirement #3 and the objective of having only one way to express a given concept in the RIM.
  3. New attributes should not be added if the same information can be more appropriately represented as an "observation."
    1. Rationale: See requirement #3 and the objective of having only one way to express a given concept in the RIM.
  4. The definition of new RIM elements should not overlap with existing elements and the names for new elements (including controlling codes) should have universal applicability (as opposed to realm-specific).
    1. Rationale: Retain the abstract nature of the RIM and its ability to satisfy a broad range of needs.

Publishing Representation(s)

  1. The primary distribution of the RIM is in the form of a file formatted according to the HL7 Model Interchange Format (MIF).
    • Provides the computable representation needed by implementers
  2. HTML representation for the ballot is MIF-based, and includes UML Class Diagrams of the content
    • The RIM is balloted in its HTML representation, which uses the MIF representation as its source. The HTML format is familiar to most HL7 participants.
    • UML graphic representation is universal and familiar.
  3. Near-term (2011-12) distribution of the RIM in an Access data base format is used to support selected tools, notably the HL7 RMIM Designer (in Visio) and vocabulary management software.
    • Rationale: Support existing tool base.

Publishing Constraints

  1. Content is provided in two MIF files and a number of graphic files:
    • RIM "core" MIF containing the "technical content" (classes, attributes, etc.)
    • RIM "publication" MIF containing the balloting rules and definitions for the core properties and principles for the RIM. This also "structures" the presentation of the technical and graphic content.
    • RIM graphics in GIF and PDF (for very large diagram) formats
    1. Rationale: Formats required by publishing process
  2. Content publication is dependent upon of the joint publication of RIM with the Abstract Data Types and Vocabulary Model to which the RIM is bound.
    1. Rationale: These models are mutually inter-dependent

Tooling Considerations

The current RIM-tooling was first used 15 years ago. Although its technology is archaic, it is robust and replacement is not simple. Some of the features of the current RIM tools include:

  1. 2011 Technology Base:
    • Fundamental storage is in the Access data base known as a RIM Repository
    • Content management of the Access content is handled by DLLs from the RoseTree family maintained in Visual Basic 6.
      • Source code is on SVN
    • Model content is documented and updated in Rational Modeler (199x release) with HL7 properties defined. The content is then read and "synched" with the RIM repository using RoseTree invocations of the APIs provided by Rational Modeler, and a set of Access VBA software in HL7 "Access tools".
    • Extraction of RIM content and its expression in the primary MIF format is done as:
      1. Content is assembled in the RoseTree application (and manually reviewed, if needed)
      2. RoseTree expresses the full content in an idiosyncratic XML format
      3. The V3 Generator is used to convert the "RIM-XML" content into a correct MIF representation.
    • Complete RIM archival content (all releases back through 0.86 in 1997) is retained in an Access data base archive.
    • Migration of data to-from the archive is managed by a set of HL7 "Access tools" encoded in VBA in an Access data base. They permit the retrieval of older versions into a current repository.
    • Trained users: Although at one time Karen vanHentenryck was trained in the RIM update process, only G. Beeler has used this process in recent years. Although this may sound risky, the risk is ameliorated by the avialable of full content in MIF (excepting only the graphics).
  2. Nice-to-have - A RIM model management based on a UML tool
    • Clearly it would be desirable to manage the RIM content from a UML model tool that could read and write MIF either directly or through MIF to XMI transforms. Notes:
      • This is an easier task for the RIM than it would be for the generalized Static Model Designer because RIM content is not "constrained" by the RIM, does not need access to code systems, and has a very low rate of change.
      • A UML modeler would not need to read the RIM MIF provided that a means of robustly verifying that the modeler representation of the RIM and the MIF representation are identical. (The current RIM maintenance process uses this strategy to maintain alignment between the RIM repository and the Rose Modeler files.)
      • The archived RIM content should be extracted and converted to MIF format to provide a MIF archive of past RIMs, albeit absent the graphics, which would have to be archived separately in GIF and PDF files.
      • HL7 has the technical resources to make this conversion, but not the manpower resources to undertake it.

Artifact Exchange and Version Management

The primary distribution of the RIM is in the form of a file formatted according to the HL7 Model Interchange Format (MIF).

RationaleThe RIM is a core technology for HL7 endeavors. As such it is a necessary element of most HL7 design tools, and must be available in a processable, MIF format.

Authoring and Maintenance Tools

Development Process Considerations

There is one and only one RIM artifact (though it will be versioned)

The complete development process for the RIM is documented in HL7 Vocabulary and RIM Harmonization Process, and subsequent GOM-defined Normative ballots.

The process for updating the RIM that results from these processes is considered in Tooling Considerations above.

Governance Process Considerations

The HL7 Reference Information Model is managed under the ANSI "continuous maintenance" process, currently (April, 2011) as HL7 Version 3 Standard: Reference Information Model, Release 4 [HL7 V3 RIM, R4]

  1. All changes to RIM content SHALL be adopted through the HL7 Vocabulary and RIM Harmonization Process, and subsequently approved through Normative ballot.
    1. Rationale: Established governance
  2. For elements of the RIM, both the action of deprecation and the final removal must be approved in harmonization, and are subject to review in the next Normative ballot.
    1. Rationale: Established governance
  3. New content or changes to existing content should be widely reviewed within the affected HL7 Work Groups and with both Modeling and Methodology and Vocabulary before a change proposal is submitted for harmonization.
    1. Rationale: The RIM is a consensus model that supports the entire HL7 community. Therefore changes should have as broad a consensus as possible before they are brought forward.
  4. Proposals for new or changed content should include a strong, readily understood use case that provides the requirements for that proposal.
    1. Rationale: Necessary to justify and gain the approval from the harmonization meeting.
  5. Each project SHALL be designed to derive from the release and version of the RIM that is current at the time that the project deliverables become a standard.
    1. Rationale:
  6. As such, the RIM definition and distribution SHALL be in a file that conforms to the HL7 Model Interchange Format (MIF).
    1. Rationale:

Issues

  • Need approval and adoption of a "Deprecation" rule set that is more clear than I have