Please explain me the full structure of document and make it as presentation

1. W17: Clinicians on FHIR - How
FHIR Enables Interoperability

2. James C McClay, MD, MS, FAMIA, FACEP, ACHIP
Chief Research Informatics Officer
University of Missouri, Columbia Missouri
Twitter: @jmcclay
DEEP DIVE INTO FHIR SPECIFICATIONS
W17: Clinicians on FHIR - How FHIR Enables
Interoperability

3. Deep Dive Learning Objectives
3
Describe the FHIR
Interoperability
Infrastructure
01
Interpret
Resources in the
FHIR specification
02
Access relevant
FHIR terminologies
03
Understand
profiling of FHIR
resources through
interpretation of
implementation
guides
04
Be familiar with
FHIR accelerators
05

4. FHIR IN CURRENT
INTEROPERABILITY
ECOSYSTEM
https://www.hl7.org/fhir/operationslist.html
21st Century Cures Regulations Requirement:
Certified technology required to have “published application programming interfaces and allows health
information from such technology to be accessed, exchanged, and used without special effort through
the use of application programming interfaces or successor technology or standards, as provided for
under applicable law, including providing access to all data elements of a patient’s electronic health
record to the extent permissible under applicable privacy laws;”
API = Application Programmer Interface
“Without Special Effort” = Open, published API
Standards = US Core Data for Interoperability (USCDI)

5. FHIR Services & Servers
Data Server – Contains the resource data (ie. EHR)
• Source Clinical data about patients
Conformance (Registry) Services – Contains the resource, profile and
extension definitions (FHIR server)
• Capability Statement advertises methods server supports
Terminology services – provides valuesets, ontologies, terminologies. Usually
distributed (ie. NLM VSAC, LOINC).
• Description: https://www.hl7.org/fhir/terminology-service.html
https://confluence.hl7.org/display/FHIR/Public+Test+Servers
https://hapifhir.io/hapi-fhir/docs/server_plain/introduction.html
Instructions to Set up your own servers
Selection of public test servers

6. REST (API) = Common Internet Technology
• “Representational State Transfer” –architecture for how to connect systems
in real time
• Uses Hypertext Transport Protocol (HTTP)
• Simple to use
• Very commonly used outside of healthcare – especially mobile
• Supports simple interactions (CRUD)
• Create
• Read (& Query)
• Update
• Delete
• Extensive of tooling / experience available
• Secure

7. REST Security with Open Authentication
OAuth 2.0 & OpenID– Open
protocols for secure authorization
and connection
• https://oauth.net/
Provides foundation of SMART on
FHIR protocol
https://smarthealthit.org/
Mandl, K. D., & Kohane, I. S. (2009). No small change
for the health information economy. The New England
journal of medicine, 360(13), 1278.

8. SMART on FHIR
SMART – Launched in 2009
• https://smarthealthit.org/
• Mandl, K. D., & Kohane, I. S. (2009). No small change for the health information
economy. The New England journal of medicine, 360(13), 1278.
“SMART App Launch Framework connects third-party applications to Electronic
Health Record data”
8

9. FHIR Ecosystem Components
Client

10. FHIR Basics
FHIR®

11. The Goal:
Share Computable Healthcare Knowledge Artifacts
• Computable knowledge artifacts: Digital objects (messages) carrying
healthcare information represented in data structures that can be parsed
by a machine (Lehmann 2018).
• The FHIR Resource Objects represent named healthcare-related concepts
based on common EHR concepts.
• The FHIR resources represent self-contained computable healthcare
knowledge artifacts.
• The FHIR resources are designed to be findable, useable, extensible
specifications based on standard internet protocols.
Lehmann HP, Downs SM. Desiderata for sharable computable biomedical knowledge for learning health systems. Learn Health Syst.
2018;2(4):e10065. https://onlinelibrary.wiley.com/doi/full/10.1002/ lrh2.10065.

12. Overview of FHIR
• Fast Healthcare Interoperability Resources (FHIR)
• Written into cures act regulations
• Freely available, detailed on-line, hyperlinked specification
• tooling, servers, libraries
• Consistent, simple to use content model (Resources) using JSON or XML
• Supports all paradigms of exchange with real-time APIs
• Functions with standard internet protocols and security models
• Designed with implementers in mind (80:20 rule) – controlled extensibility
• Profiles
• Implementation Guides

13. Modeling Health Information
Clinical Data
Medications
Diagnostics
Problems and Conditions
Procedures and Results
Allergies
Family History
Labs, Radiology &
Genomics
…
Administrative Data
Patient Demographics
Provider Qualifications
Encounter Description
Claims
Insurance
Organizational
Descriptions
Appointments
Orders management
…
Process Information
Care Planning
Workflow Support
Care Episodes
Basics
Lists
Compositions
Bundles
Library

14. FHIR Models HC information as Resources
Informed by and Related to other Healthcare Standards
Resource ontology recapitulates EHR functions and
Healthcare Services – (not too big, not too small)
Each resource is a self-contained knowledge unit with
references to associated resources (i.e. Procedure –
references -> Patient)
Resource organization guided by 5Ws, Who, What, Why,
When, Where.
Complete healthcare information built through linked
resources by reference
Incorporates
lessons learned
from prior efforts
Iteratively
designed by
stakeholders and
tested at regular
connectathons.

15. Exploring the FHIR specification
Let’s Dive In

16. FHIR Specification
Orientation
(www.hl7.org/fhir)
Free: licensed under Creative Commons
”derivative works allowed“
• Release number
• Documentation
• Specifications (resources, profiles…)
• API operations
• Terminologies.

17. FHIR Resources: What are they?
The Content model
• Small logically discrete units of exchange
• Defined behaviour and meaning = FHIR specification
• Known identity / location (URL)
• complete unit of transaction
• “of interest” to healthcare
• Extensible through controlled process (Profiles)
The computable thing (knowledge object that is exchanged)
• Via REST ( FHIR Restful API), Messages, Documents, etc.
Review basic structure at http://hl7.org/fhir/resource.html

18. Hierarchy of
Resource Types
• Level 1-5 Foundational to Reasoning
• Not all are representing patient data
• Some describe how to profile others
• Administrative items
• Medical Records
• Workflow
• Financial
• Reasoning
Patient
Encounte
r
Provider
A Main Starting point:
A patient has an encounter with a
provider

19. Resource Index
Take a look
Maturity Model
Applied to Each Resource:
0 = draft
1 = proposal approved, tested
2 = tested between 3+ systems
3 = balloted with comments
4 = published in STU, multiple prototypes
5 = 2 release cycles/5+ production systems
= NORMATIVE – balloted, approved, locked

20. Clinical Resources
General:
AllergyIntolerance
Condition (Problem)
Procedure
ClinicalImpression
FamilyMemberHistory
RiskAssessment
DetectedIssue
Care Provision:
CarePlan
CareTeam
Goal
ReferralRequest
ProcedureRequest
NutritionOrder
VisionPrescription
Medication & Immunization:
Medication
MedicationOrder
MedicationAdministration
MedicationDispense
MedicationStatement
Immunization
ImmunizationRecommendation
Diagnostics:
Observation
DiagnosticReport
DiagnosticOrder
Specimen
BodySite
ImagingStudy
ImagingObjectSelection

21. Exploring Resource Specifications
Resource Identity & Metadata
Human Readable Summary
Extension with URL to definition
Standard Data:
• MRN
• Name
• Gender
• Birth Date
• Provider
XML and JSON
1) Open Patient Resource
2) Scroll down to Resource Content
3) Open Detailed Descriptions
Let’s do this together…

22. Resource structure
Walk through Resource Elements:
• Name
• Flags (implementer
• Cardinality (few required elements)
• Type = Data Type
• Description
• Terminology binding with links
• Other Details on page
Patient

23. Organizing Resources:
Connecting resources to complete a record
PROCEDURE
PATIENT
DIAGNOSTIC
REPORT
CONDITION
Subject
Report
reasonReference
Encounte
r
Performer
ENCOUNTER PRACTITIONER
http://hl7.org/fhir/procedure.html

24. Organizing Resources: Lists of things
Examples
• Medication list
• Problem List
(Conditions)
• Allergies
• Past Medical History
• Past Social History
• Social History
• ‘Organizer’ in Document
Manage ‘points in time’
and changes
List
Bundle
Composition

25. Organizing Resources:
Questionnaires
Organized collection of questions intended to solicit
information from individuals involved in the healthcare
domain.
May be simple flat lists of questions or can be
hierarchically organized in groups and sub-groups, each
containing questions.
Defines the questions to be asked, how they are ordered
and grouped, any intervening instructional text and what
the constraints are on the allowed answers.
The results of a Questionnaire can be communicated
using the QuestionnaireResponse resource.
Examples of
Questionnaires
• Past medical history (PMH)
• Family diseases
• Social history
• Research
questionnaires/Clinical
research forms (CRFs)
• Quality and evaluation forms
• Patient intake form (e.g.
clipboard)
• Forms to support insurance
claims
Questionnaire QuestionnaireResponse

26. QuestionnaireResponse
Each time a questionnaire is completed for a different subject or at a different
time, a distinct QuestionnaireResponse is generated, though it may be possible
for a previously entered set of answers to be edited or updated.
Questionnaire responses record specifics about data capture - exactly what
questions were asked, in what order, what answers were given, etc.
QuestionnaireResponse
Note: Check out LOINC LHC-Forms:
https://loinc.org/lhc-forms/ for FHIR-enabled Questionnaires

27. Recording a patient encounter
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
difficulties. On examination, urticarial rash on both arms. No
evidence meningitis. Diagnosis of penicillin allergy. Antibiotics
changes to Erythromycin 250mg 4 times per day for 10 days.
Patient
Encounter
Condition
Observation
Medication
Allergy Intolerance
Resource Type

28. As a bundle of linked resources…
A Document is a Bundle of resources of type "document" that has a
Composition resource as the first resource in the bundle, followed by a series
of other resources,

29. Documents – are signed bundles
Observation Resource
Composition Resource
Section
Device Resource
Condition Resource
List Resource
<Bundle>
<entry>
<Composition />
</entry>
<entry>
<Observation />
</entry>
<entry>
<Device />
</entry>
<entry>
<List/>
</entry>
<entry>
<Condition/>
</entry>
</Bundle>
Attester
Metadata Section
Section
• Very common
• Summary at a point in
time
• Part of record
• Like CDA

30. STRUCTURED AND CODED
DATA IN FHIR RESOURCES

31. HL7 FHIR Vocabulary
Support for coded data of varying complexity
Some codes defined as part of resource; others referenced from
external vocabularies
• LOINC, SNOMED, UCUM, etc.
Recognition some will differ by implementation space
Can use Value Set resource to define more complex code lists (NLM
VSAC)
Managed by HL7 Terminology Authority (HTA)

32. HL7 FHIR Datatypes:
Data Types:
• Simple types
• General-purpose types
• Metadata types
• Special purpose data typss
Identifiers
Review coded data
• ValueSet binding
https://www.hl7.org/fhir/datatypes.html

33. Data types: Primitive
Based on w3c schema and ISO data types
Stick to the “80% rule” – only expose what most will use
• Simplified
https://www.hl7.org/fhir/datatypes.html
Open Mappings

34. Data types: Complex
Complex Data Type:
• Composed of other data
types
• Can be “Profiled’
(constrained)
• Example: USCDI
specifications
https://www.hl7.org/fhir/datat
ypes.html

36. Terminology and Data Types
Code system are codes with a word or concepts that is represented by the
code and a definition or description
Using standardized terminology in FHIR is a way towards consistent
semantics

37. Value Sets
Computer must
know the code
system used to
correctly reference
and find the
intended value set

38. FHIR PROFILING:
WHERE THE ACTION IS

39. Adapting FHIR to your needs: Profiling &
Extensions
• Many different contexts in healthcare, but want a single set of Resources for 1 context
• 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.
• 3 main aspects:
• Constraining a resource - remove element, change multiplicity fix values
• Change coded element binding
• Adding a new element (an extension)
• Profiling adapts FHIR for specific scenarios

40. Profiling
Typical Adaptions in Profiles.
• Rules about which resource elements are or are not used, and what
additional elements are added that are not part of the base
specification
• Rules about which API features are used, and how
• Rules about which terminologies are used in particular elements
• Descriptions of how the Resource elements and API features map to
local requirements and/or implementations
• Look a lot like the definition of the resources themselves

41. For example…
Note: Limited mandatory elements in the core spec
Require that the
identifier uses the
NHS number –
and is required
Limit names to
just 1 (instead
of 0..*)
Change
maritalStatus
to another set
of codes that
extends the
one from HL7
international Add an
extension
to support
ethnicity
Doesn’t
support
photo

42. Extension Definitions
• Simple or Complex
• Definition:
• Available on the web
• Canonical Url (definition resolvable from FHIR
server)
• In resource instance:
• Reference to Url
• Extension or ModifierExtension
• Example: US Core – Patient Resource –
Extended to include race and ethnicity.
“extensibility is a
fundamental
part of the
design of this
specification.
Every element in
a resource can
have extension
child elements
to represent
additional
information that
is not part of the
basic definition
of the resource.”
https://www.hl7.org/fhir/extensibility.html>

43. FHIR IMPLEMENTATION GUIDES
(FHIR IG)
https://www.hl7.org/fhir/implementationguide.
html

44. FHIR Implementation Guides
• FHIR Implementation Guides support Specific Use
Cases
• Implementation Guides both restrict and extend
APIs, resources and terminologies.
• A Product of FHIR Accelerators
• There are currently over 160 FHIR Implementation
Guides registered with HL7 FHIR Foundation
• Many more at SIMPLIFIER.NET
US CORE IMPLEMENTATION GUIDE
https://build.fhir.org/ig/HL7/US-Core/uscdi.html

45. FHIR IG Registries
The HL7 FHIR Foundation (https://www.fhir.org/guides/registry/)
SIMPLIFIER.NET (https://simplifier.net/)

46. FHIR is Freely available
Unencumbered – free for use, no membership required
http://hl7.org/fhir
46

47. More information
From HL7
• HL7 FHIR: http://hl7.org/fhir/index.html
• FHIR Confluence: https://confluence.hl7.org/
• HL7 FHIR Foundation: http://www.fhir.org/
Community
• Zulip: 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
http://www.hl7.org/about/fhir-accelerator/
HL7 FHIR ACCELERATOR™ Projects
FHIR Implementation Guide
Registry:
https://www.fhir.org/guides/r
egistry/
SMART on FHIR App
Registry:
https://apps.smarthealthit.or
g/

48. James McClay,
jmcclay@health.Missouri.edu
Thank you