FHIR for implementers in New Zealand

FHIR forImplementers
InNewZealand

About me
• Medical Doctor
• Developer
– EMR
– Tooling: clinFHIR, conMan
• HL7 Fellow
• Chair Emeritus of HL7 New Zealand
• Co-chair FHIR Management Group
• Contractor – MOH, Rhapsody, CSIRO, HL7 Intl.
• Blog: fhirblog.com
3

Objectives for day
• Understand the basics of FHIR
• Feel confident to participate in a FHIR Implementation
• Know how to use clinFHIR / conMan tooling
• Know where to find more info and help
• Build the local community!
– Encourage people to comment on work…

Agenda
Time Activity
9.00 – 10.30 Technical Overview, Terminology
10.30 – 11.00 Morning tea
11.00 – 11.45 Profiling, Implementer support
11.45 – 12.30 Individual Exercises
12.30 - 1.15 Lunch
1.15 - 2.00 Exchange paradigms
2.00 – 2.30 National perspective – current projects, ecosystem, reviewing
2.30 – 3.00 Afternoon tea
3.00 – 3.30 Security & Additional standards
3.30 – 4.00 Exercises
4.00 – 4.30 Wrap up, unanswered questions, next steps

Zulip chat
https://chat.fhir.org/

Technical Overview
• What is FHIR
• Resources
• Resource Graphs (incl. clinFHIR)
• Terminology
– Interaction and resources
• Exchange Paradigms
– CRUD operations
– Update operations
• PUT, PATCH, Operation
• Wire representation
– Extensions & Contained
• Implementer Support
– Tooling and Libraries

What is FHIR
• Fast Healthcare Interoperability Resources
• An HL7 Interoperability Standard
– For sharing clinical information
– No assumption on storage form
– Focused on the now
• (with an eye to the future)
• 2 main parts
– Content Model (Resources)
– Exchange Specification
• Extending into
– Clinical Knowledge
– Decision Support
– Quality Measures
– Also being used for persistence
• Supported by a large community
– https://chat.fhir.org/
– Libraries
– Reference servers
® Health Level Seven and HL7 are registered trademarks of Health8

Where can you use FHIR
9
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office.
FHIR
Application
PHR
FHIR
API Library
Database
FHIR
Integration Engine
V3
V2

Timeline: Where does FHIR fit?
FHIR Maturity model & releases
1980 1990 2000 2010 2020
FHIR
CDA
V3
V2
V2
1987
Start V3
1995
V3 CDA
2005
Fresh Look
2011
FHIR Release 4
2018

Where is it going?
• More resources
• Moving resources to Normative
– More implementation experience,
connectathons
• Moving beyond Interoperability
– Extending into Clinical Knowledge
• Decision Support
• Quality Measures
– Bulk extract and query
– Research
– Also being used for persistence
• Associated standards
– SMART
– CDS-Hooks
– Bulk Data
• Accelerating implementations
• Supporting the community

Who’s using it?
• Vendors
– Epic, Cerner, Allscripts
– Apple
– Microsoft
– Google
– Amazon
• Countries
– US - ONC
– UK
– Russia, Lithuania
– Australia, New Zealand
– Pretty much everywhere
12® Health Level Seven and HL7 are registered trademarks of Health

Resources: What are they?
• The Content Model
• The Thing that is exchanged
– Via REST ( FHIR Restful API), Messages,
Documents
• Informed by much past work inside
& outside of HL7
– HL7: version 2, version 3 (RIM), CDA
– Other SDO: openEHR, CIMI, ISO 13606,
IHE, DICOM

Clinical Resource types
General
AllergyIntolerance
Condition (Problem)
Procedure
ClinicalImpression
FamilyMemberHistory
RiskAssessment
DetectedIssue
Care Provision
CarePlan
CareTeam
Goal
ReferralRequest
ProcedureRequest
NutritionOrder
VisionPrescription
Medication & Immunization
Medication
MedicationRequest
MedicationAdministration
MedicationDispense
MedicationStatement
Immunization
ImmunizationRecommendation
Diagnostics
Observation
DiagnosticReport
ProcedureRequest
Specimen
BodySite
ImagingStudy
Sequence

References between resources
15
PROCEDURE
Patient
Diagnostic reportCondition
Subject
Report
Related
Item
Encounter Performer
Encounter Practitioner
http://hl7.org/fhir/references.html

Recording a consultation
16
12-year-old-boy
First consultation
Complaining of pain in the right ear for 3 days with an
elevated temperature. On examination, temperature 38°C
and an inflamed right eardrum with no perforation.
Diagnosis Otitis Media, and prescribed Amoxicillin 250mg
3 times per day for 7 days.
Follow up consultation
2 days later returned with an itchy skin rash. No Breathing
Normal. On examination, urticarial rash on both arms. No
evidence meningitis. Diagnosis of penicillin allergy.
Antibiotics changed to Erythromycin 250mg 4 times per
day for 10 days.
Patient
Encounter
Condition
Observation
Medication
Allergy Intolerance

First consultation as a Graph
17

Visualizing the connections: conMan
18

Demonstration
http://conman.clinfhir.com/connectathon.html?event=nz
 Build a resource graph for the first
consultation
- (Exercise 2 uses conMan)

Resources: Type vs Instance
• ‘Type’ is the definition in the spec
– Like a template or a cookie cutter
• ‘Instance’ is a ‘filled out’ type
– Like a cookie
• Take Patient:
– Patient type (in spec) is what can be recorded for a patient
• (Can alter with Profiling)
– An actual patient is a particular instance of the Patient type

Contained resources
• Resources instances generally stand alone
– With references between them
• Contained resources:
– Resources ‘inside’ another
– When doesn’t have separate identity
• Wire format (‘contained’ element)
• Library support
http://hl7.org/fhir/references.html#contained

Resource instance example
Resource Identity &
Metadata
Human Readable
Summary
Extension with URL
to definition
Structured Data:
•MRN
•Name
•Gender
•Birth Date
•Provider
XML and JSON
<valueString value=“jedi”/>

Structured / coded data
• Unstructured vs Structured vs Coded
• Value:
– Greatly improves quality of exchange
– ‘semantic’ interoperability
• Secondary uses
– Analytics
– Population Health
– Reporting

Resource type structure and definition
24
Examine the spec…

Resource type Hierarchy
Resource
• Id
• Meta
Domain Resource
• Text
• Contained
• Extensions
Specific type
Bundle

Base Types
• DataTypes
– Each element in an instance is a single datatype
• Spec indicates allowed types
• Choice element
– 2 classes of datatype
• Primitive
• Complex
• Other types
– MetaData
– Element
– Resource / Domain Resource
– Logical Model

Data types: Primitive (R3)
27
Based on w3c schema and ISO data types
• Stick to the “80% rule” – only expose what most will use
– Simplified
instant
Value : xs : dataTime 0..1
time
Value : xs : Time 0..1
date
Value : xs:gYear [xs:gYearMonth | Time 0..1
dateTime
Value : xs:gYear [xs:gYearMonth | xs:date | Time 0..1
decimal
integer
Value : xs : int 0..1
Element
Extension : Extension 0..
boolean
value : xs:boolean 0..1
string
Value : xs :string 0..1
uri
Value : xs :anyURI 0..1
base64Binary
Value : xs : base64Binary 0..1
unsignedint positiveInt code id oid
Value : xs :
decimal 0..1

Ratio
numerator: Quality [0..1]
denominator: Quantity [0..1]
Quantity
value: decimal [0..1]
comparator: code [0..1] QuantityComparator!
units: string [0...1]
system: uri [0..1]
code: code [0..1]
Range
low: Quantity(SimpleQuantity) [0..1]
high: Quantity(SimpleQuantity) [0..1]
HumanName
use: code [0..1] NameUse!
text: String [0..1]
family: String [0..*]
given: String [0..*]
prefix: String [0..*]
suffix: String [0..*]
period: Period [0..1]
Identifier
use: code [0..1] IdentifierUse!
type: CodeableConcept [0..1] IdentifierType+
system: uri [0..1]
value: String [0..1]
assigner: Reference [0..1] Organization
Address
use: code [0..1] AddressUse!
type: code [0..1] AddressType!
text: string [0..1]
line: string [0..*]
city: string [0..1]
district: string [0..1]
state: string [0..1]
postalCode: string [0..1]
country: string [0..1]
period: Period 0...1
Coding
system: uri [0..1]
version: string [0..1]
code: code [0..1]
display: String [0..1]
userSelected: boolean [0..1]
Element
extension:
Extension 0..*
Timing
event: dataTime [0..*]
code: CodeableConcept [0..1] TimingAbbreviation?
Repeat
bounds[x]: Type [0..1] Duration|Range|Period
dount: Integer [0..1]
dountMax: integer [0..1]
duration: decimal [0..1]
durationMax: decimal [0..1]
durationUnit: code [0..1] UnitsOfTime!
frequency: integer [0..1]
frequencyMax: integer [0..1]
period: decimal [0..1]
periodMax: [0..1]
periodUnit: code [0..1] UnitsOfTime
dayOfWeek: code [0..*] DaysOfWeek!
timeOfDay: time [0..*]
when: Code [0..*] EventTiming!
offset: unsginedInt [0..1]
ContactPoint
system: Code [0..1] ContactPointSystem!
value: String [0..1]
use: Code [0..1] ContactPointUse!
rank: PositiveInt [0...1]
CodeableConcept
coding: Coding [0..*]
text: String [0..1]
Attachment
contentType: Code [0..1] MimeType!
language: Code [0..1] CommonLanguages+
data: base64Binary [0..1]
url: uri [0..1]
size: unsignedInt [0..1]
hash: base64binary [0..1]
title: string [0..1]
creation: dateTime [0..1]
Period
start: dateTime [0..1]
end: dateTime [0..1]
SampledData
origin: Quantity(SimpleQuantity) [1..1]
period: Decimal [1..1]
factor: Decimal [0..1]
lowerLimit: Decimal [0..1]
upperLimit: Decial [0..1]
dimensions: Positivelnt [1..1]
data: String [1..1]
Data types: Complex (R3)
Signature
type:Coding [1..*] Signature Type?
when: Instant [1..1]
who[x]: Type [1..1] uri |
Reference(Practitioner|Related
person|PatientDevice|Organization)
onBehalfOf[x]: Type [0..1]
uri|Reference(Practitioner|RelatedPers
on|Pateint|Device|Organization)
contentType: code [0..1] MimeType!
blob: base64Binary [0..1]
Annotation
author[x]: Type [0..1]
Reference(Practitioner|Patient|
RelatedPerson)|string
Time: dateTime [0..1]
Text: string [1..1]
repeat
[0..1]
28

DataType: Identifiers
• Business identifiers
– NHI, Driving License, CSC Card, Lab order number
– Most resources have them (name is ‘identifier’ as well)
• Identifier datatype
– Key child elements
• System
– The ‘namespace’ within which the value is unique (uri)
» NamingSystem resource to describe
• Value
– The actual value
• Not the same as the resource Id

Coded datatypes
• Refer to a terminology
• 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"
}
Datatypes in the spec…

Why have structured / coded data
• Unstructured vs Structured vs Coded
• Value:
– Greatly improves quality of exchange
– ‘semantic’ interoperability
• Secondary uses
– Analytics
– Population Health
– Reporting
32s of States

Terminology Sub-system
34
Code System:
Defines a set of concepts
with a coherent meaning
Code
Display
Definition
‣ SNOMED CT / LOINC
‣ NZULM / NZMT
‣ ICPC, MIMS + 100s more
‣ ICD-X+
‣ A drug formulary
‣ Custom

35
Code System:
Code
Display
Definition
Value Set:
A selection of a set
of codes for use in a
particular context
Selects

36
Code System:
Code
Display
Definition
Value Set:
particular context
Element Definition:
Type and Value set
reference
Selects Binds
▸ Binding:
 Connection between element and ValueSet
 Strength determines if can change

37
Code System:
Code
Display
Definition
Value Set:
particular context
Element:
code/
Coding/
CodeableConcept
Element Definition:
Type and Value set
reference
Selects Binds
Refers to
Conforms

38
Code System:
Code
Display
Definition
Value Set:
particular context
Element:
code/
Coding/
CodeableConcept
Element Definition:
Type and Value set
reference
Selects Binds
Refers to
Conforms
Definition
Instance

Terminology binding: Condition resource
39
• a
ValueSet binding in the spec…

Canonical Urls / system
• Certain resources
– http://hl7.org/fhir/references.html#canonical-list
• StructureDefinition
– Profile and Extension Definition
• ValueSet
• CodeSystem
– Element name is ‘url’
• Is really a URI
– Globally unique
• Eg Extension definition or profile url
– A form of reference
• Eg ValueSet to CodeSystem
• Should resolve (usually) but not required to
– Eg support registry

Example of canonical url
• ValueSet -> CodeSystem

Demonstration
http://conman.clinfhir.com/connectathon.html?event=nz
 Add data to the resources in the resource graph

Adapting FHIR to your needs: Profiling
• Many different contexts in healthcare, but want a single set
of Resources
• The 80% rule
• Need to be able to describe ‘usage of FHIR’ based on context
• Allow for these usage statements to:
– Authored in a structured manner
– Published in a registry & Discoverable
– Used as the basis for validation, code, report and UI generation.
• Profiling adapts FHIR for specific scenarios
– A Statement of Use

FHIR as a platform spec
• Base on which profiles / IGs are created
• ‘80%’ rule
• Minimum required fields
• Minimum ‘required’ bindings
Base Spec Profiling Customized Spec
Eg IPS

More on Profiling
• 3 main aspects:
– Constraining a resource - remove element, change multiplicity fix
values
– Change coded element binding
– Adding a new element (an extension)
• Modifier Extensions
• Each profile has a unique (canonical) url
– Represent as StructureDefinition resource
• Package multiple profiles as Implementation Guide
– Along with other artifacts (ValueSets, ConceptMaps etc.)

Example: Profile on a Patient
Limit names to
just 1 (instead
of 0..*)
Change
maritalStatus to
another set of
codes that
extends the one
from HL7
international
Specify that the identifier
uses the NHI – and is
required
Don’t
support
photo
Add an
extension
to support
ethnicity

Profiling in (more) depth
• Conformance resources
– StructureDefinition
• Profile
• Extension definitions
• Conformance registries
– FHIR server
• Terminology
– ValueSets, CodeSystems, NamingSystem

Extensions
• Extensions are normal
– Can occur at many levels in resource instance
• Same capabilities as core
• ‘Levels’ and reuse
– Core, National, Regional, Local
• Extension Definition
– (StructureDefinition)
• Canonical Url in definition
• Resource instance includes that Url
– Therefore client can locate definition
• Registry of extension definitions
48
® Health Level Seven and HL7

Extension in an instance
<valueStringvalue=“jedi”/>

Extensions: Examples
• Simple
• Complex

Implementation Guide (IG)
• All the artifacts for a particular business need
– Outcome of profiling
• For an implementer
• Can be balloted by HL7
• Examples
– US Core
– Argonaut
– IPS
– QI-Core
– CCDA on FHIR
– Da Vinci (multiple)
– Provider directory
http://www.fhir.org/guides/regis

IG: General considerations
• Must Support
• Tooling
– Forge (https://fhir.furore.com/forge/ )
– Simplifier Registry (https://registry.fhir.org/)
– clinFHIR / conMAN (clinfhir.com)
• Governance

Demonstration
54
http://hl7.org/fhir/uv/ips/2019Sep/
International Patient Summary

Implementer support
• Development
– Libraries
• .net, java, python, swift, javascript
– Reference servers
• On-line, downloadable (http://hl7.org/fhir/downloads.html)
– Validation
• $validate operation
• Java library
– FHIR (zulip) chat
• Design
– clinFHIR Logical Modeler
– conMan Graph Builder

net – update a patient

net – get extensions

clinFHIR Logical Modeler
• Graphical tool to build model using FHIR datatypes
• 2 model types:
– Pure information (eg Adverse Reactions)
• Collect and document data from clinicians
• Can review and publish as HISO information standard
– Resource based (eg NHI / HPI)
• To generate FHIR artifacts for Implementation Guide
– Eg profiles
– Can follow Information model
• Review and publish in conjunction with HL7 NZ

Demonstration
• Creating a resource model to inform a
profile
– (Exercise 1 uses the Logical modeler)
60

Exercises
• https://docs.google.com/document/d/18pns_rXOjzgSBHM4
Fi7nXc54BWrpY94PWy7kVbYxty0/edit#
• http://bit.ly/2PhBZHN

Exchange Paradigms
62
REST Documents
Messages
Services
(Operations)

Bundles
• Container resource
• Types of Bundle
– Searchset
– Transaction
– Document
– Message
– …
• Inherit from Resource
– No text or extensions
Bundle Resource
Patient Resource
List Resource
Condition Resource

Exchange paradigm: REST
• Preferred paradigm
– Can be async
• Searching
– Defined searches per resource
• Can add others
– Chaining
– Parameters (eg _include)
– Results in Bundle
• Operations
– For more complex interactions (still real-time)
– Defined and Custom
• Eg Terminology search, $validate
– Parameters resource
Server can support any subset

When to use REST?
• Want low coupling between systems
– In theory, very little up-front negotiation required
• Small, light-weight exchanges
• Focus is CRUD operations
– Also for publish/subscribe
• Client-driven client-server orchestration
• Server endpoint has fixed location
• Well-suited for Mobile, PHR, Registries
65

When to avoid REST?
• Complex or server-driven orchestration
– Order of operations matters (e.g. complex decision support)
• Unit of work != resource
– “Transaction” may be an option
• No natural “server” or no fixed network location
• Lack of trust in the client for contextual audit, etc.
66

Locating a single resource…
http://server.org/FHIR/Patient/1
base path resource type
id
Not the same as a resource identifier

Business identifiers
• Id is not the same as a business identifier
– Eg a Medical Records Number
– Eg Patient.identifier, Encounter.identifier
• Id is ‘structural’ – depends on server
• Identifier is a resource property.
– Same if a resource is moved
69

Specify format
URL: GET [server]/fhir/Patient/1?_format=json
Response: HTTP/1.1 200 OK
Response headers: Content-Type: application/json+fhir;charset=utf-8
Content-Length: 787
URL: GET [server]/fhir/Patient/1 HTTP/1.1
Request header: accept: application/fhir+json
Response: HTTP/1.1 200 OK
Response headers: Content-Type: application/json+fhir;charset=utf-8
Content-Length: 787

CRU(P)D: Mapping to verbs
create
The create interaction creates a new resource in a server assigned location. The create interaction is performed by an HTTP
POST operation as shown:
POST [base]/[resourcetype] (?_format=mimeType)
read
The read interaction accesses the current contents of a resource. The interaction is performed by an HTTP GET operation as
shown:
GET [base]/[resourcetype]/{id} (?_format=mimeType)
update
The update interaction creates a new current version for an existing resource or creates a new resource if no resource
already exists for the given id. The update interaction is performed by an HTTP PUT operation as shown:
PUT [base]/[resourcetype]/{id} (?_format=mimeType)
patch
The patch interaction updates an exiting resource by supplying a document with the list of changes to apply. The document
can be Json, XML or FHIR Path. The interaction is performed by an HTTP PATCH operation as shown:
PATCH [base]/[resourcetype]/{id}
delete
The delete interaction removes an existing resource. The interaction is performed by an HTTP DELETE operation as shown
(note logical delete & versioning):
DELETE [base]/[resourcetype]/{id}

Versioning
• FHIR defines an API for managing changes
– Optional
• Previous versions can be listed / returned
– At resource level
• Delete is a ‘marker’ in the history
– Can re-animate with a PUT to the same location
• Resource history
– GET [base]/[type]/[id]/_history
• Get a specific version
– GET [base]/[type]/[id]/_history/3
– Version not necessarily a number

REST SEARCHING
http://hl7.org/fhir/search.html
73

Standard parameters
• Each resource has a set of “standard” search operations, so not every element can be searched
– Search name not always same as element name
• Can define custom ones
– SearchParameter resource

Executing queries
• POSTMan - https://www.getpostman.com/
• Server declares support in CapabilityStatement
– GET [host]/metadata
– http://hl7.org/fhir/http.html#capabilities
• Returns a Bundle
– Watch out for paging
• _count parameter
• Reference database really helpful
– I use hapi (http://fhirtest.uhn.ca/baseR4/)
• clinFHIR to create sample data
– Patient Viewer -> Select Patient ? Add new patient
– Much more at synthea - https://github.com/synthetichealth/synthea
• Examples
http://snapp.clinfhir.com:8081/baseDstu3/Patient?name=hay
75

Combining parameters
• Can search by GET & POST
• Multiple parameters
– Specifying multiple parameters finds resources matching all params  “AND”
http://snapp.clinfhir.com:8081/baseDstu3/Patient?name=hay&gender=male
– Parameters may list multiple values  “OR”
http://snapp.clinfhir.com:8081/baseDstu3/Patient?name=smith,hay

Summary of common parameters

Chained searches
• Search based on referenced properties
– http://hl7.org/fhir/search.html#chaining
• eg
– Observations for a patient
• Observation has a search for “subject” (the id of the Patient, Group or Device)
• Patient has a search for “name” and “identifier”.
• ‘chained’ search:
– [host]/Observation?subject.name={x}
– [host]/Observation?subject.identifier={y}
• But note: this still only works on the predefined search parameters. You cannot
just use any property of the resource.
http://snapp.clinfhir.com:8081/baseDstu3/Observation?subject.name=hay

Reverse Chaining
• Selecting resources based on the properties of resources that refer to them
– http://hl7.org/fhir/search.html#has
• Return patients that have an Observation with a code of 9279-1
79
http://snapp.clinfhir.com:8081/baseDstu3/Patient?_has:Observation:patient:code=92
Particularly useful when using Proven
Return a patient ‘search’ property on Observation
Observation code
Observations
that reference
the patient

_Include related resources
• Include related resources in the response
• Based on search parameters
• Server declares in conformance
• Format
– [host]/{type}?_include={source type}:{search parameter}:{target type}
• Eg
– [host]/MedicationOrder?_include=MedicationOrder:patient&criteria...
http://snapp.clinfhir.com:8081/baseDstu3/Observation?_id=7294&_include=Observation:patient
http://snapp.clinfhir.com:8081/baseDstu3/Observation?code=http://loinc.org|8310-
5&_include=Observation:patient

Conditionals
• Perform an operation if conditions met
– Based on search parameters
• Conditional Read
– ‘If-modified-since’ header
• Conditional Create
– HTTP header
– If-None-Exist: [search parameters]
• Conditional Update
– PUT [base]/[type]?[search parameters]
• Conditional Delete
– DELETE [base]/[type]/?[search parameters]
https://fhirblog.com/2019/03/25/importing-csv-data-into-a-fhir-server/

Custom queries
• Use SearchParameter to define
– http://hl7.org/fhir/searchparameter.html
• Useful for searches on extensions
• Like custom operations, does raise the interoperability bar

Compartment
• Syntactic sugar for queries
• Resources that share common property
– Eg patient
• Purpose:
– Access mechanism for finding a set of related resources quickly
– Provide a definitional basis for applying access control to resources quickly
• http://hl7.org/fhir/compartmentdefinition.html
• Eg
– http://snapp.clinfhir.com:8081/baseDstu3/Patient/7268/$everything

$match
• Defined operation for EMPI searching
• Send partial Patient resource
– Elements to match filled in
• POST to “Patient” endpoint on server
– Server applies business rules then (potentially) runs query
• Response is bundle of matching patients with score
{
"resourceType":"Patient",
"name":[{"family":"Doe"}],
"birthDate":"1987-03-12",
"gender":"male”
}

GraphQL
• Allows queries to specify ‘shape’ to return
– Generally REST returns whole resource
– Though note _elements and _summary modifier
• Can operate on single resource or at the ‘system’ level
• Mostly query
– Update not well defined
• http://hl7.org/fhir/graphql.html
http://test.fhir.org/r3/Patient/example/$graphql?
query={name(use:official){text,given,family}}

Updating patterns
• Resource PUT
– Replace the entire resource
• Patch
– The patch document
• Operations
– User defined update operations

Resource PUT
• Submit an updated resource
• Client is in control (mostly)
• Server
– Doesn’t have to support
– Can apply business logic / security to call

Validating first…
• Knowing the resource is valid
– Actually, ‘conformant’ is the preferred term
– Must be conformant to the core spec, additionally other profiles
• Validation code from the community
• $validate operation
– Most reference servers support
• http://hl7.org/fhir/validation.html
88

Operations example
• Operations hide complexity
– Some in spec, can defined custom
• OperationDefinition resource to define
• Parameters resource
– Enclose input data
– Return result
• Custom operations are a barrier to global interoperability
– Not consistent across implementations
https://fhirblog.com/2019/07/09/thoughts-about-updating-registries/
https://ontoserver.csiro.au/stu3-latest/ValueSet/$expand
?url=http://hl7.org/fhir/ValueSet/condition-code&filter=asthma

Parameters resource
• Use Parameters resource to pass parameters
{ "resourceType":"Parameters",
"parameter":[
{"name":"nhi","valueIdentifier":
{"system":"https://standards.digital.health.nz/id/nhi",
"value":"XXX1234"}
},
{"name":"address","valueAddress":
{"use":"home","text":"23 Thule Street "}
}
]
}

PATCH example
• Update part of a resource
• Patch document
– Specify changes to make
– JSON, XML, FHIRPath
• PATCH [base]/[type]/[id] {?_format=[mime-type]}
• (Careful with arrays)
http://hl7.org/fhir/http.html#patch
https://fhirblog.com/2019/08/13/updating-a-resource-using-patch/
[{ "op": "add", "path": "/gender", "value": "female" }]

Transactions & Batches
• Same principle as Db transactions
– POST a Bundle to server root
• Transaction
– Succeed / Fail as a unit
• Batch
– Partial update
• http://hl7.org/fhir/http.html

DOCUMENTS AND MESSAGES
95

Document paradigm
• Summary at a point in time
• Part of record
• Very common
– Discharge Summary
– Referral letter
– Progress Note
• A collection of resources
• Equivalent to CDA
– CCDA on FHIR
Patient
Practitioner
Observation
Resource
Device
List
Condition
Composition
• Subject
• Author
• Section:Obs
• Section:Probs
List
Condition
Bundle
Note: Most resources have a reference to Patient
https://chat.fhir.org/#narrow/stream/179273-CCDA-.2F.20FHIR.20mapping.20stream

Composition resource
• Document header
– Document type
– References to Patient, Author, Custodian …
– Equivalent to:
• CDA header
• IHE XDS metadata
• Sections (headings)
– Contents are text and structured/coded data
• Rules for rendering
• Can be profiled (i.e. specific document types)

Messaging
• Similar to v2 and v3 messaging
• Also a collection of resources as a
Bundle resource
• Allows request/response behavior
with bundles for both request and
response
• Event-driven
• Needs agreement between parties
– Tight coupling
• E.g. Send lab order, get back result
• Can be asynchronous and/or
indirect

Conversion between v2 & FHIR
• Often replaced by REST
– (REST wasn’t an option until recently)
– Eg instead of ADT message, POST Patient resource to Lab server
• Conversion ‘reasonably’ straightforward
– Quite a few nuances though
• HL7 working on mapping advice
• https://chat.fhir.org/#narrow/stream/179188-v2-to.20FHIR

FHIR AND THE MOH
(Adapted from a HISO presentation)

Current NZ projects
• Adverse Reactions
– Improve collection of Adverse Reaction data
– Information model ready for comment
• FHIR interface for NHI / HPI
– Draft models created for phase 1
• Practitioner, PractitionerRole, Organization, Location
– Plan to release test API asap
– phase 2 will add services and careteams
• Medication query API against NZULM
– Support new users (ULM is complicated)
– Support new functionality (future phase)
• Bulk download for local caches
• Decision support
• CDS-hooks for EHR integration
– Plan to release test API asap

Development Process
1. Confirm requirements
2. Setup Test server & project app
– http://nz.clinfhir.com/
– Currently standard FHIR server (HAPI)
3. Use clinFHIR Logical Modeler to build information models
– Use conMan to build resource graphs where useful
– Examples
4. Review models
– HISO document based process at the moment
– https://chat.fhir.org/#narrow/stream/179178-new-zealand
5. Build FHIR artifacts from models & publish in IG
– Extension definitions automatically
– Profiles combination manual / automatic
– ValueSets & CodeSystems manual
– Searches, queries, other technical stuff
– FHIR IG publisher to generate IG
6. Technical review / ballot
– With HL7 NZ – details TBD.
2 stage review as
technical review is
specialized.
Separate business &
technical aspects

FHIR Community Process (FCP)
• Proposed process for building FHIR Implementation Guides
– Minimize overlap between IGs
– Encourage/support community development
– HL7 membership encouraged – not required
• Co-ordination committee
– Clearing House, not veto
• Each project:
– Documented governance process for IG development
– Description, License, Maintenance Plan, Realm
• https://wiki.hl7.org/index.php?title=FHIR_Community_Process

clinFHIR Logical Modeler (redux)
• Graphical tool to build model using FHIR datatypes
• 2 model types:
– Pure information (eg Adverse Reactions)
• Collect and document data from clinicians
• Can review and publish as HISO information standard
– Resource based (eg NHI / HPI)
• To generate FHIR artifacts for Implementation Guide
– Eg profiles
– Can follow Information model
• Review and publish in conjunction with HL7 NZ

Adverse reactions (Information Model)

CSIRO: (Information Model)

NHI (single resource)

Once it’s in a model:
We can generate different views /quality reports

Analysis: ValueSets list

Security
• FHIR is not a security standard, but…
• Existing privacy well aligned with GDPR
– (https://healthcaresecprivacy.blogspot.co.uk/2015/04/privacy-
principles.html)
• Current FHIR support:
– AuditEvent, Provenance, Consent
– Any resource has security tags
– Authentication/Authorization
• SMART on FHIR, Pages in spec
– Identity resources
• Patient, RelatedPerson, Practitioner, Organization & others…
• Some gaps and areas for improvement
– White paper to come

Blockchain
• Technology behind bitcoin
• Distributed list of transactions (blocks)
• Cryptographically signed
– Can’t change without detection
• What is relationship with FHIR?
– Unlikely actual clinical data
– Tamper proof audit records
– Provider Authentication
– Supply chain (eg medication provenance)

SMART
• Substitutable Medical Applications, Reusable Technologies
– http://hl7.org/fhir/smart-app-launch/
• History
• Originally limited to EHR external apps
– Becoming the ‘de-facto’ Authentication
• 2 aspects
– App launching
• Public & confidential
– Authentication ‘Profile’ on OAuth2 & OpenID Connect
• Endpoints and scopes
• Sandbox: https://sandbox.smarthealthit.org/#/start
• App Gallery: https://apps.smarthealthit.org/

Oauth2
App Resource
Server
Authz
Server
1. Delegate
Authorization
3. Use App
4. Authenticate and Grant access
5. Issue code
7. Access resource
(with token)
2. Application is
registered with Auth
server
6. Request access
token (+refresh token)
Repeat step 6 when access token expires

Ecosystem
• An ecosystem really needs one, shared Auth server
– Most implementations combine Auth & Data servers
• For this to work, more standards will help
– Dynamic Client Registration (RFC 7591)
– Token introspection (RFC 7662)
– Server discovery (RFC 5785)
• More granular scopes
• Common Consent models
• Standardized auditing
– So consumer can see who accessed their data
More data: bit.ly/smart-fhir-tech

CDS Hooks
• Clinical Decision Support (CDS)
– User Interface for display CDS
– ‘hooks’ to EHR activity
• Service can call back to EHR
– Or any other data store
• Discovery & endpoints
• Prefetch
• Security Model
– ‘out of band’ setup
• Key exchange
– TLS
– Encrypted JWT in call to service
– Access token provided for call back
http://cds-hooks.org/specification/1.0/
https://chat.fhir.org/#narrow/stream/179159-cds-hooks

Bulk Data
• Population level data
– Multiple patients
– Large data sets
• Define operations
– $export / $import
– ndjson as format
• Asynchronous operation
• SMART as security
• Still in development
• http://hl7.org/fhir/uv/bulkdata/STU1/
• https://chat.fhir.org/#narrow/stream/179250-bulk-data

Decision Support
• Clinical Reasoning module
• 2 main use cases
– Sharing knowledge artifacts
– Evaluating knowledge artifacts in the context of a population
• Decision Support, Quality measures
• A complex area!
• http://hl7.org/fhir/clinicalreasoning-module.html
• https://chat.fhir.org/#narrow/stream/179220-cql

WorkFlow
• Eg Referral, tracking
orders
• Resource characteristics
– Request
• Eg MedicationRequest
– Event
• Eg
MedicationDispense
– Definition
– Eg PlanDefinition
• Task Resource
– As a ‘tracker’

Reality check
• Sounds wonderful!
• Managing Expectations
• Analogy of building house
– All this is the concept plan…
• What does FHIR really stand
for?
Far Harder In Real life!

More information
• From HL7
– http://hl7.org/fhir/index.html
– wiki.hl7.org/index.php?title=FHIR
• Community
– http://www.fhir.org/
– https://chat.fhir.org/
– List server (fhir@lists.hl7.org )
– Stack Overflow (tag FHIR)
• Blogs
– www.healthintersections.com.au/
– https://fhirblog.com/
– https://thefhirplace.com/
– https://brianpos.com
• Libraries
– Java (http://hapifhir.io/)
– C# (NuGet HL7.FHIR)Tooling
– Forge (http://fhir.furore.com/Forge)
• Tooling
– Forge (http://fhir.furore.com/Forge)
– http://clinfhir.com/
• Test servers
– http://wiki.hl7.org/index.php?title=Publicly
_Available_FHIR_Servers_for_testing
– https://fhirblog.com/2016/10/19/setting-
up-your-own-fhir-server-for-profiling/
124

That’s it!
1

FHIR for implementers in New Zealand

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie FHIR for implementers in New Zealand

Ähnlich wie FHIR for implementers in New Zealand (20)

Mehr von David Hay

Mehr von David Hay (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

FHIR for implementers in New Zealand