Skip to main content
. 2023 Jun 27;30(9):1532–1542. doi: 10.1093/jamia/ocad114

Figure 1.

Figure 1.

Summary of a DEPLOYR enabled model deployment. Blue shading indicates infrastructure operated by the Stanford School of Medicine (academic research). Orange shading indicates infrastructure operated by Stanford Health Care (clinical operations). (A) De-identified EMR data are sourced from Stanford’s clinical data warehouse (STARR), a model is developed and retrospectively validated using the DEPLOYR-dev python package. (B) The model is deployed to the inference engine, and exposed as a REST API using DEPLOYR-serve. (C) Inference is triggered, spawning an HTTPS request from the EMR directed at the exposed model. (D) The request results in the collection of a feature vector from the EMR’s transactional database using REST (both FHIR and EMR specific) APIs maintained by the EMR vendor. Inference is performed on the real-time retrieved data, and routed back to the EMR closing the loop with end-users and integrating into workflow. (E) Inferences and relevant metadata are additionally saved to the inference store, (F) and consumed by monitoring software (DEPLOYR-dash) that continuously tracks model performance via dashboard. REST: representation state transfer; HTTPS: hypertext transfer protocol secure; FHIR: fast healthcare interoperability resources.