Logica/SMART Reference Implementation Collaboration
Reference Implementation Collaboration Overview
The purpose of the Logica/SMART Reference Implementation is to consolidate the code-base for each organization's code base since, up to this point, both organizations share the same specification. Until one or the other group decides to deviate from either a logical or technical approach, the organizations benefit by sharing resources to accomplish the same end. This page will serve a collaboration portal for the project and will include links to each groups current implementations, decisions on what components from each will be used, the shared code base, and links to the project plan (backlog, current sprints, burn-downs, etc.).
Components Map & Usage Decision Matrix
| Security & Context | FHIR Resource Server | FHIR Starter | Tools | |
|---|---|---|---|---|
| SMART on FHIR Reference Impl | https://github.com/smart-on-fhir/auth-server/ fork of MITREid, plus a mvn overlay for LDAP integration depends on: LDAP server deploy as: war or standalone jar | https://github.com/smart-on-fhir/api-server custom Grails web app depends on: Postgres deploy as: war or standalone jar | https://github.com/smart-on-fhir/fhir-starter static web app (AngularJS 1) depends on: auth server, api server deploy as: static web app | |
| Logica Reference Impl | hspc-reference-authorization.war - openid-connect-server-webapp-1.2.0.war - openid-connect-server-1.2.0.jar | Tomcat 8 hspc-api.war - HAPI DSTU1 Resource Server hspc-reference-api.war - HAPI DSTU2 Resource Server MySQL Database | Logica uses SMART on FHIR's version. | Data Import Tool |
| Collaborative Reference Impl | Decision to use: |
Project Artifacts
Code Repos
- https://bitbucket.org/hspconsortium/reference-impl
- This repo is possibly going to contain both the security server and the api server
- https://bitbucket.org/hspconsortium/reference-auth
- This repo contains the authorization server, is an overlay of the OpenID Connect server. Possibly move this into the reference-impl server above and change the name
- https://bitbucket.org/hspconsortium/reference-apps
- This repo contains the FHIR Starter application and Bilirubin app. Need to move Bilirubin into its own repo.
- https://bitbucket.org/hspconsortium/reference-api
- This repo contains the fhir resource server. Possibly move into the reference-impl above and change the name to indicate "server"
Build Pipeline
- Build on commit
Maven Artifacts
Not released to maven yet.
Features Roadmap
| Component | Feature | Details/JIRA link |
|---|---|---|
| Auth Server | Public able to create accounts |
HRI-327
-
Getting issue details...
STATUS
|
| API Server | Ability to register arbitrary launch context |
HRI-415
-
Getting issue details...
STATUS
|
| Auth Server | Ability to persist launch contexts |
HRI-414
-
Getting issue details...
STATUS
|
| API Server | Access to resources segregated by patient "compartment" |
HRI-371
-
Getting issue details...
STATUS
|
| API Server | Transaction & Batch Support | Allow submission of multiple items at once. Tx all succeed or fail together, batch they don't all have to succeed together. Part of DSTU2 - may get for free as part of HAPI |
| API Server | Profile Validation | |
| API Server | Consistent Validation Result Representation | A resource can be validated against 0...M profiles. Come up with a way to represent the results of that validation consistently. |
Project Status
The collaboration project will be managed in JIRA here: JIRA Agile Project. Below is a snapshot of the identified stories and tasks for the collaboration.
Misc./Collaboration Notes
Notes from first look at HSPC stack:
Josh Mandel (Unlicensed): Authz server: our server uses an LDAP back-end for account management. We currently use a mvn overlay to accomplish this; probably it can be updated to work with the HSPC server (stacked overlays -- I assume this works?)
Travis Cummings: Yes, stacked overlays work. We will work on the LDAP account management in HRI-327 - Getting issue details... STATUS
Josh Mandel (Unlicensed): When I sign into the authz server as demo/demo, I see 253 approved sites. It looks like all apps are automatically approved for access, and with specific launch scopes? Are these hard-coded? Apps running multiple times? I'm not sure what's going on here.
- LaunchContext needs to accept arbitrary data (not just patient) Current approach to LaunchContext is fragile
- Travis Cummings HRI-415 - Getting issue details... STATUS
- involves an HTTP REdirect from API server -> Authz server, and so it depends on browser cookies for authorization? I'm not 100% sure on this, but testing the public server seems to confirm. This is a mistake, since launching is an admin act, or requires appropriate scopes. The auth server doesn't know about such things. Diagrams: are confusing on this point, showing LaunchEndpointOrchestration vs. LaunchOrchestrationEndpoint
- Travis Cummings HRI-416 - Getting issue details... STATUS
- does not store arbitrary params (encounter, need_patient_banner) need to handle arbitrary params to cover the spec and allow room for expansion/exploration
- Travis Cummings Also covered by HRI-415 - Getting issue details... STATUS
- are not persisted (currently in ThreadLocal map). Would be good to keep these on record in DB alongside the rest of server state.
- Travis Cummings HRI-414 - Getting issue details... STATUS
- patient-level scopes like patient/*.read need to be limited in the data they can see. This is an important feature especially for patient-facing apps where the access model is more limited. We're taking this use case on in Argonaut Implementation Program, for example.
- Travis Cummings HRI-371 - Getting issue details... STATUS
Josh Mandel (Unlicensed): DSTU2 links on https://healthservices.atlassian.net/wiki/display/HSPC/HSPC+Sandboxes are broken which made it hard for me to explore live server behavior.
Travis Cummings: Fixed links