EMR vendor profiles
Reference data on someone else's cadence · vendor profiles. On a deployment this row is a control; the demo shows the row with the reading its source supports.
Evidence
- Running
- 15 vendor profiles (PHP mirror, pinned by tests/test_emr_profiles_coverage.py)
- Built
- 15 profiles (core/fhir/emr_profiles.py PROFILES); emulators on ports 9101 to 9115
- Latest known
- 15 vendor pages unchanged, checked 12 days ago
- Source
- core/fhir/emr_profiles.py PROFILES
- Checked
- 12 days ago
- Cadence
- every 90 days
- Mode
- guided
- State
- current
- Backup unit
- The previous release.
- Recovery
- The previous release.
The five steps
Plan, back up, apply, verify, recover — in guided mode. On a deployment each step runs, is verified and lands on the audit trail; every component on the demo is current, so every step reads done.
- ✓ done Plan The CLI's vendor page hashes are compared with the hashes the profiles cite; a changed page lists the vendor, the page and the profile fields it may affect; the admin confirms.
- ✓ done Back up The previous release stays kept; a profile change is a code change and ships in a release.
- ✓ done Apply The admin re-reads the vendor's page, updates the profile in core/fhir/emr_profiles.py and the PHP mirror, and records doc_checked; the coverage test pins the two.
- ✓ done Verify The cited page hash matches, the coverage test passes, and the emulator for that vendor still answers the profile's grant.
- ✓ done Recover Roll back to the previous release; the previous profile returns with it.
Every row behind this reading (15)
| Vendor | Auth | Vendor page | Checked |
|---|---|---|---|
| Altera Digital Health | SMART Backend Services — private-key JWT client assertion verified against the JWKS URL registered on a System-type app; the token request must carry a scope (Altera's own example is system/*.read); signing algorithm not documented by the vendor | https://marketplace.alterahealth.com/Developers | 12 days ago |
| athenahealth | OAuth2 client credentials — client ID and client secret (no JWT assertion) | https://docs.athenahealth.com/api/guides/our-process | 12 days ago |
| eClinicalWorks | SMART Backend Services JWT assertion | https://fhir.eclinicalworks.com/ecwopendev/ | 12 days ago |
| Epic | SMART Backend Services — RS384-signed JWT client assertion; public key registered with the client ID | https://vendorservices.epic.com/ | 12 days ago |
| Greenway Health | SMART Backend Services — ES384-signed JWT client assertion (EC P-384 key pair published at a JWKS URL registered on the Developer Platform; no client secret); the token request carries explicit system/<Resource>.read scopes | https://developers.greenwayhealth.com/developer-platform | 12 days ago |
| MEDHOST | SMART Backend Services — private_key_jwt client assertion signed RS384 or ES384; public key served from a JWK Set URL registered on the app (set with each facility for production); no client secret for service clients | https://www.medhost.com/ehr/interoperability/ | 12 days ago |
| MEDITECH Expanse | SMART Backend Services JWT assertion | https://greenfield.meditech.com/ | 12 days ago |
| ModMed | SMART Backend Services — ES384-signed JWT client assertion (EC P-384 key, public JWKS registered on the app); explicit system/<Resource>.rs scopes REQUIRED on every token request; no client secret on this grant | https://www.modmed.com/what-we-do/integrations/synapsys/developers/ | 12 days ago |
| Netsmart | SMART Backend Services — Private Key JWT (Netsmart's recommended grant; JWK Set URI registered with the app) or client secret, both documented; explicit system/<Resource> scopes required on every token request; one app registration per tenant | https://www.ntst.com/marketplace/partners-apply | 12 days ago |
| Nextech | SMART Backend Services (system app) — RS384- or ES384-signed JWT client assertion against sts.mypatientvisit.com; public key served from a registered TLS 1.2 JWK Set URL; explicit system/<Resource>.read scopes in the token request; 15-minute tokens with no refresh tokens; one client ID per practice on a single multi-tenant base URL | https://www.nextech.com/developers-portal | 12 days ago |
| NextGen Healthcare | SMART Backend Services JWT assertion | https://www.nextgen.com/developer-program | 12 days ago |
| Oracle Health (Cerner) | SMART Backend Services with MANDATORY explicit system/<Resource>.read scopes — wildcard scopes are not supported | https://www.oracle.com/health/developer/api/ | 12 days ago |
| Practice Fusion | SMART Backend Services — signed JWT client assertion (RS384 or ES384, kid required, public key at a JWKS URL registered on the PDS API Portal); no client secret; explicit per-type system/<Resource>.read scopes required, limited to what the practice administrator authorized in the EHR | https://www.practicefusion.com/developer-center/ | 12 days ago |
| TruBridge | SMART Backend Services — private_key_jwt client assertion against a JWKS URL given at registration (RS256/RS384/ES256/ES384 accepted; PHI AI signs RS384); TruBridge equally documents client_secret_basic/post. scope is REQUIRED in the token request — one explicit system/<Resource>.read per ingested type | https://trubridge.com/contact/ | 12 days ago |
| Veradigm | SMART Backend Services — RSA-signed JWT client assertion (RS384) against a JWKS you host; Veradigm requires RSA 2048 keys with a kid, syncs the JWKS nightly, and documents no client secret for System apps | https://veradigm.com/veradigm-connect/ | 12 days ago |
History
Applies and recoveries of this row, from the update journal. On a deployment every apply and every recovery lands here as it completes.
No apply or recovery recorded for this row. The demo's journal holds one completed update, of Running image.
Acknowledge: keep as is until <date> because <reason> — on a deployment this line is a form, audited as system.component_acknowledged; the demo shows the words.