Check out our YouTube Playlist about EMR/EHR integration that covers everything on this page!
Topology Health leverages SMART on FHIR (Substitutable Medical Applications and Reusable Technologies on Fast Healthcare Interoperability Resources) to connect to EMR/EHRs.
When creating a SMART on FHIR app, consider the app context.
- Is it a patient or provider-facing app?
- How will the user access the app?
- Does the app require multi-context access to the EMR/EHR?
Topology Health supports all of these contexts and therefore can support many kinds of applications. During app development, you’ll need to consider what kinds of users and launch contexts you’ll require.
Note: Each EMR/EHR will offer different levels of support for each of these contexts.
User Types
The user context determines who will be the app’s end-user: patients or providers. If your app fits into multiple contexts, check out the Multicontext Apps section.
Patients
Here’s a list of example apps that a patient would use:
| Example App | Goal | Functionality |
|---|---|---|
| Personal Health Record/Patient Portal | Empower patients to access and manage their own health information. | Patients can view their electronic health records (EHRs), check lab results, review medication lists, and monitor their health history. |
| Health Data Sharing | Enable patients to share their health data with authorized individuals and healthcare providers. | Patients can securely share specific health information with other healthcare apps or providers, ensuring controlled access to their data. |
| Self-Management | Facilitate self-management of health conditions and wellness. | May include features for setting health goals, tracking activities, receiving reminders for medications, and accessing educational resources. |
| Engagement and Communication | Foster patient engagement and communication with healthcare providers. | Patients can communicate with their healthcare team, schedule appointments, and receive notifications or alerts related to their care. |
Providers
Here’s a list of example apps that might be used by a provider.
| Example App | Goal | Functionality |
|---|---|---|
| Clinical Decision Support | Support healthcare providers in making informed decisions at the point of care. | Integrate clinical decision support tools, providing relevant information, guidelines, and recommendations based on patient data. |
| Care Coordination | Improve coordination of care among healthcare providers. | Share patient data, care plans, and relevant information with other members of the healthcare team, facilitating collaborative and patient-centered care. |
| Population Health Management | Assist providers in managing the health of populations and identifying trends. | Analyze population health data, identifying at-risk patients, and implementing interventions to improve overall health outcomes. |
| Data Exchange | Facilitate secure and standardized data exchange between different healthcare systems. | Exchange health data, enabling providers to access information from external sources while ensuring data security and privacy. |
Launch Context
There are 2 kinds of launch contexts.
- EHR Launch
- Standalone Launch
Both EHR Launch and Standalone Launch cater to both patient and provider contexts. Patients can initiate app launches from inside or outside their patient portal, similar to how providers might launch apps within their EMR/EHR. EHR and Standalone launches are supported by our SMARTerFHIR toolkit.
In addition to these, there is another connection type known as the Backend Service Connection, primarily used for server-to-server connections rather than contextual launches. We also have an EHR Auth Gateway service available.
Learn more about Launch contexts in this YouTube video
EHR Launch
EHR Launched apps typically have a provider focus, such as with clinical decision support applications, voice assistants, and other tools accessed within EMR/EHR patient context. Providers typically launch these apps using button inside the EMR/EHR.
Standalone Launch
Standalone Launch supports applications like dashboards and data access, presenting information in a separate window from the EHR. Users navigate to the app from their web browser, log in, and retrieve information from their EHR, whether they are a patient or a provider.
Backend Service Connection
Backend services offer a server-to-server connection from a given app to the EMR/EHR. Often these kinds of applications are headless and need routine access to EMR/EHR data.
Any app that needs to use BulkFHIR, such as an analytics app or dashboard, is a great candidate for a Backend Service connection.
Most EMR/EHR vendors prefer to keep the number of backend connections to a minimum for security reasons, and prefer developers to use EHR and Standalone Launch whenever possible.
Multicontext Apps
Some apps may need to use multiple launch contexts, usually when their users include both patients and providers. Examples include:
- A chatbot that captures patient information and saves it to the EMR/EHR
- Remote patient monitoring apps
In many of these contexts there is no front-end user interaction, which would require the app to use a backend connection. Then, if the provider were to view the data, it would use an EHR Launch or Standalone Launch.
When choosing contexts, consider your users and how you want them to access the information.
Questions?
Please contact us if want to discuss contexts with regards to your app.