Logical State Machine Artifact Definition

Return to Artifact List

Logical State Machine

Definition and Purpose

The primary purpose of a logical state machines is to allow "trigger events" (events that initiate communication) to be defined with respect to the state transitions of select RIM class. These logical state machines are not intended to represent a full behavioral model for their respective classes. At present, logical state machines are only defined for those "back bone" classes that have a unique identity, and thus represent persistent concepts.

SAIF Matrix Location

Row(s)

• Logical (PIM)

Column(s)

• Computational

Prior Methodology Correspondence

Corresponds with the state machine defined in prior methodology.

Audience

Health Care Semantic Analysis Audiences:

• Business Analysts: Map requirements to models (or system requirements)
• System analysts: Map system requirements to specific technical solutions

Health Care Information Technology (IT) Audiences:

• Standards developers and standards development organizations
• System designers and architects

Applicability

A logical state machine is mandatory for each RIM class with a populated stateAttribute property.

Rationale: Provides the reference behavior semantics for key RIM classes.

Requirements, Relationships and Content

1. Include the set of states needed to support a rich set of behaviors for information objects relevant to healthcare.
   1. Rationale: Provides common behavioral semantics for RIM based models.
2. Maintain a degree of abstraction in the logical state machine model such that they can be used across a broad range of healthcare information objects.
   1. Rationale: The state machine must be applicable to all healthcare objects represented by the associated RIM class. Many healthcare objects may have fine grained specialized states that are not broadly applicable.
3. Manage the allowed states for a particular logical state machine using controlled terminologies (code systems) that are formally approved as an integral part of the RIM. These terminologies shall be universally bound to the RIM class attribute identified in the stateAttribute for the associated RIM class.
   1. Rationale: Controlling terminologies determine the meaning of the abstract states, and must, themselves be part of the RIM.

Relationships and traceability

• Some relationship
  • Rationale: Reason for relationship
• Some other relationship
  • Rationale: Reason for other relationship

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

• Many-related Artifact Type
• Another Many-related Artifact Type

Content

• Content element name - Brief Description
• Another content element name - Brief Description
  • Sub-element name - Brief Description
• Another content element name - Brief Description

Artifact Technology

Text here

Rationale

• Some reason
• Some other reason

Alternatives

Some technology

• Some pro or con
• Some other pro or con

Content Constraints

1. Some rule
   1. Rationale: Some reason
2. Some other rule
   1. Rationale: Some other reason

Content Guidelines

1. Some rule
   1. Rationale: Some reason
2. Some other rule
   1. Rationale: Some other reason

Publishing Representation(s)

1. Some text
   1. Rationale: Some rationale
2. Some other text
   1. Rationale: Some other rationale

Publishing Constraints

1. Some rule
   1. Rationale: Some reason
2. Some other rule
   1. Rationale: Some other reason

Tooling Considerations

1. Nice-to-have|Required: Some feature
   1. Rationale: Some rationale
2. Nice-to-have|Required: Some other feature
   1. Rationale: Some other rationale

Development Process Considerations

1. Some text
   1. Rationale: Some rationale
2. Some other text
   1. Rationale: Some other rationale

Governance Process Considerations

1. Governance Process name - Some process description
   1. Rationale: Some rationale
2. Another Governance Process name - Process description
   1. Rationale: Some other rationale

Issues

• Some issue
• Some other issue