** IMPORTANT NOTE **
Google Chrome blocks third-party apps from sending cookies back to the server when using incognito window mode, which can have some unintended effects on the performance of Smile’s App Management Tools application.
To avoid this, please enable cookies manually by following the instructions below.
Step 1: Select the eye icon in the URL bar and the “site not working” link.
Step 2: Select “Allow cookies".
These are resources that we recommend for internal or third-party SMART on FHIR developers to help get SMART on FHIR App running and connected to Smile CDR. Developers should also review the RESTful API documentation for FHIR here.
While Smile maintains this documentation, we recommend that the Developer Portal feature users include these resources in a publicly accessible web page for app developers to access conveniently.
An account is required to gain access to the developer portal and begin registering 3rd party Apps. Creating a developer account requires the developer’s first name, last name, email address, and creation of a password.
The developer registration process continues after the developer has logged in for the first time. The developer will be prompted to enter more identity information to set up their account:
This information can be found in the “Vendor Account” tab under the profile dropdown list in the developer portal. Only the following information is editable:
Below is a description of the UI for the Developer Portal:
The developer portal utilizes an App registration wizard built to be easy to use and provide everything a developer needs to showcase their App to the reviewers and potential consumers in the App gallery.
The 7-step process to provide an App submission request includes:
Step 1: Provide App name as it appears in supported App stores and download sites
Step 2: Select the operating system i.e., web, iOS or Android for which the App is available and to be published in the public-facing site.
Enter the following information:
Step 3: Provide App description for the public-facing site
Step 4: Select categories that apply to your App (multiple options can be selected for each category)
Step 5: Enter scopes to request app permissions (note: link is provided for more information on SMART App Launch: Scopes and Launch Context)
Step 6: Option to enter notes for the reviewer to help in the evaluation of the submission. If a re-submission is provided, then users are required to summarize the changes made.
Step 7: Review legal attestation and either accept or decline adherence to the terms that describe the minimum privacy and security criteria to sufficiently protect patients' protected health information in accordance with the CMS and ONC.
** IMPORTANT NOTE **
In compliance with regulations, a developer may decline the terms and still successfully register the app. However, refusing the attestation terms will result in the display of a warning to patients both in the App Gallery as well as after patient authentication. Patients will be informed explicitly of the risks involved in using apps where the developer has declined the attestation terms and have the opportunity to refuse consent to the app during the OAuth process.
As part of the App registration process, developers are required to follow a 7-step process to provide an App submission request. The 4th step of this process enables developers to switch between the "public" or “confidential” option for the App to be submitted. By default the toggle switch is set to the “confidential” option.
In order to gain more information, the user can hover over the “i” icon and select the “learn more” option that leads to the “Smart App Launch Implementation Guide” webpage. Under the “Smart App Launch Framework”, the webpage provides information on support for “public” and “confidential” Apps and when to select the private versus confidential profile for Apps. The main differentiation is based on whether the execution environment within which the App runs enables the App to protect secrets or not, in the OAuth2 sense.
Once the appropriate option (public versus private) has been selected and the subsequent steps of the 7-step process to provide an App submission request have been completed, the App will be sent for review. The status of the App submitted for review can be seen by developers in the Registered App page.
If the App has been reviewed and promoted by the admin to “Live” in the status column, the flyout that appears when the App name is selected shall contain the following information.
As shown below, the "System Generated Secret", "Activation Date" and "Expiration Date" will not be included for public Apps.
Developers are asked to attest that their App has privacy and security policies that meet or exceed the minimum standards required to protect a patient’s private health information.
To comply with regulations set by the CMS and ONC, app developers are allowed to decline the attestation terms and still register their App. Apps that have refused the attestation will be labeled in the App Gallery to warn potential users against its use. Additionally, patients are made aware of the risks of using these potentially harmful apps during the authentication process.
The attestation document for each App can be accessed from an App’s information page.
Each attestation document will be electronically signed with the developer’s: Legal name, Position/ Designation, Legal business name and Date of attestation.
Developers are required to re-attest when attestation documents are updated. Developers will be notified of updated attestation via two methods. An email will be sent to their registered email address for the App, and a notification will be displayed next to the App on the Developer portal.
The notification shows how many days has passed since the attestation document for an App has been out of date. Hovering over the notification displays a pop-up message asking the Developer to re-register the App and accept the updated attestation.
** IMPORTANT NOTE **
Developers can re-register their App by using the App registration process (outlined in the "App Registration Section")
A developer can register a new App version via the register App button on the registered App list page and by selecting “submit a new version” in the registration wizard. Developers should select the existing App from the drop list and edit the existing information to suit their new version.
A "Change Notes" section is provided in the registration wizard to allow developers to summarize any changes made in the App to help expedite the review process.
When registering a new App version, the App information from the previous version would be pre-populated in the registration wizard. This makes it easier for developers to keep the standard information while making the necessary changes.