CDS-on-FHIR CONNECT-A-THON 11 IMPLEMENTATION EXPERIENCE

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  Resulted in  Conceptual Metadata Model  Clinical Quality Language  CQIF IG  eCQM FHIR Profile

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

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 ruleswww.opencds.org  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)

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

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”

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

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

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

Questions? Bryn Rhodes – Clinical Quality Framework SME