Issues, barriers, and solutions from the implementation and use of the EMBED intervention, an integrated web application for decision support and automation of EHR workflow to simplify the ED-initiation of BUP for OUD
| Issue . | Barrier . | Solution . |
|---|---|---|
| Usability | Vendor-provided CDS tools have limited capabilities for interface customization to develop intuitive, efficient user interfaces and workflow | Created an integrated web application that embedded into EHR clinical workflow for the end-user |
| Needed to support health systems in the trial network using different EHR vendors (Epic and Cerner) | ||
| Two-way communication between EHR and web application | FHIR standard does not yet cover enough resources and two-way (“read /write”) communication for many FHIR resources is still not widely available. SMART on FHIR tools have limited capability to directly interact with an EHR API. Real-time interaction (order entry and documentation) cannot be pushed back to EHR from a web app. | Short-term: Epic AGL and flowsheet solution in main health system. Secondary health system has to rebuild web-app features in EMR vendor tool resulting in multiple separate instantiations of protocol. |
| Long-term: await maturation of FHIR, SMART on FHIR or similar standards for interoperability | ||
| Institutional IT support | Some secondary health systems reluctant to invest in hosting and supporting a custom web application on-premise | Designed a lightweight, single-page web application running on open source technologies, to maximize flexibility in hosting and minimize infrastructure requirements |
| Long-term: consider centralized, secure hosting of the web application in software as a service (SaaS) model | ||
| Security and privacy concerns from secondary health systems | Utilized secure methods that pass no protected health information outside the EHR to the web application. Achieved independent, third-party security audit and certification for the provided web application. | |
| Stakeholder buy-in and alignment | Informatics leadership in secondary systems reluctant to change established, local interfaces and workflows with which users are already familiar | Secondary health systems made local, pragmatic decisions on how the intervention was built in their system provided it allowed for decision support for diagnosing OUD, assessing withdrawal, and automating documentation, orders, prescriptions, referral, and discharge instructions |
| Informatics leadership reluctant to take responsibility for updating of local instance of EMBED CDS as protocol or other variables change over time (“technology debt”) | No solution until progress is made in standards-based interoperability | |
| Referral to community providers for continued medications for opioid use disorder (MOUD) | Limited availability of community providers of MOUD. Even if available, often not on the same vendor’s EHR product | Used platform-agnostic secure messaging |
| Engaged local care coordination teams | ||
| Piggy-backed onto other local MOUD initiatives | ||
| Governance | Prioritization of intervention required review by local committees in each health system. | Early engagement with informatics leadership to accelerate EHR prioritization requests and navigation of local governance norms to maximize the time available for local implementation of intervention |
| Sometimes multiple committees in the same system. | ||
| Human resources | Limited workforce available to make changes in local EHR build | Leveraged local physician builders, where available |
| Issue . | Barrier . | Solution . |
|---|---|---|
| Usability | Vendor-provided CDS tools have limited capabilities for interface customization to develop intuitive, efficient user interfaces and workflow | Created an integrated web application that embedded into EHR clinical workflow for the end-user |
| Needed to support health systems in the trial network using different EHR vendors (Epic and Cerner) | ||
| Two-way communication between EHR and web application | FHIR standard does not yet cover enough resources and two-way (“read /write”) communication for many FHIR resources is still not widely available. SMART on FHIR tools have limited capability to directly interact with an EHR API. Real-time interaction (order entry and documentation) cannot be pushed back to EHR from a web app. | Short-term: Epic AGL and flowsheet solution in main health system. Secondary health system has to rebuild web-app features in EMR vendor tool resulting in multiple separate instantiations of protocol. |
| Long-term: await maturation of FHIR, SMART on FHIR or similar standards for interoperability | ||
| Institutional IT support | Some secondary health systems reluctant to invest in hosting and supporting a custom web application on-premise | Designed a lightweight, single-page web application running on open source technologies, to maximize flexibility in hosting and minimize infrastructure requirements |
| Long-term: consider centralized, secure hosting of the web application in software as a service (SaaS) model | ||
| Security and privacy concerns from secondary health systems | Utilized secure methods that pass no protected health information outside the EHR to the web application. Achieved independent, third-party security audit and certification for the provided web application. | |
| Stakeholder buy-in and alignment | Informatics leadership in secondary systems reluctant to change established, local interfaces and workflows with which users are already familiar | Secondary health systems made local, pragmatic decisions on how the intervention was built in their system provided it allowed for decision support for diagnosing OUD, assessing withdrawal, and automating documentation, orders, prescriptions, referral, and discharge instructions |
| Informatics leadership reluctant to take responsibility for updating of local instance of EMBED CDS as protocol or other variables change over time (“technology debt”) | No solution until progress is made in standards-based interoperability | |
| Referral to community providers for continued medications for opioid use disorder (MOUD) | Limited availability of community providers of MOUD. Even if available, often not on the same vendor’s EHR product | Used platform-agnostic secure messaging |
| Engaged local care coordination teams | ||
| Piggy-backed onto other local MOUD initiatives | ||
| Governance | Prioritization of intervention required review by local committees in each health system. | Early engagement with informatics leadership to accelerate EHR prioritization requests and navigation of local governance norms to maximize the time available for local implementation of intervention |
| Sometimes multiple committees in the same system. | ||
| Human resources | Limited workforce available to make changes in local EHR build | Leveraged local physician builders, where available |
Issues, barriers, and solutions from the implementation and use of the EMBED intervention, an integrated web application for decision support and automation of EHR workflow to simplify the ED-initiation of BUP for OUD
| Issue . | Barrier . | Solution . |
|---|---|---|
| Usability | Vendor-provided CDS tools have limited capabilities for interface customization to develop intuitive, efficient user interfaces and workflow | Created an integrated web application that embedded into EHR clinical workflow for the end-user |
| Needed to support health systems in the trial network using different EHR vendors (Epic and Cerner) | ||
| Two-way communication between EHR and web application | FHIR standard does not yet cover enough resources and two-way (“read /write”) communication for many FHIR resources is still not widely available. SMART on FHIR tools have limited capability to directly interact with an EHR API. Real-time interaction (order entry and documentation) cannot be pushed back to EHR from a web app. | Short-term: Epic AGL and flowsheet solution in main health system. Secondary health system has to rebuild web-app features in EMR vendor tool resulting in multiple separate instantiations of protocol. |
| Long-term: await maturation of FHIR, SMART on FHIR or similar standards for interoperability | ||
| Institutional IT support | Some secondary health systems reluctant to invest in hosting and supporting a custom web application on-premise | Designed a lightweight, single-page web application running on open source technologies, to maximize flexibility in hosting and minimize infrastructure requirements |
| Long-term: consider centralized, secure hosting of the web application in software as a service (SaaS) model | ||
| Security and privacy concerns from secondary health systems | Utilized secure methods that pass no protected health information outside the EHR to the web application. Achieved independent, third-party security audit and certification for the provided web application. | |
| Stakeholder buy-in and alignment | Informatics leadership in secondary systems reluctant to change established, local interfaces and workflows with which users are already familiar | Secondary health systems made local, pragmatic decisions on how the intervention was built in their system provided it allowed for decision support for diagnosing OUD, assessing withdrawal, and automating documentation, orders, prescriptions, referral, and discharge instructions |
| Informatics leadership reluctant to take responsibility for updating of local instance of EMBED CDS as protocol or other variables change over time (“technology debt”) | No solution until progress is made in standards-based interoperability | |
| Referral to community providers for continued medications for opioid use disorder (MOUD) | Limited availability of community providers of MOUD. Even if available, often not on the same vendor’s EHR product | Used platform-agnostic secure messaging |
| Engaged local care coordination teams | ||
| Piggy-backed onto other local MOUD initiatives | ||
| Governance | Prioritization of intervention required review by local committees in each health system. | Early engagement with informatics leadership to accelerate EHR prioritization requests and navigation of local governance norms to maximize the time available for local implementation of intervention |
| Sometimes multiple committees in the same system. | ||
| Human resources | Limited workforce available to make changes in local EHR build | Leveraged local physician builders, where available |
| Issue . | Barrier . | Solution . |
|---|---|---|
| Usability | Vendor-provided CDS tools have limited capabilities for interface customization to develop intuitive, efficient user interfaces and workflow | Created an integrated web application that embedded into EHR clinical workflow for the end-user |
| Needed to support health systems in the trial network using different EHR vendors (Epic and Cerner) | ||
| Two-way communication between EHR and web application | FHIR standard does not yet cover enough resources and two-way (“read /write”) communication for many FHIR resources is still not widely available. SMART on FHIR tools have limited capability to directly interact with an EHR API. Real-time interaction (order entry and documentation) cannot be pushed back to EHR from a web app. | Short-term: Epic AGL and flowsheet solution in main health system. Secondary health system has to rebuild web-app features in EMR vendor tool resulting in multiple separate instantiations of protocol. |
| Long-term: await maturation of FHIR, SMART on FHIR or similar standards for interoperability | ||
| Institutional IT support | Some secondary health systems reluctant to invest in hosting and supporting a custom web application on-premise | Designed a lightweight, single-page web application running on open source technologies, to maximize flexibility in hosting and minimize infrastructure requirements |
| Long-term: consider centralized, secure hosting of the web application in software as a service (SaaS) model | ||
| Security and privacy concerns from secondary health systems | Utilized secure methods that pass no protected health information outside the EHR to the web application. Achieved independent, third-party security audit and certification for the provided web application. | |
| Stakeholder buy-in and alignment | Informatics leadership in secondary systems reluctant to change established, local interfaces and workflows with which users are already familiar | Secondary health systems made local, pragmatic decisions on how the intervention was built in their system provided it allowed for decision support for diagnosing OUD, assessing withdrawal, and automating documentation, orders, prescriptions, referral, and discharge instructions |
| Informatics leadership reluctant to take responsibility for updating of local instance of EMBED CDS as protocol or other variables change over time (“technology debt”) | No solution until progress is made in standards-based interoperability | |
| Referral to community providers for continued medications for opioid use disorder (MOUD) | Limited availability of community providers of MOUD. Even if available, often not on the same vendor’s EHR product | Used platform-agnostic secure messaging |
| Engaged local care coordination teams | ||
| Piggy-backed onto other local MOUD initiatives | ||
| Governance | Prioritization of intervention required review by local committees in each health system. | Early engagement with informatics leadership to accelerate EHR prioritization requests and navigation of local governance norms to maximize the time available for local implementation of intervention |
| Sometimes multiple committees in the same system. | ||
| Human resources | Limited workforce available to make changes in local EHR build | Leveraged local physician builders, where available |
This PDF is available to Subscribers Only
View Article Abstract & Purchase OptionsFor full access to this pdf, sign in to an existing account, or purchase an annual subscription.
