This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Connectathon 6"

From HL7Wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by 13 users not shown)
Line 63: Line 63:
 
*[mailto:brian.pech@kg.org Brian Pech], Kaiser Permanente
 
*[mailto:brian.pech@kg.org Brian Pech], Kaiser Permanente
 
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd
 
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd
 +
 
== Registered Participants ==
 
== Registered Participants ==
  
Line 71: Line 72:
 
* Gordon Point Informatics / Lloyd McKenzie.
 
* Gordon Point Informatics / Lloyd McKenzie.
 
** client scenario 2
 
** client scenario 2
 +
* SMART Platforms / Josh Mandel
 +
** server, maybe a questionnaire app (or will combine forces with someone else's)
 
* Orion Health / David Hay.  
 
* Orion Health / David Hay.  
 
** client scenario 2,
 
** client scenario 2,
 
** server for all scenarios
 
** server for all scenarios
 
* Richard J. Ettema (AEGIS.net)
 
* Richard J. Ettema (AEGIS.net)
 +
** Track 1, client and server
 +
** Track 3, demo of FHIR messaging - Clinical Decision Support Immunization Forecasting
 +
* GE Healthcare / Scott Bolte.
 +
** client scenario 3 - genetic profiles, BDD auto-testing, repeatable testing via tagged resources
 +
** landscape photography
 +
* Edidin Group, Inc / Howard S. Edidin
 +
** Track 3
 +
* NIST/ Bill Majurski
 +
** Track 3
 +
* Oridashi / Brett Esler
 +
** 2 servers: tracks 1 + 3 - read-only legacy system wrappers; pub/sub
 +
* University Health Network / James Agnew
 +
** Hoping to get a code-generator up that will build a server for tracks 1+2.... but will it work?
 +
* Lantana Consulting Group / Dale Nelson, Rick Geimer, Sean McIlvenna
 +
** Track 3: CDA/Composition profile resource tooling, services
 +
* Roche Diagnostics International Ltd / Stefan Heesch
 +
** Track 1 as client + track 3: notifications on resource updates/creations for mobile devices, probably Windows 8.x and Android
 +
* Systems Made Simple, Inc. / Jeff Ting, Matt Jenks, Bill de Beaubien, Jeff Hoherz , Cosmo DiFazio
 +
** Tracks 1 and 2, both as clients
 +
*Health Samurai/Choice Hospital Systems/Pavel Smirnov
 +
*RelayHealth / Peter Bernhardt and Todd Pitchall
 +
* Brian Postlethwaite (DCA eHealth Solutions)
 +
** Track 1+2 (.NET clients - extensive Questionnaire publishing)
 +
* NProgram / Rik Smithies
 +
** Update my server up to DSTU
  
 
== Connectathon tracks ==
 
== Connectathon tracks ==

Latest revision as of 00:41, 4 May 2014

Introduction

This page describes the sixth FHIR connectathon that will be held on Saturday May 3 and the morning (9am - 12.30pm) of Sunday May 4, 2014 in Phoenix Arizona prior to the HL7 Working Group Meeting (see http://www.hl7.org/events/wgm052014/).

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

Location

To be determined

Themes

This connectathon will have 3 separate themes

Basic patient scenarios that will be tested

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 will include scenarios that cover:

  • search
  • 'CRUD'
  • history
  • extensions


Questionnaire

The Questionnaire resource is a structured set of questions and their answers. The Questionnaire may contain questions, answers or both. The questions are ordered and grouped into coherent subsets, corresponding to the structure of the grouping of the underlying questions.

It's primary use is to facilitate the capture of information via forms based interfaces, which can then be used to generate and/or update more specific resources.

Here is some extra information on Questionnaires:

Experimental

These are scenarios that are used by the core team to test assumptions made when developing the specification itself. They are intended for those with a good understanding of FHIR, and who don't mind the constant change that occurs during these 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

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
    • server, maybe a questionnaire app (or will combine forces with someone else's)
  • Orion Health / David Hay.
    • client scenario 2,
    • server for all scenarios
  • Richard J. Ettema (AEGIS.net)
    • Track 1, client and server
    • Track 3, demo of FHIR messaging - Clinical Decision Support Immunization Forecasting
  • GE Healthcare / Scott Bolte.
    • client scenario 3 - genetic profiles, BDD auto-testing, repeatable testing via tagged resources
    • landscape photography
  • Edidin Group, Inc / Howard S. Edidin
    • Track 3
  • NIST/ Bill Majurski
    • Track 3
  • Oridashi / Brett Esler
    • 2 servers: tracks 1 + 3 - read-only legacy system wrappers; pub/sub
  • University Health Network / James Agnew
    • Hoping to get a code-generator up that will build a server for tracks 1+2.... but will it work?
  • Lantana Consulting Group / Dale Nelson, Rick Geimer, Sean McIlvenna
    • Track 3: CDA/Composition profile resource tooling, services
  • Roche Diagnostics International Ltd / Stefan Heesch
    • Track 1 as client + track 3: notifications on resource updates/creations for mobile devices, probably Windows 8.x and Android
  • Systems Made Simple, Inc. / Jeff Ting, Matt Jenks, Bill de Beaubien, Jeff Hoherz , Cosmo DiFazio
    • Tracks 1 and 2, both as clients
  • Health Samurai/Choice Hospital Systems/Pavel Smirnov
  • RelayHealth / Peter Bernhardt and Todd Pitchall
  • Brian Postlethwaite (DCA eHealth Solutions)
    • Track 1+2 (.NET clients - extensive Questionnaire publishing)
  • NProgram / Rik Smithies
    • Update my server up to DSTU

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 - Questionnaire

1. Retrieve a completed Questionnaire Instance

  • Action: Download a completed Questionnaire and display to the user
  • Precondition: completed Questionnaires exist on the server
  • Success Criteria: A rendition of the Questionnaire is presented
  • Bonus point: Allow the user to display all the completed questionnaires for a given user and select one to display
  • Bonus point: Allow the Questionnaire to be presented in a different format (like a mobile device)

2. Retrieve a Questionnaire Template

  • Action: Download a Questionnaire defined as a template, and render a User Interface from it
  • Precondition: Questionnaire templates exist on the server
  • Success Criteria: A User Interface matching the Questionnaire is presented
  • Bonus point: Provide a list of templates for the user to select from
  • Bonus point: Choose a template that references an external (or contained) ValueSet, and use the ValueSet contents to display a selection list

3. Save a Questionnaire Instance

  • Action: Complete a Questionnaire and save it to a server
  • Precondition: Questionnaire template previously downloaded
  • Success Criteria: The completed Questionnaire can be retrieved and displayed
  • Bonus point: Pre-populate the Questionnaire from information that already exists in the client system

4. Create a Questionnaire Template

  • Action: Create a new Questionnaire as a template and save it to a server
  • Precondition: None
  • Success Criteria: The Questionnaire can be retrieved and used to generate a completed Questionnaire instance
  • Bonus point: Implement a template that uses some of the standard extensions - like show/hide...

5. Generate resources

  • Action: Create external resources from a completed Questionnaire
  • Precondition: completed Questionnaire send to server
  • Success Criteria: The Questionnaire and the resources generated from it can be retrieved from the server
  • Bonus point: There is a reference to the external resource in the Questionnaire.
  • Bonus point: There is a reference to the Questionnaire from the generated resource in some way.

Note: This scenario could be server or client initiated

6. Pre-populate a questionnaire

  • Action: Return a questionnaire instance pre-populated with information referenced in a provided CCDA Document
  • Precondition: CCDA Document and Questionnaire definition exist. Concept map indicates linkage between document data elements and Questionnaire definition
  • Success Criteria: A partially-populated questionnaire instance is returned containing appropriate data from the supplied document
  • Bonus point: Do the same thing with data drawn from a FHIR document

Track 3 - Experimental

Will depend on what attendees want to do...

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