Before getting started in this section we recommend you review the steps outlined in Epic’s documentation for “Requesting An Epic On FHIR App”. We will be heavily referencing the documentation published by Epic as we talk about the specifics of CART.
The red arrows in the architectural diagram above represent data moving between the three CART applications and the EMR. These read only connections provide the raw data CART processes to determine if triggers have been fired.
Step 1: Reach out to Epic with relevant information
As stated in their documentation there is a three party line of communication that will need to be in place in order to get the CART application up and running. In order to streamline this process it’s best to understand all the information that will be needed up front. A support specialist from CART will be available to assist in getting all the necessary information and setup. We will be opening up three connections between epic and CART. Let’s review what information will be needed.
- CDS Hook (allows user to start monitoring for new patient from EMR) –
- CART CDS server url that will pick up information from the EMR
- Specify on patient-view event (and any potential filtering of patients)
- If launching the SMART app from the notification, will need to have the launch url registered
- CART Backend Service (runs trigger logic against FHIR)
- client ID for sandbox testing (provided by CART)
- the security key files to establish secure connection (provided by CART)
- ensure CART has read only access to the required FHIR resources to run the triggers
- CART SMART App (Access patient feed and trigger information)
- Launch URL of SMART App (provided by CART)
- Read only access to required FHIR resources
- Client ID for CART SMART App (provided by CART)
The majority of this information will be provided by the team at CART and the support contact on the Epic side.
Depending on the setup of the client Epic system, it may also be necessary to map certain CDS Hooks to certain Best Practice Advisories inside of Epic. This is the recommended approach to leveraging CDS Hooks as outlined in their documentation. This way the system will filter down which patients will be sent back
Step 2: Create a test plan
Once all the necessary connections are in place, the CART system is ready for a test drive. The support team at CART will work directly with clinical stakeholders to identify which triggers are the most impactful to focus on first. After those are identified, testing can be done against the FHIR server to ensure that the triggers and alert routing are properly configured.
A typical test plan will involve multiple parts:
- Retroactive testing to determine trigger parameters
- This step is to ensure the generic coding and selection logic in the triggers matches up with the clients FHIR server.
- A test period of silent monitoring
- A time period where a subset of hospital patients are under CART monitoring, with silent alerts. Allows for the fine tuning of alerts against an active dataset.
- Phased Rollout
- Slowly begin to turn alerting on for triggers and rapidly iterate based on user feedback.
Step 3: Production Support and Continued Expansion
CART is designed under a SAAS model, which means part of your monthly subscription pays for live support. You can use the links on the SAPHUR (saphur.com) website to get in touch with support. The Trigger Admin and Organization Admin pages provide the ability to support the basic setup and operation of the triggers, but deeper customizations and adjustments can be made in connection with the technical team at CART.
CART is constantly collecting analytical information that can be used to more accurately tune triggers and alerts. Part of the continuing improvement process includes a quarterly review with SAPHUR clinical specialists to help providers understand what is working, what isn’t, and how to adjust to improve operations.
