FHIR Connectathon 1

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

• Date/time: Tuesday, June 26, 2012, at 4:00 p.m. EDT.
• Telephone: +1 770 657-9270, passcode 459876#
• Web meeting link: https://www1.gotomeeting.com/join/141723121

Conference 2

• Date/time: Tuesday, July 10, 2012, at 4:00 p.m. EDT.
• Telephone: +1 770 657-9270, passcode 459876#
• Web meeting link: https://www1.gotomeeting.com/join/939804585, Meeting ID: 939-804-585

Connectathon Planning Team

• Mike Henderson, Eastern Informatics, Inc., project manager
• Rene Spronk, Ringholm bv
• Peter Hendler, Kaiser Permanente
• Grahame Grieve, Health Intersections Pty Ltd
• Marc Koehn, Gordon Point Informatics Ltd
• Gavin Tong, Gordon Point Informatics Ltd

Committed Attendees

• Furore (Ewout Kramer)
• Health Intersections (Grahame Grieve)
• Orion Healthcare (David Hay)
• Corepoint Health (Dave Shaver)
• Ringholm (Rene Spronk)
• Thrasys (Chris White)
• Exnihilium (Thomas Lukasik)

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 Profiles, Persons, and Lab Reports.

Resource Profiles

See constraint profiles. Note also that systems are connected to profiles by Conformance Statements, and servers will be expected to provide these at the connectathon.

Actors:

• Profile Consumer
  • Simple system access to retrieve referenced profiles (the information flow is in one direction only: Profile Server to Profile Consumer).
  • operations: read (and optionally history and vread) on "profile"
  • success criteria: can retrieve profiles from a server (and optionally and watch for changes)

• Profile Server
  • provides services a RESTful service that stores and publishes resource profiles
  • operations: create,update,read,vread,delete,history,updates,search on "profile" and conformance statement
  • success criteria: supports both maintainer and consumer

• Profile Maintainer
  • A profile maintainer provides a tool that assists a human user to create a valid FHIR profile that provides constraints/extensions/vocab bindings for one or more resources, and allows the user to interact with a profile registry
  • operations: create,update,delete,updates,search on "profile"
  • success criteria (1): produce a profile that is valid according to the FHIR schema, and that is process correctly by the FHIR publication tooling for profiles
  • success criteria (2): can fetch profiles, watch for changes, and upload new resources
  • Note: commonly grouped (although not mandatorily so) with the Profile Consumer actor.

Full Scenario:

• system analyst A defines a profile on a Person resource
• submits it to a Profile registry
• Implementer B searches for Profile, and accesses it
• System C sees a resource that references the profile, and retrieves it

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 Profile Consumer 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 Profile Consumer actor.
• 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 Profile Consumer 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 Server
  • Capability to store Person resources, and to make those available to Person Demographics Consumers.

Scenario

•  ?

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
• 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.