More Meaningful Use of CDA: the CDA-FHIR Bridge

1. More Meaningful Use of CDA: the CDA-FHIR Bridge Robert Worden rpworden@me.com

2. Summary • For Meaningful Use of CDA, you may need to compare an incoming CDA with existing information about the patient. • This means matching patient data from the CDA, with data from an EHR • FHIR can be the standard data format for matching and comparing • This requires a three-component architecture • All three components are easy to build • Proof-of-concept implementations exist now • This will encourage adoption of both CDA and FHIR

3. More Meaningful Use of CDA • When reading a CDA, a physician is not just a blank slate for new information. • Often, he or she knows about the patient already. • The physician needs to compare the new information in the CDA with what they already know. • Their knowledge of the patient may be stored in an EHR. • Comparing requires matching of information from the CDA, with information in the EHR: • Match and identify the patient • Match clinical data for the patient (e.g. allergies, medications,..) • Then (possibly) make updates to the EHR, at the physician’s discretion

4. Architecture for CDA Match/Compare Patient Search Parameters • CDA Handler Module: • Extract patient data from CDA • Search and match patients • User chooses the matching patient • Extract clinical information from CDA • Compare with clinical information from application • (User choice of updates to the application) Clinical Application (e.g. EHR) Candidate Matching Patients CDA Selected Matching Patient Patient Clinical Information (Updates to Clinical Information) Few clinical applications support this now.

5. FHIR-enabled CDA Match/Compare User Searches on Patient CDA-FHIR Bridge Search, Match and Display (FHIR client) FHIR adapter for application Clinical Application Patient Resource Candidate Patient resources search CDA FHIR data FHIR Searches on Clinical Resources Searches on Clinical Resources Clinical Resources Clinical Resources (update) (Updates to Clinical Resources) Three components simplify implementation.

6. (1) CDA-FHIR Bridge • Enables any incoming CDA as a small FHIR server • The CDA ‘server’ supports FHIR searches on common resources (Patient, AllergyIntolerance,...) • This is not a full transform from CDA to a FHIR Composition resource; extracting specific FHIR resources is much easier • Transforms depend on CDA templates • There will be a different bridge for each CDA profile • There is no dependence on the EHR application – the bridge is universal for each CDA profile

7. (2) FHIR-Enabling an Existing Application • Initially, read-only; to search for FHIR resources represented in the application. • Done by mapping FHIR to the application’s APIs, or by mapping to the application database • Mapping to a database supports many FHIR searches automatically (by generated SQL) • It is easy to do ( < 1 man-month per resource) • e.g. It is being done for the PAS in an NHS hospital in London (resources: Patient, Appointment,...)

8. (3) Search, Match and Display • An interactive component • Lives in a FHIR-only world (XML or JSON) • Client to 2 or more FHIR servers (CDA, EHR,...) • Functions: • Run searches on all connected FHIR servers • Match and display resources (e.g. in a table) • Allow the user to review, compare, match, take actions: • Patient resource • Clinical resources for the patient • Proof of Concept implementation exists (on Eclipse) • Can be web-based, tablet based • Independent of CDA profiles, or EHR data model (depends only on supported FHIR resources) • Can be universal, configurable

9. Three-Component CDA-FHIR Architecture: Summary • Separation of components makes each one easy to implement: • CDA-FHIR bridge: depends only on CDA profile and FHIR resources supported • FHIR front-end for a clinical application: depends only on the application and the FHIR resources supported • Search, Match and Display: depends only on the FHIR resources supported • Components can be developed and distributed independently • Promotes adoption and competition

10. Supporting Many Clinical Applications FHIR adapter for Application 1 Clinical Application 1 search CDA-FHIR Bridge Search, Match and Display Patient Resource data update CDA Searches on Clinical Resources FHIR adapter for Application 2 Clinical Application 2 search Clinical Resources data update

11. Supporting Several CDA Profiles (e.g. cross-realm) FHIR adapter for Application 1 Clinical Application 1 CDA-FHIR Bridge (CDA Profile 1) search Search, Match and Display CDA Profile 1 data update CDA-FHIR Bridge (CDA Profile 2) FHIR adapter for Application 2 Clinical Application 2 CDA Profile 2 search data update

12. Conclusions • Meaningful Use of CDA requires matching of CDA data with EHR data. • FHIR is a simplestandard format for matching • The 3-component CDA-FHIR architecture is easy to build: • CDA-FHIR bridge (for a few key resources) • FHIR front-end to application (a few key resources) • Search, Match, and Display (pure FHIR, configurable) • This can all be done now • It will promote the adoption of both CDA and FHIR • For more detail, see the white paper from rpworden@me.com