Patient Journey Intelligence 2.0.0: Application Modes, OpenShift and EKS deployment, and Databricks data sources
Patient Journey Intelligence 2.0.0 introduces Application Modes, which let an administrator define what a given environment can do: Demo, Production, and Playground each carry their own feature set and restrictions. The release also adds Red Hat OpenShift and AWS EKS deployment, connects Databricks Unity Catalog volumes and Delta tables as data sources, and improves de-identification review for DICOM, PDF, and whole-slide images.
Clinical scenarios in this page are illustrative. Any patient data shown is synthetically generated.
Application Modes
Demo, Production, and Playground, with feature sets and restrictions defined per mode by an administrator.
Enterprise deployment
Red Hat OpenShift, AWS EKS with EFS and EBS storage strategies, resolver read replicas, and container resource limits.
Databricks data sources
Unity Catalog volumes as a data source, Delta tables as an OMOP source.
De-identification review
Manual PHI correction in DICOM, PDF entity review, and corrected whole-slide label coordinates.
Application Modes: one platform, three operating profiles
Patient Journey Intelligence 2.0.0 introduces Application Modes, three configurations of the same deployment: Demo, Production, and Playground. An administrator defines the feature set and the restrictions that apply in each mode.
An environment holding real patient data and an environment used to evaluate or learn the platform have different requirements, and running both under one configuration forces a compromise. Application Modes let an administrator set the feature set and the restrictions appropriate to each, rather than maintaining separate builds.
Where this matters. A health system runs its production deployment against live records while a data science team evaluates cohort building in a Playground environment on synthetic data. Each environment carries the feature set its administrator assigned, and both run the same platform version, so what the evaluation team learns transfers directly.
Enterprise deployment and scaling
Four changes make the platform easier to run at enterprise scale and in the environments healthcare IT teams already operate.
Red Hat OpenShift deployment. Patient Journey Intelligence deploys on Red Hat OpenShift. For a health system standardized on OpenShift, that removes the platform exception from the deployment conversation: it lands on the same cluster, under the same operational controls, as everything else the team runs.
AWS EKS persistent volume strategies for EFS and EBS. Storage in EKS is a trade between shared access and per-volume performance, and clinical workloads want both in different places. Supporting both strategies lets you match the volume type to the workload rather than to whichever one the platform assumed.
Resolver database scaling through read replicas. The resolver answers terminology lookups against the platform's clinical vocabularies, a read-heavy workload. Read replicas add capacity for those lookups without contending with writes on the primary.
Resource limits across all containers. Every container now carries an explicit resource limit, so one workload cannot exhaust a node and take neighbors down with it.
Databricks integration: read your clinical data where it already lives
Two connectors bring Databricks data into the platform without staging it somewhere else first.
Unity Catalog volumes as a data source. A Unity Catalog volume can be used directly as a source, so clinical data your team already governs in Databricks is read where it sits.
Delta tables as an OMOP data source. Where an organization's OMOP CDM is already materialized as Delta tables, the platform reads it as an OMOP source. The mapping work, the vocabulary decisions, and the analyst SQL written against that model all remain in place.
Where this matters. An academic medical center maintains its OMOP CDM in Delta and its scanned outside records on a Unity Catalog volume. Both become sources for the same patient journey, so a cohort defined on structured data can be extended with facts that exist only in the narrative documents beside it.
De-identification review
De-identification is reviewed before it is trusted, and 2.0.0 improves what a reviewer can see and correct.
Manual PHI entity correction in DICOM files. A reviewer can correct and apply PHI entities directly. Automatic detection carries the volume; a person carries the judgment on the cases where the model was uncertain or wrong. That review is what a privacy officer signs against, and it is the difference between a de-identification claim and a documented de-identification process.
PDF entity review on the de-identification details page. PDF entities are reviewed on the de-identification details page, alongside the rest of the job.
SVS label OCR coordinate accuracy. Coordinate mismatches in whole-slide label OCR are fixed. The label attached to a slide file is where the patient name and medical record number usually sit, so a mask drawn at the wrong coordinates leaves visible PHI on an image that has been reported as de-identified.
De-identification services refactored for large file processing. The de-identification services are restructured to better support large files, which is what whole-slide images and full DICOM studies are.
See de-identification.
General improvements
- FHIR JSON detection inside zip files. FHIR bundles delivered in a zip archive are detected correctly, so an archive upload no longer partially ingests.
- DICOM mask alignment during panning. Masks stay aligned with the text while a reviewer pans a study. A mask that drifts on pan is indistinguishable, at a glance, from PHI that was never covered.
- De-ID text viewer rendering. The text viewer no longer occasionally fails to render.
Patient Journey Intelligence 2.0.0 introduces Application Modes (Demo, Production, and Playground), adds deployment on Red Hat OpenShift and AWS EKS with EFS and EBS persistent volume strategies, scales the resolver database with read replicas, applies resource limits across all containers, connects Databricks Unity Catalog volumes and Delta tables as data sources, and improves de-identification review for DICOM, PDF, and SVS whole-slide images.
Application Modes are three configurations of the same deployment: Demo, Production, and Playground. An administrator defines the feature set and restrictions that apply in each mode, so an environment holding live patient data and an environment used for evaluation or training can run the same platform version under different controls.
Patient Journey Intelligence runs inside your own environment, on-premises or in a private cloud. Release 2.0.0 adds Red Hat OpenShift deployment and AWS EKS support for both EFS and EBS persistent volume strategies.
Yes. From 2.0.0, a Databricks Unity Catalog volume can be used directly as a data source, so data your team already governs in Databricks is read where it sits.
Yes. Where an organization already materializes its OMOP Common Data Model as Delta tables, Patient Journey Intelligence 2.0.0 reads that model directly as an OMOP source, so existing vocabulary mappings and analyst SQL remain in place.
Reviewers can manually correct and apply PHI entities in DICOM files, PDF entity review is available on the de-identification details page, coordinate mismatches in SVS whole-slide label OCR are corrected, and the de-identification services are refactored to better support large file processing. DICOM masks also stay aligned with the text while a reviewer pans a study.
The resolver answers terminology lookups against the platform's clinical vocabularies, which is a read-heavy workload. Read replicas add capacity for those lookups without contending with writes on the primary database.