FHIR Connectathon 1

Event Planning

A FHIR Connectathon will be held on Baltimore USA on Saturday September 8th, 2012 (at the same place as the HL7 working meeting, the day before it starts). The connectathon is hosted by the RIMBAA WG and we are working towards confirming some sponsorship to meet the costs of the basic infrastructure.

Any FHIR implementers are welcome to join in the event.

Please note that the connectathon planning team is Mike Henderson, Rene Spronk, Peter Hendler, Grahame Grieve, and a representative from a sponsor (yet to be confirmed)

General Comments

The aim of this initial connectahon is to test the infrastrutural 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. Systems should have a) capacity to ignore unknown extensions, b) (for server applications) capacity 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)

Scenarios

During the connectathon 3 types of workflows will be tested: the creation and exchange of Profiles, Persons and Labreports.

Resource Profiles

See constraint profiles

Actors:

• Profile Author
  • Allows for the creation (mandatory) and modifification (optional) of profiles, has the capacity to send these profiles to the Profile Server
  • Note: modification requires that this Actor be grouped with the Profile Consumer actor.
• Profile Server
  • Provides a repository of Profiles; provides a RESTful service (per FHIR spec) for Profiles (i.e. providing all service operations for Profiles, inclusive of queries).
• Profile Consumer
  • Provides user access to profiles on Profile Server (find/retrieve). The information flow is in one direction only: Profile Server to Profile Consumer.

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

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
• LabReport Server
• LabReport Consumer
• LabReport Active Tracker
  • subscribes to all changes to a LabReport, processes all changes occuring.
  • 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.