1. Da Vinci Community Forum
Connectathons!
Summer 2019
Disclaimer

2. Preparing to participate Tracking Issues Touchstone Testing Use Cases
Agenda
Purpose & Goals
Preparing to participate
Tracking Issues
Touchstone Testing
Use Cases
Upcoming Connectathons
Disclaimer

3. Join a community of FHIR users
Why Connectathons?
Join a community of FHIR users
Develop and test your system and use of the standard
Increase the visibility of resources, profiles and implementation guides.
In-Depth discussion of a use case
Demonstrate what’s possible
Refine the FHIR Specification
Testing as part of a connectathon is a pre-requisite for resources and implementation guides progressing up the FHIR Maturity Model.
Disclaimer

4. Connect with your track Useful Skills System Readiness
How to get the most out of Connectathon
Connect with your track
Useful Skills
System Readiness
Disclaimer

5. Track Pages on Confluence
Connect with your Track
Track Pages on Confluence
Connect to your track lead on Zulip (chat.fhir.org)
Communicate issues so others will know what you know.
Disclaimer

6. Familiarize yourself with base technologies
Useful Skills
Familiarize yourself with base technologies
ReST-based APIs and conventions – e.g. GET vs. POST vs. PUT, HTTP headers
Inspect and understand the HTTP protocol with tooling – i.e. Postman, Browser debugger, Server-side debugger
General Healthcare System
Clinical concepts
Administrative and payer functions
Disclaimer

7. Usefull Skills Cont. FHIR interactions:
FHIR-for-developers or FHIR-for-architects level training
Specifically understand the profiles, resources within the relevant IG
JWTs and access tokens
Experience with a FHIR client and server libraries
You can find a list of these at
CDS-Hooks 
Ability to build/configure/test/monitor APIs
e.g. via java, node.js, AWS Lambdas and gateway
JSON is a must
Basic database management skills
SMART 
Web UI development – e.g. Angular or React
OAuth
Disclaimer

8. Preparing your Environment
Environment Accessibility
Open – over the internet
Firewall should allow inbound and outbound http(s)
Open Sandbox environment is ideal
Access for doc shares like Google Docs, Zulip, and other internet-based tools
Configuration changes are often required on site
Try to ensure manageability without off site dev-ops support
Test with simulators ahead of time
SMART-on-FHIR
Implement and test with multiple sandboxes – HSPC, Epic App-Orchard, Cerner
Pre-test with the healthcare instances, if possible, since provisioning (of client-ids and OAuth handshake)
support multiple client-ids
For EPIC, support and test Internet Explorer (embedded browser used by Hyperspace)
Systems readiness:
Do NOT expect that the system will not need changes during the connect-a-thon. There will always be nuances of interpretation, different codesets, endpoints, payloads, etc., which will require that code is changed and redeployed
Thus, make sure that your developers have appropriate access to the environment and can perform the changes without relying on DevOps support. This is particularly important for HL7 connect-a-thons that happen on the weekend
Environment needs to be open/accessible over the internet
If running server systems on a laptop, the client firewall needs to be configurable to allow inbound http(s). This is NOT typically the case for secure/HIPAA-compliant systems.
If running server in a data center, firewall needs to be configurable to allow inbound and outbound http(s). For the connect-a-thon, an open sandbox environment is ideal.
Recommend AWS or Google Cloud, for flexibility
Test with simulators ahead of the connect-a-thon – this reduces changes that may be required “on the day”
Make sure you have a device that communicate with zulip
Make sure you have a device that can access open shares, such as google docs (many corporate devices will block access)
SMART-on-FHIR in particular:
Implement and test with multiple sandboxes – HSPC, Epic App-Orchard, Cerner
Pre-test with the healthcare instances, if possible, since provisioning (of client-ids and OAuth handshake) can take a while to get compatibly configured and working
Make sure you can support multiple client-ids, since you cannot force each EHR to use the same one
For EPIC, make sure to support and test Internet Explorer (the embedded browser used by Hyperspace)
Disclaimer

9. Zulip – https://chat.fhir.org/
Tracking Issues
Zulip –
Disclaimer

10. Gforge - https://gforge.hl7.org
Tracking Issues
Gforge -
Be sure to sign up for a Gforge account ahead of time
Disclaimer

11. Conformance Testing Value Set
Defines a set of coded values (see "Using Codes" for more details)
StructureDefinition
Makes rules about how a resource (or type) and its data elements are used in a particular context, including defining how extensions are used. A structure definition references value sets for the coded elements in a resource
CapabilityStatement
A statement of the kinds of resources and operations provided and/or consumed by an application. The Capability Statement references profiles to describe specific use of resources by the application
Implementation Guide
A single coherent collection of capability statements, profiles, extensions, value sets, and documentation describing a set of interoperable applications
To provide details about specific usage of the frameworks and resource contents, FHIR provides a conformance layer that implementers, national/regional programs, and other profiling organizations such as IHE, can use to provide a computable statement about how the resources and their exchange paradigms are used to solve particular use cases. The conformance layer itself is implemented using these key resources.
Conformance with this specification does not provide any guarantee of patient or data safety. However, choosing to not conform to this specification carries additional risk in two ways:
FHIR has been subject to a level of review and vetting unlikely to be received by any non-conformant variation; variations may result in introduction of undetected risks
FHIR-like solutions (based on FHIR, but not conformant) may set expectations by trading partners which are not met due to the non-conformance of the system and these un-met expectations may also result in risk
Disclaimer

12. Touchstone Validation Testing www.Touchstone.com
Disclaimer

13. Confluence
Disclaimer

14. Confluence
Disclaimer

15. Confluence site coming soon Focus on RIs for NEW WORK ONLY Alerts
VIRTUAL Connectathon
August 28 and September 4
12PM – Noon
Confluence site coming soon
Focus on RIs for NEW WORK ONLY
Alerts
Payer Coverage Decision
Prior Authorization Support
Directory
Disclaimer

16. Atlanta Use Cases Alerts Clinical Data Exchange (CDex)
Data Exchange for Quality Measures - DEQM
(Under Clinical Reasoning Track at FHIR Connectathon)
Directory
Payer Coverage Discovery
Payer Data Exchange (PDex)
Prior Authorization Support
Documentation Templates and Rules (DTR) with Coverage Requirements Discovery (CRD)
Disclaimer

17. https://confluence.hl7.org/display/FHIR/Connectathons
ATLANTA FHIR CONNECTATHON
Disclaimer