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

Difference between revisions of "Conceptual - Computational"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
'''Owner'''
 
'''Owner'''
 
AMS will do, John Koisch will review
 
AMS will do, John Koisch will review
 +
 
'''Summary'''
 
'''Summary'''
 
Conceptual artifacts representing analysis and requirements for communicating between applications to support a particular business purpose for a particular healthcare domain or topic.  
 
Conceptual artifacts representing analysis and requirements for communicating between applications to support a particular business purpose for a particular healthcare domain or topic.  
  
'''Detail - Computational Semantics at the Conceptual Level''
+
'''Detail - Computational Semantics at the Conceptual Level'''
 
Capturing semantics at the Conceptual level using the Computational Viewpoint is done to provide both consistency to the rest of the specification and to lay the foundation for a more rigorous discussion of computational semantics at the platform-independent levels. This is done by focusing on TODO
 
Capturing semantics at the Conceptual level using the Computational Viewpoint is done to provide both consistency to the rest of the specification and to lay the foundation for a more rigorous discussion of computational semantics at the platform-independent levels. This is done by focusing on TODO
  
'''Traceability to Reference Material'''
+
=Traceability to Reference Material=
 
Should formally be expressed using the Behavioral Framework schema. May also reference other analysis artifacts from other sources, such as the EHRs-FM or Clinical Statements.
 
Should formally be expressed using the Behavioral Framework schema. May also reference other analysis artifacts from other sources, such as the EHRs-FM or Clinical Statements.
  
'''Relationship to and Consistency with other Viewpoints'''
+
=Best Practices / Templates=
At the Conceptual level, the Computational constructs may reflect a level of analysis without undue concern for engineering the components into appropriate primitives or worrying about intersections with other viewpoints. For example, if an appropriate Domain Analysis Model exists, then it a Conceptual specification should call that model out, and concepts from it may be used in describing the functional and collaborative behaviors for distributed systems at this level. However, these are not always available.  
+
TODO
 +
 
 +
=Quality Criteria=
 +
TODO
 +
 
 +
=Conformance Statement=
 +
TODO
 +
 
 +
==Guidance on format of Conformance Statement==
 +
TODO
 +
 
 +
 
 +
=Relationship to and Consistency with other Viewpoints=
 +
At the Conceptual level, the Computational constructs may reflect a level of analysis without undue concern for engineering the components into appropriate primitives or worrying about intersections with other viewpoints. However, if those connections can be made, they should be made. For example, if an appropriate Domain Analysis Model exists, then it a Conceptual specification should call that model out, and concepts from it may be used in describing the functional and collaborative behaviors for distributed systems at this level. However, these are not always available.
  
'''Candidate Artifacts'''
+
=Candidate Artifacts=
 
* Analysis Activity Diagram - These activity diagrams should contain business roles and responsibilities partitioned across swimlanes. They should reference domain objects of significance, but should not provide details past what would be found in the domain analysis model (whether real or notional).  
 
* Analysis Activity Diagram - These activity diagrams should contain business roles and responsibilities partitioned across swimlanes. They should reference domain objects of significance, but should not provide details past what would be found in the domain analysis model (whether real or notional).  
 
* Collaboration Analysis - Collaborations (defined in the Behavioral Framework) may be defined in some detail here, including descriptions, business milestones, and broad sequencing of communications between elements. These collaborations should re-use, where available, Service Roles, and should define the relationships between those roles and other actors in the collaborations (broken down by Commissioning and Responsible Agents).  
 
* Collaboration Analysis - Collaborations (defined in the Behavioral Framework) may be defined in some detail here, including descriptions, business milestones, and broad sequencing of communications between elements. These collaborations should re-use, where available, Service Roles, and should define the relationships between those roles and other actors in the collaborations (broken down by Commissioning and Responsible Agents).  
Line 20: Line 34:
 
* Service Roles and Relationships - Service Roles may be defined at the Conceptual level, providing foundational elements such as  
 
* Service Roles and Relationships - Service Roles may be defined at the Conceptual level, providing foundational elements such as  
  
'''Examples'''
+
=Examples=
TODO
+
The following examples are full specifications. Following the link, the appropriate sections of the specifications that support the Computational Viewpoints are in brackets.
 +
* EIS Service Functional Model
 +
* RLUS Service Functional Model
 +
* NCI Person Service SPecification
 +
 
  
 
Back to [[Saeaf_specification_stack | SAEAF Specification Stack]]
 
Back to [[Saeaf_specification_stack | SAEAF Specification Stack]]

Latest revision as of 23:01, 16 April 2009

Conceptual - Computational Owner AMS will do, John Koisch will review

Summary Conceptual artifacts representing analysis and requirements for communicating between applications to support a particular business purpose for a particular healthcare domain or topic.

Detail - Computational Semantics at the Conceptual Level Capturing semantics at the Conceptual level using the Computational Viewpoint is done to provide both consistency to the rest of the specification and to lay the foundation for a more rigorous discussion of computational semantics at the platform-independent levels. This is done by focusing on TODO

Traceability to Reference Material

Should formally be expressed using the Behavioral Framework schema. May also reference other analysis artifacts from other sources, such as the EHRs-FM or Clinical Statements.

Best Practices / Templates

TODO

Quality Criteria

TODO

Conformance Statement

TODO

Guidance on format of Conformance Statement

TODO


Relationship to and Consistency with other Viewpoints

At the Conceptual level, the Computational constructs may reflect a level of analysis without undue concern for engineering the components into appropriate primitives or worrying about intersections with other viewpoints. However, if those connections can be made, they should be made. For example, if an appropriate Domain Analysis Model exists, then it a Conceptual specification should call that model out, and concepts from it may be used in describing the functional and collaborative behaviors for distributed systems at this level. However, these are not always available.

Candidate Artifacts

  • Analysis Activity Diagram - These activity diagrams should contain business roles and responsibilities partitioned across swimlanes. They should reference domain objects of significance, but should not provide details past what would be found in the domain analysis model (whether real or notional).
  • Collaboration Analysis - Collaborations (defined in the Behavioral Framework) may be defined in some detail here, including descriptions, business milestones, and broad sequencing of communications between elements. These collaborations should re-use, where available, Service Roles, and should define the relationships between those roles and other actors in the collaborations (broken down by Commissioning and Responsible Agents).
  • EHR-FM Profile(s)
  • Service Roles and Relationships - Service Roles may be defined at the Conceptual level, providing foundational elements such as

Examples

The following examples are full specifications. Following the link, the appropriate sections of the specifications that support the Computational Viewpoints are in brackets.

  • EIS Service Functional Model
  • RLUS Service Functional Model
  • NCI Person Service SPecification


Back to SAEAF Specification Stack