CanShare:

Proof Of Concept

To help drive CanShare design

Multi part presentation

• Introduction
• Part 1 - Functionality - for Clinician
• Emphasis on Structured Pathology workflow
• Part 2 - FHIR design - Informatician, implementer
• Includes terminology
• Part 3 - API - Implementer
• Part 4 - Infrastructure - for hoster

Today is only Part 1

Focus on Structured Pathology

What is canShare

• Cancer related data repository
• Multiple data sources
• Data available for realtime clinical use
• Source of analytics data
• 3 key projects
• Structured Pathology
• ACT-NOW
• Breast Cancer Foundation

What is the POC & Why

• The ‘How’
• Example implementation
• Test functionality
• Feedback from users, implementers
• How it ‘could work’
• Other designs are possible
• Validate / refine design by doing
• Structure & process
• Complicated under the hood!
• Development environment for implementers
• Not production
• No PHI
• It isn’t:
• A ‘real’ implementation
• Finished
• Fully featured forms layout designer
• But should it be?

Clinical Viewer

Requester

Lab

CanShare

Forms Designer

Analytics

POC Use Cases

• Structured Pathology (Workflow)
• A request authoring system for Clinicians
• Prompt for appropriate data
• Track requests
• A report authoring system for Pathologists
• Pre-populate as much as possible
• Report as text and machine data
• Clinical data viewing
• Requests & reports
• ACT-NOW data
• General forms

• Acquiring data
• ACT-NOW
• Breast Cancer Foundation
• Others to come…
• Publishing forms
• From designer to Forms server
• Need to consider
• Versioning
• Governance
• Developer support
• Validation
• Visualization

We’ll cover Structured Pathology & Data viewing today

Benefits of Design

• Form template management
• Central repo, easy to update & distribute
• Using term serv
• SP Data in repo at all stages (cf messaging between entities)
• Visibility at all times
• Track completion by SR
• Could add task for more complex flows - eg send aways

Structured Path forms

Form Templates Server

Designer

Request Form

Report Form

Pre-population

Pre-population of request data into the report occurs when report form selected

Local Store

Clinical Review

Publish

Select

Select

Canshare Server

Clinical Viewer

Form Template

• Define template in a structured and coded way
• Uses FHIR & SNOMED-CT standards
• Items in hierarchical Tree
• Each item has
• Text and description
• A snomed code
• Data type - eg text or a set of answers
• Possible answers (or ValueSet)
• Conditional hide/show
• Template can be rendered as form
• Rendering is basic in POC!
• Used for Data Model (HISO) and implementing
• ?Are they the same template

Render

Part 1: User experience

• Review of key POC user components
• Requester
• Create a new pathology request
• Clinical Viewer
• View the request in an example app
• Lab
• Enter a draft report
• Finalize the report
• CanShare server stores request and report
• Not direct messaging from requester to lab

​

1. Make a request

• What is a request
• Textual request for humans
• Structured data (SNOMED-CT / FHIR) for computers
• Workflow
• Process
• In an EMR - eg Orion Portal (Concerto)
• Select Patient
• Select form template
• Enter data
• Save request to CanShare
• Demo
• Create request
• View in viewer

CanShare

Requester

FHIR

Interface

EMR

Form

2. Clinical Viewer

• An example of accessing CanShare data
• Uses FHIR API - standardized sharing
• View SP requests & reports
• ACT-NOW Data
• Any other data
• Eg General forms
• Possibility of general forms capability - with resource extraction

CanShare

Application

FHIR

Interface

3. Lab - enter the report

• What is a report
• Textual report for Humans
• Structured data (SNOMED-CT / FHIR) for computers
• Template based
• Pre-populated from request
• Demo
• Select the request
• Select the report template
• Issue preliminary report
• Issue final report
• Likely that will still need to export HL7 v2
• Process can be a lot more complex
• How far should CanShare go?

​

CanShare

Lab

FHIR

Interface

Local

Data

Form

V2

Forms publishing

• Performed by administrators using dashboard app
• Copy from designer to forms server
• Process TBD
• Governance
• Should be Immutable in forms server
• Could work for any forms based requirement
• ​

Dashboard

Local

Repo

Form

Designer

Clinical Review

Plans for the POC

• In the next few weeks:
• Finish debugging
• Improve integration with designer
• Terminology integration
• Deploy on web so can be more generally used
• Further engage with vendors
• Lab IT
• Requesters

Questions

• Some sections (Demographics / admin) contain data populated by EMR. Should they be in the forms?
• Demographics anyway - there a case to include admin, though need to think through identifiers and elements created outside of the form (ie not entered by clinician)
• General question is difference between form developed for the data standard, and one to render the data input form
• Report:
• Which items should be separate observations, and which in the textual report
• Request:
• Similar question, though overlaps with pre-population question to lab vendors

Clinical documents (not sure whether to mention this)

• Create structured clinical documents based on templates
• View in ‘CDV’ tree (todo)
• Uses forms technology
• Can extract resources
• Doesn’t create SR

Part 2: FHIR design

• Data model is FHIR resources
• Repository is FHIR Native
• Requests & Reports are graphs of resources
• All data submitted as Bundles with Conditional create/update on identifier
• Full REST API for query
• ​

Key FHIR concepts

• Resources, datatypes, references, coded data
• Resource versions
• Key resources
• Profiles / validation
• Resource Graph
• Bundle, transactions
• The REST API

• Terminology
• ValueSets
• Operations
• $expand
• $lookup
• $translate
• ​

Key resources

• Patient
• Organization
• Practitioner
• Questionnaire
• QuestionnaireResponse
• ServiceRequest
• Observation
• Condition
• Procedure
• Provenance

• CarePlan
• MedicationAdministration
• MedicationRequest
• ​

Terminology

Request graph

​

Graph

• ServiceRequest to track order
• QR has form representation
• Extracted Observations
• SDC process
• Tracked by Provenance
• Could potentially model as document
• Add composition

Questions

• What needs to be extracted as Obs / Proc?
• Related to pre-pop question for report
• Should we extract Specimen/s as separate resources
• Note that could be tricky to associate other parts of the Q to a specimen
• How to manage multiple specimens
• Inside of the QR should be Ok (nested sections, though not supported by POC)
• If wish to extract as separate observations could be tricky working out the relationships
• Eg observations of size
• How to manage consent for data access through the API
• Will be much more complex if more than opt-out (ie at the individual level)
• Prefer to manage externally - in deployment environment through API manager

The request graph

Key resources in request graph

Resource extraction from QR - obs, proc, cond

Why extract

Provenance: Provenance

Work flow: SR

Instructions in Q

Demo

Create request, view resources, do text extract

View in clinical viewer

Demographics, admin from EMR

Potential for pre-pop

Report graph

Graph

• Link to ServiceRequest
• Uses DiagnosticReport & Observations
• Textual report in DR
• Observations for computable purposes

Adding the report graph

• Resources used - DR / Obs
• How to pre-pop
• Obs / QR
• Link to request through SR
• SR status update when complete
• Potential for Task for more sophisticated tracking - eg sendaways
• Provenance
• Preliminary vs Final
• Algorithm for updates
• Should Obs only be done on final report? Still have textual for interim
• Invalidate Obs
• Update DR

Questions

• How should prepop work. 2 possibilities
• From Observations (extracted from request)
• Could mean a lot of Observations - is that useful?
• From the QR instance
• Needs the Q to extract the codes (not in QR)
• Maintains the request structure - eg multiple specimens
• How to manage multiple specimens
• In general, what should be extracted as Observations
• All, or a subset. How to decide?
• Should Observations be extracted for interim reports
• If so, then what is the update strategy for interim -> final
• Should Task be supported for more sophisticated workflow
• Algorithm for updates
• Should Obs only be done on final report? Still have textual for interim
• Invalidate Obs
• Update DR

ACT-NOW data

ACT-NOW data

• CarePlans for regimen / cycle instances
• MedicationAdministration for actual drug given
• MedicationRequest is script

Part 3: API

Getting data in & out

All POC

Security through API Manager

Update

Through transactions, conditional operations, validated

Tightly controlled - only specific users can update

​

Read

Wider use (still controlled)

REST pattern, _include

Custom search operations

Demo

Query page

Part 4: Infrastructure

Architecture details

API, docker components, FHIR server

Deployment

Requestor

Lab

Clinical

Viewer

Clinical Data Platform

Data

API

API

API

Forms

Term

Analytics Platform

Data

Forms Designer

Data

Publish Q

ELT

Other feeds

ACT-Now

API

Log

API

Dashboard

HL7 v2

Components

• Internal components
• FHIR server
• Custom Operations
• Conformance / Forms
• Log
• Dashboard
• External components
• Terminology server
• NHI / HPI
• Analytics
• API Manager
• Participants
• Requester
• Labs
• Act Now source
• Other client

Security

• Assume supplied by Hira as hoster
• Consent
• Through REST API
• ​

Containers

Request - UI after selecting form

Requester: testing the extraction

Containers