Database Homework

cyberdreams

introductiontofhir.pptx

Home >Computer Science homework help >Database Homework

Introduction to FHIR

David Hay

May 11, 2015

This presentation

Can be downloaded here:

http:// gforge.hl7.org/svn/fhir/trunk/presentations/2015-04 Tutorials/Introduction to FHIR.pptx

Use “anonymous” and email address to logon

Is licensed for use under the Creative Commons, specifically:

Creative Commons Attribution 3.0 Unported License

(Do with it as you wish, so long as you give credit)

Who am I?

Name: David Hay

Company: Orion Health

Background:

Involved in FHIR almost from beginning

Ex Clinician

Co-Chair FHIR Management Group

Chair HL7 New Zealand

Blog: FHIRBlog.com

Who are you?

What’s your background with HL7?

v2? v3? CDA? Brand new?

What’s your role?

Developer? Manager? Clinician? Other?

What’s the single most important thing for you to get out of today’s course?

Please be brief!

Tutorial Objectives

You should:

Know where FHIR fits in the broader healthcare landscape, including other HL7 specifications

Be able to explain what FHIR is to others in your organization, and what impact it might have

Be equipped to help your organization determine if, when, where and how you might use FHIR

Know how to approach the FHIR specification to find out what more you need to know

Be prepared for the more detailed tutorials

Be able to engage with the community

9:15

What is FHIR?

DSTU 2

Answer: An instigator of bad puns

FHIR is the hottest thing since . . .

This spec is spreading like wild. . .

This company is really on FHIR

Feel free to come up with your own

(but please, not here )

The acronym

F – Fast (to design & to implement)

Relative – No technology can make integration as fast as we’d like

H – Health

That’s why we’re here

I – Interoperable

Ditto

R – Resources

Building blocks – more on these to follow

9:25

Genesis of FHIR

Has been a need to share healthcare information electronically for a long time

Increasing pressure to broaden scope of sharing

Across organizations, disciplines, even borders

Mobile, Device & Cloud-based applications

Faster – integration in days or weeks, not months or years

v2 is over 25 years old

Genesis of FHIR

Q: So what did HL7 have to offer in this space?

A: Not much

V2 old, and limited by it’s own rules (though hugely successful)

V3 too slow and too hard

CDA has success, but both limited and too hard

Different contexts of interoperability  different representations that aren’t compatible

Nothing suitable for light-weight integration, or for Health 2.0

Genesis of FHIR

HL7 undertook a “Fresh look”

What would healthcare exchange look like if we started from scratch using modern approaches?

Web search for success markers led to RESTful based APIs

Exemplar: Highrise (https://github.com/37signals/highrise-api)

Drafted a healthcare exchange API based on this approach

Timeline: Where does FHIR fit?

1980

2000

1990

2010

2020

1987

Fresh

Look

2011

CDA

2005

FHIR

DSTU

2014

Start V3

1995

10 years

years

FHIR Principles

FHIR Manifesto

Focus on Implementers

Target support for common scenarios

Leverage cross-industry web technologies

Support human readability as base level of interoperability

Make content freely available

Support multiple paradigms & architectures

Demonstrate best practice governance

We don’t actually have a formal manifesto, but these are the principles we adhere to.

Implementer Focus

Specification is written for one target audience: implementers

Rationale, modeling approaches, etc. kept elsewhere

Multiple reference implementations from day 1

Publicly available test servers

Starter APIs published with spec

C#, Java, Pascal, ObjectiveC, Javascript

more to come

Connectathons to verify specification approaches

Instances you can read and understand 

Lots of examples (and they’re valid too)

using HL7.Fhir.Instance.Model;

using HL7.Fhir.Instance.Parsers;

using HL7.Fhir.Instance.Support;

XmlReader xr = XmlReader.Create(

new StreamRead

IFhirReader r = new XmlFhirReader

// JsonTextReader jr = new JsonTe

// new StreamRead

// IFhirReader r = new JsonFhirRe

ErrorList errors = new ErrorList(

LabReport rep = (LabReport)Resour

Assert.IsTrue(errors.Count() == 0

Who’s read the v3 spec? – modeler & balloter focused

Spec is driven by people who write code

Numerous pieces have been changed because of experience with what worked when trying to implement

Even have a test workbench for RESTful servers

External libraries already available

Whole spec is built like software project

Support “Common” Scenarios

Focus on scenarios implementers ask for

Inclusion of content in core specification is based on core content rule

“We only include data elements if we are confident that most normal implementations using that resource will make use of the element” (80%)

Other content in extensions (more on this later)

Easy to say, governance challenge to achieve

Resources are simple and easy to understand and use

Design by constraint failed – years to develop, what was produced required yet more design to be implementable and after that might not be interoperable

How to determine the 80%? Look to existing specs – v2, v3, CDA templates, OpenEHR, jurisdictional projects, what implementations we’ve seen

If not sure, err on the side of “not in for now”

Note: not 80% of instances, 80% of implementations

Challenges with “raising the bar”

What happens when there aren’t many/any implementations?

Web technologies

HTTP

DataTypes W3C complaint

Instances shared using XML or JSON

REST supported

Web calls work the same way they do for Google, Facebook & Twitter

Rely on HTTPS, OAuth, etc. for security functions

Atom was used for bundles

Replaced in DSTU-2

DSTU 2

We try very hard to *not* invent stuff that exists elsewhere unless it’s really broken or totally unaligned with the FHIR principles.

Human Readable

CDA has both narrative and data

The data / narrative dynamic exists throughout the process

In FHIR, every resource should have a human-readable expression

Can be direct rendering or human entered

Even when you think your target will understand all the encoded data, reality is data often gets shared beyond the originally intended context

Allow for exceptions for things like automated device readings, etc.

Freely available

Unencumbered – free for use, no membership required

http://hl7.org/fhir

Was a bigger deal before HL7 decided to open up all IP

full legal text towards bottom of FHIR home page

Paradigms and Architectures

9:45

Paradigms

FHIR supports 4 interoperability paradigms

REST

Documents

Messages

Services

REST

“Representational state transfer” – an architecture for how to connect systems

CRUD

Outcomes

Simple stable interfaces

High Performance / Scalability

Visible Process (e.g. can debug)

Portability

Reliability (resistance to failure)

Document

Bundle

Resource 1

Resource 2

Composition

Similar to CDA

Collection of resources bound together

Root is a “Composition” resource

Just like CDA header

Sent as part of Bundle

One context

Can be signed, authenticated, etc.

DSTU 2

Message

Bundle

Resource 1

Resource 2

MessageHeader

Similar to v2 and v3 messaging

Also a collection of resources as a Bundle

Allows request/response behavior with bundles for both request and response

Event-driven

E.g. Send lab order, get back result

Can be asynchronous

DSTU 2

10:30

Service Oriented Architecture (SOA)

Do whatever you like

(based on SOA principles)

Ultra complex workflows

Ultra simple workflows

Individual resources or collections (in Bundle or other formats)

Use HTTP/S or use something else

Only constraint is that you’re passing around FHIR resources in some shape or manner

Comment about SOA discovery day

Services

Operations

RPC in REST

Examples in spec

Get Patient record

Expand ValueSet

Fetch Encounter data

Resources that define Input & Output

DSTU 2

FHIR

Repository

Regardless of paradigm

the content is the same

Lab System

Receive a lab result in a message…

FHIR Message

FHIR Document

…Package it in a discharge summary document

National

Exchange

REST

Governance

FGB

Management

FMG

Methodology

MnM

Oversight

TSC

Content

Work Groups

Content

Core Team

FHIR Governance Board

Maintains FHIR principles

Identifies risks, precepts

Handles coordination w/ external groups

FHIR Management Group

Coordinates Work Groups

Manages ballot process

Education delivery

Day-to-day activities

Modeling & Methodology

Defines criteria for artifacts

Determines processes

Documents best practices

Work Groups

Do the actual development work

Core Team

Temporary

Takes on work Work Groups can’t

Expedites

What haven’t we talked about yet?

Architectures

FHIR makes no assumptions about the architectural design of systems

You can use it for

Light or heavy clients

Central server or peer-to-peer sharing

Push or pull

Query or publish/subscribe

Loosely coupled or tightly coupled environments

With history tracking (versions) or without

Tags

Contain metadata about resources

Beyond ID, version & date

Used for different purposes:

Compliance to Profile

Security – e.g. sensitivity of resource

Indicate Document/Message

User defined

Transported in different ways:

REST – as an HTTP header

In a bundle (document, message, transaction) - in the metadata element of the resource or the bundle

DSTU 2

Versioning

Most recent version

http://server.org/fhir/Patient/1

Returns single resource

All versions

http://server.org/fhir/Patient/1/_history

Returns bundle of versions

Specific version

http://server.org/fhir/Patient/1/_history/1

Returns single resource

Version support is optional

Works at instance and type level – originally there

Version history - revival

33, v13 – 2012-12-05

33, v14 – 2012-12-08

/server.org/fhir/Patient/33/_history/14

/server.org/fhir/Patient/33/_history/13

/server.org/fhir/Patient/33/_history/15

/server.org/fhir/Patient/33

33, v15 – 2012-12-09

33, v16 – 2012-12-10

/server.org/fhir/Patient/33/_history/16

33, v17 – 2012-12-11

/server.org/fhir/Patient/33/_history/17

* The resource returns back to life!

Bundles

When more than one resource needed

Query result

Document

Message

Transaction

Specific Resource

Was “Atom feed” with JSON representation

DSTU 2

Bundle as a serialized Object Graph

Imagine that all resources in a single bundle

Links maintain references

Comment on new recources (cid: id’s)

About REST and Resources

Because REST was the biggest need and the most currently worked out…

REST in practice

“Resources” with an explicit and stable URI

The name for what gets exchanged in REST

Defined behaviour and meaning

Known identity / location

Quite an abstract idea

Formats: XML / JSON / RDF

Exchange using HTTP

Security: SSL / OAuth

“REST” followed loosely, hence “RESTful”

REST Activities

CRUD:

Create – create a new instance of data

Read – get the content (state) of an instance of data

Update – change the content of an instance of data

Delete – remove the instance of data

Delete isn’t necessarily physical

Execute – eg transaction

RPC vs REST

RPC (Remote Procedure Call):

Ask a server to perform some operation

Hand it a set of parameters

Server performs some operations

Returns a set of parameters

REST:

Define a URI that represents the state of something

Tell the server what the state should be

Server makes the state change happen

DSTU 2

RPC vs REST example

Example:

A device that monitors a patient %02 Sat

Raises an alarm on EHR if it’s too low

EHR can turn the alarm off

RPC:

POST http://acme.org/devices/turnOffAlarm

Parameters: device id, alarm id

REST:

POST http://acme.org/devices/[deviceid]/[alarmid]

Content: data to say “Alarm is off”

FHIR Activities

(Based on CRUD REST – not Operations)

Business Processes

Create a Patient Resource

Admit a patient:

Create an Encounter Resource

Move a patient from one bed to another

Find and update the encounter resource

Prepare a list of medications to administer

Search through the medication prescriptions for a patient (and then apply logic)

Or, use a List resource

Note relation to v2 messaging

FHIR Resource URLs

Template	Description	Example
[base]	Server URL	http://fhir.com
[base]/[type]	URL for type manager	http://fhir.com/Patient
[base]/[type]/[id]	URL for a resource	http://fhir.com/Patient/23
[base]/[type]/[id]/_history/[vid]	URL for a past version of a resource	http://fhir.com/Patient/23/_history/2

Activity/ Type

Activity	Description	Request Content	Response Content
create	Create a new resource with a server assigned id	Resource	--
search	Search through all resources of the type based on some filter criteria	Params	Bundle
history	Get a list of all the past versions of this resource type	--	Bundle
validate	Check that the content would be acceptable as an update	Resource	Resource (OperationOutcome)

Activity/ Instance

Activity	Description	Request Content	Response Content
read	Read the current state of the resource	--	Resource
vread	Read the state of a specific version of the resource (e.g. what it was in the past)	--	Resource
update	Update an existing resource by its id (or create it if it is new). Use the resource representation supplied	Resource	--
delete	Remove the resource so it is no longer present (note: it still has a history)	--	--
history	Get a list of all the past versions of the resource	--	Bundle

Activity/ System

Activity	Description	Request Content	Response Content
conformance	Get a conformance statement for the system	--	Resource
transaction	Update, create or delete a set of resources as a single transaction	Bundle	Bundle
history	Retrieve the update history for all resources (full pub/sub)	--	Bundle
search	Search through all resources of all types based on some filter criteria	Params	Bundle

Playing with FHIR

Access public server

DSTU 2

Sample CRUD stuff

Search for patient on name

Specify json or xml

Get a patient

Update a patient

Grahames & Ewouts server

Profiles & conformance

DSTU 2

10:15

The need for Profiles

Many different contexts in healthcare, but a single set of Resources

Need to be able to describe restrictions based on use and context

Allow for these usage statements to:

Authored in a structured manner

Published in a repository

Used as the basis for validation, code, report and UI generation.

Note Profiling is going to be very important

‘Message from the chair’

The need for Profiles

Profiles can serve the same purpose as:

CDA templates & implementation guides

HL7 v2 “static” profiles

CIMI implementation guides

OpenEHR Archetypes & templates

Profiles aren’t mandatory for interoperability, but they improve the degree of it.

Profiles never change meaning of an instance

Profiling a resource. For example...

Require that the identifier uses the NHI – and is required

Limit names to just 1 (instead of 0..*)

Limit maritalStatus to another set of codes that extends the one from HL7 international

Add an extension to support “Iwi”

Note: hardly any mandatory elements in the core spec!

Using Profiles

You can just go ahead and use a resource

No need for a profile

But you should write a profile

Document your usage in detail for partners

You can mark a resource or bundle with a profile

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

Denormalization for performance

Comment that profiles will be really important

Conformance

There’s a resource for documenting conformance to FHIR

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 themselves “FHIR Conformant”, a system must publish a Conformance instance

Doesn’t have to support XML – is can be json only

Conformance (cont’d)

Implementing FHIR

Where can FHIR be used?

Classic in-institution interoperability

Back-end e-business systems (e.g. financial)

Regional Health Information Organizations (RHIO)

National EHR systems

Social Web (Health)

Mobile Applications

Near

Term

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

Implementation Assistance

Reference Implementations – object models, parsers, serializers, clients, validators, utilities

Schema, Schematron, Validation Pack

1000’s of examples

Live Servers to test against

http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing

Connectathons

Servers

Use the servers to explore how it works

Write clients that use the test data

Test that you got your own system right

Most developers:

Use the servers to learn

Consult the documentation occasionally

We do recommend to read the specification

(RTFS)

Other Free software

See http://wiki.hl7.org/index.php?title=Open_Source_FHIR_implementations

Coming shortly:

“Sprinkler” – a conformance test tool for servers

“Forge” – an editor for conformance statements

A Value set Editor

Several implementation guide publishers

100

Connectathons

Open invitation to any interested party to come and write software that exchanges FHIR resources

Always hold one before HL7 meetings (last week) + Others by invitation

Mix of skills

Newbies (“where is the spec?”)

Old hands who’ve been to every connectathon

Experiment with new features

We have a virtual connectathon all the time…

101

Implementation Assistance

Stack Overflow – ask implementation questions

Link from front page

Search for answers first

Don’t ask for changes to the spec (get deleted!)

gForge Tracker – ask for changes to the spec

Link from bottom of every page

But have discussion somewhere first

Disqus – on every page of the specification

Skype – implementers channel – 251 participants

FHIR Email list, Connectathons, Tutorials

102

Migration

No expectation that people will migrate existing interfaces any time soon.

Initial adopters will be green-field, new technology

FHIR may see use behind the scenes in v2 systems before it sees use over the wire

Forthcoming policy initiatives may necessitate revisiting existing interfaces

Migration – v2

Already have at least one integration engine that supports translation between v2 and FHIR

Resources map to segments reasonably well

As always, the challenge with v2 mapping is the variability of v2 interfaces

“Common” mappings can be created, but they won’t be one size fits all

Focus of Connectathon this time

Migration – CDA

Made more complex by human-readable nature

Need to ensure text <-> entry linkages are retained

Will best be handled on a template by template basis

Start with well defined ones like C-CDA

Argonaut

105

DSTU 2

12:15

Text linkages not as important when not human-attested

105

What’s next?

106

Development plans

Performing rigorous QA on initial set of resources

Full support for C-CDA in next DSTU

Additional resources will continue to be introduced in future DSTU cycles as implementers identify needs

Continue to seek testing & real world implementation experience

107

Balloting plans

First Draft Standard for Trial Use ballot (DSTU) complete

DSTU publication in Jan 2014

Will provide a semi-stable platform for implementers while still allowing non-backward-compatible change for Normative version if implementation experience dictates

Additional DSTU versions roughly annually to make fixes, introduce new resources

Normative is around 2.5 years out

We want *lots* of implementation experience before committing to backward compatibility

108

Next Steps for you

Attend the other FHIR tutorials

Architects, Developers, Profiles

Read the spec: http://hl7.org/fhir

Comment on the spec (link on each page)

Follow #FHIR on Twitter

Shape the specification:

Join the FHIR track at this WGM

Join the FHIR email list http://wiki.hl7.org/index.php?title=FHIR_email_list_subscription_instructions

Try implementing it

Make Ballot comments

Come to a Connectathon!

109

Review

What does FHIR provide?

Resources (building blocks)

Extensions

Methodology

Versioning, Bundles, Profiles, Conformance

Syntax (XML, JSON)

Human readability

Support for multiple Paradigms

REST, Messaging, Documents, Services

111

FHIR Manifesto

Focus on Implementers

Target support for common scenarios

Leverage cross-industry web technologies

Require human readability as base level of interoperability

Make content freely available

Support multiple paradigms & architectures

Demonstrate best practice governance

112

FHIR & Cost of Integration

These factors will drive down the cost of integration and interoperability

Easier to Develop

Easier to Troubleshoot

Easier to Leverage in production

More people to do the work (less expensive consultants)

Competing approaches will have to match the cost, or disappear – effect is already being felt

Future impact of FHIR

Impact of FHIR on the market

Drive interoperability prices down

Higher Expectations

Sense of a community

Enormous interest from vendors and Legislators

Overall Market focus

Web based PHR

Mobile

Device Data management

Healthcare repositories (MHD+)

Retooling existing connections (v2, CDA)

Resistance is futile!

114

How much integration do you need? Nx2 – twice what you have

114

Questions?

http://www.hl7.org/implement/standards/fhir/

http://hl7.org/fhir/2015May/index.html

http ://wiki.hl7.org/index.php?title= FHIR

http://fhirblog.com/

115