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.).
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:
| Decision to use:
|
Not released to maven yet.
Component | Feature | Details/JIRA link |
---|---|---|
Auth Server | Public able to create accounts | |
API Server | Ability to register arbitrary launch context | |
Auth Server | Ability to persist launch contexts | |
API Server | Access to resources segregated by patient "compartment" | |
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. |
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.
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
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.
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