How Facebook's Technologies can define the future of VistA and Health IT

Copyright © 2015 M/Gateway Developments Ltd

How Facebook’s Technologies can Define the Future of VistA

…and HealthIT generally!

Rob Tweed

Twitter: @[email protected]

http://www.mgateway.com

mailto:[email protected]


The Future of VistA

• Where is the next generation of developers going to come from?

• How can code be re-factored to attract and retain new developers?– Young developers are in high demand elsewhere– Mumps seen as career-limiting

• VistA experts getting older / retiring and not being replaced

• Ferocious learning curve of VistA needs taming


24 August 2015


Facebook's Technical Challenges

• Massive application development needs• Need to scale to unimaginable levels and

still have very high performance• Need high availablity• Need to support desktop and full range of

mobile devices• Need to cope with multiple versions of

apps


The Facebook Technologies

• React.js• React Native• GraphQL• Relay


Why did they bother?

• Facebook has better things to do than develop its own technologies just for the sake of it– If they needed them, there must have been

good reasons– They analysed their development, support &

maintenance issues• Concluded that what's already out there wasn't

good enough


Can't Ignore Facebook

• Facebook can't just talk a good game– The stuff they create has to work– Their technology is working well and realising

major benefits at Facebook• it has to be worth examining• They actively want others to use them

– To create a community from which they benefit


Relevant to VistA and HealthIT?

• Massive application development needs• Need to scale to very high levels and still

have very high performance• Need high availablity• Need to support desktop and full range of

mobile devices• Need to cope with multiple versions of

apps



• Facebook develop database-backed browser and mobile applications

• Complex, graph-based data• They need to ensure that their teams work

as efficiently together as possible– Avoid re-invention of wheels– Ensure code and data re-use



• VistA, and HealthIT more widely, needs:– proven, not theoretical solutions– to maximise the productivity of scarce,

expensive development resources– to build on the shoulders of giants instead of

reinventing wheels and assuming they have unique needs

• Application development• Data interchange

– to attract a new generation of developers



• React.js– Radically new approach to front-end

JavaScript frameworks, based on components, one-directional data flow and "virtual DOM"

• React Native• GraphQL• Relay


ReactState Change Virtual DOM Real

DOM

React.js

Browser


ReactState Change

Re-renderVirtual DOM

RealDOM

React.js

Browser


ReactState Change


RealDOM

React.js

Browser

CalculateChanges


ReactState Change Virtual DOM Real

DOM

React.js

Browser

CalculateChanges

Modify DOMwith least neededchanges



• React.js• React Native

– Uses React principles and patterns for developing true mobile applications

• GraphQL• Relay


ReactState Change


iOSUIKit

Components

Standard React.js

JavaScriptCore



• React.js & React Native– Same team can develop browser & native

apps– Use same back-end logic for both

• GraphQL• Relay



• React.js• React Native• GraphQL

– Declarative data-fetching specification language.

– Doesn't dictate a particular language or back-end technology

• Relay




– Intelligent front-end environment– allows GraphQL queries to be co-located with

React Components– intelligently caches fetched data to minimise

network round-trips




– And they're all now available as Open Source projects


All or nothing?

• React and React Native can be used without GraphQL

• GraphQL can be used on its own– Can be used with other JS frameworks– Doesn't even need to be used in the context

of browser-based or mobile applications

• Relay pulls together React and GraphQL, so doesn't make sense on its own


Find out more:

• http://bit.ly/1IN2rIJ

http://bit.ly/1IN2rIJ


Why GraphQL instead of REST?

• Fetching complex object graphs require multiple REST round-trips

• GraphQL can return a complex graph in one request, and just return the fields needed by the client


Single GraphQL Endpoint v REST

Server

Endpoint 1 Endpoint 2

Client

Feature 1 Feature 2

Data Data



Server

Endpoint 1

Feature 1

Client

Data

Endpoint 2

Feature 2

Data

Endpoint 3

Feature 3

Data

Endpoint 4

Feature 4

Data



Server

1

1

Data

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10



Server

Endpoint 1 Endpoint 2

Client

Feature 1.1 Feature 2.1

Data Data

Endpoint 1.1 Endpoint 2.2



Server

1

1

Data

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

1 2 3 4 5 6 7 8 9 10



Server

1

1

Data

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

1 2 3 4 5 6 7 8 9 101 2 3 4 5 6 7 8 9 101 2 3 4 5 6 7 8 9 10



Server

GraphQL

Client

Feature 1 Feature 2

Query Query



Server

GraphQL

Client

Feature 1 Feature 2

Data Data


GraphQL Server

• Exposes a single endpoint• Endpoint parses and executes queries• Queries execute over a type system• Type system available via introspection

• EWD.js can now be used to create a VistA-based GraphQL Server– Makes use of Facebook's JS Reference

Implementation


GraphQL: Hierarchical

{ "user" : { "id": 3500401, "name": "Jing Chen", "isViewerFriend": true, "profilePicture": { "uri": "http://someurl.cdn/pic.jpg", "width": 50, "height": 50 } }}

Responses are JSONand can be complex graphs:


GraphQL: Hierarchical

{ "user" : { "id": 3500401, "name": "Jing Chen", "isViewerFriend": true, "profilePicture": { "uri": "http://someurl.cdn/pic.jpg", "width": 50, "height": 50 } }}

Request shaped just like response:

{ user(id: 3500401) { id, name, isViewerFriend, profilePicture(size: 50) { uri, width, height } }}


GraphQL: retro-fitting using EWD.jsvar Query = new GraphQLObjectType({ name: 'Query', fields: () => ({ patient: { type: Patient, args: { id: { type: new GraphQLNonNull(GraphQLID) } }, description: 'Patient Object', resolve(parent, {id}, context) { var ewd = context.rootValue; var data = new ewd.mumps.function('legacy^function', [id]); data.id = id; return data; } } })});

•Legacy functions•Wrappers around RPCs•FileMan API wrappers


GraphQL: App-layer Protocol

• No particular wire protocol required– HTTP(S)– WebSockets


GraphQL: Introspective

• Type system can be queried using GraphQL's own syntax

• Facebook predict growing range of tools, client software

• Allows for automated parsing of incoming JSON data into strongly-typed interfaces


GraphQL = Graph Data Model

• Caregraf's work on FMQL– FileMan provides meta-data for VistA's data

graph• Potential for wrapping FMQL in GraphQL?• Automated generation of GraphQL

schemas from FileMan data?


GraphQL and VistA

• Appears to be a perfect fit• Can be used today

– EWD.js + Facebook Reference Implementation

– Demo….


The Future of VistA

• Where is the next generation of developers going to come from?

• How can code be re-factored to attract and retain new developers?– Young developers are in high demand elsewhere– Mumps seen as career-limiting

• VistA experts getting older / retiring and not being replaced

• Ferocious learning curve of VistA needs taming


Facebook Tech Could Help• Apply current expertise to building out GraphQL Schema

& Type System for VistA– No re-factoring needed to existing working code

• Queries against VistA Type System– No Mumps knowledge needed to introspect or query VistA

• Adopt React, Relay, GraphQL– Working with VistA as cool and leading edge as working for

social media, media, games firms– VistA can be modernised by a new generation, using tools and

technologies they want to use and that enhance their career– Mobile & desktop apps can be built using same teams and using

same GraphQL-based back-end


Application to Wider HealthIT?

• Interchange of data between EHRs and other HealthIT systems– FHIR as Lingua Franca


GraphQL & FHIR

• Josh Mandel already exploring mapping GraphQL queries around FHIR payloads

• https://github.com/jmandel/gra-fhir-ql

https://github.com/jmandel/gra-fhir-ql


Here today, gone tomorrow?• Unlikely – Facebook committed to using these

technologies for foreseeable future• cf Google who drop technologies regularly

– If anything will be gone tomorrow it's Angular!• Also Facebook have designed all 3 technologies

to meet needs across their full development environment after lengthy analysis:– Front-end– Back-end– Database queries


Facebook's Technologies

• Could be just what's required for VistA and Health IT more widely

• I've already demonstrated their feasibility• Next steps?


How Facebook’s Technologies can Define the Future of VistA

…and HealthIT generally!

Rob TweedTwitter: @rtweed

[email protected]://www.mgateway.com

mailto:[email protected]

How Facebook's Technologies can define the future of VistA and Health IT

Technology

Transcript of How Facebook's Technologies can define the future of VistA and Health IT