Care Coordination Management
0.0.1 - ci-build Estonia (EST)

Care Coordination Management, published by Helex OÜ. This guide is not an authorized publication; it is the continuous build for version 0.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/helexlab/bridge-ig/ and changes regularly. See the Directory of published versions

Governance and Operational Framework

OVERVIEW

The Technical Working Group (TWG) is established to support the development of a comprehensive reference architecture describing health-specific Digital Public Infrastructure (DPI-H), and foundational DPI (DPI-F) for health sector goals.

Objectives of the Project

  • Develop detailed technical specifications and implementation guidance (IG) for DPI-H services that interface with DPI-F services
  • Ensure architectural coherence and interoperability across all components
  • Ensure architecture supports effective implementation of TEHIK Implementation Guides and WHO SMART Guidelines
  • Create narrative guidance and document best practices
  • Deliver high-quality, evidence-based technical documentation

Purpose of this document

To guide TWG members on the modus operandi for the coordinated design, development and documentation of a standards-aligned, scalable, and context-relevant reference architecture for Digital Public Infrastructure for Health (DPI-H). The framework hereby presented provides the foundation for effective collaboration while maintaining the flexibility needed for technical innovation and adaptation to evolving requirements.

OPERATIONAL STRUCTURE

Project Lead

Role and Responsibilities

  • Coordinate timelines, milestones, and inter-group collaboration.
  • Approves major deliverables and milestone completions
  • Facilitates cross-domain coordination, alignment and issue resolution
  • Facilitates coordination between chief architect, core architects, domain co-chairs and the broader TWG.
  • Facilitates liaison with the Steering committee
  • Coordinates and oversees the development of the normative guidance

Solution Architect

Role and Responsibilities

  • Provides overall technical leadership and guidance
  • Approves design principles, architecture patterns, and domain outputs
  • Approves domain-specific deliverables
  • Ensures architectural coherence across all TWG domains
  • Validates alignment with global standards and country use cases
  • Will make final technical decisions when consensus cannot be reached

Domain Experts Group

Role and Responsibilities

  • Lead technical development of documentation within their assigned domain
  • Coordinate domain expert activities and deliverables
  • Ensure quality and consistency of domain outputs
  • Report progress and issues to Chief Architect
  • Participate in cross-domain alignment meetings
  • Ensure outputs align with the overall reference architecture
  • Contribute specialized subject matter technical expertise to the developmentof specific services
  • Provide input on cross-domain dependencies and interfaces
  • Review outputs from other domains as requested
  • Support testing and validation activities
  • Outline integration and implementation considerations/ methodologies for assigned domains

Reviewers & Domain Communities of Practice

Application through public notice, Expert invitation, or via existing CoPs)

Role and Responsibilities

  • Informs the Domain Experts Group on business requirements
  • Not contributing directly to development of artifacts
  • Review and validate technical specifications and documentation
  • Identify gaps, overlaps, and interdependencies.
  • Share country and implementation experiences

GOVERNANCE PROCESSES

Decision-Making Framework

Consensus-Based Approach:

  • Domain-level decisions made through expert consensus
  • Cross-domain issues escalated to domain co-chairs and core architects’ forum
  • Chief Architect makes final decisions when consensus not possible
  • Documented rationale for all major technical decisions

Decision Categories:

  • Level 1 (Domain): Component specifications, implementation details
  • Level 2 (Cross-Domain): Interface definitions, shared standards
  • Level 3 (Architecture): Overall design principles, major architectural decisions

Coordination mechanisms

Cross-Domain Alignment

  • Interoperability coordination: Interface design sessions between dependent domains

Standards Harmonization

  • Consistent application of architectural principles
  • Shared terminology and data definitions
  • Common security and privacy frameworks

Dependency Management

  • Dependency mapping between components
  • Regular dependency review and validation

Conflict Resolution

  • Escalation procedures for technical disagreements
  • Mediation through Chief Architect when needed
  • Documented resolution and rationale

Quality Assurance

Peer Review Process:

  • All deliverables undergo peer review within domain
  • Cross-domain review for components with external dependencies
  • Chief Architect final review for architecture-level impacts
  • External expert review for validation

Change Management

Change Request Process:

  • Create Issue on GitHub and/or submit pull request via GitHub
  • Domain co-chair initial assessment
  • Domain Group review
  • Cross-domain impact evaluation (if applicable)
  • Chief Architect approval for significant changes
  • Implementation and communication of approved changes

OPERATIONAL PROCEDURES

Meeting Structure

Technical workgroup

  • Frequency: Monthly
  • Duration: 60-90 minutes
  • Purpose: Review architecture design

Chief Architect and Domain Experts

  • Frequency: Monthly or as needed
  • Duration: 90 minutes
  • Purpose: Strategic alignment, domain updates, issue resolution, progress review

Domain Group Meetings

  • Frequency: Weekly or as needed
  • Duration: 60-90 minutes
  • Purpose: Technical development, expert collaboration

All-Hands TWG

  • Frequency: Weekly
  • Duration: 2 hours
  • Purpose: Cross-domain updates, major announcements, collective decisions

Ad-Hoc Coordination Meetings

  • Called as needed for urgent issues or cross-domain coordination

Communication Protocols

Reporting Structure:

  • TWG → Chief Architect & Project Lead → Steering Committee
  • Quarterly Steering Committee briefings

TWG Communication Channels:

  • Primary: Dedicated collaboration platform (TBD)
  • Documentation: Shared repository (GitHub)
  • Formal communications: Email with defined subject line conventions

Documentation Standards

  • All outputs must follow a consistent documentation template (https://smart.who.int/ig-starter-kit/ ).
  • Deliverables stored in shared repository (GitHub).
  • A changelog maintained for version control.
  • Technical and business documentation should be publically available.

Required Documentation:

  • Full narrative guidance that links to the technical specifications and IGs
  • Technical specifications with clear acceptance criteria
  • Implementation guidance and methodologies
  • Testing and validation procedures

Documentation Review Cycle:

  • Initial draft → Peer review → Expert group review → Cross-domain review → Chief Architect approval

INDICATIVE WORKFLOW AND DELIVERABLES

Development Lifecycle (indicative timelines, which may differ according to domain)

Phase 1: Requirements and Design (Weeks 1-3)

  • Requirements gathering and articulation: requirements definition across business, functional and technology layers
  • High-level design and alignment with health-sector goals
  • Dependency analysis
  • Integration requirements
  • High-level architectural documentation
  • PoC application with very limited functionality

Phase 2: Detailed Development (Weeks 4-14)

  • Detailed business requirements and use-cases
  • Detailed technical specifications
  • Implementation guidance and example use-cases
  • Testing procedures and validation criteria

Phase 3: Review and Validation (Weeks 10-16)

  • Internal peer review and refinement
  • Cross-domain alignment verification
  • External expert review

Phase 4: Testing and Finalization (Weeks 15-16)

  • Refinement following external review
  • Final draft documentation preparation
  • Pilot testing where applicable
  • Internal review of documentation
  • External expert review of documentation
  • Final documentation preparation

Key Deliverables

Technical Specifications & Implementation Guidance

  • Component architecture documents
  • Domain-specific specifications for business, functional and technology layers
  • API specifications and implementation guides
  • Data models and schema definitions

Care Coordination Management System

  • Informational system according to the business requirements and architecture

RISK MANAGEMENT

Identified Risks and Mitigation Strategies

Technical Risks

  • Architecture inconsistencies → Regular alignment meetings
  • Technology changes → Flexible design principles
  • Integration complexities → Early interface definitions; Core Architects review and resolution

Operational Risks

  • Expert availability → Asynchronous collaboration methods
  • Communication gaps → Structured reporting protocols
  • Scope creep → Clear change management procedures

Escalation Procedures

  • Domain level → Domain co-chair intervention
  • Cross-domain → Chief Architect mediation
  • Strategic → Escalation to Steering Committee

FRAMEWORK EVOLUTION

This governance framework is a living document that will be reviewed and updated based on:

  • TWG operational experience
  • Changing technical requirements
  • Stakeholder feedback
  • International best practice evolution

Review Schedule:

  • Monthly: Operational procedure adjustments
  • Quarterly: Process effectiveness assessment
  • Annually: Comprehensive framework review