System thesis
Case study
HL7 AI Challenge Platform
Event-driven healthcare quality platform that moves from HL7 messages to FHIR resources, predictive risk, SMART/CDS workflow, and operational dashboards.
Primary evidence: High-level, low-level, and swimlane diagrams
At a glance
- Standards
- HL7 v2.x, FHIR R4, SMART on FHIR, CDS Hooks
- Services
- HL7 processing, risk prediction, care orchestration, dashboard
- Infrastructure
- RabbitMQ, PostgreSQL, Redis, Docker
Architecture assetsHigh-level, low-level, and swimlane diagrams
Risk layerXGBoost-style care-gap prioritization
Workflow layerSMART/CDS provider action surface
System problem
Why this system exists.
Clinical quality and care-gap workflows often depend on fragmented events and manual chasing. This challenge platform shows how HL7-style events can become FHIR-aligned resources and downstream intelligence.
Implementation surface
What was built.
- Architecture notes.
- Dockerized service graph.
- Care-gap intelligence framing.
- Environment-driven demo configuration.
Architecture
A system map for the project.
HL7-style events -> event gateway -> FHIR mapper -> quality intelligence -> risk scoring -> CDS/SMART workflow -> dashboard and audit outputs.
A microservices architecture where HL7 events, FHIR mapping, risk services, SMART/CDS, and dashboards are independent reviewable layers.
Event Sources
HL7 ADTHL7 ORUHL7 MDM
Message Bus
RabbitMQevent routingasync workers
AI Services
HL7 processingrisk predictioncare orchestration
Workflow
FHIR R4 resourcesSMART appCDS Hooksdashboard
How it works
Input, transformation, model or agent logic, and reviewable output.
Event intake
HL7-style ADT, ORU, and MDM flows enter through an event-processing layer rather than a batch-only process.
FHIR transformation
Messages are mapped toward Patient, RiskAssessment, CarePlan, Task, and related FHIR R4 resource shapes.
Risk and orchestration
Risk services prioritize non-compliance/care-gap attention while orchestration services create reviewable work.
Provider workflow
SMART on FHIR and CDS Hooks patterns make the demo about workflow integration, not only model scoring.
Evidence
Screenshots, responses, diagrams, tests, and model tables from the source repos.
Artifacts are included only where the public repo has enough context to show them safely.
High-level architecture
Service-level architecture
Data-flow swimlane
Engineering Decisions
Event-driven design
RabbitMQ makes the platform shape closer to real healthcare integration where events arrive asynchronously.
Standards before models
HL7/FHIR/SMART/CDS choices keep the AI layer anchored to existing healthcare interoperability patterns.
Challenge-safe framing
The portfolio shows architecture and synthetic/sample behavior without publishing sensitive implementation details.
Validation / reliability
How the system is made reviewable.
- Docker Compose configuration validates the service graph.
- Service and demo scripts compile.
- Live demo tests require the documented local stack.
- RabbitMQ, Postgres, Redis, dashboard, and services are represented locally.
- Environment-driven configuration avoids hardcoded internal hosts or credentials.
Limits / responsible use
Public challenge/demo code using synthetic or sample data only. Not a production clinical decision system.
- Architecture diagrams and Docker service boundaries make the platform shape reviewable.
- HL7, FHIR, SMART, and CDS are treated as workflow constraints before any AI layer is promoted.
- Challenge and sample-data boundaries stay explicit; this is not represented as a production clinical platform.
Repository
Open the source repo and inspect the implementation boundary.
All public examples are synthetic, sanitized, historical, or research/demo implementations. No PHI, PII, employer-confidential data, proprietary claims data, private keys, production credentials, or sensitive datasets are included.