The app is responsible for protecting itself from potential misbehaving or Other security mechanisms, such as those mandated by HIPAA in the US (end-user authentication, session time-out, security auditing,Īnd accounting of disclosures) are outside the scope of this profile. In other words, if the patient chart is changed during the session, the application will not inherently be updated. Synchronization of patient context is not addressed. The profile defines a method through which an app requestsĪuthorization to access a FHIR resource, and then uses that authorization This profileĭoes not dictate the institutional policies that are implemented in the Include requesting end-user authorization. OAuth 2.0 authorization servers are configured to mediate access based onĪ set of rules configured to enforce institutional policy, which may It is compatible with FHIR DSTU2 and above, and includesĮxplicit definitions for extensions in DSTU2 and STU3. This profile is intended to be used by developers of apps that need to accessįHIR resources by requesting access tokens from OAuth 2.0 compliantĪuthorization servers. Provider apps that launch from a portal.It provides a reliable, secure authorization protocol forĪ variety of app architectures, including apps that run on an end-user’s deviceĪs well as apps that run on a secure server. Patients, and others via a PHR or Patient Portal or any FHIR system where a user can give permissions to launch an app. The framework supports apps for use by clinicians, Health Record data, allowing apps to launch from inside or outside the user The SMART App Launch Framework connects third-party applications to Electronic
#SMARTAPP CODE FULL#
For a full list of available versions, see the Directory of published versions SMART App Launch Framework The current version which supercedes this version is 2.0.0.
This page is part of the Smart App Launch Implementation Guide (v1.0.0: STU 1) based on FHIR R3.
0 kommentar(er)
