FHIR: From Idea to World Wide AdoptionFHIR: The web, for Healthcare Open Community Open Standard •Make it easier to exchange healthcare information •Open Participation - uses web

http://sli.do #HL7Finland

FHIR Tutorial Grahame Grieve

26-Nov 2019

Helsinki


Slides licenced under Creative Commons Public Domain

http://sli.do/

http://sli.do/


FHIR: The web, for Healthcare

Open Community Open Standard

• Make it easier to exchange healthcare information

• Open Participation - uses web infrastructure (social media)

• Lead by HL7 - deeply connected to world wide health community

• Describes how to exchange healthcare information

• A web API - web standards where possible

• Continuity with existing healthcare standards

• Public Treasure (http://hl7.org/fhir)

http://sli.do/

http://hl7.org/fhir


• Based on Web technology

• Open license

• Simple definitions

• Pragmatic, not based on dogma

• Cheap to implement

• Implementable framework for localisation / extensibility

• Suitable for both B2B and C2B

• That’s what we all needed (HL7 is just an open community)

HL7 needed a new direction

http://sli.do/


Freely available

• Known address: http://hl7.org/fhir ( + http://fhir-ru.github.io )

• License: Creative Commons Public Domain (CC0):

• “No Rights Reserved”

• You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission

• The most open of open licenses

• Anyone can do anything with the content

• There can be no disputes about ownership of rights to do anything with the FHIR content

• HL7 waived it’s rights

4

http://sli.do/

http://hl7.org/fhir

http://fhir-ru.github.io/




Trademark Protection

• HL7 has a trademark on “FHIR” and the icon

• ‘Defends’ the trademark enthusiastically

• Fair use (nominative) of the name and icon cannot (and should not) be stopped

• You can use the name or icon in your own product provided:

• You get written permission (http://www.hl7.org/about/product.trademark.application.cfm)

• The name differentiates your product from the FHIR standard

http://sli.do/

http://www.hl7.org/about/product.trademark.application.cfm


• Specification is written for one target audience: implementers

• not just developers

• Rationale, modeling approaches, etc. kept elsewhere

• Multiple reference implementations (C#, Java, Pascal, Swift, Javascript…)

• Publicly available test servers

• Connectathons to verify specification approaches

• Lots of example instances you can read and understand

• Provide solid validation framework

Implementer Focus

6

http://sli.do/


Web APIs are better

• Capability based approach (rather than use case based approach)

• Search is ubiquitous

• Stable identifiers (a struggle?)

• Web framework offers deep well support stack

• Big community

• But FHIR is more than a Web API

http://sli.do/


FHIR – a RESTful API

• RESTful API- based on web/http

• Each record is a “resource” – a URL that can be read, updated etc

• GET [Server]/[ResourceType]/[id] using HTTP • Id – up to 64 chars (letters, numbers, _, .)

• Common features of all resources: • Common metadata

• A human-readable XHTML summary

• A set of defined common data elements

• An extensibility framework

• Represented as either XML or JSON (or RDF)

8 AMIA 2019 Annual Symposium | amia.org

http://sli.do/


http://sli.do/


Use POSTman


http://sli.do/


• Create = POST https://example.com/path/{resourceType}

• Read = GET https://example.com/path/{resourceType}/{id}

• Update = PUT https://example.com/path/{resourceType}/{id}

• Delete = DELETE https://example.com/path/{resourceType}/{id}

• Search = GET https://example.com/path/{resourceType}?search parameters...

• History = GET https://example.com/path/{resourceType}/{id}/_history

• Transaction/Batch = POST https://example.com/path/ (POST a transaction bundle to the system)

• Operation = GET https://example.com/path/{resourceType}/{id}/${opname}

11

http://sli.do/


Reading a Resource

GET /Patient/glossy?_format=xml HTTP/1.1

Host: example.com

Accept: application/xml+fhir

Cache-Control: no-cache

12

http://sli.do/


Read response

HTTP/1.1 200 OK

Content-Length: 729

Content-Type: application/xml+fhir

Last-Modified: Sun, 17 Aug 2014 15:43:30 GMT

ETag: "1"

<?xml version="1.0" encoding="UTF-8"?>

<Patient xmlns="http://hl7.org/fhir">

<id value="347"/>

<meta>

<versionId value="1"/>

<lastUpdated value="2014-08-18T01:43:30Z"/>

</meta>



</Patient>

13

http://sli.do/


Exploring Reading Resources

• Use “_summary” to reduce what is returned

• Use “_elements” to control what is returned


http://sli.do/


Update Request

PUT /Patient/glossy HTTP/1.1

Host: example.com

Content-Type: application/json+fhir

Content-Length: 1435

Accept: application/json+fhir

{

"resourceType": "Patient",

"id" : "347",

"meta" : {

"versionId" : "1",

"lastUpdated" : "2014-08-18T01:43:30Z"

}

15

http://sli.do/


Update Response

HTTP/1.1 200 OK

Content-Length: 161


Date: Mon, 18 Aug 2014 01:43:30 GMT

ETag: "2"

{

"resourceType": "OperationOutcome",

"text": {

"status": "generated",

"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">The operation was successful</div>"

}

}

16

http://sli.do/


Creating a resource

POST {some base path}/Patient HTTP/1.1

Authorization: Bearer 37CC0B0E-C15B-4578-9AC1-D83DCED2B2F9

Accept: application/json+fhir


Content-Length: 1198

{

"resourceType": "Patient",

...

}

17

http://sli.do/


Server Response

HTTP/1.1 201 Created

Content-Length: 161


Date: Mon, 18 Aug 2014 01:43:30 GMT

ETag: "1"

Location: http://example.com/Patient/347

{


"text": {


"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">The operation was successful</div>"

}

}

18

http://sli.do/


Server Failure

HTTP/1.1 422 Unprocessable Entity

Content-Length: 161


Date: Mon, 18 Aug 2014 01:43:30 GMT

{


"text": {


"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">MRN conflict

- the MRN 123456 is already assigned to a different patient</div>"

},

}

19

http://sli.do/


Search Request

GET [base]/Patient?name=henry

20

http://sli.do/


{

"resourceType": "Bundle",

"id" : "eceb4882-5c7e-4ca4-af62-995dfb8cef01"

"meta" : {

"lastUpdated" : "2014-08-19T15:43:30Z"

},

"type" : "searchSet",

"base": "http://example.com/base",

"total": "3",

"link": [

{

"relation" : "next",

"url" :

"https://example.com/base/MedicationPrescription?patient=347&searchI

d=ff15fd40-ff71-4b48-b366-09c706bed9d0&page=2"

}, {

"relation" : "self",

"url" :

"https://example.com/base/MedicationPrescription?patient=347"

}

],

21

http://sli.do/


"entry": [

{

"resource" : {

"resourceType": "MedicationPrescription",

"id" : "3123",

"meta" : {

"versionId" : "1",

"lastUpdated" : "2014-08-16T05:31:17Z"

},

... content of resource ...

},

},

... 2 additional resources ....

]

}

22

http://sli.do/


Search Parameters

http://sli.do/


Search

• Explore the mimic patients using POSTman…

• Note – no names / phone numbers / addresses

• Other sample Searches (all http://mimic.fhir.org/r3)

• Encounter

• http://mimic.fhir.org/r3/Condition?code=038.9&_include=Condition:patient

• Observation?code=600-7&subject=Patient/9467

• Observation?code=2708-6&subject=Patient/30831


http://sli.do/


Capability Statement

• GET [base]/metadata

• Capability statement defines everything that a server can do

• considered in detail later

http://sli.do/

http://sli.do #HL7Finland 26 AMIA 2019 Annual Symposium | amia.org

http://sli.do/


Server

• Terminology Server

• Conformance Server

• Document / Clinical Repository

• Middleware service

• EHR etc

• Decision Support provider

• Master Patient Index

• Client

• Conformance Workbench

• Administration/Billing

• Clinical Information System

• CIS plug-in (e.g. CDS)

• Data Analytics

• Patient Portal / Aggregator

• Form / Referral Initiator

Common Application Roles

http://sli.do/


Clinical Findings

Laboratory Results Blood panels such as CBC with Differential, Liver Panel, etc)

DiagnosticReport with Observations

Imaging Study Findings CT Scans, MRI, Plain Radiographs, Ultrasounds)

DiagnosticReport (some withObservations)

Diagnostic Test Results EKG, pulmonary function test, EEG) Observations (and maybe aDiagnosticReport)

Vital Signs Temperature, Blood Pressure, Heart Rate, Respiratory Rate)

Observation

Other Physical Exam Findings

Auscultation findings) Observation

Pulmonary Artery Catheter readings

Pulmonary artery pressure) Observation

Patient Problems, Allergies and Adverse Events

Allergy Food or drug allergies AllergyIntolerance

Clinical Diagnosis Diabetes, Congestive Heart Failure Condition

Adverse Event / Reaction Adverse reaction to an agent, falls, adverse surgical events, hospital infections

AdverseEvent

Patient Clinical Summary

http://sli.do/


Patient History

Chief Complaint Cough, Pain, Fever, Fatigue Condition

Past Surgical History Appendectomy, Hernia repair Procedure

Past Medical History Diabetes, Congestive heart failure Condition

MAR (Medication Administration Record)

Warfarin 5mg PO administered on 12/10/2013 at 3pm

MedicationAdministration

Home Meds Warfarin 5mg, 30 day supply, dispensed on 12/01/2013

MedicationStatement

Social History Sexual behavior, Smoking status, Alcohol intake, Illicit drug use

Observation

Family History Mother has diabetes FamilyMemberHistory

Signs & Symptoms from a review of systems- Pain, Fever Condition

Interdisciplinary Care Planning

Patient Goal Reduce risk of falls, lose weight Goal (as part of a CarePlan)

Intervention Patient assessments ProcedureRequest

Patient Clinical Summary (2)

http://sli.do/


MedicationRequest An order for both supply of the medication and the instructions for administration of the medicine to a patient.

MedicationDispense Provision of a supply of a medication with the intention that it is subsequently consumed by a patient (usually in response to a prescription).

MedicationAdministration When a patient actually consumes a medicine, or it is otherwise administered to them

MedicationStatement This is a record of medication being taken by a patient, or that the medication has been given to a patient where the record is the result of a report from the patient, or another clinician. A medication statement is not a part of the prescribe->dispense->administer sequence but is a report that such a sequence (or at least a part of it) did take place resulting in a belief that the patient has received a particular medication.

Medications

http://sli.do/


Security in FHIR

• Communications Security – SHOULD use TLS/SSL

• Authentication - Any way desired. OAuth recommended

• Authorization/Access Control – RBAC/ABAC as appropriate. Security Labels!

• Audit - provenance and audit event for tracking origins, authorship, history, status and access

• Digital Signatures - FHIR includes several specifically reserved locations for digital signatures

• Data Management Policies – You’ll need some

• Attachments, Narrative – possible attack surfaces - beware

http://sli.do/

http://hl7-fhir.github.io/provenance.html

http://hl7-fhir.github.io/auditevent.html


http://sli.do/


Security Labels

• Tag resources with specific instructions:

• Still need an access control engine

http://sli.do/


SMART on FHIR

• A framework for extending clinical applications

• http://docs.smarthealthit.org/

• Profile on OAuth + openID Connect (Aligned with industry usage, but thoroughly checked for security)

• Add launch context + other integration (styles, sessions, scopes)

• Suitable for human mediated interoperability

• Also has a back end system to system interfaces

http://sli.do/


Using FHIR for Personal Access

• Put up FHIR end-point that requires OAuth token

• User decides what access application should have

• OAuth Token can be tied to System User or Patient • In USA: cannot charge for patient token

• Applications must be registered (security protocol) • Contention about trust / control over applications

• (demonstration)

• Read-only access to Patient Clinical summary

http://sli.do/



• Interface specified by Smart App Launch http://hl7.org/fhir/smart-app-launch

• Content rules specified by Argonaut http://www.fhir.org/guides/argonaut/r2/

• Then adopted as US national standard https://www.hl7.org/fhir/us/core/

• International Adaptation https://build.fhir.org/ig/grahamegrieve/ipa-candidate/

http://sli.do/

http://hl7.org/fhir/smart-app-launch





http://www.fhir.org/guides/argonaut/r2/

https://www.hl7.org/fhir/us/core/

https://build.fhir.org/ig/grahamegrieve/ipa-candidate/





• Data doesn’t change lives, Services change lives

• Access to record is an infrastructure enabler • The benefit is when patient becomes natively part of the clinical process

• So: • Don’t use a government proxy record

• impose central risk averse policies on all interactions

• Get between provider and consumer of healthcare services

• Do use a national authentication service

• Do provide a national directory service to handle application registration

• Consider using a national Consent service

http://sli.do/


http://sli.do/


• No central authorities

• Permutation of biological and sociological complexity

• Fractal use cases

• Economics favours balkinisation

• Externalizing complexity

• Much confusion about the problem

Problems we face with Consensus

39

http://sli.do/


http://sli.do/


http://sli.do/


http://sli.do/


http://sli.do/


• W3C rules: must interoperate without extensions – but this is not possible in healthcare

• A Choice

• design for absolutely everything

• or allow extensions

• FHIR has a standard extension framework - every FHIR element can be extended

• Every extension has:

• Reference to a computable definition

• Value – from a set of known types

• Every system can read, write, store, validate and exchange all legal extensions

Extensions

http://sli.do/


• Extensions are not a silver bullet

• FHIR has a sliding scale governance for extensions

• Local Projects

• Domain standards (e.g. Best Practice Cardiology)

• National Standards (e.g. Standard Russian Extensions)

• HL7 published extensions (corner cases with international scope)

Governing Extensions

http://sli.do/


FHIR is a platform specification

• Most users will be mandated to use it

• FHIR shouldn’t force them to change non-IT behaviour • Though it should support them if they do

• FHIR is a framework for standards • A proto-standard, a meta-standard • Defines capabilities and common framework

• Additional work is needed to define actual standards • Combine requirements, solutions and FHIR capabilities • “Implementation Guide”

http://sli.do/


The 3 Legs of the process

• Platform Standard

• HL7, FHIR

• Adapting to a Community of Use

• Affiliates (HL7 Russia), Argonaut, IHE, ONC

• “FHIR Community Process”

• Driving into production

• Regulation, Vendor Consortiums, NHS(X), HIMSS

• Where the action & challenges are

http://sli.do/


• Use Case 1: Access to Data (e.g. Personal Health Repository)

• I want to get data from multiple systems, and display it to a user

• Not much content agreement necessary (FHIR out of the box)

• Use Case 2: Business Workflow Implementation

• I want to do ordering/reporting between clinical and diagnostic systems

• Workflow / business practice agreements needed (IG)

• Use Case 3: Shared Clinical Solutions

• I want to run the same code as a plug-in to multiple systems

• Extensive clinical agreements needed (IG on steroids)

Do you need Implementation Guides?

http://sli.do/


• A package that describes how an application does or should work, with both:

• Human readable documentation

• Computer Processible Specifications

• Specifies:

• API or other exchange method features & Security

• Rules for Resource Contents

• Details about Terminology usage

• Mappings to other specifications / terminologies

• Business Processes

Implementation Guide

http://sli.do/


Capability Statement

• Can be used for:

• Stating how a specific system instance behaves

• Defining how a software system is capable of behaving (including configuration options)

• Identifying a desired set of behavior (e.g. RFP)

• To declare itself “FHIR Conformant”, a server must respond to \metadata with a CapabilityStatement defining it’s functionality

50

http://sli.do/


StructureDefinition

• Document a resource structure

• What it has in it

• How it’s used

• Aka Profile, Template, Clinical Model

• Defined as a resource (defines itself)

• All definitions provided as part of the spec

51

http://sli.do/


What profiles can do

• Restrict cardinality, including to 0..0

• Fix the value of something, or constrain to a pattern

• Make invariants (rules that must be true)

• Restrict the types (if multiple are allowed)

• Require a type or reference to conform to a profile

• Bind to a different terminology

• Provide additional definitions, usage notes etc

• Provide more specific or additional mappings

• Make rules about must-support

http://sli.do/


What profiles can’t do

• Profiles cannot break the rules established in the base specification (e.g. cardinality as described above)

• Profiles cannot specify default values or meanings for elements

• Profiles cannot give more specific names to elements

• It must be safe to process a resource without knowing the profile

http://sli.do/


Using Profiles

• You can just go ahead and use a resource

• No need for a profile

• But you can write a profile

• Document your usage in detail for partners

• You can mark a resource with a profile

• It’s just a claim – can test conformance with that

• Denormalization for performance

54

http://sli.do/


Terminology Sub-system

• SNOMED CT / LOINC / RxNORM

• HGVS, ICPC, MIMS + 100s more

• ICD-X+

• ANZSCO, METEOR

• A drug formulary

• A config table in an application

• A list of enums in a java class

• Australian state codes

Code System: Defines a set of concepts with a

coherent meaning

Code Display

Definition

http://sli.do/


Code System Resource

• Meant for simple small code systems (<50k codes ?)

• Crop up all over the place

• Need a really easy way to handle them

• Not intended for big /broad systems (LOINC, SNOMED CT etc)

• They all have their own distributions, tailored to their requirements

• Defines Properties, Filters, Concepts

• For each concept:

• Code, display

• Designations

• Properties

http://sli.do/



Value Set: A selection of a set of codes for

use in a particular context


coherent meaning

Code Display

Definition

http://sli.do/




coherent meaning

Code Display

Definition

Element Definition: Type and Value set reference

Value Set: A selection of a set of codes for

use in a particular context

Binds

Element: code/

Coding/ CodeableConcept

Conforms

http://sli.do/


Referring to a code system

Each “use of a code” (a reference into a code system) has 4 properties:

• system: URL of the code system

• version: stated version of the code system (optional)

• code: the symbol defined for the concept (code/expression)

• display: a human readable representation of the concept (optional – debugging/display)

http://sli.do/


• Code: "status" : "confirmed"

• Coding: { "system": "http://www.nlm.nih.gov/research/umls/rxnorm",

"code": "C3214954",

"display": "cashew nut allergenic extract Injectable"

}

• CodeableConcept: { "coding": [{

"system": "http://snomed.info/sct",

"code": "39579001",

"display": "Anaphylactic reaction“

}],

"text" : "Anaphylaxis"

}

Examples

http://sli.do/


Terminology Service

• There’s lots of power & complexity in the terminology sub-system

• Needs specialist knowledge (decades of investment)

• Most software just wants to use simple operations that hide the complexity

• FHIR defines a terminology service to make this possible: • $expand – get a list of codes in a value set

• $validate-code – check that the coding is valid against a value set

• $subsumes – find out whether one code is subsumed by another

• $translate – convert from one code system to another (e.g. ICD-10 -> Snomed CT)

• $closure – build a search table for integrated search

http://sli.do/


Architecture

• Standalone FHIR Server

• A FHIR Server in front of an existing application (e.g. SQL) • FHIR as front end to an XDS server (“MHD”)

• An interface engine that ‘speaks’ FHIR

• A tablet/mobile phone application

• Web portal uses FHIR to access other systems

• A healthcare application that access information from multiple systems as well as it’s own server

• Smart-On-FHIR – an EHR plug-in framework

62

http://sli.do/


Should you Persist FHIR Resources?

• If your requirements are tightly managed (e.g. approved changes annually) • Typical of heavy-iron Enterprise Information Systems

• Relational schemas are magically efficient compared to storing resources (general format)

• But don’t underestimate REST stack tooling

• If you encounter requirements with little warning (e.g. days/weeks) • Typical of Clinical Data Repositories

• Storing resources is robust and resilient – FHIR caters for everything (extensions)

• Most systems are somewhere between these extremes • It’s an engineering trade-off

• Hybrid systems are not uncommon – store everything as resources, pull out the things that matter for performance / control

63

http://sli.do/


Multiple releases of FHIR

• We make multiple releases of FHIR (working on R5 now)

• Over time, we change things – make breaking changes

• It would be better if we got it right first time

• But it’s better to fix things when we don’t

• Maturity rating reflects our process – change slows down over time

• No changes to normative content (some in R4)

• In the mean time, we support multiple versions…

http://sli.do/


Full release history

• http://hl7.org/fhir/directory.html

• Or http://hl7.org/fhir/package-list.json

http://sli.do/

http://hl7.org/fhir/directory.html

http://hl7.org/fhir/package-list.json




Supporting Multiple Versions

• Converting between versions

• API Strategy

• Persistence Strategy

• Documentation Strategy

http://sli.do/


Converting between versions

• R3 Diff: http://hl7.org/fhir/diff.html

http://sli.do/


Converting between versions

• R3/R4 Transform:

http://sli.do/


Java Converter

• Only supported fully for conformance resources

• Contributions for other resources are welcome

http://sli.do/


Version independent logic

• Use a façade in front of versions e.g. IPatient = interface (IDomainResource) {

IHumanName getNameI();

}

R3.Patient = class (DomainResource, IPatient) {

public HumanName getName() {…}

public IHumanName getNameI() {…}

}

• This is a lot of work, but partially done in some reference implementations – you can contribute

http://sli.do/


Resource Conversion isn’t everything

• GET [base]/Patient/[id]?(params) Accept: [content-type]

• HTTP 200 OK Content-Type: [content-type] { … body …}

• The entire exchange has a version (can’t mix with one exception)

http://sli.do/


Simplest Approach: multiple end-points

• http://test.fhir.org/r2



• fhirVersion element in the applicable CapabilityStatement applies

• Pro: Simple

• Con: Logical records get multiple URLs

http://sli.do/

http://test.fhir.org/r2


http://build.fhir.org/capabilitystatement-definitions.htmlCapabilityStatement.fhirVersion

http://build.fhir.org/capabilitystatement-definitions.html


Single end-point, multiple versions

• http://test.fhir.org/rX

• The fhirVersion parameter on the MIME-type that applies to the resource (but fixes the whole exchange) GET [base]/metadata

Accept: application/fhir+json; fhirVersion=4.0

http://sli.do/

http://build.fhir.org/http.html#version-parameter




Determining Server Versions

GET [base]/$versions

Accept: application/fhir+json

[other headers]

"resourceType": "Parameters",

"parameter": [{

"name": "version",

"valueString": "3.0"

}, {

"name": "version",


}, {

"name": "default",


}]

http://sli.do/


Determining Server Versions

GET [base]/$versions

Accept: application/json

[other headers]

{

"versions": ["3.0", "4.0"],

"default" : "4.0"

}

http://sli.do/


Single end-point, multiple versions

• Server specifies what versions it supports, with a default

• Client chooses a version using the fhirVersion parameter

• Fixes the whole exchange

• Conversion information for resource names and search parameters: https://github.com/FHIR/interversion/tree/master/package

http://sli.do/




https://github.com/FHIR/interversion/tree/master/package


$convert

• Ask server to convert versions

http://sli.do/


Non-API Exchange

• There’s almost always a mime type: application/fhir+json; fhirVersion=4.0

• If that’s not possible: "meta" : {

"profile" : ["http://hl7.org/fhir/4.0/StructureDefinition/Patient"]

}

http://sli.do/


Persisting Multiple versions

• Store Resources with known version (implicit, or explicit)

• Use the profile marker if you really need to

http://sli.do/


Persistence and Conversion

In general 3 options:

• Store resources as you get them (and convert on the fly if needed)

• Store resources in your preferred version (and convert if needed)

• Extract information from resources and store in (relational?) database

Or… Do all 3 things at once:

• Store resources as you first received them (for audit trail)

• Store resources in your preferred version (for flexibility)

• Build specific tables for particular indexing (for performance)

http://sli.do/


Documentation Strategy

• Simple: Different documentation for different versions • Multiple repetitions of narrative

• Implementers have to compare between versions

• Complex: One set of documentation, with different profiles/examples • One combined narrative with explicit differentiation

• Implementers explicitly deal in multiple versions

• Which is better depends on the implementers

• Do the business rules differ? What about documentation versions?

http://sli.do/


Living with v2 and CDA

• V2 and CDA are in extensive use around the world • And in Finland

• Organizations are using FHIR in new interfaces, leaving existing interfaces in place • FHIR can – and eventually will – replace both. But no hurry

• Privacy / Security will drive the eventual change

http://sli.do/


Co-existing with V2

• Need to receive v2 feed into FHIR Repository • Convert content from v2 to FHIR resources (Segments ~ Resources)

• Handle transaction semantics (hard)

• Need to generate v2 feed from FHIR Repository • Reverse of problem

• New Subscription re-work addresses big gap

http://sli.do/


v2 Problem Statement

• Commit a v2 message to a FHIR repository

• E.g perform a transaction • Process Message Header

• Create / Update Patient, Encounter

• Process other segments

http://sli.do/


v2 Challenges

• Create vs update appears through the problem (& permutates)

• Update business rules can be significant complex

• |""| - can be very difficult to manage (specially for repeating fields)

• Implicit patterns in OBX sequences can be very difficult to manage

• Many identifiers are local – need to be made global

http://sli.do/


Co-existing with CDA

• CDA/XDS repository (regional/national systems)

• Problem: reading lists of documents is inefficient

• Use FHIR to access PDF/CDA documents more easily • IHE MHD

• Use FHIR to make contents of documents available read-only • Assumes that you have sufficient control over documents

• Record identifiers, variance on document content, lack of clinical agreements

• Use FHIR to commit to CDA Document Store • Just a really bad idea

http://sli.do/


CDA Problem Statement

• Convert Clinical Document to a bundle of resources (or set)

• Output: • Composition

• Patient

• Practitioner

• Sections + linked resources

http://sli.do/


CDA Challenges

• Mapping from Section content to Resource

• Resource Type depends on classCode, moodCode & context

• Or may be indeterminate

• Mapping from statusCode may be incomplete

• GTS Timing particularly difficult

• Resolution of record identities / snapshot reconciliation may be difficult or impossible

http://sli.do/


Basic Rule of thumb

• 90% of elements are simple 1:1 mappings

• 99% of elements involve restructuring / conditional logic • E.g. a list of coded elements to a set of named fields (or vice versa)

• May depend on implicit semantics of coded values

• Last 1% very hard (potentially very hard indeed) • Need specific logic to manage restructuring

• Examples: restructuring implicit OBX trees

http://sli.do/


Goals

• Do not add to the complexity of the problem

• Be complex enough to meet requirements • Depends on how much you’re trying to do

• Be fast enough (?)

• Move mapping from being a solitary activity • E.g. make mappings portable – do not depend on specific features of

implementing system

http://sli.do/


First principles

• Most data being transformed is a Directed Acyclic Graph (= tree) • Root element has an arbitrary name

• Elements have a primitive value and/or a set of named child Elements

• Elements have a named type that controls their ‘value domain’

• Elements have an assigned cardinality m..n (0..1, 0..*)

• Structures are different because: • Variable use of named properties vs coded repeats

• Design driven by underlying ‘reference model’

• Original understanding of requirements different

• Expression of information is fractal

http://sli.do/


Types of Mappings

• Skeletal Mappings • Map the class backbones – pointers about the relationships

• Concept Mappings • Map all the elements in the class model

• Detailed Mappings • Map all the elements, down to primitive types

• Executable Mappings • Describe conversions for all domain values, all special cases

http://sli.do/


Code

• Everybody’s default option: programming language (or XSLT) • Transforming data is application #1 for all languages

• Meets Complexity requirements

• Skills are always at hand

• Fast to execute

• So why not just use code? • Choice of language (/platform) variable

• Code depends on external facilities – so not portable

• Code is compiled, subject to deployment restrictions

• Work does not need programmers (more $$$)

http://sli.do/


Table Mapping forms

• Some form of column based table (spreadsheet, database)

• A very obvious thing to do

• Handles the 90% well (complements the code approach)

• Maps well between elements when • names are different

• Value domains are very similar or assumed to be so (context dependent)

• Rapidly gets complicated for the other 10% • Frequently encounter sophisticated implied language in the columns

http://sli.do/


https://docs.google.com/spreadsheets/d/13pgda5xl-PwCgB9j0axyymwwv7RJVcrIzY8Ah1y1Y1M/edit#gid=0

http://sli.do/


http://sli.do/


Table Mappings: Limitations

• Table mappings are a very convenient way to approach the problem • Work very well for the 90% easy elements

• Implicit grammar gets out of control for the next 9%

• Can’t address the last 1%

• Can’t automate the transform based on this information

• So this is documentation to support code • (or maybe called from code)

• Corresponds (roughly) to ConceptMap – element mapping in concept

http://sli.do/


Concept Map

http://sli.do/


Table Mapping Approach

• Need to reflect this formally as a FHIR resource • Goal: Make mapping a community activity

• Use ConceptMap for now – needs work

http://sli.do/


FHIR Mapping Language

• Principles

http://sli.do/


Design Features

• Describe transform from one instance to another where instances are trees of elements

• Describe one way transforms

• Statements of relationship • no procedural features - supports meta analysis

• Structure/hierarchy based • e.g. support graphical transform builders

• Modular to allow re-use

• Can use types where they are present, but does not depend on them

http://sli.do/


Resource StructureMap

• A resource like all others

• Has the same metadata as other conformance resources

• Defined content is the abstract syntax tree for the mapping language • Technically, that’s another concrete syntax

• Recommended narrative is the mapping language

• Tools can interconvert between the forms (FHIR Validator)

• http://test.fhir.org/r3+ supports text format

http://sli.do/



http://sli.do/


Fields with Different Names

http://sli.do/


http://sli.do/


Examples

• FHIR Version Transforms: • http://hl7.org/fhir/r3maps.html

• https://github.com/FHIR/interversion - ongoing

• Prototype CDA Maps: • https://build.fhir.org/ig/HL7/fhir-cda

• https://github.com/jduteau/ccda-to-fhir-maps

http://sli.do/

http://hl7.org/fhir/r3maps.html

https://github.com/FHIR/interversion

https://build.fhir.org/ig/HL7/fhir-cda/



https://github.com/jduteau/ccda-to-fhir-maps








Mapping Language

• Very Portable

• Total ban on Procedural Code is conceptually challenging • Allows for Meta-analysis

• Adoption is very slow – but real

• Key feature: the API

http://sli.do/


Mapping Language API

• ValueSet validation operation

• Translation operation

• Lookup another tree of data

• Create an instance tree

• Return the correct string format to refer to a tree (input or output)

• This is what creates the portability

http://sli.do/


Javascript Sandbox

• Proposal – Documentation: • https://github.com/FHIR/interversion/blob/master/engine/readme.md

• Standard sandbox that can be implemented by any application. E.g. • Integrated engine inside interface engine

• Canned Lambda function

• In any clinical application

• Requires a standard Javascript engine

http://sli.do/

https://github.com/FHIR/interversion/blob/master/engine/readme.md

https://github.com/FHIR/interversion/blob/master/engine/readme.md


Sandbox Entry Point

function convert(services, object, api) {

}

Parameters:

• services: an object that makes conversion/transformation services available to the script - see below for documentation

• object: the source object being converted

• api: a FHIR Client - provides direct access to the FHIR persistence store, pre-authorized

http://sli.do/


Sandbox Services - Terminology

function lookup(coded, params) : Parameters;

function translate(conceptMap, code, params) : Parameters;

function expand(valueSet, params) : ValueSet;

function validateVS(valueSet, coded, params) : Parameters;

function validateCS(codeSystem, coded, params) : Parameters;

function subsumes(system, coded1, coded2) : code;

function translateCode(code, srcSystem, dstSystem) : String;

http://sli.do/


Sandbox Services - Conversion

function factory(typeName) : Object;

function runJS(scriptName, routineName, params....) : Object | void;

function runMap(url, source[, target], callBacks...)

function runLiquid(fileName, source, type[, format]) : Object;

function runMarkdown(fileName, source) : Object;

function translateUri((value, type)) : String;

function translateDate(date, srcFmt, dstFmt) : String;

Other – MDMI? QVT? XSLT?

http://sli.do/


Example

// for use with ADT_A01 message

function convert(services, object, api) {

// first step: process the patient

var pid = object.segment[2];

var patid = pid.field[3].element[1].text;

// or it could be: patid = pid.q('field[3].element.where(component[5] = "MR")').text;

var pat = api.read('Patient', patid, patid); // assuming that we store patients with MYN as

master

if (pat == null)

pat = makePatient(services, pid, api);

else

updatePatient(pat, pid, api);

// now: process the encounter

}

http://sli.do/


Example

function makePatient(services, pid, api, patid) {

// use a liquid script to make the patient resource

var pat = services.liquid("pid.liquid", pid, "Patient", "json");

// doing this in the code here rather than the liquid script is a design choice;

// the id might not always be the same, or setting it in the liquid template might

//make the liquid template less reusable

pat.id = patid;

return api.update(pat);

}

http://sli.do/


Methods for Transforming content

• Work in progress

• None of the options are perfect (yet)

• Need to focus on making it a community approach • Not a solitary obsession

http://sli.do/


GraphQL

• FHIR Has a well described modular schema + CRUD Operations

• Client applications built against the API

• User interface applications require a set of resources

• To build a view e.g. List of encounters • For each encounter, fetch the patient to get their name

• For each encounter, fetch the consulting physician to get their name

• For each encounter, fetch the ward location to get it’s name

• etc

• Similar for almost every operation

http://sli.do/


Getting a set of resources (1)

• Fetch the encounters

• Iterate the encounters fetching the related resources

• Cache up local copies of fetched resources

• Price: bandwidth, latency * N, cache management

http://sli.do/


Getting a set of resources (2)

• Fetch the encounters

• Use _include to fetch the related resources

• Price: bandwidth (up), latency * 1 (down)

http://sli.do/


Getting a set of resources: ideal

• Just fetch what you want to display:

• Fetch the elements from encounter that you want to display

• Get the server to replace the links to the other resources with your choice of display for them

• No work on the client…

• Price: bandwidth (down), latency * 1

http://sli.do/


GraphQL

• A language to tell the server what you want

• Query against the graph of resources it has

• Get just the structure you want returned

http://sli.do/


Simple GraphQL example

{ name { text given family }

}

{

"data" : {

"name":[{

"given":["Peter","James"],

"family":"Chalmers"

},{

"given":["Jim"]

},{


"family":"Windsor"

}]

}}

[base]/Patient/example/$graphql?query={name{text,given,family}}

http://sli.do/


Polymorphic Fields

{

valueQuantity { value unit }

}

{

"data" : {

"valueQuantity":{

"value":185,

"unit":"lbs"

}

}

}

http://sli.do/


Lists

• fhirpath - a FHIRPath statement selecting which of the subnodes is to be included

• [field] - the name of a sub-property with a specified value that must be matched for the field to be included

• _offset - specify the offset to start at for a repeating element (see below)

• _count - specify how many to elements to return from a repeating list

http://sli.do/


Polymorphic Fields

{

name(use: official)

{ text given family

myext: extension(url: "[url]")

{ value : valueString }

}

}

{

"data" : {

"name":[{


"family":"Chalmers"

}],

"myext" : {

"value" : "some value"

}

}

}

http://sli.do/


Lists

{

name(fhirpath: "family.exists()")

{ text given family }

}

{

"data" :

{

"name":[{


"family":"Chalmers"

},{


"family":"Windsor"

}]

}}

http://sli.do/


References

• { resource } – walk into the target of a resource • Optional – return an error if not resolvable

• Type selector – specify type of target (always required, may be parameter)

• Can also search on reverse references, and add other resources that refer to the focus resource

http://sli.do/


Lists

{

subject {

resource {

...on Patient {

birthDate

}

}

}

code {coding {system code} }

}

{

"data" : {

"subject":{

"resource":{

"birthDate":"1974-12-25"

}

},

"code":{

"coding":[{

"system":"http://loinc.org",

"code":"29463-7"

}

...

http://sli.do/


Managing a list of Resources

• On the server root, or an a particular resource

• By search parameter

• 2 forms: • List: Simple

• Connection: Complex - With cursors

http://sli.do/


Simple GraphQL example

{ Patient(id: example)

{ id, active }

}

{

"data" : {

"Patient" {

"id" : "example",

"active" : "true",

}

}

}

[base]/$graphql?query={Patient(id:example){id,name{given,family}}}

http://sli.do/


Search / List

{

ConditionList

(clinical_status: relapse,

patient: example)

{ id, clinicalStatus }

}

{

"data" : {

"ConditionList" : [{

"id" : "100",

"clinicalStatus" : "relapse"

},{

"id" : "100",

"clinicalStatus" : "relapse"

}]

}

}

http://sli.do/


Search / List

{

ConditionConnection

(clinical_status: active,

patient: example) {

count offset pagesize

edges {

mode, score, resource

{ id, active }

}

first previous next last

}

}

{

"data" : {

"ConditionConnection" : {

"count": 50,

"offset" : 0,

"pageSize" : 25,

"next" : "45f9ada8-db37-4498-ba7d…:3"

"edges" : [{

"resource" : {

"id" : "100",

"clinicalStatus" : "relapse",

}

}…

http://sli.do/


Flattening

• Drop spacer nodes

• Break Lists up

http://sli.do/


Flattening

{

identifier @flatten

{ system value }

active

name @flatten

{ text given family }

}

{

"data" : {

"system":["[urn]"],

"value":["12345"],

"active":true,


"family":["Chalmers","Windsor"]

}

}

http://sli.do/


Test Cases

• Found in FHIR test Suite https://github.com/FHIR/fhir-test-cases

• r5\graphql\manifest.xml – deep tests cases for graphql engine

• r5\graphql\server-tests.json – test the graphQL API

http://sli.do/

https://github.com/FHIR/fhir-test-cases






GraphQL

• Powerful tool for client to reshape data to suit their own purposes

• May be particularly relevant where data is passed to analysis tools

• Supported by • test.fhir.org

• HAPI

• Assymetrik

• Others ?

http://sli.do/


Our Goals

• Disrupt Healthcare IT Standards

• Disrupt Healthcare IT

• Disrupt Healthcare

• Not about commercial outcomes

http://sli.do/


• Data / narrative dynamic exists throughout the clinical process

• All resources carry an xhtml representation of their content • Clinical safety issue: fall back option if the system is not sure it fully understands the content

• It is not mandatory, but SHOULD be present

• In a closed eco-system, with extremely tight control and strong conformance testing, it may not be necessary • But things often change over time

• So using narrative may save a lot of money downstream from the author

• Limited XHTML – security and safety concerns

Human Readable

http://sli.do/


Overall Progress

http://sli.do/


Disrupting Healthcare IT Standards

• Move to open source / open process

• Move to Agile systems

• Much more focus on implementation success

• Reduce the economic comfort of the SDOs

• Finished….

http://sli.do/


Disrupting Healthcare IT

• Empower applications to offer more functionality at less cost

• Drive implementations towards interoperability as core

• Use cloud / web changes to allow modular software • Best of Breed

• Open source drives change in market

• In progress…

http://sli.do/


Shallow vs Deep Interoperability

• Integration points on the perimeter:

• Integration Points part of the system:

http://sli.do/


Where adoption is happening

• Secondary Data Repositories • Patient access to data

• Specific Clinical Data Repositories -> Big Data

• National Health Records / Sharing frameworks

• Application Extension • Argonaut / EHR Plug-ins / Decision Support Integration

• Primary Apps: SaaS (health)

• Business Process Automation • Meds mgmt, Payments, Diagnostics, supply chains

http://sli.do/


National Adoption around the world

• USA • Argonaut / Patient Access to Data

• Da Vinci: refactor the payment process

• CMS / CDA: many projects around adoption

• Europe • UK, Netherlands, Germany, Scandinavia, Lithuania

• Others • Australia, Russia…

http://sli.do/


Limits Of Clinical Interoperability

• The dream: fully standardized

content

• ~100,000k care providers,

no(?) interest in standards

• Requires consistent

configuration, work practices

• HL7 standardizes exchanges

• ~1000 vendors understand

how standards work

• Highly configurable systems

- limit what can be

standardized

It’s not a Technology Problem

http://sli.do/


Innovation Strategy

• Get engaged early • Wear the risk of unstable interfaces & ongoing change • Expose your IP to the wider community (open process) • Influence the outcome (standard more naturally fits your goals) • Demonstrate your expertise

• Get engaged late • No (or much lower) risk of ongoing change • No need to engage with the community • No influence and not reputation

• Pace of change is changing…

http://sli.do/


Future Plans

• Make existing content normative (finished, stable)

• Round out specification (EBM, Research, Translational Science) • + work on related specifications – imaging, social media, etc

• Consolidate implementation eco-system + Community Process

• Build out country support (multi-language support)

• Create and Support related communities • Healthcare knowledge standards

http://sli.do/


Disrupting Healthcare

• Clinical Processes are disconnected • Governance boundaries are points of failure • Boundaries: physical (buildings), organisations, regulatory • Costly to change (and inappropriate to change)

• Instead, allow deep integration of work flows across boundaries • Requires cultural change (and community involvement) • Can only be driven by clinical champions • Provide IT / Governance / Policy / Cheer-leading support

• Remove IT as a barrier to seamless care (+ Path for AI to be delivered)

• Just beginning….

http://sli.do/


Changing A Clinical Process

Rat

e o

f A

dve

rse

Even

ts

Events not addressed by change

Events caused by old process

Net reduction in adverse events

Events caused by new process

http://sli.do/


Empowering Patients

• Bring Patient and Primary Carer into the information framework

• Services empower the patient (not Data)

• Common Frustration of Patients: • Scheduling/Communication problems, Conflicting care plans / payment

options / definitions of success

• Must be resolved by the patient

• FHIR enables Services for distributed care plan & virtual clinical review

• Virtual Institutions / Integrated Home Care (medication management)

http://sli.do/


Join Us

• FHIR is a critical infrastructure enabler • A community solution for the IT requirements

• But FHIR is not a solution to anything itself

• Need new community infrastructure at many levels • Governance is critical: Build confidence and trust – open community treasure

• Needs stable Governance foundations with consistent transparency

• Join the community (FHIR, or others) • http://hl7.org/fhir, http://fhir.org

http://sli.do/

http://hl7.org/fhir

http://fhir.org/

Documents

FHIR: From Idea to World Wide AdoptionFHIR: The web, for Healthcare Open Community Open Standard •Make it easier to exchange healthcare information •Open Participation - uses web