Forces Analysis

Understanding the forces that drive pattern selection is crucial for successful FHIR implementations. This analysis breaks down the key tensions and constraints that healthcare interoperability systems must address.

What are Forces?

In pattern-oriented design, forces are the conflicting concerns and constraints that shape a problem space. They represent the tensions that must be balanced when choosing and implementing design patterns.

For FHIR implementations, forces typically arise from:

• Technical constraints (performance, reliability, capability differences)
• Regulatory requirements (audit, consent, privacy)
• Organizational needs (federated access, legacy integration)
• Clinical workflows (real-time collaboration, imaging integration)

Detailed Force Analysis

Force Analysis Template

Each force follows a consistent structure:

• Problem Statement: Core issue or tension
• Manifestations: Real-world symptoms and examples
• Pattern Solutions: Specific patterns that address this force

---

Speed vs Rigor Forces

Ship quickly without undermining conformance and semantic consistency.

Short feedback loops

Problem: Late feedback increases rework cost.

Manifestations:

• Long review cycles
• Validation fails late
• Stakeholders disagree about narrative intent

Pattern Solutions:

• HL7 Build Preview Pipeline (base template): Use HL7 auto-build to generate previews for every push using fhir.base.template#current.
• Validator Gate in CI: Run IG Publisher validation as a hard gate on every PR.
• Example-Driven Profiling: Use examples as first-class design artifacts; every profile/value set validates and renders.

Avoid over-scoping

Problem: Big-bang scope stalls delivery.

Manifestations:

• Too many profiles/extensions in v0.1
• Unbounded terminology work
• No end-to-end demo

Pattern Solutions:

• Thin-Slice Use-Case First: Prevent profile-first paralysis by starting with a thin slice of a real workflow demonstrable end-to-end.
• Release Trains + Compatibility Contracts: Ship on predictable trains with semver, published packages, and compatibility promises.
• Profile Minimalism with Justification: Every constraint must have a reason, an example, and a test; keep profiles lean.

---

Interoperability reality Forces

Different products interpret edge cases differently; test explicitly.

Multi-product variance

Problem: Passing one tool does not guarantee ecosystem interoperability.

Manifestations:

• Terminology expansion differences
• Validation differences
• Search behavior differences

Pattern Solutions:

• Cross-Product Interop Matrix: Test across validators/servers/SDKs continuously to catch ecosystem differences early.
• TestScript / Inferno / Touchstone Alignment: Write portable conformance tests using TestScript/TestPlan conventions and execute on common platforms.
• Terminology as a Service (TaaS) Gate: Run $expand/$validate-code/$lookup in CI against a pinned terminology environment.

---

Meaning management Forces

Terminology changes can silently break interoperability; meaning must be governed and tested.

Terminology drift

Problem: ValueSet meaning changes across environments/versions.

Manifestations:

• Different expansions for same canonical
• Local codes proliferate
• Mappings become stale

Pattern Solutions:

• Three-Layer Terminology Model: Separate CodeSystem/ValueSet/ConceptMap roles to reduce semantic drift.
• Terminology as a Service (TaaS) Gate: Run $expand/$validate-code/$lookup in CI against a pinned terminology environment.
• Terminology Release Train: Coordinate terminology change with IG releases using deprecation windows and diffs.

---

Decision & ownership Forces

Without clear ownership and decisions, IGs accumulate conflicting constraints and slow reviews.

Too many cooks

Problem: Broad participation blocks decisions.

Manifestations:

• Meetings with 20 people
• No single owner
• Repeated debates

Pattern Solutions:

• Two-Speed Workgroups: Separate a small delivery core from a broader review ring to balance velocity and legitimacy.
• Decision Log (ADR) with Reversibility: Capture key decisions as lightweight ADRs with explicit revisit triggers.
• Definition-of-Done per Artifact: Define Done for each artifact type to prevent “nearly done” outputs.

---

Forces Summary Table

Force Area	Force	Description
Speed vs Rigor	Short feedback loops	Late feedback increases rework cost.
Speed vs Rigor	Avoid over-scoping	Big-bang scope stalls delivery.
Interoperability reality	Multi-product variance	Passing one tool does not guarantee ecosystem interoperability.
Meaning management	Terminology drift	ValueSet meaning changes across environments/versions.
Decision & ownership	Too many cooks	Broad participation blocks decisions.

How to Use This Analysis

1. Identify Your Forces: Review the force areas above to identify which forces are most relevant to your implementation context.

2. Prioritize: Not all forces carry equal weight in every scenario. Consider your specific regulatory, technical, and organizational constraints.

3. Select Patterns: Use the pattern solutions listed for each force as starting points for your architecture decisions.

4. Consider Interactions: Many forces are interconnected. Address related forces together using pattern combinations from the Co-Usage Map.

Start Small

Begin with the most critical forces for your use case, then incrementally address additional forces as your implementation matures.