Stream: smart
Topic: SMART App Registration
Travis Cummings (Mar 07 2017 at 22:24):
HSPC would like to help SMART on FHIR apps along the process of registing with the various sandboxes. For example, an app developer could use the HSPC sandbox to build their app, and could easily move it to the Cerner/Epic/AllScripts sandboxes. Would anyone be interested in collaborating on this topic?
Travis Cummings (Mar 08 2017 at 05:53):
A great idea from Kevin and team is to help with the registration process by finding common registration data elements between the sandboxes and include those within the application somehow (manifest or something like that).
Josh Mandel (Mar 08 2017 at 12:59):
Thanks for starting this conversation! It would be great to understand where/how vendor-specific "stores" would consume this kind of data. Some places we could expose it would include: in-app manifests, gallery-hosted metadata, or even a standalone registry. (Each of these solutions fits better in certain models, and they're not exclusive.) I'd love to link in a related conversation about app registration (from our mailing list last week): if vendors are interested in pushing forward with jwt-based (asymmetric) auth and url-based client identifiers, the app registration process can be dramatically simplified (without giving up *control*, in the sense that vendors could still decide which apps to allow, but no explicit registration would be required).
Josh Mandel (Mar 08 2017 at 13:00):
I don't want to conflate these topics (happy to talk through each separately) but I do want to make sure we think about the "vision" of where we could get by solving both.
Travis Cummings (Mar 08 2017 at 17:57):
With the dev/reference sandboxes (thinking of SMART on FHIR and HSPC sandboxes), there are galleries and sandboxes. I would think that these galleries would align with EHR stores, and dev sandboxes would align with EHR dev sandboxes. So this possibly represents 2 diffferent peices of information.
Travis Cummings (Mar 08 2017 at 18:00):
@Josh Mandel we were actually going to try to get something in place for the HIT Dev Conf, Mar 30. Whether that was just a set of instructions or something programmatic, we were wanting to do a little push in the next couple of weeks.
Josh Mandel (Mar 08 2017 at 18:29):
Definitely - no reason not to pick off the low hanging fruit here. I'd propose starting with the Metadata fields in https://gallery.smarthealthit.org/manifest/15
Josh Mandel (Mar 08 2017 at 18:30):
Apps could create a Json snippet with most of these (not the client id, obviously) and host that at /.well-known/smart/manifest.json or paste it into a web form in a vendor store to facilitate registration
Josh Mandel (Mar 08 2017 at 18:31):
There are certainly some additional fields that we could track, including information about being developer of course.
Kevin Shekleton (Mar 08 2017 at 18:48):
This was my suggestion in an offline conversation with Travis as a good starting point (app manifest)
Travis Cummings (Mar 08 2017 at 20:14):
I've created a matrix of fields used by each system, and added Josh's Gallery metadata fields as well as those used by the SMART and HSPC sandboxes.
Travis Cummings (Mar 08 2017 at 20:14):
https://docs.google.com/spreadsheets/d/1G_BD5YHZCkXamRn_mtxIM62i5sWlEP-Yr93Zz7tGLKM/edit?usp=sharing
Jeffrey Danford (Mar 09 2017 at 17:13):
Allscripts would definitely be interested. Look forward to talking more about it at the Dev Conference.
Travis Cummings (Mar 09 2017 at 17:36):
I wonder what work could be done on the user's account side. A super simple model would be something like mint...a system independent of each EHR and Ref Sandbox that would "connect" to each of our environments. Functionality could be addressed iteratively, but could initially be just showing a user's app registration in each system.
Travis Cummings (Mar 09 2017 at 17:40):
Another user account model would be for the reference systems (SMART, HSPC) to have an OAuth token to the EHR systems dev. Then from the reference system, the user could actually do some operations like register or possibly push a packaged app. This is definately a deeper integration, but are people interested in this level of functionalilty?
Travis Cummings (Mar 09 2017 at 17:51):
Hi @Jeffrey Danford! Thanks for joining the conversation! I'm just taking a look at Allscripts Developer program-FHIR App registation form to see what fields you collect.
Jeffrey Danford (Mar 09 2017 at 17:53):
@Travis Cummings Great to hear. Let me know if I can answer any questions about ADP. It's pretty simple to navigate and I don't think we require all that much from you.
Josh Mandel (Mar 09 2017 at 17:56):
For a fuller set of fields we use, see https://apps.smarthealthit.org/api/v1/applications/12?d4q6q6685jjeb9afczobm4pldi (not intended to be a shareable format, but it shows the fields we use to populate our full gallery view).
Josh Mandel (Mar 09 2017 at 17:58):
On the registration front: the most effective solution I know is to host a set of these manifests and include in each one enough data for an EHR to populate an app registration. If we can agree on a client identifier scheme + asymmetric auth, that could get us all the way to "no explicit registration step is technically required".
Travis Cummings (Mar 09 2017 at 18:23):
The manifest works well for situations where the app bundle is given to the EHR for hosting, and a model similar to the cds-hooks discovery works well for apps that are remote to the EHR. But it does seem that the same information is required by each model?
Kevin Shekleton (Mar 09 2017 at 18:41):
Regarding the Mint model, I don't think we should go down this route from a risk/security perspective. I don't think HSPC should take on securing the various credentials from each vendor sandbox.
I think integrating via APIs would be best (but obviously require coordination/collaboration between all)
Travis Cummings (Mar 09 2017 at 18:49):
Good call! I got a little too excited about that one.
Kevin Shekleton (Mar 09 2017 at 19:00):
:)
Travis Cummings (Mar 10 2017 at 14:44):
I think our case of discovering registration related info about an SOF app is pretty similar to a search engine, mail client, social media site discovering information about a website. What would you think about using a schema.org + metadata approach to this problem? If I put on my app developer hat, I'd like to be able to enhance the Bilirubin Risk Chart with a few things it is missing: 1) an "info" page 2) a "demo/sample" page 3) search engine/social media friendly. Along those lines, the "launch" page would be a natural fit to have metadata about the purpose and usage of the launch. An EHR, Gallery, or Reference Sandbox could use this metadata to wire up the app.
Dan Gottlieb (Mar 10 2017 at 15:09):
I think that could work, but why would metadata in a launch or about page be better than a manifest.json file? Keeping the metadata as a separate file and submitting it to sandboxes, etc. via a url or upload would give developers the option of creating multiple versions (for example dev and prod) and potentially hosting the file separately from the app distribution. Also, it may simplify machine generation, validation, versioning, etc.
Travis Cummings (Mar 10 2017 at 15:38):
I guess also, that the launch is an outbound URL (from the EHR's perspective) and not necessarily in inbound page. So the proposal would be for some web page that describes the app. The advantage of using schema.org + metadata is that it is a generalized solution. If we look at the fields we are wanting to represent most of them are generalized: {name, desc, marketing url, contact email, sales contact, screen shots, video links, pricing, demo url, browser compatibility, ...}. There is already a vocabulary (https://schema.org/WebApplication, https://schema.org/ProfilePage) and a representation (Google recommends JSON-LD, but others exist).
Travis Cummings (Mar 10 2017 at 15:38):
This looks remarkably similar to what we would like in a manifest:
Travis Cummings (Mar 10 2017 at 15:38):
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "Organization",
"url": "http://www.your-company-site.com",
"contactPoint": [{
"@type": "ContactPoint",
"telephone": "+1-401-555-1212",
"contactType": "customer service"
}]
}
</script>
Travis Cummings (Mar 10 2017 at 15:45):
What I don't know is, does this have to be in a .html file (or accessed by a URL)? Maybe the proposal boils down to 1) use schema.org for the model and 2) json-ld for the representation. Then surfacing the information (manifest.json, /about.html, ...) is a seperate decision?
Pascal Pfiffner (Mar 10 2017 at 16:45):
Since these manifests are going to be small-ish and not complicated, is it necessary to use schema.org for them? Would also be nice to use the same approach/format for native apps that don't have launch pages (and may not even have a website).
Travis Cummings (Mar 10 2017 at 17:16):
Do you know if schema.org is going to add a lot of overhead? I had thought it was just going to establish our vocabulary. I'll do a quick compare with the https://gallery.smarthealthit.org/manifest/15 example to see what it would look like.
Josh Mandel (Mar 10 2017 at 18:53):
A benefit of using a simple data structure is that apps can host it directly, or a third-party service (e.g. gallery) can host it, and it does't impose any expectations about being embedded in a web page.
Josh Mandel (Mar 10 2017 at 18:53):
This manifest could also host a public key or a link to one, when we get there.
Travis Cummings (Mar 10 2017 at 23:28):
Comparing SMART’s simple example and a schema.org version
pasted image
Travis Cummings (Mar 11 2017 at 00:59):
I'm not saying it is all or nothing, 100% strict compliance. I think we can build up like this,
1) Choose JSON-LD over JSON. Both are entirely consumable as JSON. Both can be in a file called manifest.json. JSON-LD adds no constrains, but does add capability. A consumer can ignore any fields of either document. JSON-LD is JSON.
2) Lets use the vocabulary from schema.org as it is an industry standard. In the example above, instead of "smart_version", we say "schemaVersion". We don't have to even declare "@context": "http://schema.org". Lets just use standards where we can.
3) We can stop here. I can't see a single argument for not going to this point.
Travis Cummings (Mar 11 2017 at 01:05):
Next, I'm saying we should go further because 1) our use case already has a great solution 2) a app developer that is serious about taking their app to market will do this anyway. They would end up with our little manifest.json and then put the same information in their app to be a progressive app.
Travis Cummings (Mar 11 2017 at 01:17):
Whats next? These steps are optional from an EHR/Gallery/Sandbox consumption perpective (don't have to enforce these).
4) Go ahead and declare "MobileApplication", "WebApplication", or "SoftwareApplication" as the schema in the JSON-LD file. Extend the schema or bend the rules if necessary :)
5) Go ahead and run the JSON-LD through the Google Structured Data Testing Tool (will make a few fields required or desired) and upgrade the JSON-LD info. Again, an EHR can ignore these not-interesting properties.
6) Go ahead and add the JSON-LD to a HTTP URL within the app space so Google, FB, Twitter, content systems, etc can find and use it. Hopefully we can find a way to consolidate this with our hosting requirement for the manifest info.
7) Ready to rock and roll! To me, this is the easiest way for an app developer to be discovered by our systems and by Google, etc.
Kevin Shekleton (Mar 13 2017 at 00:59):
FWIW, I think the concept of an app manifest and a document (schema.org) for search engines/twitter/etc are orthogonal. Using Apple & Google as examples, they both separate these concepts where each has a respective App Store but also will index/parse the schema.org document. Additionally, I agree with Pascal on the point that not all SMART apps will be web apps (eg, native apps) and may not want to host a document.
I'd prefer to start with a simple JSON manifest/metadata.json file (not JSON-LD). That is the most straightforward and easiest approach. We can start with this and see how it goes and adjust accordingly.
Travis Cummings (Mar 13 2017 at 17:33):
Good, now that we are all in agreement (haha)...
Travis Cummings (Mar 13 2017 at 17:50):
Considering the hosting env API,
1) a register app info API could exist that someone could use to post the manifest information
2) or, a register remote app API could exist that someone could call with a URL the hosting env could query to gain the manifest data (similar to cds hooks services)
Thoughts?
Kevin Shekleton (Mar 13 2017 at 18:27):
@Travis Cummings - Are you asking whether the SMART Sandbox has the manifest pushed to it (option 1) or pulls the manifest from some URL (option 2)?
Travis Cummings (Mar 13 2017 at 18:40):
Hosting env was the wrong term. Is "registry host" a better term for the SMART Sandbox, Gallery, EHR Dev System, Store?
How should an app become registered? Push or pull model. Or something else all-together?
Travis Cummings (Mar 13 2017 at 18:58):
It seems that a web form would also be a way to register. The web form and a push model would both use an HTTP POST API. Does that seem the most basic way to start?
Kevin Shekleton (Mar 13 2017 at 18:58):
In my head I was thinking:
1. Developer signs into the HSPC Sandbox
2. Developer either:
a. Manually fills out form with their app details
b. Uploads the app manifest JSON
<At this point the SMART app has been registered in the HSPC Sandbox>
3. Developer clicks some button to import/register their app into the Cerner Sandbox
4. Developer is redirected to Cerner Sandbox to authenticate and authorize the HSPC Sandbox to import apps on their behalf
5. Developer approves
6. Developer is redirected back to the HSPC Sandbox
7. HSPC Sandbox POSTs to some Cerner Sandbox API with the app manifest JSON
<At this point the SMART app has been registered in the Cerner Sandbox>
Steps 4-6 are a one-time only step to authorize the HSPC Sandbox app.
Admittedly, I have not thought through all of the scenarios here or how it would work if we wanted to go the other direction. The key piece though is that when you upload/ingest an app manifest JSON, you need to know who the developer is so that the SMART app is tied to their account.
Kevin Shekleton (Mar 13 2017 at 18:59):
The most basic way to start would be for the HSPC Sandbox to allow the developer to upload the app manifest JSON file
Travis Cummings (Mar 13 2017 at 19:11):
HSPC can definately start on 1-3. Does the Cerner OAuth system exist that could provide #4? Which do you think we could work on first, 4 or 7 (without auth)?
Kevin Shekleton (Mar 13 2017 at 21:50):
This would all be development work on the Cerner side :)
We have a very robust OAuth 1.0a implementation that we could do this with today; however, I don't want that as we're migrating to OAuth 2. Right now though our OAuth 2 server (authz server) has been focused on the SMART & FHIR use cases. We need to expand it to support these other use cases
Kevin Shekleton (Mar 13 2017 at 21:50):
I think the best thing to start with right now is defining this manifest JSON file
Travis Cummings (Mar 14 2017 at 20:50):
I've added some tabs to this tracking sheet for Development, Gallery, and Store registration. On the development tab, I've put down some ideas for the fields we would want. I'll put together a json example next.
https://docs.google.com/spreadsheets/d/1G_BD5YHZCkXamRn_mtxIM62i5sWlEP-Yr93Zz7tGLKM/edit?usp=sharing
Any thoughts on the development registration info?
Josh Mandel (Mar 14 2017 at 21:23):
For the workflow you've described here, Kevin: why put this work on each sandbox? Wouldn't it be simpler across the board to just treat a sandbox "API" as a service that statically hosts manifest files, with cache headers etc?
Josh Mandel (Mar 14 2017 at 21:24):
er @Kevin Shekleton
Josh Mandel (Mar 14 2017 at 21:25):
We'd define the same manifest JSON file as our first step, however we do it.
Kevin Shekleton (Mar 14 2017 at 21:26):
I think this all warrants further discussion and I agree that the first step, regardless, is defining that app manifest JSON.
Josh Mandel (Mar 14 2017 at 21:26):
:-)
Kevin Shekleton (Mar 14 2017 at 21:27):
My workflow example was putting down an idea in my head of a developer who has registered their app in the HSPC Sandbox and with single click and transfer that app to the Cerner/Epic/athena/Allscripts Sandbox and run the the app from their SMART Sandbox container
Kevin Shekleton (Mar 14 2017 at 21:27):
And the easiest way we can accomplish that (assuming everyone agrees this would be a good thing to do) is fine by me ;-)
Josh Mandel (Mar 14 2017 at 21:28):
If Cerner did build a registration API, would it generate client ids + secrets and expose them to the source sandboxes? Or are you just thinking about an API for "updating app description details", rather than "registering an app"?
Kevin Shekleton (Mar 14 2017 at 21:29):
Today we have to generate client ids + secrets (due to internal implementation details).
Kevin Shekleton (Mar 14 2017 at 21:30):
I've always been open to further discussion around constant ids+secrets across vendors but as time goes on I see this less and less of a concern/hassle
Kevin Shekleton (Mar 14 2017 at 21:32):
The API I was thinking of would be to register an app
Travis Cummings (Mar 14 2017 at 22:24):
Here is an example of a registration:
https://bitbucket.org/hspconsortium/registration/src/802d83aa93fb0ecda9426d888b783efc9ee9f820/dev-sandbox-hierarical.json?at=master&fileviewer=file-view-default
Travis Cummings (Mar 14 2017 at 22:25):
I mean, a manifest that is used for registering an app
Travis Cummings (Mar 15 2017 at 14:36):
@Kevin Shekleton @Josh Mandel @Isaac Vetter @Jeffrey Danford Any feedback on the sample manifest for registration? I think the manifest use cases can be progressive like this:
0) abstract registration: client info + app info
1) reference dev sandbox: registration + sample data + demo launch
2) attribution: dev sandbox + org info
3a) vendor integration: attribution + vendor dev account (i'm not sure what "vendor dev account" is unless the manifest is per vendor)
3b) reference gallery: attribution + marketing info
4) vendor store: vendor integration + marketing info + pricing + contract + validation certificates (these are just ideas)
Josh Mandel (Mar 15 2017 at 14:48):
Thanks for the example, @Travis Cummings. Can you help clarify the difference between client and app? Seems like there is overlap. Also I'd recommend that we avoid sharing the sandbox-specific OAuth client ID in this kind of manifest, because it's likely to create expectations or mistaken assumptions about who's responsible for generating IDs.
(In our current world, each SMART on FHIR EHR needs to generate these —to keep beating the drum... I'd love to move towards universal client IDs, but we should do this very deliberately and only once we have agreement on a scheme for validating them. Something like "the URI pointing to an app's manifest" ;-))
Josh Mandel (Mar 15 2017 at 14:49):
Overall, I'd definitely put emphasis on "can we solve the client identifier problem" before trying to solve the issue of "how do we standardize pricing models" (because I think those are going to vary pretty widely and creatively across vendors).
Travis Cummings (Mar 15 2017 at 14:57):
Good point, i'll remove the client id. I was imaging the different between an app and a client is that a client may be used by multiple apps. Maybe that is something we don't actually want. But for example, the Meducation RS and Meducation TimeView might both share the same client id (in HSPC gallery, they each have a seperate client). Or an app "Big App with Modules" might have 1..* client id's.
But if these are totally fictitious examples, client info and app info could certainly be merged.
Travis Cummings (Mar 15 2017 at 20:06):
For Dan:
{
"client": {
"type": "public",
"name": "Bilirubin SMART sandbox client",
"description": "Client used by the Bilirubin Risk Chart app"
},
"app": {
"id": "15dfd791-3e5f-4f1a-83ef-d5e0ea898a1d",
"name": "Bilirubin Risk Chart",
"summary": "Demonstration app designed to help clinicians treat newborn hyperbilirubinemia appropriately.",
"logo_256x256_png": "https://example.com/1.png",
"logo_512x512_png": "https://example.com/1@2x.png",
"oauth_redirect_uri": "https://example.com/bilirubin-risk-chart/index.html",
"smart_launch_uri": "https://example.com/bilirubin-risk-chart/launch.html",
"scope": "launch patient/*.read online_access",
"fhir_version": [
"1.0.2",
"1.4",
"1.8"
],
"user_profile_type": [
"Practitioner"
]
},
"organization": {
"developer_contact_email": "travis@iSalusSolutions.com"
}
}
Travis Cummings (Mar 15 2017 at 20:11):
https://bitbucket.org/hspconsortium/registration/src
Josh Mandel (Mar 16 2017 at 06:12):
It's also worth knowing about https://github.com/HHSIDEAlab/poet/blob/master/README.md which is a take on a related problem -- but includes a way to publish a manifest of app details (signed by an "endorsing" organization).
Josh Mandel (Mar 16 2017 at 07:20):
And the other manifest design consideration (as in the original SMART gallery example) is using field names that keep our manifest compatible with the specified payload to an OAuth 2.0 Dynamic Registration API (with additional properties for the information not explicitly defined in the dyn reg specification).
Josh Mandel (Mar 16 2017 at 07:21):
This keeps options open for how the manifest can be used downstream.
Travis Cummings (Mar 17 2017 at 16:03):
@Josh Mandel Thanks for getting me up to speed on this style. Do you imagine that this sort of OAuth-registration token would be narrowly focused (marketing, demo, contacts, etc, not included)?
Josh Mandel (Mar 17 2017 at 16:24):
At a minimum it's the data necessary for interoperability, including launch and redirect URLs, public key (if we get there). I think that as more details are included, it becomes easier to trust. For example, including an app name and a description in the signed content seems natural.
Travis Cummings (Mar 17 2017 at 16:37):
Poet talks about an app having possibly several badges that are presented to the user. It seems their goal would be if an app had a badge, "OAuth2 Secured", another "HIPAA verified", another "CMMI Level 4", etc, then the user or UI could have more confidence about it.
Travis Cummings (Mar 17 2017 at 16:38):
So I am wondering if our other types of data are better contained in other badges. For example, context data such as "FHIR Version", "App Category", "User Profile Type" should be in a badge that isn't oauth specific.
Josh Mandel (Mar 17 2017 at 16:39):
Oh, well the goal of the endorsements is that an outside group signs off on "the app".
Travis Cummings (Mar 17 2017 at 16:39):
And less relevant data like "Demo Video URL" in a different badge again.
Josh Mandel (Mar 17 2017 at 16:39):
The point of signing a pile of app details is to *identify* the app that's being endorsed.
Josh Mandel (Mar 17 2017 at 16:39):
So, the more attributes, the better the identification can be.
Josh Mandel (Mar 17 2017 at 16:40):
But as I said, the minimum data set are the fields needed for interop.
Josh Mandel (Mar 17 2017 at 16:41):
I'd say the best practice is to include these + any other fields available; the more details in the signed payloads, the most sophisticated processing an EHR can do downstream in validating the signature and fields.
Travis Cummings (Mar 17 2017 at 16:41):
Ok, an EB investigator would check out the url, name, etc to verify the app. I had thought that the software_id was sufficient, but wasn't thinking of the EB perspective.
Josh Mandel (Mar 17 2017 at 16:41):
I don't see a downside.
Josh Mandel (Mar 17 2017 at 16:43):
Imagine an app presents itself for automated registration and has a software id of "my-good-app-1". It presents a signed endorsement where the only field in the signed payload is the software id ("my-good-pp-1"). Now, a malicious app could present this endorsements as its own, and could supply a redirect URI like "http://evilapp.com". If the redirect URI doens't appear in the signed endorsement body, the EHR can't determine this is foul play.
Josh Mandel (Mar 17 2017 at 16:43):
The more fields in the signed endorsement body, the better matching/assurance the EHR can provide.
Travis Cummings (Mar 17 2017 at 16:49):
I had thought a couple of fields would really help with sandbox and gallery use cases. Do you think this type of info would also belong in this registration-centric token? Of course it would be optional, but is it inappropriate?
Sample Data: a FHIR bundle, either with POST/PUT for supplying data, and GET for requiring data from the target environment
Demo Launch Context: a launch (parameters, ex: patient=123) the app is saying will present an interesting demo, probably coordinated with the sample data
Josh Mandel (Mar 17 2017 at 16:51):
I agree that things like "sample data" and "demo launch context" don't fit there.
Josh Mandel (Mar 17 2017 at 16:52):
The key is: could this information be presented to an end-user in identifying an app? So description, title, URLs, etc all make sense.
Josh Mandel (Mar 17 2017 at 16:52):
Sample data doesn't.
Josh Mandel (Mar 17 2017 at 16:52):
I just added https://github.com/HHSIDEAlab/poet/pull/3 BTW @Alan Viars @Travis Cummings because I think there's a gap in what POET explains...
Travis Cummings (Mar 17 2017 at 16:57):
Ok got it, thanks!
Travis Cummings (Mar 17 2017 at 21:24):
With the POET approach, the most basic manifest could just look like this:
{
"software_id": "15dfd791-3e5f-4f1a-83ef-d5e0ea898a1d",
"client_name": "Bilirubin Risk Chart",
"client_uri": "https://example.com/bilirubin-risk-chart/about.html",
"logo_uri": "https://example.com/bilirubin-risk-chart/images/logo.png",
"initiate_login_uri": "https://example.com/bilirubin-risk-chart/launch.html",
"redirect_uris": [
"https://example.com/bilirubin-risk-chart/index.html"
],
"scope": "launch patient/*.read online_access",
"token_endpoint_auth_method": "none",
"grant_types": [
"authorization_code"
]
}
Travis Cummings (Mar 17 2017 at 21:26):
A couple of fields we might want to add soon could be 1) is this a Patient or Provider app 2) What FHIR versions are supported 3) client type {public|confidential} (is this inferred somehow)
Travis Cummings (Mar 17 2017 at 21:28):
@Kevin Shekleton @Josh Mandel @Dan Gottlieb @Isaac Vetter Would the POET-influenced manifest body be a satisfactory place to start?
Josh Mandel (Mar 17 2017 at 22:17):
token_endpoint_auth_method tells you public vs confidential.
Josh Mandel (Mar 17 2017 at 22:17):
"none" means no authentication --> public client
Josh Mandel (Mar 17 2017 at 22:21):
I'd start with these fields (which is to say, the fields in OAuth 2.0 dyn reg, which is also the fields we use in the SMART gallery manifest) and define our own ad-hoc extensions wherever we want them. We should be all-inclusive by defining as many extensions as we need to cover the manifest use cases from your spreadsheet (patient vs provider, sample data, whatever). Call that "The Full Manifest".
Now, when it comes to using dyn reg (for systems that want to support this): the full manifest can be used as the body of a POST request to register a new app.
When it comes to signing app metadata (if/when we want to go there), we'd define a set of "signed properties" (probably software id, name, descriptoin, uris, scopes, token endpoint auth method, and grant types) that would be used to create a JWT.
Kevin Shekleton (Mar 18 2017 at 02:59):
There is a lot to catch up on here!
Re: #4 - standard pricing models - this is something we will never be able to align on. The pricing will most likely be determined by the SMART app developer and pricing business software is so complex (per bed? per user? per concurrent user? etc etc). Similar reasoning for contract/valdiation details
I agree with Josh on deferring the OAuth client id sharing across vendors.
Kevin Shekleton (Mar 18 2017 at 03:13):
Rather than using the POET or the OAuth 2 dynamic registration terminology, would make more sense to align on the naming that SMART uses? Eg: client_id instead of software_id and launch_url instead of initiate_login_uri.
.
It's a subtle difference but would avoid the appearance that we're trying to solve either dynamic client registration or the notion of endorsements.
Isaac Vetter (Mar 18 2017 at 22:34):
avoid the appearance that we're trying to solve either dynamic client registration or the notion of endorsements.
What are we trying to solve here?
You want to define an interoperable manifest spec for an app to make it easier for a developer to register their app in the 6 or so healthcare app stores/galleries, right? @Travis Cummings, what's the specific workflow that you're envisioning? Given that, I can provide feedback on the current list of fields.
I'm not convinced that an app manifest solves a significant problem.
I think that SMART app compatibility across different FHIR servers (compatibility testing) and to a lesser extent, better enabling users to trust apps (endorsements -- for which POET looks like a solid technical specification) are much more valuable features.
Isaac
Josh Mandel (Mar 20 2017 at 20:56):
@Kevin Shekleton Regarding terminology: The client_id and software_id represent different concepts. A client_id is generally out of a client's control, and represents the over-the-wire id that it uses to perform the OAuth dance with any given provider. A software_id is asserted by an app developer and uniquely identifies a version/release of a given product.
Kevin Shekleton (Mar 20 2017 at 20:58):
Thanks, Josh
Josh Mandel (Mar 20 2017 at 21:00):
@Isaac Vetter Agreed we need to be clear on the problems(s) we want to solve. I think the goal at this point is to define a building block that would be a useful component for a few overlapping goals.
I've heard:
1) app registration within multiple vendor stores and/or multiple provider sites,
2) workflow where updates to an app's description and details can propagate across vendor stores,
3) a lightweight protocol where an organization can publish a list of apps they "trust"
Josh Mandel (Mar 20 2017 at 21:02):
It's possible that a single building block (manifest format) isn't the best way to solve any of these.
Josh Mandel (Mar 20 2017 at 21:02):
(But I suspect it's a pretty good start, and my personal take is that it's worth a good shot.)
Travis Cummings (Mar 21 2017 at 17:34):
{
"software_id": "15dfd791-3e5f-4f1a-83ef-d5e0ea898a1d",
"client_name": "Bilirubin Risk Chart",
"client_uri": "https://example.com/bilirubin-risk-chart/about.html",
"logo_uri": "https://example.com/bilirubin-risk-chart/images/logo.png",
"launch_url": "https://example.com/bilirubin-risk-chart/launch.html",
"redirect_uris": [
"https://example.com/bilirubin-risk-chart/index.html"
],
"scope": "launch patient/*.read online_access",
"token_endpoint_auth_method": "none",
"grant_types": [
"authorization_code"
],
"fhir_versions": [
"dstu2", "1.9"
]
}
Travis Cummings (Mar 21 2017 at 17:39):
1) changed initiate_login_uri to launch_url
2) added fhir_versions (the fhir server declares this, does the app also need to declare this? I think it would be helpful)
3) I have the software_id as a UUID. For sure, it should be unique within a deployment space (site?). What is the preference here?
Travis Cummings (Mar 21 2017 at 17:43):
For the topic of where this file lives, would it be good to follow FHIR's convention of having a /metadata endpoint on the app hosting?
Josh Mandel (Mar 21 2017 at 19:01):
software_id should just be a string -- developer asserts this.
Josh Mandel (Mar 21 2017 at 19:02):
can be a UUID or whatever.
Josh Mandel (Mar 21 2017 at 19:04):
The initiate_login_uri name (along with the iss param) comes from http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin
Travis Cummings (Mar 22 2017 at 16:49):
@Kevin Shekleton had suggested using the smart naming of launch_url because it was consistent with the smart terminology. I'd also favor launch_url because it is where the EHR should initiate a SMART launch and that is scemantically more than an OpenID initiate_login_uri. @Josh Mandel, thoughts?
Josh Mandel (Mar 22 2017 at 17:17):
Compatibility out-of-the-box with existing dyn-reg implementations is nice (e.g. SMART and HSPC use the MITREid server in our reference stack), but it's not a huge deal.
Travis Cummings (Mar 22 2017 at 18:36):
Noticed that Josh had previously suggested hosting this at /.well-known/smart/manifest.json. I think that is better than my proposal of /metadata.
Travis Cummings (Mar 23 2017 at 17:42):
@Josh Mandel @Kevin Shekleton I've released a version of the bilirubin risk chart that includes the manifest. The manifest uses relative paths for deployment simplicity (though absolute paths could be supported).
A registering system can register an app at this path: https://apps.hspconsortium.org/hspc-bilirubin-risk-chart/
and discover a manifest at this path: /.wellknown/smart/manifest.json
and the manifest has addresses like this:
"client_uri": "/",
"logo_uri": "/images/logo.png",
"launch_url": "/launch.html",
"redirect_uris": [
"/index.html"
],
Full manifest: https://apps.hspconsortium.org/hspc-bilirubin-risk-chart/.wellknown/smart/manifest.json
We are going to add a dynamic registration option in the HSPC sandbox for this style.
Travis Cummings (Mar 23 2017 at 18:27):
Spec: https://bitbucket.org/hspconsortium/registration
Possibly we could port this spec over to smarthealthit.org at some point in the future?
Josh Mandel (Mar 23 2017 at 18:36):
Cool! Note that it looks like there may be a double / when you append the relative URIs to the base. We should be clear on where each component begins/ends.
Josh Mandel (Mar 23 2017 at 18:37):
I think including this in the SMART docs site would be great. @Dan Gottlieb what are your thoughts?
Josh Mandel (Mar 23 2017 at 18:39):
Also regarding relative URIs, I think this may be a dangerous thing. Especially if "endorsers" want to be in the business of signing off on app details like redirect_uri, it's essential to have an absolute URI here.
Travis Cummings (Mar 23 2017 at 23:25):
Updated the manifest from @Josh Mandel 's feedback. I have the "client_uri" pointing to an actual page (.../index.html) instead of the root path to align with dynamic registrations intention of showing this address to the end-user as a clickable link.
Dan Gottlieb (Mar 23 2017 at 23:37):
Looks good! @Josh Mandel - yup, Travis and I spoke briefly yesterday about adding the manifest definition to the docs site and I agree that it makes sense.
Last updated: Apr 12 2022 at 19:14 UTC
