FHIR Connectathon 1

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). Any FHIR implementers are welcome to join in the event.

Preparatory Conference Call

A vendor/implementor conference (similar to what's done for the IHE connectathons) will be held virtually via telcon link and GoToMeeting 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.

• Date/time: Tuesday, June 26, at 4:00 p.m. EDT.
• Please note that the connectathon planning team is Mike Henderson, Rene Spronk, Peter Hendler, Grahame Grieve, Marc Koehn, and Gavin Tong.

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)
• Authentication is not in scope of the connectathon - not 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 Labreports.

Resource Profiles

See constraint profiles

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.