Why Health Informatics Needs a Work-Item Meta-Model, Not Just a Fields Table

From a Simple Request to a Meta-Model

In health informatics, a seemingly simple requirement often hides a complex web of rules. Consider a clinician saying: "When a defect moves from 'pending verification' to 'closed,' the system must require a verification result." That sounds straightforward. But swap 'verification result' for 'root cause,' and the rule changes completely. Root cause analysis happens during investigation, not at closure, and low-risk defects may not warrant it. So you'd design it as: verification result is mandatory at closure, but root cause is only required for high-severity defects. That's a different rule for a different stage.

This is where a work-item meta-model becomes essential. It separates six questions: What is this object? What facts can it hold? How do users interact with it? How can it change? What can it connect to? And where do these rules apply? Each has its own model, and they combine at runtime to define a single work item.

Types Define Identity, Not Defaults

A work-item type is the stable identity of a class of objects—like 'defect' or 'clinical task'—not a container for default assignees or field rules. In health systems, a 'clinical note' type shouldn't hardcode a default owner because different departments (radiology, cardiology) will have different assignment rules. The assignee is a person-type attribute, and its default value and candidate pool are rules scoped to the space and business context.

If you bake a default assignee into the type, you're stuck when a team's structure changes. Instead, keep the type lean: name, icon, description, lifecycle. Let the attribute model handle who's responsible, and let the workflow define when that responsibility can change.

Attributes: More Than Just Fields

Health informatics deals with complex data: not just text and dates, but patient identifiers, lab values, medications, imaging references, and timestamps. A 'custom field' model falls short. A unified attribute model treats everything—text, numbers, people, attachments, hours, references—as a single contract. Each attribute has an ID, a data type, a value structure, cardinality, default rules, permissions, and query capabilities.

This uniformity pays off. The same attribute can appear in a creation form, a detail view, a transition screen, or an API payload. It's the same definition, just presented differently. That's crucial for interoperability, a cornerstone of health informatics.

Scope: Global vs. Space-Level Attributes

In a project-management tool, you might have global fields for common concepts and space-specific fields for team nuances. Health systems face the same tension. A 'patient ID' should be a global attribute, while a 'research cohort' might be space-specific. The rule: global attributes carry the organization's standard vocabulary; space attributes carry local business language. But a work item instance stores only the actual values.

A critical guideline: don't create duplicate attributes for a one-off project. Instead, scope existing attributes to a context. If two spaces use the same attribute name but mean different things, they should be separate attributes. If they mean the same thing, they should share an ID so cross-space reports stay meaningful.

Workflow: States and Steps, Not Just Statuses

A workflow defines the lifecycle of a work item through states and steps. States are stable phases (e.g., 'open', 'in review', 'closed'). Steps are the actions that move between states, with conditions, required attributes, and post-actions. For health informatics, this is where compliance lives: a medication order can only go to 'dispensed' after a pharmacist approves it. That's a step with a permission check and a required 'approval note' attribute.

When designing multi-flow support, separate three concerns: how multiple workflows are configured for a type, how a specific workflow is chosen at creation, and whether the workflow allows parallel nodes. Different products handle this differently—some use mappings, some use business-field routing, some allow parallel states. Choose based on your clinical process complexity.

Layouts: Context Matters

Page layouts are not just field arrangements; they're context-specific views. The creation form should be minimal to get the object valid; the detail view should prioritize status and actions; the transition screen should collect the attributes required for that specific step. In health informatics, a nurse might see a simplified view for quick data entry, while a physician sees a full diagnostic panel. Layouts must respect role-based visibility and data-entry requirements.

Remember: layouts are not the source of truth for validation. Server-side rules must enforce mandatory fields and permissions, not just the UI. Otherwise, batch imports or APIs can bypass required checks.

Relationships: More Than Lines

Work items connect in two ways: hierarchy (parent-child) and association (dependencies, blocks, relates-to). In health, a patient case might have sub-tasks for each diagnostic test, and a medication order might block a discharge. These relationships carry semantics: hierarchy aggregates progress, while associations may affect scheduling and permissions. Don't store just a parent ID; define allowed parent-child types, depth limits, and whether cross-space relationships are allowed.

Config Scope: Space Over Project

Jira's recent rename from 'Project' to 'Space' reflects a deeper truth: long-lived teams need a container that outlasts individual projects. In health informatics, a clinical department is a space; a specific research study is a delivery context within it. Don't create a new container for each study—use goals, versions, and iterations to bound the work. This keeps configuration manageable and reports consistent.

Configuration Changes Are Data Migration

Changing an attribute's type or a workflow's state is not a simple edit; it's a migration. Existing work items may have values that don't map cleanly. For example, changing a free-text 'priority' to a single-select requires mapping old values like 'high' to the new set. Always use stable IDs for types, attributes, and workflows, and track references. Provide draft and versioning for high-risk changes, and plan for deprecation and migration paths.

Putting It All Together

The meta-model isn't just a technical exercise; it's what makes a health informatics platform both flexible and safe. By separating type, attributes, workflow, layout, relationships, and scope, you can adapt to new clinical workflows without breaking existing ones. The next time someone asks for a mandatory field on closure, you'll know exactly where to put it—in the step, not the type.