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
  • A profile author provides a tool that helps a human user create a valid FHIR profile that provides constraints/extensions/vocab bindings for one or more resources
  • operations: none
  • success criteria: produce a profile that is valid according to the FHIR schema, and that is process correctly by the FHIR publication tooling for profiles
• Profile publisher
  • Allows a user (person or application) to upload a resource profile to a FHIR RESTful server
  • operations: create|upload on "Profile"
  • success criteria: profile is successfully accepted by server
• 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 publisher and consumer
• 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.
  • operations: read,search,updates,history? on "profile"
  • success criteria: can retrieve profiles from a server, and watch for changes

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

Standing issues:

• Are author, publisher and consumer too granular? authoring a resource is quite a different process to publish/consume. Would you ever consume without publishing or vice versa?
  • note - publisher/author/consumer are required to be combined if modifications are planned)

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.