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

Difference between revisions of "Logical State Machine Artifact Definition"

From HL7Wiki
Jump to navigation Jump to search
(Replaced content with "{{subst::Template:SAIF Artifact Definition}}")
Line 1: Line 1:
 
 
[[Category:SAIF Artifact Definition]]
 
[[Category:SAIF Artifact Definition]]
 
[[:Category:SAIF Artifact Definition|Return to Artifact List]]
 
[[:Category:SAIF Artifact Definition|Return to Artifact List]]
  
=Some Artifact Name=
+
=Logical State Machine=
  
 
<!-- Artifact names should be descriptive and short.  They may change as we further refine the methodology -->
 
<!-- Artifact names should be descriptive and short.  They may change as we further refine the methodology -->
Line 11: Line 10:
 
<!-- 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 -->
  
Put text here
+
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 ==
 
== SAIF Matrix Location ==
Line 17: Line 16:
 
<!-- Where does this artifact fit into the SAIF matrix?  Delete those rows and columns that do not apply and provide qualification if appropriate -->
 
<!-- Where does this artifact fit into the SAIF matrix?  Delete those rows and columns that do not apply and provide qualification if appropriate -->
 
'''Row(s)'''
 
'''Row(s)'''
* Conceptual (CIM)
 
 
* Logical (PIM)
 
* Logical (PIM)
* Implementable (PSM)
 
  
 
'''Column(s)'''
 
'''Column(s)'''
* Enterprise/Business
 
* Information
 
 
* Computational
 
* Computational
* Engineering
 
* Technical
 
  
 
== Prior Methodology Correspondence ==
 
== Prior Methodology Correspondence ==
  
 
<!-- Identifies how this artifact relates to artifacts from HL7's previous methodology and, in particular, whether there have been changes in scope or behavior from previous artifacts.  In some cases, the artifact will be net new. -->
 
<!-- Identifies how this artifact relates to artifacts from HL7's previous methodology and, in particular, whether there have been changes in scope or behavior from previous artifacts.  In some cases, the artifact will be net new. -->
 +
Corresponds with the state machine defined in prior methodology.
  
 
== Audience ==
 
== Audience ==
  
 
<!-- Who will be the consumers of this artifact type and what will they do with it? Select from or add to the following lists.-->
 
<!-- Who will be the consumers of this artifact type and what will they do with it? Select from or add to the following lists.-->
Health Care Community Audiences:
 
*General public <!-- as health care participants -->
 
*Health care practitioners <!-- of all stripes -->
 
*Health system administrators <!-- includes payors, pharma management -->
 
*Health care policy makers
 
 
 
Health Care Semantic Analysis Audiences:
 
Health Care Semantic Analysis Audiences:
 
*Business Analysts: Map requirements to models (or system requirements)
 
*Business Analysts: Map requirements to models (or system requirements)
*Informaticists: Select and differentiate between information models and terminologies
 
 
*System analysts: Map system requirements to specific technical solutions
 
*System analysts: Map system requirements to specific technical solutions
  
Line 49: Line 36:
 
*Standards developers and standards development organizations
 
*Standards developers and standards development organizations
 
*System designers and architects
 
*System designers and architects
*System purchasers
 
*Programmers/implementers
 
*System vendor management
 
*Education/Research
 
  
 
== Applicability ==
 
== Applicability ==
  
 
<!-- Under what circumstances does this artifact type need to be created?  Are there circumstances where this artifact should not exist?  Why? -->
 
<!-- Under what circumstances does this artifact type need to be created?  Are there circumstances where this artifact should not exist?  Why? -->
Text
+
A logical state machine is mandatory for each RIM class with a populated stateAttribute property.
  
<i>Rationale</i>: More text
+
<i>Rationale</i>: Provides the reference behavior semantics for key RIM classes.
  
 
== Requirements, Relationships and Content ==
 
== Requirements, Relationships and Content ==
  
 
<!-- 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.) -->
 
<!-- 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.) -->
# Some requirement
+
# Include the set of states needed a rich set of behaviors for information objects relevant to healthcare.
## <i>Rationale</i>Some reason
+
## <i>Rationale</i>: Provides common behavioral semantics for RIM based models.
 
# Some other requirement
 
# Some other requirement
 
## <i>Rationale</i>Some other reason
 
## <i>Rationale</i>Some other reason

Revision as of 20:10, 20 July 2011

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 a rich set of behaviors for information objects relevant to healthcare.
    1. Rationale: Provides common behavioral semantics for RIM based models.
  2. Some other requirement
    1. RationaleSome other reason

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

Artifact Exchange and Version Management

Authoring and Maintenance Tools

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