RoofMan Official Blog
"If we teach today as we taught yesterday, we rob our children of tomorrow."
CareFabric — Architecture
CAREFABRIC · Overview & impact / Architecture / Explore & connect
Architecture, trust and implementation reference
Explore the responsibilities, boundaries and standards behind CareFabric. These are proposed design contracts to validate against the participating systems, governance and clinical workflows.
- Architecture and deployment settings
- Trust and safety
- Detailed engineering reference
- Sources and implementation reading
Understand the architecture
CareFabric separates the coordination of exchange from the custody of records. Three roles make that separation practical.
Trust Authority
Operates the participant registry, policy catalog, discovery service and audit intake. In a group, this is an accountable central function. Across independent organizations, it needs an agreed governance structure.
PeerNode
Provides each participant’s controlled boundary. It adapts local systems, resolves local identifiers, enforces sharing decisions and records activity. The local EMR, laboratory and pharmacy systems remain in place.
Controlled Relay
Provides an optional encrypted transport path when direct connectivity is impractical. It does not make clinical access decisions. End-to-end protection, retention limits and operator responsibilities must be designed explicitly.
Two planes, with different responsibilities
The control plane coordinates participation, discovery, policy and authorization, then receives the audit evidence. The data plane carries approved clinical requests and responses between PeerNodes. Keeping them separate helps make access decisions inspectable and limits where clinical payloads travel.
The control plane is still sensitive infrastructure. Patient references, record locations, purposes of use and audit trails can reveal health information even without a copy of the chart. They need access controls, minimization, retention rules and jurisdiction-specific review. “Metadata only” is a design boundary, not an exemption from privacy obligations.
One pattern, two deployment settings
- Enterprise exchange: connect branches, acquired providers or a diagnostic network under a group governance function. This offers a bounded place to establish the participant contract and support model.
- Cross-organization exchange: apply a compatible participant contract between independently governed providers. Participation agreements, consent responsibilities, trust anchors and local legal obligations need explicit alignment.
A common PeerNode contract can reduce later integration rework. It does not make federation automatic: governance, identity, terminology and permitted uses still have to line up.
Why this shape
Point-to-point integration spreads policy, identity and recovery logic across interfaces. A shared repository brings different migration and governance obligations. CareFabric concentrates the exchange responsibilities at a clear participant boundary and coordinates the shared rules. That is the architectural choice to evaluate against the actual estate.
Make trust and safety operational
A connection is useful only when the organization can explain and control what moves across it. CareFabric’s proposed rules are intended to be tested at the boundary.
Identity ambiguity needs a workflow
The PeerNode translates local identifiers into the agreed exchange context. Deterministic identifiers and demographic matching can contribute evidence; the network must also handle missing, stale and contradictory data.
FHIR’s match-grade vocabulary distinguishes “certain”, “probable”, “possible” and “certainly-not”. A probable match may need review; a possible match should be reviewed. CareFabric should not turn a score or grade into blanket permission to retrieve.
- Accepted identity: permit only the retrieval allowed by the clinical workflow and access policy.
- Ambiguous identity: send the case to an accountable review queue; restrict any discovery to what the governing policy permits.
- Rejected or unresolved identity: block clinical retrieval and record the reason.
The deployment must validate matching thresholds with its own population, monitor false matches and missed matches, and define who can resolve ambiguity. Identity proofing for a person logging in is a separate concern from matching clinical records across sites.
A token is one input to the access decision
Every request needs an approved purpose, an authenticated participant, an allowed recipient and a constrained data scope. The responding PeerNode must enforce the current applicable policy, including local restrictions and consent requirements; it cannot simply trust that a token makes every requested record shareable.
Short lifetimes and audience restrictions reduce exposure, but they do not by themselves prevent a stolen bearer token from being used. Where the implementation requires sender-constrained access, specify a mechanism such as mutual-TLS certificate-bound tokens and test that the resource server enforces the binding.
Audit the useful failures too
Record discovery, authorization decisions, route choice, retrieval and exceptions with correlation identifiers. Both ends need evidence. Store the decision reason and policy version without copying access tokens or unnecessary clinical payloads into logs. Retention, availability and access to those logs are part of the operating design.
Consent information, purpose of use and legal authority are related but distinct. A treatment-purpose code is not itself evidence of consent or a universal legal basis. The deployment’s policy owners must define and approve the rules that the software enforces.
Use AI as a reviewable assistant
AI may help summarize approved records, classify documents or prioritize operational review. It should not silently merge identities, override policy or expand an exchange request. High-impact or uncertain proposals enter a review workflow with accountable decisions and a traceable model version.
Start the pilot without AI in the exchange path. Add it only when the baseline workflow is reliable and its contribution can be evaluated against explicit safety, privacy and quality criteria.
Technical reference
The sections below retain the engineering detail behind the proposal. Expand the area relevant to your review. Names such as PeerNode and Trust Authority describe CareFabric responsibilities; they do not imply accreditation or equivalence to a particular national program.
Architecture views and the PeerNode reference
The responsibilities inside a PeerNode
- Exchange gateway: the exposed contract for approved network interactions; internal databases are not directly exposed to peers.
- Local adapters: map local records and workflow events to the agreed exchange contract, preserving provenance and identifying unavailable fields.
- Identity crosswalk: reconcile local identifiers with the exchange context and route ambiguity to authorized reviewers.
- Policy enforcement: apply the governing decision and the responder’s current local restrictions at retrieval time.
- Audit and delivery: record decisions and exchanges, buffer events durably and monitor delivery to the agreed audit service.
- Review hub: give identity, data-quality and optional AI exceptions a named owner and a recorded resolution.
These are responsibilities rather than a prescribed set of processes. A deployment may implement several in one service, reuse an integration platform, or separate them where trust boundaries and operational needs justify it.
Read the architectural views from outside in
The retained C4 views describe the proposed structure at progressively greater detail. Their role names are conceptual; the versioned implementation contract must resolve the protocol, policy and identity choices described in this reference.
System context
Containers
PeerNode components
Trust Authority components
Availability must be designed for the shared services as well as the participant nodes. Federation of records does not by itself keep authorization available. Define failure behavior, certificate lifecycle, policy rollout, rollback and support ownership before choosing infrastructure.
Standards, versions and terminology crosswalk
Choose a versioned implementation baseline
The examples use FHIR R4 terminology where a resource example is needed. A real delivery must select a published FHIR version, implementation guides, terminology bindings and security profiles together, then validate against them. A named clinical package such as “lab-results-summary” is a CareFabric use-case label; it is not an official HL7 conformance claim.
| Concern | Design basis and implementation decision |
|---|---|
| Clinical exchange | Use the selected FHIR release and published implementation guide for structured data. Use appropriate document profiles where the source is document-oriented. |
| System authorization | SMART Backend Services provides an OAuth client-credentials pattern with asymmetric client authentication. Patient and purpose restrictions still require explicit policy and server enforcement. |
| Federated trust | The HL7 UDAP Security guide describes certificate-based trust-community workflows. Select the applicable version and trust agreement; a CareFabric role name does not establish that agreement. |
| Patient matching | Use explicit evidence and workflow policy around FHIR Patient $match or the appropriate identity services. Do not equate a patient-match grade with a login-assurance level. |
| Human digital identity | NIST SP 800-63-4 supersedes SP 800-63-3 and covers identity proofing, authentication and federation of users. Select assurance requirements for the actual actors and risks. |
| Consent and policy | Use a documented policy model and version-compatible consent representation. FHIR Permission is an R5 resource; it must not be silently assumed in an R4 baseline. |
| Audit content and transport | FHIR AuditEvent represents audit information; IHE Basic Audit Log Patterns supplies reusable patterns. Select the applicable ATNA/BALP profiles and transport explicitly; these are not interchangeable labels for one wire format. |
| Sender-constrained tokens | Where selected, RFC 8705 defines certificate-bound access tokens. Validate the binding at the resource server; audience checks serve a different purpose. |
CareFabric names describe responsibilities
- Trust Authority: the accountable operating function for participation, policy coordination, discovery and audit. Its responsibilities may span several services and organizations.
- Policy decision point (PDP): evaluates the relevant rules. A policy catalog is where rules are managed; it is not necessarily the runtime decision service.
- Policy information point (PIP): supplies attributes such as role, purpose and consent context to the decision.
- Policy enforcement point (PEP): applies the decision at the participant boundary and enforces the responder’s applicable restrictions.
- Discovery/locator: identifies eligible holders, data classes and capabilities. Apply access policy to discovery itself and minimize patient-linked metadata.
- Controlled Relay: transports encrypted traffic under an explicit operator contract. It is not a substitute for either endpoint’s access enforcement.
National frameworks have their own legal roles, participation agreements and certification requirements. CareFabric can be evaluated alongside them; an architectural resemblance is not evidence of membership or equivalence.
Communication flow and illustrative decision examples
The contract to settle before implementation
The following YAML is a discussion model for an exchange decision. It is deliberately not a published API, a FHIR resource or a production authorization token. All identifiers are illustrative. Actual endpoints, signed claims, resource filters, terminology bindings and error responses belong in the versioned implementation specification.
# Illustrative decision model: direct laboratory retrieval
exchange:
correlation_id: demo-visit-001
requester: demo-clinic-node
responder: demo-lab-node
patient_reference: demo-patient-001
use_case: lab-results-summary
purpose: treatment
requested_window: agreed-recent-results
decision:
result: allow
policy_version: pilot-policy-1
identity_decision_reference: demo-reviewed-match-001
sharing_basis_reference: demo-approved-basis-001
grant:
lifetime_seconds: 300
intended_recipient: demo-lab-node
sender_constraint: required-by-pilot-security-profile
permitted_patient: demo-patient-001
permitted_resources: [DiagnosticReport, Observation]
route:
mode: direct
execution:
responder_rechecks_local_policy: true
clinical_response: selected-FHIR-profile
audit_correlation_at_both_ends: demo-visit-001The corresponding request follows the selected direct route. If the decision selects a relay instead, the implementation must establish the approved end-to-end protected path before sending the clinical request. The relay cannot become a plaintext termination point if the design promises it cannot read the content.
# Alternative decision for the same requested exchange
exchange:
correlation_id: demo-visit-002
requester: demo-clinic-node
responder: demo-lab-node
decision:
result: deny
reason: identity-requires-review
policy_version: pilot-policy-1
review_reference: demo-review-002
execution:
clinical_retrieval: blocked
audit_locations: [requester, authorization-service]
audit_correlation: demo-visit-002In the denial case, record the authorization attempt and decision in the relevant control-plane and requester audit records. If no request reaches the responding PeerNode, do not fabricate a responder retrieval event. The audit model distinguishes a decision to deny from a clinical access attempt.
Implementation checks that the sketch leaves open
- Binding and enforcement: how the resource server obtains and enforces patient, purpose, recipient, sender and data constraints. An OAuth scope alone does not represent all of them.
- Identity and consent: which service produced the evidence, how fresh it must be, and when a review or revocation invalidates the request.
- FHIR conformance: validate resources, required fields, coding systems, references and bundles against the chosen release and guides. Do not certify a shortened prose example.
- Reliability: timeouts, retries, idempotency, partial results, rate limits, duplicate events and interrupted transfers.
- Safe references: identify source and freshness, constrain follow-up retrieval and avoid forwarding access tokens to untrusted referenced URLs.
- Audit: correlate events and preserve the required evidence without logging reusable credentials or unnecessary payloads.
SMART Backend Services uses “system/” scopes for pre-authorized system access and a client-authentication assertion to obtain a token. The assertion is not the access token. A concrete pilot must specify its authorization details rather than treating the YAML above as a substitute for the published security profile.
Clinical exchange catalogue
A candidate exchange catalogue
Select a small subset for a pilot. Each use case needs a precise resource profile, authorized actors, purpose, freshness rule, terminology binding and acceptance test. Availability depends on source systems. Write operations need a separate command, acknowledgment and duplicate-handling contract.
“patient-summary” — Cross-organization patient summary at the point of care.
Use the document structure and required content defined by the selected International Patient Summary implementation guide.
“encounter-summary” — Visit-scoped data exchange anchored to one Encounter.
Candidate resources: Encounter, Condition, Observation, MedicationRequest, Procedure, ServiceRequest.
“discharge-summary” — Hospital to community handoff at end of admission.
Candidate resources: Composition, Encounter, Condition, MedicationRequest, ServiceRequest, AllergyIntolerance.
“lab-results-summary” — Recent laboratory results.
Candidate resources: DiagnosticReport, Observation.
“lab-orders” — Outbound laboratory order to a reference lab; a separate write workflow, not a retrieval variation.
Candidate resources: ServiceRequest, Specimen.
“pathology-report” — Full pathology report with specimen and microscopy.
Candidate resources: DiagnosticReport, Specimen, Observation, ImagingStudy.
“medication-dispense-90d” — Recent dispense history (default 90-day window).
Candidate resources: MedicationDispense, MedicationRequest.
“medication-list-active” — Current active medications snapshot.
Candidate resources: MedicationStatement, MedicationRequest, AllergyIntolerance.
“prescription-history” — Full prescription history including renewals and substitutions.
Candidate resources: MedicationRequest, MedicationDispense.
“imaging-report-references” — Diagnostic imaging reports plus document references.
Candidate resources: DiagnosticReport, DocumentReference.
“imaging-study-metadata” — Study-level metadata without DICOM bytes.
Candidate resources: ImagingStudy, DiagnosticReport.
“allergies-and-reactions” — Allergies, intolerances, and adverse events.
Candidate resources: AllergyIntolerance, AdverseEvent.
“problem-list-active” — Current active problem list.
Candidate resources: Condition, ClinicalImpression.
“procedures-history” — Past procedures within a window.
Candidate resources: Procedure, ServiceRequest.
“vitals-recent” — Recent vital signs.
Candidate resources: Observation ( category = vital-signs ).
“care-plan-active” — Active care plans and goals.
Candidate resources: CarePlan, Goal, ServiceRequest.
“care-team” — Assigned care team members.
Candidate resources: CareTeam, Practitioner, Organization.
“referral-package” — Referral with supporting clinical context.
Candidate resources: ServiceRequest, Composition, Condition, DocumentReference.
“appointment-context” — Pre-visit context for the receiving clinician.
Candidate resources: Appointment, Encounter, Practitioner, ServiceRequest.
“clinical-document-set” — Generic document exchange (CCD, CCDA, custom).
Candidate resources: DocumentReference, Composition, Bundle.
“immunization-record” — Full immunization history plus recommended-next.
Candidate resources: Immunization, ImmunizationRecommendation.
Treat the catalogue as a governed product surface. Publish a version, certify the selected behavior, advertise participant capability and define compatibility before adding a package to live exchange.
Architecture decisions, quality attributes and integration toolkit
The decisions this blueprint takes
| Decision | Trade-off to evaluate |
|---|---|
| Federated custody with shared coordination | Preserves local ownership and introduces dependencies on shared trust services. |
| A PeerNode boundary per participant | Concentrates integration and enforcement responsibilities; needs certification and lifecycle ownership. |
| Separate control and data planes | Makes responsibilities clearer; requires secure correlation and explicit failure handling across both. |
| A replaceable, transport-only relay | Accommodates network constraints; end-to-end confidentiality and metadata exposure still need verification. |
| Versioned standards and exchange packages | Supports conformance work; mapping legacy systems remains a local delivery cost. |
| Explicit identity review | Reduces silent ambiguity; requires staff capacity and measured review turnaround. |
| Discovery with minimized metadata | Enables targeted retrieval; the locator itself requires privacy and access controls. |
| AI proposals under review and audit | Enables assistance while creating evaluation, governance and monitoring obligations. |
| A clinical scope with separate funding decisions | Keeps purpose and payment apart; shared services and participant operations still need sustainable funding. |
| A minimum participation floor with staged depth | Allows mixed-maturity adoption; the floor must be useful, testable and supportable. |
Quality attributes to make measurable
Write concrete acceptance criteria for security, privacy, audit completeness, recovery time, response time, operational support and compatibility. Measure authorization latency as well as clinical transfer latency: the control plane can limit end-to-end performance. Test the workload and outage assumptions rather than inferring resilience from the diagram.
A practical toolkit is delivery work
A reusable PeerNode contract should be accompanied by adapter guidance, sample data, a conformance suite, reference flows and operational runbooks. The proposal does not claim that an official CareFabric SDK is already available. Further exploration should identify which toolkit elements are worth building and who would maintain them.
Explore the interface concepts
These are illustrative interface concepts for discussing operational responsibilities. Counts, organizations, statuses and activity in the screens are demonstration content, not evidence of a live network or measured results.
Operations overview
Policy catalogue
Participant registry
A deployment-specific design review should also decide which details an operator may see. A useful dashboard must respect the same minimization and role boundaries as the services underneath it.
Glossary
CareFabric — The architecture proposal described in this project.
PeerNode — A participant’s controlled integration and enforcement boundary.
Trust Authority — The accountable function operating shared participation, policy, discovery and audit services.
Controlled Relay — An optional transport component for an end-to-end protected exchange path.
EMR / EHR — Electronic medical/health record; the clinical record system and record context used by a provider.
LIS — Laboratory Information System.
RIS / PACS — Radiology Information System / Picture Archiving and Communication System.
FHIR — HL7’s standard for representing and exchanging healthcare information.
Implementation guide — A published set of constraints and usage rules for a particular interoperability context.
Exchange package — A named CareFabric use case that must be mapped to concrete, versioned resource contracts.
MPI / EMPI — Master Patient Index / Enterprise Master Patient Index: identity matching and identifier reconciliation services.
SMART Backend Services — An OAuth-based pattern for system access to pre-authorized FHIR resources.
UDAP — Security profiles for scalable registration, authentication and authorization in a trust community.
PDP / PIP / PEP — Policy decision, information and enforcement responsibilities.
Consent — Information about an applicable consent decision; its interpretation is part of the governing policy.
Purpose of use — The stated reason for requesting access, evaluated alongside the other authorization conditions.
AuditEvent — A FHIR resource for recording audit information.
ATNA / BALP — IHE audit-related profiles; the chosen content patterns and transport must be specified.
IAL / AAL / FAL — NIST assurance levels for identity proofing, authentication and federation of users.
Match grade — An assessment of how confidently a patient record matches supplied identity evidence.
PHI — Protected health information; the applicable definition and obligations depend on the governing jurisdiction.
Sender-constrained token — An access token whose use is bound to a client-held cryptographic key by an enforced mechanism.
Break glass — A tightly governed exceptional-access workflow with explicit accountability and review.
Provenance — Information about where data came from and how it was produced or transformed.
Sources and implementation reading
The references below support the architecture and healthcare-impact discussion. They do not certify CareFabric. Select the applicable published versions and jurisdictional requirements when developing the design for a specific setting.
- HL7 FHIR R4 specification — resource and exchange baseline for the illustrative technical discussion.
- FHIR Patient $match and match-grade definitions — matching operation and interpretation of its result grades.
- SMART App Launch 2.2: Backend Services — system authorization and token acquisition.
- HL7 UDAP Security 2.0 — scalable security within a trust community.
- NIST SP 800-63-4: Digital Identity Guidelines — human digital identity assurance; supersedes SP 800-63-3.
- FHIR R5 Permission — a version-specific policy resource to assess separately from an R4 baseline.
- IHE Basic Audit Log Patterns — reusable FHIR AuditEvent patterns.
- RFC 8705: mutual TLS and certificate-bound tokens — sender-constrained access with certificate binding.
- WHO: Consolidated telemedicine implementation guide — service design and implementation considerations for remote care.
- WHO: Surveillance in emergencies — early warning, monitoring and public-health response.
- WHO: Digital interventions for health system strengthening — evidence, feasibility, equity and the limits of digital interventions.
What would you explore next?
I’m interested in the questions this blueprint raises, the trade-offs you would approach differently and the possibilities you see. If you’d like to compare notes, let’s connect.
