Artifact Domain Artifact Definition

Return to Artifact List

Domain Artifacts - initial

Definition and Purpose

Groups all of the artifacts defined by a particular HL7 functional domain, perhaps within a particular namespace realm. The purpose of this "grouper" artifact is to collect or package the content defined by Work Groups or projects for a particular domain.

Domain

From the V3 Glossary:

Core Glossary:

1. A particular area of interest. For example, the domain for HL7 is healthcare.

2. The set of possible values of a data type , attribute, or data type component. See also vocabulary domain .

3. A special interest group within HL7, such as Pharmacy, Laboratory, or Patient Administration.

As used here, a domain is definition #3, as a qualification of definition #1.

Namespace Realm

From the "description" of the HL7Realm code system:

... concepts representing ... Namespace Realms (used to help ensure unique identification of HL7 artifacts). This code system is partitioned into three sections: Affiliate realms, Binding realms and Namespace realms. All affiliate realm codes may automatically be used as both binding realms and namespace realms...

SAIF Matrix Location

This artifact is "Level-independent" because it is designed to collect all artifacts from a particular domain and realm, regardless of which project or at which level they exist.

Row(s)

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

Column(s)

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

Audience

Health Care Information Technology (IT) Audiences:

• System designers and architects
• System purchasers
• Programmers/implementers
• System vendor management

Applicability

By definition, each domain in HL7 that is participating in SAIF will have one of these artifacts in the "universal" namespace realm. However, it is likely that this artifact will never be instantiated. Absent instantiation, it exists as the logical union of "All of the defined artifacts whose defined within this domain at the universal level."

Moreover, there will also be an artifact of this type for every non-universal namespace realm in which definitional artifacts for this domain are being created.

An "incomplete" variant of this artifact may be assembled (instantiated) for a particular purpose, such as balloting or publication.

Rationale: Domain Artifacts is the sole vehicle available for assembling a package of artifacts created for a particular domain. A package of this type "exists logically" whether or not an instance is every created.

Requirements, Relationships and Content

1. Provide a vehicle (grouper) that includes all of the artifact "output" for a particular HL7 [#Domain|domain].
   1. RationaleA domain is a grouping of activity used by HL7 to help manage the development of standards and their component artifacts. A domain requires a vehicle by which to refer to its output.
2. Provide an artifact that that includes a defined sub-set of the artifacts defined for a particular HL7 [#Domain|domain] and .
   1. RationaleThe acts of publishing and distributing HL7 defined artifacts requires the ability to define and assemble a sub-set of all artifacts for a particular domain, such as "those artifacts that are required for Normative Edition 2012."

Relationships and traceability

• If an instance is defined for a particular realm (such as universal or an affiliate realm), then that instance will be a subset of the unqualified Domain Artifacts for the same domain.
  • Rationale Each constrained instance of Domain Artifacts is a subset of one or more less constrained instances.
• If an instance is not complete and is defined for either a domain or a particular domain/realm combination, then that instance will be a subset of the complete instance of Domain Artifacts for the same definition.
  • Rationale Each constrained instance of Domain Artifacts is a subset of one or more less constrained instances.

Any artifact that is defined in a particular domain is contained in an instance this artifact type. Only only the following artifact types will not hold this relationship:

• Domain Artifacts (these relate as subs-sets, not as containment)
• Reference Information Model
• Abstract Data Types
• Vocabulary Model (and its sub-artifacts)
  • Concept Domains
  • Code System
  • Code System Supplement
  • Code Translations
  • Value Set
  • Context Binding
• Interface Model
• Structures Implementation Technology Specification
• Data Types Implementation Technology Specification

Content

• Identifier set - data elements specifying the HL7 functional domain (required) and namespace realm (optional) that defines this instance
  • Indicator that collection is complete, and, if not, an optional designator of the intended sub-set.
• Contents - All of the element types that are defined within domains. Excluded artifact types are listed under Relationships and traceability, above.

Artifact Technology

At its highest level, the Domain Artifacts instance for a given domain simply is an abstraction that is "created" the day the domain itself is defined. Instantiations of this artifact type created as a file that conforms to the HL7 Model Interchange Format (MIF).

The underlying technology is:

• Artifacts will be maintained in some form of "respository"
  • Current design content for universal specifications is maintained in SVN on the HL7 [http:/gforge.hl7.org/gf Gforge site]
    • Current practice maintains directory structures intended to hold the full content for each domain.
• Contained artifacts will be retrievable by instituting a query' (or equivalent) or defining a manifest for a particular sub-set
  • Current V3 Publishing Tools use a combination of:
    • ANT scripts to control the processes,

    • Publication Databases (Access) to both define subsets of Domain Artifacts and to define specific artifacts,

    • XSLT transforms to define/determine constraints', execute queries and build manifests

    • XML editors to define packages and content that are not covered by the above tools.

Rationale

• The whole of the HL7 specification management and publication process is based on the notion of producing "processable" content files in MIF that can be used to publish the ballot and as a resource for implementers. The definition of "Domain Artifacts" sub-sets is central to this process, and the underlying technology defined is the engine that runs this.
• The objective of the evolution of these tools is to move to an open platform dependent (Java). This is a work in progress. With the exception of the Publication Database and RMIM Designer, the rest of these tools have in recent years moved to this platform.

Alternatives

Proprietary tools

• Hl7 is working to extract itself from dependency on tools (Access and Visio) whose development paths do not necessarily coincide with ours, and which run on a limited, albeit ubiquitous, operating environment.

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