1. Connect-A-Thon 11 Implementation Experience
CDS-on-FHIR
Connect-A-Thon 11 Implementation Experience

2. S&I Framework Clinical Quality Initiatives
Health eDecisions
Focused on Sharing and Evaluating decision support artifacts
Resulted in
Knowledge Artifact Specification
Decision Support Service R2 & IG
vMR R2 & related Templates
Clinical Quality Framework
Focused on Alignment/Harmonization with Quality Measurement
Conceptual Metadata Model
Clinical Quality Language
CQIF IG
eCQM FHIR Profile

3. Clinical Quality Improvement Framework IG – Goals
Use Case 1: Artifact Structure
DecisionSupportServiceModule and DecisionSupportRule
Library
OrderSet
DocumentationTemplate (profile of Questionnaire)
Use Case 2: Evaluation
DecisionSupportServiceModule/ecrs-cdc-immunizations/$evaluate
API Independence as a primary design goal
Use Case 3: Distribution
Sharing artifact definitions
Discovery of Data Requirements
Module search functionality

4. Connect-a-thon 11 – Use Case 2
Partners Healthcare – Exposed a FHIR endpoint using CQIF resources as an adapter to their production ECRS rule system
Exposed CDC Immunization Guideline Module
University of Utah Health Care – Also Exposed a FHIR endpoint as an adapter
Exposed Colorectal Screening Module using OpenCDS ( – FHIR logical model, flow diagrams, guided rules
Also exposed simple GAO Assessment
Prototype/Example Implementation
Built on Furore’s Spark and FHIR-NET-API
“Echo” implementation
Adapter implementations (for ECRS and CDS-Hooks)

5. ECRS CDC Immunization
Partners Healthcare Exposed a FHIR endpoint but retained their current model
Data is passed to and from the service using “in-line” XML in FHIR parameters
Example implementation was used as an Adapter
Input data was transformed from FHIR – ECRS input
Result was transformed from ECRS Recommendation to FHIR ImmunizationRecommendation in a GuidanceResponse

6. CDS-Hooks Adapter
Example implementation was extended to implement $cds-hook
Defined “cdc-immunization” activity
Expects Patient/Immunziation resources as preFetchData
Repackages Parameters in the format expected by $evaluate
Executes the call to the ECRS-CDC-Immunization Module
Repackages results as a “suggestion card”

7. What worked well?
Able to quickly expose functionality from various sources
Partners Healthcare, University of Utah
Flexible module and API definition enabled multiple scenarios
“Echo” – Quick and dirty plumbing tests
“Adapter” – Marshalling between existing services w/ different information models
“Bridge” – Routing calls between existing FHIR services w/ different operations
FHIR Stack and Tooling enabled rapid development of diverse scenarios
First Class Resources
Much easier to understand and use than the “Basic profiles” in the previous ballot

8. What didn’t work well? Difficulty of managing contained resources
From a development perspective, location of the resource is painful
Difficulty of dealing with extensions
From documentation to development, still painful to deal with extension data
Structures are often verbose and difficult to deal with in Java/C#
Cardinality of elements
Extraneous properties
Constructing resources is often difficult (should be more fluent)
There is some of this, but it should be more prevalent
In general, more helper functions throughout the APIs
For example, accessing parameter values is quite involved

9. Where to next? Interface generation based on profile definitions?
Allows for purpose-built representations of particular structures
Could reduce cardinality where possible
Could make reference location transparent (largely)
Could eliminate difference between extensions and first-class properties
Could be used in both Java and C# implementations

10. Questions? Bryn Rhodes – Clinical Quality Framework SME