In Part 6, we saw how FHIR can be leveraged to simplify exchange of data when members switch health plans. In Part 7 of the series, we share 5 key ingredients to develop a SMART on FHIR mHealth application.
New CMS and ONC guidelines under the HHS (Health and Human Services) aim to share more payment and clinical data with patients, when and where they need it. The guidelines will require payers to share member information using open data standards, especially Fast Healthcare Interoperability Resources (FHIR).
Consequently, adoption of SMART for FHIR APIs (an open standard-based technology platform) becomes crucial for developing applications and to meet the diverse needs of patients, clinicians and other stakeholders in healthcare. Development of SMART on FHIR applications do not require specialized knowledge about a given health data system.
Successful SMART on FHIR implementation will need healthcare organizations to overcome challenges around accessing and exchanging data from a growing number of systems, devices, facilities, and other organizations.
Key design considerations for architecting SMART on FHIR mHealth applications
1. Authentication and Authorization
Some common scenarios for authentication and authorization include:
- Enabling federated login to securely connect FHIR data stores with multiple applications
- Eliminating credential re-authentication to boost faster patient claim requests
- Identifying healthcare ecosystem stakeholders, and restricting unauthorized users from receiving sensitive information from data providers (such as hospitals and PCPs)
- Ensuring HIPAA audit and access reporting
Designing a successful authentication and authorization framework for enterprise healthcare applications should be flexible and robust to accommodate the
complexities of modern computing environment. It should also acknowledge the following rules: - Customer Identity and Access Management (CIAM) – It allows profile management and integration with CRM, ERP and other customer management systems and databases.
- Standard Protocol Support – It supports common authentication standards such as SAML, oAuth, OpenID and integration with diverse directories such as LDAP, Microsoft Active Directory, etc.
- API Security – Enables IAM for use with B2B commerce, integration with the cloud, and microservices-based IAM architectures.
- Identity Analytics (IA) – Allows security teams to detect and stop risky identity behaviors using rules, machine learning and other statistical algorithms.
- Identity-as-a-service (IDaaS) – Offers SSO for client applications (e.g., mobile, web, etc.)
- Identity Management and Governance (IMG) – Provides automated and repeatable ways to govern the identity life cycle.
- Biometrics Authentication – Integrates with TouchID, FaceID, etc.
2. Scalability and Performance
While architecting a SMART on FHIR application, organizations should consider factors such as management of high user volumes and traffic to legacy healthcare applications, interoperability with multiple healthcare systems, implementation of data-driven approaches to care and accommodating digital trend adoptions such as AI / ML for decision support, etc. Adoption of technologies such as Kubernetes, microservices, containerization, serverless, and more will help organizations achieve an auto-scaled SMART on FHIR architecture.
Organizations should ensure the following before designing and configuring a SMART on FHIR application: - Enterprise-grade, FHIR-based endpoint for data access and storage in FHIR format.
- Free up operational and development resources.
- Control data access at scale.
- Secure management of Protected Health Data (PHI) in a compliant cloud environment.
3. Security
Most of the mHealth applications that leverage SMART on FHIR APIs will need access to the web. This may attract certain security vulnerabilities such as PHI data leakage, improper session handling, non-secure offline patient data storage, accepting inputs from untrusted sources, injection attacks, man-in-the-middle attacks, etc. There are a few approaches organizations could follow to avoid security vulnerabilities: - Accept API Gateways to securely communicate with FHIR APIs.
- Implement network ACLs and security groups to blacklist IP addresses.
- Embrace SSL / TLS protocol for communicating with FHIR backend.
- Encryption at rest should be implemented to encrypt data while writing to disk and decrypt during reading.
4. Extensibility and Reusability
SMART on FHIR use-cases are set to grow at a rapid pace with increasing digital trends such as wearables, IoT, AI/ML, etc. It would be worth exploring latest design techniques and patterns like micro-frontends, progressive web-apps, etc.
Leveraging micro-frontend architecture will help create reusable plug and play healthcare components. It can also be used to develop a repository of FHIR complaint healthcare apps which can integrate and communicate to accelerate development. Utilizing Progressive Web Apps will help organizations lower maintenance cost, improve user retention, and provide browser-mobile support with single codebase.
5. Analytics
Implementation of SMART on FHIR APIs involves interoperability with multiple healthcare systems may result in challenges around high volume management, inconsistent performance of applications, high infrastructure consumption under normal conditions, user over-usage, etc.
Tracking key APIs and analytics involves monitoring in real-time, tracing, and logging API services to track exceptions/errors, etc. Out-of-the-box APM solutions (Firebase, Google Analytics, New Relic) or open source tools (Prometheus, Grafana, etc.) can be leveraged to achieve important analytics for SMART on FHIR applications. However, tracking important metrics and leveraging advanced techniques such error correlation and AIOps would act as a differentiator.
Fig. - SMART on FHIR Integration with mHealth Applications
Conclusion
Non-optimized SMART on FHIR applications may result in unstable service environment. It can also develop complications around integrity and interoperability between different healthcare systems. Organizations may experience high operational and maintenance cost, degradable performance, and compromised security layer. It becomes crucial for organizations to architect a reliable SMART on FHIR application for patient safety and quality of care.
Read all Blogs in the FHIR Series
Part 1: CMS Interoperability & Patient Access Rule - Impact & Opportunities
Part 2: CMS Interoperability & Patient Access Rule - Patient Consent on Data Sharing
Part 3: CMS Interoperability & Patient Access Rule - Provider Engagement using ‘SMART on FHIR®’ Apps
Part 4: CMS Interoperability & Patient Access Rule - FHIR Bulk Data API
Part 5: CMS Interoperability & Patient Access Rule - FHIR Data Repository
Next in the blog series, Part 8: "Data Ingestion Framework and Data Loader”.
