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

FHIR Connectathon 1

From HL7Wiki
(Redirected from FHIR Connectathon)
Jump to navigation Jump to search


A FHIR Connectathon will be held at the Hyatt Regency Hotel in Baltimore, Maryland, USA on Saturday, September 8, 2012 (at the same place as the HL7 Plenary and Working Group Meeting, the day before it starts).

If your company or organization can demonstrate the ability to connect via one of the FHIR scenarios outlined below, you are welcome to join in the event. Onsite participation will be limited to the first 20 enrollees.

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. Details will be added to these descriptions in the coming weeks. However, the intent is to maintain focus on the goal of implementing HL7-type exchange in a RESTful web environment, rather than to specify myriad details of interface or application behavior.
  • Send an email expressing interest to connectathon project manager Mike Henderson. Be sure to include a link to your product's website (if available) and to state which scenarios your product will be engaged in.
  • Join our preparatory conference call for which details are given in the next section.

Preparatory Conference Calls

Vendor/implementor conferences (similar to what's done for the IHE connectathons) will be held virtually via telcon and web meeting links and will give a high-level overview of FHIR, outline the connectathon scenarios, and provide contact points for participants and a timeline for the work items leading up to and through the event.

Conference 1

Conference 2

Connectathon Planning Team

Committed Attendees

And there are more coming...

General Comments

The aim of this initial connectathon is to test the infrastructural components of FHIR (mainly: its REST interface and Profiles), using a few relatively stable Resources.

  • There will be extensions
    • Applications should be able to share stuff with other applications whose extensions you don't understand
    • Client applications should be able to ignore unknown extensions, unless they are flagged as "must understand", in which case they should invoke appropriate exception handling
    • Server applications should be able to store unknown extensions and reproduce them faithfully
  • All participating applications should play the role of at least one of the Person actors (see below)
  • Authentication is not in scope of the connectathon -- no authentication methods will be tested (that doesn't mean it's out of scope for FHIR, just not for the connectathon)

Scenarios

During the connectathon 3 types of workflows will be tested: the creation and exchange of Conformance, Persons, and Lab Reports.

To ease operations: - If possible, make content available using HTTP rather than HTTPS - If using HTTPS, disable any expectation for client side certificates or other security features

Resource Conformance

See statements. Conformance statements may reference Profiles and some systems may choose to make use of profile information to guide interaction.

Actors:

  • Conformance Consumer
    • Simple system access to retrieve conformance statements (the information flow is in one direction only: Conformance Server to Conformance Consumer).
    • operations: search on "conformance"
    • optionally: read on "profile"
    • success criteria: can retrieve conformance statements from a server (and optionally watch for changes). May also optionally query "Profile" to check for unsupported "must understand" extensions.
  • Conformance Server
    • provides services a RESTful service that publishes conformance statements
    • operations: search on conformance statement
    • optionally: read on "profile"
    • success criteria: enables consumer
  • In theory we could have a repository actor that functions as a clearing house for conformance statements and profiles, but that's a less likely scenario and unnecessary in the near term.

Full Scenario:

  • Conformance Consumer is configured with the base URL of a Server
  • Conformance Consumer queries Conformance Server via REST to determine what operations & search parameters it supports for operations of interest
  • Conformance Consumer uses information so gained to determine what operations it will use when engaging with that server - what resources, what search parameters

Person

See persons

Actors

  • Person Demographics Author
    • Creates and modifies Person records, has the capability to store those in a Person Demographics Server
    • Note: this Actor SHALL also play the role of the ConformanceConsumer actor.
  • Person Demographics Consumer
    • queries for demographics data, id to demographics, partial demographics to list of candidates
    • Note: this Actor SHALL also play the role of the ConformanceConsumer actor.
  • Person Demographics Server
    • Capability to store Person resources, and to make those available to Person Demographics Consumers.
    • Note: This Actor SHALL also play the role of the ConformanceServer actor.

The following actors need to be fleshed out as the concepts of subscribing and notifications have not been addressed in the FHIR specification.

  • Person Demographics Active Tracker
    • subscribes to all changes to a Person record, processes all changes occuring.
    • Note: this Actor SHALL also play the role of the ConformanceConsumer actor.
    • Note: this Actor is normally grouped with the Person Demographics Consumer. The latter is a query-only-once Actor, whereas this Actor commits to consume and processes all (future) changes to a Person record.
  • Person Demographics Subscriber
    • accepts subscriptions to a Person record, sending out notifications for any changes that occur
    • Note: this Actor is normally grouped with the Person Demographics Server.

Scenario 1

  • Client Author creates a new Person resource and sends it to Server.
  • Client Consumer queries the Server and retrieves the Person resource.

Scenario 2

  • Client Tracker subscribes to changes in a Person resource
  • Client Author modifies the Person resource.
  • Client Subscriber sends a notification of the change to Client Tracker.

LabReport

The LabReport scenario has been deliberately kept as simple as possible.

  • For LabReport, applications SHOULD not implement <admission> and <clinicalinfo>; applications processing the LabReport MAY ignore these elements. The <requester> SHALL be an Organization resource.
    • Note: Specimen resource to be documented prior to the connectathon.

Actors

  • LabReport Author
    • Note: this Actor SHALL also play the role of the Profile Consumer actor.
  • LabReport Server
    • Note: This Actor SHALL also play the role of the ConformanceServer actor.
  • LabReport Consumer
    • Note: this Actor SHALL also play the role of the Profile Consumer actor.
  • LabReport Active Tracker
    • subscribes to all changes to a LabReport, processes all changes occuring.
    • Note: this Actor SHALL also play the role of the Profile Consumer actor.
    • Note: this Actor is normally grouped with the LabReport Consumer. The latter is a query-only-once Actor, whereas this Actor commits to consume and processes all (future) changes to a LabReport.

Scenario 1

  • Consumer retrieves a list of available lab reports for a known person
  • Active Tracker subscribes to receive updates to one or more of the lab reports
  • Author updates one of the lab reports
  • Active Tracker receives notification of the update

Connectathon results

The first FHIR Connectathon was held on Saturday 8 September 2012 in Baltimore from 8:00 a.m. to 5:00 p.m.

Participants

  • Duane Bender
  • Keith Boone
  • Jean-Henri Duteau
  • Grahame Grieve
  • David Hay
  • Peter Hendler
  • Ewout Kramer
  • John Landers
  • Joginder Madra
  • Gordy Raup
  • Chris White

Observers

  • Chuck Jaffe
  • Paul Knapp
  • Thomas Lukasik
  • John Moehrke
  • Rene Spronk
  • Stephen Chu
  • Vin Sekar

Manager

  • Mike Henderson

Demonstrators

Repository servers were provided by representatives of HealthFire, Health Intersections, Furore and Thrasys. FHIR clients were developed (some in advance of the event, others entirely during the Connectathon itself) and demonstrated by representatives of GE Healthcare, HealthFire, Health Intersections, Kaiser Permanente, Mohawk College and Orion Health.

Lessons learned

  • Although rapidly developed, clients were able to interact with multiple servers, and to sync servers if they included that capability.
  • Small-footprint clients could potentially be used as testing tools.
  • Extensions could be provided to allow transmission of date/time recorded information and synchronization or update links to authorized clients.
  • Participants agreed that FHIR provides an easily accessible standard for a rapidly deployable framework. Secondary in importance is the RESTful framework within which FHIR operates.
  • There is a governance board that has final accountability for the integrity of the FHIR specification. Ewout Kramer is the developer community representative to that board.
  • The success of the Connectathon bodes well for the continuance of this event. It will be profitable to learn both from today's event and from the example of IHE connectathons.
  • Connectathon manager Mike Henderson will be asking for feedback from the participants that can be used to help plan connectathons around future HL7 meetings.
  • While it is desirable to hold the Connectathon immediately prior to the HL7 meeting, a day other than Saturday may need to be chosen to avoid conflict with the Saturday meeting of the Technical Steering Committee.

Other References

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_1&oldid=83517"