Specification Templates
Ready-to-use templates for documenting FERIN register specifications. Customize for your register type and requirements.
Template Overview
Every FERIN register should have a specification document. These templates provide a starting point for each register type.
Content Register Template
Use this template for Content Registers and Governed Content Registers.
# Register Specification
## 1. General Information
| Field | Value |
|-------|-------|
| Register Title | [Your Register Name] |
| Register Abbreviation | [Abbreviation] |
| Version | [Version Number] |
| Specification Date | [YYYY-MM-DD] |
| Register Type | Content Register / Governed Content Register |
## 2. Scope and Purpose
### 2.1 Purpose
[Describe why this register exists and what problem it solves.]
### 2.2 Scope
[Describe what is included in this register.]
**Included:**
- [Item type 1]
- [Item type 2]
**Excluded:**
- [Out of scope item 1]
- [Out of scope item 2]
### 2.3 Target Users
[List who will use this register and for what purposes.]
### 2.4 Use Cases
1. [Use case 1]
2. [Use case 2]
## 3. Identifier Scheme
### 3.1 Object Identifier Format
[Specify format, e.g., `urn:org:type:id`]
### 3.2 Functional Identifier Format (if used)
[Specify format, e.g., `prefix:code`]
### 3.3 Assignment Rules
[Describe how identifiers are assigned.]
### 3.4 Persistence Policy
[Describe commitment to identifier persistence.]
## 4. Content Requirements
### 4.1 Required Attributes
| Attribute | Type | Description | Constraints |
|-----------|------|-------------|-------------|
| [name] | [type] | [description] | [constraints] |
### 4.2 Optional Attributes
| Attribute | Type | Description | Constraints |
|-----------|------|-------------|-------------|
### 4.3 Content Validation Rules
[Describe any content validation rules.]
## 5. Versioning
### 5.1 Versioning Scheme
[Describe versioning approach, e.g., semantic versioning.]
### 5.2 Substantive Change Criteria
[List what constitutes a substantive change requiring a new version.]
## 6. Status Management
### 6.1 Status Values
- Valid / Invalid
- Published / Unpublished
### 6.2 Status Transitions
[Describe allowed status transitions.]
## 7. Governance (if applicable)
### 7.1 Register Owner
[Name and organization]
### 7.2 Register Manager
[Name and organization]
### 7.3 Control Body
[Name and composition]
### 7.4 Proposal Process
[Describe how proposals are submitted and processed.]
### 7.5 Approval Criteria
[List criteria for approving proposals.]
### 7.6 Appeal Process
[Describe how to appeal decisions.]
## 8. Conformance Claims
### 8.1 Register Type
[Specify claimed register type(s).]
### 8.2 Capabilities
[List implemented capabilities beyond minimum.]Concept Register Template
Extends the Content Register template with concept modeling sections.
Additional Sections for Concept Registers
## 9. Concept Modeling
### 9.1 Concept Definition Requirements
[Describe required elements for concept definitions.]
### 9.2 Concept Versioning
[Describe how concept versions are managed.]
### 9.3 Concept-Item Linking
[Describe how concepts link to register items.]
## 10. Concept Relationships
### 10.1 Inheritance (Is-A)
[Describe if and how inheritance is used.]
### 10.2 Composition (Has-Part)
[Describe if and how composition is used.]
### 10.3 Custom Relationships
[List any custom relationship types.]
## 11. Concept Domains (if used)
### 11.1 Domain Definitions
| Domain Name | Values | Description |
|-------------|--------|-------------|
| [domain] | [values] | [description] |
## 12. Codeset Incorporation (if used)
### 12.1 Incorporated Codesets
| Codeset | Source | Scope |
|---------|--------|-------|
| [name] | [URL] | [scope] |
### 12.2 Synchronization Strategy
[Describe how incorporated codesets are synchronized.]Governed Register Template
Extends templates with complete governance documentation.
Additional Sections for Governed Registers
## 13. Governance Framework
### 13.1 Governance Structure
| Role | Name/Organization | Responsibilities |
|------|-------------------|------------------|
| Register Owner | | |
| Register Manager | | |
| Control Body | | |
### 13.2 Proposal Types
[List types of proposals that can be submitted.]
### 13.3 Proposal Requirements
[List required information for proposals.]
### 13.4 Review Process
[Describe the review workflow.]
### 13.5 Decision Criteria
[List criteria used to make decisions.]
### 13.6 Timeline Requirements
| Proposal Type | Target Response |
|---------------|-----------------|
| [type] | [timeframe] |
## 14. Audit and Compliance
### 14.1 Audit Trail Requirements
[Describe what is recorded in the audit trail.]
### 14.2 Audit Trail Retention
[Specify retention period for audit records.]
### 14.3 Compliance Requirements
[List any regulatory or policy requirements.]
## 15. Transparency
### 15.1 Public Information
[Describe what is publicly visible.]
### 15.2 Confidential Information
[Describe what is kept confidential and why.]CCR Template
The complete template for Complete Concept Registers. Combine all previous sections with commitments documentation.
Additional Sections for CCR
## 16. Commitments
### 16.1 Access Commitments
| Commitment | Level | Description |
|------------|-------|-------------|
| Access - Metadata | [None/Low/Medium/High] | [description] |
| Access - Content | [None/Low/Medium/High] | [description] |
| Access - Historic | [None/Low/Medium/High] | [description] |
### 16.2 Persistence Commitments
| Commitment | Level | Description |
|------------|-------|-------------|
| Persistence - Identifier | [None/Low/Medium/High] | [description] |
| Persistence - Content | [None/Low/Medium/High] | [description] |
| Persistence - Historic | [None/Low/Medium/High] | [description] |
### 16.3 Transparency Commitments
| Commitment | Level | Description |
|------------|-------|-------------|
| Transparency | [None/Low/Medium/High] | [description] |
### 16.4 Succession Plan (if applicable)
[Describe succession arrangements if register is discontinued.]
## 17. Service Level Agreements
### 17.1 Availability
[Specify availability commitment, e.g., 99.9%]
### 17.2 Response Times
[Specify target response times for operations.]
### 17.3 Support
[Describe support arrangements.]
## 18. Operational Requirements
### 18.1 Backup and Recovery
[Describe backup procedures and recovery objectives.]
### 18.2 Security
[Describe security measures in place.]
### 18.3 Monitoring
[Describe health monitoring arrangements.]Completeness Checklist
Use this checklist to verify your specification is complete:
Essential (All Types)
- ☐ Register title and abbreviation
- ☐ Scope and purpose
- ☐ Identifier scheme
- ☐ Content requirements
- ☐ Versioning approach
- ☐ Status management
- ☐ Conformance claims
Concept Registers
- ☐ Concept definition requirements
- ☐ Concept versioning rules
- ☐ Concept relationships
- ☐ Domain definitions (if used)
Governed Registers
- ☐ Role assignments
- ☐ Proposal process
- ☐ Approval criteria
- ☐ Appeal process
- ☐ Audit requirements
CCR Only
- ☐ Access commitments
- ☐ Persistence commitments
- ☐ Transparency commitments
- ☐ Succession plan
- ☐ SLA definitions
Example Specifications
See these complete examples:
- RUM: Register of Units of Measure - Full CCR specification example