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

Difference between revisions of "Sandbox"

From HL7Wiki
Jump to navigation Jump to search
(Replaced content with "hello")
Line 1: Line 1:
hello
+
 
 +
[[Category:SAIF Artifact Definition]]
 +
[[:Category:SAIF Artifact Definition|Return to Artifact List]]
 +
 
 +
=Some Artifact Name=
 +
 
 +
<!-- Artifact names should be descriptive and short.  They may change as we further refine the methodology -->
 +
 
 +
== Definition and Purpose ==
 +
 
 +
<!-- At a high level, what is this artifact and why is it needed?  Should ideally be only a few sentences -->
 +
 
 +
Put text here
 +
 
 +
== SAIF Matrix Location ==
 +
 
 +
<!-- 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)'''
 +
* Conceptual (CIM)
 +
* Logical (PIM)
 +
* Implementable (PSM)
 +
 
 +
'''Column(s)'''
 +
* Enterprise/Business
 +
* Information
 +
* Computational
 +
* Engineering
 +
* Technical
 +
 
 +
== 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. -->
 +
 
 +
== 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.-->
 +
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:
 +
*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
 +
 
 +
Health Care Information Technology (IT) Audiences:
 +
*Standards developers and standards development organizations
 +
*System designers and architects
 +
*System purchasers
 +
*Programmers/implementers
 +
*System vendor management
 +
*Education/Research
 +
 
 +
== Applicability ==
 +
 
 +
<!-- Under what circumstances does this artifact type need to be created?  Are there circumstances where this artifact should not exist?  Why? -->
 +
Text
 +
 
 +
<i>Rationale</i>: More text
 +
 
 +
== 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.) -->
 +
# Some requirement
 +
## <i>Rationale</i>Some reason
 +
# Some other requirement
 +
## <i>Rationale</i>Some other reason
 +
=== 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?
 +
 
 +
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 relationship
 +
** <i>Rationale</i>: Reason for relationship
 +
* Some other relationship
 +
** <i>Rationale</i>: Reason for other relationship
 +
 
 +
<b>Artifact types that may or must relate to this artifact types:</b>
 +
* Many-related Artifact Type
 +
* Another Many-related Artifact Type
 +
 
 +
=== 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.) -->
 +
* <b>Content element name</b> - Brief Description
 +
* <b>Another content element name</b> - Brief Description
 +
** <b>Sub-element name</b> - Brief Description
 +
* <b>Another content element name</b> - Brief Description
 +
 
 +
== Artifact Technology ==
 +
 
 +
<!-- What technological/standard solution has been selected for use in creating this artifact and why? -->
 +
Text here
 +
 
 +
=== Rationale ===
 +
 
 +
<!-- What's the justification for selecting the chosen technology? -->
 +
* Some reason
 +
* Some other reason
 +
 
 +
=== Alternatives ===
 +
 
 +
<!-- What other technical solutions might have been possible that were discarded, what did they offer and why were they not chosen? -->
 +
 
 +
<b>Some technology</b>
 +
* Some pro or con
 +
* Some other pro or con
 +
 
 +
== Content Constraints ==
 +
 
 +
<!-- 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 rules.  These are rules that can reasonably be enforced or validated by tools. -->
 +
# Some rule
 +
## <i>Rationale</i>: Some reason
 +
# Some other rule
 +
## <i>Rationale</i>: Some other reason
 +
 
 +
== Content Guidelines ==
 +
 
 +
<!-- 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. -->
 +
# Some rule
 +
## <i>Rationale</i>: Some reason
 +
# Some other rule
 +
## <i>Rationale</i>: Some other reason
 +
 
 +
== Publishing Representation(s) ==
 +
 
 +
<!-- How will this artifact be shared and published as part of specifications? -->
 +
# Some text
 +
## <i>Rationale</i>: Some rationale
 +
# Some other text
 +
## <i>Rationale</i>: Some other rationale
 +
 
 +
== Publishing Constraints ==
 +
 
 +
<!-- 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? -->
 +
# Some rule
 +
## <i>Rationale</i>: Some reason
 +
# Some other rule
 +
## <i>Rationale</i>: Some other reason
 +
 
 +
== Tooling Considerations ==
 +
 
 +
<!-- What tooling features are required or "nice to have" to allow successful development, publication or other use of the artifact? -->
 +
# Nice-to-have|Required: Some feature
 +
## <i>Rationale</i>: Some rationale
 +
# Nice-to-have|Required: Some other feature
 +
## <i>Rationale</i>: Some other rationale
 +
 
 +
== Development Process Considerations ==
 +
 
 +
 
 +
<!-- 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. -->
 +
 
 +
# Some text
 +
## <i>Rationale</i>: Some rationale
 +
# Some other text
 +
## <i>Rationale</i>: Some other rationale
 +
 
 +
== Artifact Exchange and Version Management ==
 +
 
 +
 
 +
<!-- What is the format that will be used to share and exchange "source" representations of this artifact and how will it be managed in source control? -->
 +
 
 +
== Authoring and Maintenance Tools ==
 +
 
 +
 
 +
<!-- What tool or set of alternate tools will be used by HL7 International and recommended for use by others for the development and maintenance of this artifact? -->
 +
 
 +
== Governance Process Considerations ==
 +
 
 +
 
 +
<!-- This section is optional.  It identifies anticipated or existing governance processes that control or impact the development and adoption of this type of artifact.  -->
 +
 
 +
# <b>Governance Process name</b> - Some process description
 +
## <i>Rationale</i>: Some rationale
 +
# <b>Another Governance Process name</b> - Process description
 +
## <i>Rationale</i>: Some other rationale
 +
 
 +
== Issues ==
 +
 
 +
 
 +
<!-- 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

Revision as of 23:31, 12 September 2011

Return to Artifact List

Some Artifact Name

Definition and Purpose

Put text here

SAIF Matrix Location

Row(s)

  • Conceptual (CIM)
  • Logical (PIM)
  • Implementable (PSM)

Column(s)

  • Enterprise/Business
  • Information
  • Computational
  • Engineering
  • Technical

Prior Methodology Correspondence

Audience

Health Care Community Audiences:

  • General public
  • Health care practitioners
  • Health system administrators
  • Health care policy makers

Health Care Semantic Analysis Audiences:

  • 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

Health Care Information Technology (IT) Audiences:

  • Standards developers and standards development organizations
  • System designers and architects
  • System purchasers
  • Programmers/implementers
  • System vendor management
  • Education/Research

Applicability

Text

Rationale: More text

Requirements, Relationships and Content

  1. Some requirement
    1. RationaleSome reason
  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