FHIR Connectathon 7

Introduction

This page describes the seventh FHIR connectathon that will be held on Saturday September 13 and the morning (9am - 12.30pm) of Sunday September 14, 2014 in Chicago prior to the HL7 Working Group Meeting (see http://www.hl7.org/events/wgm092014/).

NOTE: This is a placeholder page - further details will be added, particularly details of the scenarios closer to connectathon.

Location

Exact room yet to be notified, but it will be in Chicago at the conference hotel

Themes

This connectathon will have 4 separate themes

• Basic patient management
  • The patient resource is well defined, and these scenarios are intended for a user new to FHIR to interact with it at a basic level. it covers:
  • search
  • 'CRUD'
  • history
  • extensions
• Profile & Value sets
  • creating profiles and value sets
  • using them to perform validation
• Experimental: SMART on FHIR
  • server playing the role of an EHR
  • clients playing the role of EHR plug-in
  • experimental themes involve ongoing change in the specifications in response to those preparing for the connectathon
• DICOM
  • TBA

Note: at every connectathon, participants attend and test functionality other than that described in the scenarios.

Connectathon Organization

The connectathon will be held over 2 days - the Saturday and Sunday prior to the HL7 Working Group Meeting.

Saturday is a full day, and is intended for participants to test and develop software in an informal way. Test servers will be available (actually, they are already - FHIR Test Servers ), but some participants may bring other servers along depending on the actors they are fulfilling. Sunday is the morning only, and has 2 parts:

• the formal testing part
• a mini-showcase where participants can demonstrate their work to the others

Enrollment

If you or your company are interested in participating in the connectathon, please do the following.

• Read the FHIR Specification and the FHIR wiki if you haven't already done so, to become familiar with the concepts.
• Read the scenario descriptions below.
• Send an email expressing interest to any of the Connectathon Planning team below. Be sure to include a link to your product's website (if available) and to state which scenarios your product will be engaged in.

Space at the venue is limited, so please register your interest as soon as possible. Preference will be given to those who are actually participating in the technical event, but observers are welcome if space permits.

For any queries, either contact a member of the planning team, or post your question in the FHIR list server

• a 'mini-showcase' session where participants can demonstrate their work to the group, if they choose.

Connectathon Planning Team

• David Hay, Orion Health
• Brian Pech, Kaiser Permanente
• Grahame Grieve, Health Intersections Pty Ltd

Registered Participants

• Health Intersections / Grahame Grieve.
  • server, all scenarios
• Furore / Ewout Kramer.
  • server, all scenarios
• Gordon Point Informatics / Lloyd McKenzie.
  • client scenario 2
• SMART Platforms / Josh Mandel
  • SMART on FHIR server and apps
• Orion Health / David Hay.
  • client scenario 2,
  • server for all scenarios

Connectathon tracks

This section lists the scenarios that are proposed for this connectathon. More detail will be added when approved. The scenarios are grouped according to two tracks. Track 1 is for those new to FHIR and requires minimal preparation in advance of the connectathon (at least for client applications). Track 2 is for those with some experience with the use of FHIR (or willing to devote up-front time to connectathon preparation) and exercises a more complete set of behavior designed to reflect a full production experience.

Track 1 - Patient

If creating a client, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.

Pre-requisites: none

1. Register a new patient

• Action: (Patient Demographics consumer) creates a new patient and save to Patient Service. The client can assign the Id.
• Precondition: Patient does not exist in service prior to action
• Success Criteria: Patient created correctly on server (use browser to inspect Patient)
• Bonus point: The Patient resource has an extension

>>Note: the requirement for the client to assign the Id has been relaxed. However, if the server assigns the Id, then the client will need to be able to retrieve the Id from the server response or by a patient query.

2. Update a patient

• Action: (Patient Demographics consumer) updates the patient created in scenario #1 and updates to Patient Service. The patient is retrieved by Id.
• Precondition: Patient has been created
• Success Criteria: Patient updated on server (use browser to inspect Patient)
• Bonus Point #1: Update a patient that has extensions, but leaving the extension untouched.
• Bonus Point #2: Update a patient that has extensions, and update the extension also.

3. Retrieve Patient history

• Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
• Precondition: There is a patient that has at least one update
• Success Criteria: patients history displayed in interface. (use browser query Patient Service)
• Bonus point: the UI allows the user to display previous versions of the Patient

4. Search for a patient on name

• Action: (Patient Demographics consumer) searches the patient Service for patients with a given name
• Precondition: Patients with that name have been created
• Success Criteria: patients displayed in interface. (use browser query to confirm)

Track 2 - Profile

This track explores interoperability between conformance tooling. There is 3 parts to this track:

• generating profiles and valuesets
• getting a server to test conformance
• implementing a process (server or client) that tests for conformance

The track also explores the use of profile tags.

1. Creating Profiles and Value Sets

This is for any process that produces Profiles and/or value sets

• Create a profile and/or valuesets
  • the method of creation is not fixed - it can be by hand, by some conversion process from other formats, or by some tool to profile the content
• The profile should have these properties:
  • Profile on Observation
  • fix observation.name to a limited set of LOINC codes
  • fix observation.value to a particular type
  • fix observation.value.units
  • fix one or more other attributes to max cardinality ..0
  • fix the value of reliability and status
• upload (create/update) the created resources on a registry
  • must get profile/value set references correct on the registry
• create pass and fail resources, and test them against the profile using the FHIR validation tool (from FHIR DSTU downloads)

For an example of the kind of profile that is intended, see ||link to be provided||

2. Getting a server to test conformance

• Given a set of observation resources (zip file to be posted here)
• and a profile (see below)
• submit the resource for validation using the validation operation on a server
  • there are no rules about how the submission is prompted
  • the server http://fhir.healthintersections.com.au/open is available, and should be the first system to test on, other servers from #3 below should be tested too
  • the validation operation requires that the profile be tagged with the full URL of the profile *on the server being tested*
  • the client must process the return response correctly (pass | fail, not be mislead by hints and warnings
• the profile master is here (link to be provided). Consult the server administrator for the correct profile tag for the test profile

3. Server Validation

• host a Profile and value set registry
• provide an implementation of the validation operation (at the resource level, no need to implement it at the instance level)
• correctly process profile tags on the validation operation
• correctly validate the submitted resource against the identified profile
  • pass|fail outcome must match those produced by the FHIR validation tool (from FHIR DSTU downloads)

Track 3 - SMART on FHIR

This track is the experimental track, focusing on user-facing apps that launch from an EHR or PHR via SMART on FHIR. SMART on FHIR provides a plug-in health app platform based on open standards including FHIR, OAuth2, and OpenID Connect. For any questions, please visit the SMART on FHIR Google Group.

1. SMART Server

Demonstrate a SMART on FHIR server. A successful server will do the following:

1. Support Patient and Observation end points, so an app can retrieve demographics and vital signs.

2. Support the SMART on FHIR launch and authorization, so an app can request permissions and learn patient context via OAuth2.

We've created a quick-start guide for SMART servers with examples of URLs, parameters, LOINC codes, and data payloads you'll need to get started.

2. SMART App

Demonstrate a SMART on FHIR client. A successful client will be a Web app or mobile app that can run against our SMART on FHIR testing server. It should:

• Talk to SMART's sandbox server
• Authorize to access patient data
• Retrieve patient data including demographics, vitals, and labs
• Present some useful view (can be just straight data table) of patient data

We've created a quick-start guide for SMART apps with code and examples to get you started.

You may also want to browser through sample apps on GitHub.

You can get started developing from http://localhost without registering your app -- but when you want to get your app running on the Web, just follow our self-service app registration instructions.

Track 4 - DICOMweb (Joint with DICOM)

DICOMweb is the web standard for medical imaging. It is primarily a set of RESTful services, enabling web developers to unlock the power of healthcare images using industry-renowned toolsets.

Although DICOMweb's REST interface and serialization (of DICOM objects) differs from FHIR, FHIR's ImagingStudy has been developed in cooperation with DICOM to make it easy for DICOM servers to expose their data as FHIR ImagingStudy on the FHIR REST api, and conversely for natively FHIR servers to expose their ImagingStudy Resources using DICOMweb's REST api.

As both DICOMweb and the FHIR ImagingStudy are recent additions to the standards, the ultimate goal of this track is not just to showcase working implementations but rather to receive feedback on where FHIR and DICOMweb are misaligned based on these implementation efforts.

We propose to focus on WADO-RS to:

• For FHIR servers: Expose the FHIR ImagingStudy using DICOMweb's REST interface, converting the ImagingStudy to the xml and/or json DICOM model
• For DICOMweb servers: Combine a study with its series and instances as and expose it as a FHIR ImagingStudy resource, using FHIR's REST interface (basically, a read operation) and FHIR's xml and/or json serialization model.

Servers

Publicly Available FHIR Servers for testing

Post-connectathon activities

Subsequent to the actual connectathon (i.e. Sunday PM) the "Application Implementation and Design (AID)" HL7 User Group will meet to discuss FHIR implementation approaches and design patterns. You're invited to share your 'lessons learned' with others in the FHIR implementation community, or to listen to other FHIR implementers.

• See AID Sunday PM Agenda for details.
• Please contact Rene Spronk to get hold of a slot on the AID agenda - we do appreciate you sharing your ideas and experiences.

Other References

• Other FHIR Connectathons:
  • 1st FHIR Connectathon (8 Sept. 2012 - Baltimore MD, USA)
  • FHIR Connectathon 2 (12/13 Jan. 2013 - Phoenix AZ, USA)
  • FHIR Connectathon 3 (4/5 May 2013 - Atlanta GA, USA)
  • FHIR Connectathon 4 (21/22 Sept. 2013 - Cambridge MA, USA)
  • FHIR Mini Connectathon (Oct. 2013 - Sydney, Australia)
  • FHIR Connectathon 5 (18/19 Jan. 2014 - San Antonio TX, USA)
  • FHIR Connectathon 6 (3/4 Jan. 2014 - Phoenix, Arizona, USA)