Skip to content

ThalesMMS/bEMR

Repository files navigation

bEMR

Prototype scaffolding for a modular EMR in Swift, aligned with the clean-architecture blueprint and FHIR/SMART on FHIR. The repo already includes reference targets for macOS (AppKit), iOS/iPadOS (SwiftUI), and watchOS, plus shared domain, use-case, data, and UI modules.

Start here in 60 seconds

git clone https://github.com/ThalesMMS/bEMR.git
cd bEMR
xcodebuild -list -workspace bEMR.xcworkspace
swift test
open bEMR.xcworkspace

Then run the EMRMac scheme on macOS 14+ for the fastest first look.

Current status

  • Prototype, not production-ready.
  • Default experience is demo-first. If FHIR_BASE_URL and FHIR_STATIC_TOKEN are not set, AppEnvironmentFactory.makeDefault() falls back to demo data.
  • Fastest deeper reads: DEMO.md for the current UI/demo surface, Blueprint.md for the larger architecture plan.

Runtime data modes

AppEnvironmentFactory.makeDefault() starts in demo mode unless it can build a live FHIR environment from process environment variables.

Mode Where it applies What you need What happens
Demo (default) All app targets Nothing extra Uses the in-repo demo patient, encounter, and observation repositories for quick UI exploration
Mock Live EMRMac only, via the top toolbar Source picker Select Mock Live while running the macOS app Keeps using local simulated data, but swaps the macOS agenda, chart review, prescription, and progress-note services to their mock-live variants. This does not call the FHIR client or replace the core patient list/summary repositories
Live FHIR All app targets FHIR_BASE_URL and FHIR_STATIC_TOKEN Uses the live FHIR composition for the shared patient list and patient summary pipeline, with a persistent SwiftData cache when available

Important: the macOS Source picker and the env-var-based live FHIR switch are separate controls. If you launch with FHIR_BASE_URL / FHIR_STATIC_TOKEN set and then choose Mock Live in EMRMac, the agenda/chart-review/prescription/progress-note surfaces still stay on simulated data.

Set these before running/compiling to use a live FHIR endpoint:

FHIR_BASE_URL=https://fhir.sandbox.example.com
FHIR_STATIC_TOKEN=ey...

For production, replace the static token with LiveAuthFactory.makeTokenProvider using a refresh closure (SMART on FHIR + PKCE) that returns AuthToken and persists it in the Keychain. LocalContainerFactory.makePersistent() is already used in the live factory; switch to in-memory storage if needed.

On macOS, the last Source picker choice is remembered between launches.

What works today

  • Patient list and patient summary demo flows across the Apple-platform targets.
  • Mock clinical modules such as history, diagnoses, allergies, exams, prescriptions, progress notes, and agenda views.
  • swift test coverage for the core domain and use-case layers.
  • A modular SwiftPM/Xcode workspace layout that is ready for deeper FHIR and SMART-on-FHIR integration work.

Screenshots

Patient List (macOS) Patient Health Record (macOS)
Patient List - macOS Patient Health Record - macOS
Patient List (iPad) Schedule (iPad)
Patient List - iPad Schedule - iPad

SwiftPM Modules

  • CoreDomain: entities and repository protocols.
  • CoreUseCases: use cases (list, summary, lookup by identifier, encounter timeline, vitals).
  • FHIRModelsKit: re-exports ModelsR4 (Apple FHIRModels).
  • SecurityKit: session/token (Keychain, refresh).
  • DataFHIR: FHIRClient + remote repositories and domain↔FHIR mappers.
  • DataLocal: local caches via SwiftData (persistent or in-memory ModelContainer) and decorators.
  • SharedPresentation: shared view models.
  • AppSharedUI: dependency composition (demo or live) + reusable SwiftUI views.

Reference apps (entry points)

  • Apps/EMRiOS: SwiftUI NavigationStack.
  • Apps/EMRiPadOS: NavigationSplitView.
  • Apps/EMRMac: AppKit with NSHostingView.
  • Apps/EMRWatch: lightweight patient list.
  • Apps/SharedUI: composition (AppEnvironmentFactory, LiveComposition, DemoComposition) and views (PatientListView, PatientSummaryView).

For live/demo configuration, see Runtime data modes.

Tests

  • Run: swift test
  • Current coverage: CoreDomainTests, CoreUseCasesTests. (Suggestion: add tests for FHIR→domain mapping and SwiftData cache.)

How to integrate in Xcode

  1. Add the local package (Package.swift) to the workspace/project.
  2. Point app targets to the AppSharedUI module and enable minimum platforms (macOS 14 / iOS 17 / watchOS 10) for SwiftData.
  3. Configure schemes to inject FHIR_BASE_URL and token via env vars or implement the SMART flow in the refresh closure.

Suggested next steps

  1. Implement the full SMART on FHIR flow (Authorization Code + PKCE) in the AuthSessionManager refresh closure.
  2. Adjust FHIR→domain mappings per server (local terminologies, MRN, encounter class).
  3. Add integration tests for FHIRClient/repositories using a SMART sandbox.
  4. Harden local persistence (per-platform file protection, avoid PHI in logs).
  5. Expand use cases/view models for orders, meds, labs, and secure messaging.

Notes

  • The repo still contains the original bEMR.xcodeproj template; use the new SwiftPM layout to build the workspace.
  • Network dependencies point to https://github.com/apple/FHIRModels.git (R4). Configure the SMART on FHIR endpoint and scopes per provider.

About

Swift-based cross-platform prototype of an Electronic Medical Record system with FHIR standards.

Topics

Resources

License

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Contributors

Languages