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

Difference between revisions of "FHIR Connectathon 1"

From HL7Wiki
Jump to navigation Jump to search
m (Rene spronk moved page FHIR Connectathon to FHIR Connectathon 1)
 
(39 intermediate revisions by 8 users not shown)
Line 2: Line 2:
 
[[Category:Active FHIR Discussion]]
 
[[Category:Active FHIR Discussion]]
  
−
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). Any FHIR implementers are welcome to join in the event.
+
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 =
 
= Enrollment =
 
If you or your company are interested in participating in the connectathon, please do the following.
 
If you or your company are interested in participating in the connectathon, please do the following.
−
*Read the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.
+
*Read the '''[http://hl7.org/fhir FHIR Specification]''' and the '''[[ FHIR | 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 messaging in a RESTful web environment, rather than to specify myriad details of interface or application behavior.
+
*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 [mailto:mike_henderson_2000@yahoo.com Mike Henderson].  Be sure to include a link to your product's website and to state which scenarios your product will be engaged in.
+
*Send an '''email expressing interest''' to connectathon project manager [mailto:mike_henderson_2000@yahoo.com 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.
 
*Join our '''preparatory conference call''' for which details are given in the next section.
  
−
= Preparatory Conference Call =
+
= Preparatory Conference Calls =
−
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.
+
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.
 
*Date/time: Tuesday, June 26, 2012, at 4:00 p.m. EDT.
 
*Telephone: +1 770 657-9270, passcode 459876#
 
*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 =
 
= Connectathon Planning Team =
Line 23: Line 31:
 
*[mailto:marc.koehn@gpinformatics.com Marc Koehn], Gordon Point Informatics Ltd
 
*[mailto:marc.koehn@gpinformatics.com Marc Koehn], Gordon Point Informatics Ltd
 
*[mailto:gavin.tong@gpinformatics.com Gavin Tong], Gordon Point Informatics Ltd
 
*[mailto:gavin.tong@gpinformatics.com Gavin Tong], Gordon Point Informatics Ltd
 +
 +
= Committed Attendees =
 +
* [http://furore.com Furore] ([mailto:e.kramer@furore.com Ewout Kramer])
 +
* [http://www.healthintersections.com.au Health Intersections] ([mailto:grahame@healthintersections.com.au Grahame Grieve])
 +
* [http://www.orionhealth.com Orion Healthcare] (David Hay)
 +
* [http://www.corepointhealth.com/ Corepoint Health] ([http://twitter.com/realworldhl7 Dave Shaver])
 +
* [http://www.ringholm.de/ Ringholm] (Rene Spronk)
 +
* [http://www.thrasys.com/ Thrasys] (Chris White)
 +
* [http://exnihilum.com/ Exnihilium] ([mailto:tlukasik@exnihilum.com Thomas Lukasik])
 +
* HealthFire ([mailto:jean@duteaudesign.com Jean Duteau])
 +
* [http://www.mohawkcollege.ca/ Mohawk] ([mailto:duane.bender@... Duane Bender])
 +
 +
And there are more coming...
  
 
= General Comments =
 
= General Comments =
−
The aim of this initial connectahon is to test the infrastructural components of FHIR (mainly: its REST interface and Profiles), using a few relatively stable Resources.
+
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. Systems should have a) capacity to ignore unknown extensions, b) (for server applications) capacity to store unknown extensions and reproduce them faithfully
+
*There will be '''extensions'''
−
* All participating applications should play the role of at least one of the Person actors (see below)
+
**Applications should be able to share stuff with other applications whose extensions you don't understand
−
* 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)
+
**'''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 =  
 
= Scenarios =  
  
−
During the connectathon 3 types of workflows will be tested: the creation and exchange of Profiles, Persons, and Lab Reports.
+
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 Profiles ==
+
== Resource Conformance ==
−
See [http://www.hl7.org/implement/standards/fhir/constraint.htm constraint profiles]
+
See [http://www.hl7.org/implement/standards/fhir/conformance.htm|conformance statements].  Conformance statements may reference [http://www.hl7.org/implement/standards/FHIR/profile.htm|Resource Profiles] and some systems may choose to make use of profile information to guide interaction.
  
 
Actors:  
 
Actors:  
−
* Profile Consumer
+
* Conformance Consumer
−
** Simple system access to retrieve referenced profiles (the information flow is in one direction only: Profile Server to Profile Consumer).
+
** Simple system access to retrieve conformance statements (the information flow is in one direction only: Conformance Server to Conformance Consumer).
−
** operations: read (and optionally history and vread) on "profile"
+
** operations: search on "conformance"
−
** success criteria: can retrieve profiles from a server (and optionally and watch for changes)
+
** 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.
  
−
* Profile Server
+
* Conformance Server
−
** provides services a RESTful service that stores and publishes resource profiles
+
** provides services a RESTful service that publishes conformance statements
−
** operations: create,update,read,vread,delete,history,updates,search on "profile" and conformance statement
+
** operations: search on conformance statement
−
** success criteria: supports both maintainer and consumer
+
** optionally: read on "profile"
 +
** success criteria: enables consumer
  
−
* Profile Maintainer
+
* 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.
−
** 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:
 
Full Scenario:
−
* system analyst A defines a profile on a Person resource
+
* Conformance Consumer is configured with the base URL of a Server
−
* submits it to a Profile registry
+
* Conformance Consumer queries Conformance Server via REST to determine what operations & search parameters it supports for operations of interest
−
* Implementer B searches for Profile, and accesses it
+
* Conformance Consumer uses information so gained to determine what operations it will use when engaging with that server - what resources, what search parameters
−
* System C sees a resource that references the profile, and retrieves it
 
  
 
== Person ==
 
== Person ==
Line 67: Line 91:
 
* Person Demographics Author
 
* Person Demographics Author
 
** Creates and modifies Person records, has the capability to store those in a ''Person Demographics Server''
 
** 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.
+
** Note: this Actor SHALL also play the role of the ''ConformanceConsumer'' actor.
 
* Person Demographics Consumer
 
* Person Demographics Consumer
 
** queries for demographics data, id to demographics, partial demographics to list of candidates
 
** 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.
+
** 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
 
* Person Demographics Active Tracker
 
** subscribes to all changes to a Person record, processes all changes occuring.
 
** 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 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.
 
** 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
+
* Person Demographics Subscriber
−
** Capability to store Person resources, and to make those available to ''Person Demographics Consumers''.
+
** 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
+
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 ==
 
== LabReport ==
Line 90: Line 127:
 
** Note: this Actor SHALL also play the role of the ''Profile Consumer'' actor.  
 
** Note: this Actor SHALL also play the role of the ''Profile Consumer'' actor.  
 
* LabReport Server
 
* LabReport Server
 +
** Note: This Actor SHALL also play the role of the ''ConformanceServer'' actor.
 
* LabReport Consumer
 
* LabReport Consumer
 
** Note: this Actor SHALL also play the role of the ''Profile Consumer'' actor.  
 
** Note: this Actor SHALL also play the role of the ''Profile Consumer'' actor.  
Line 96: Line 134:
 
** Note: this Actor SHALL also play the role of the ''Profile Consumer'' actor.  
 
** 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.
 
** 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 ==
 +
 +
* Other FHIR Connectathons:
 +
**[[FHIR Connectathon]] (Sep 8, 2012)
 +
**[[FHIR Connectathon 2]] (Jan 12/13, 2013)
 +
**[[FHIR Connectathon 3]] (May 4/5, 2013)
 +
**[[FHIR Connectathon 4]] (Sep 21/22, 2013)
 +
[[Category:FHIR Connectathons]]

Latest revision as of 12:32, 17 February 2014


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"