FHIR Connectathon 5

Introduction

This page describes the fifth FHIR connectathon that will be held on Saturday January 18th and the morning (9am - 12.30pm) of Sunday September 19th, 2013 in San Antonio, Texis prior to the HL7 Working Group Meeting (WGM) - see http://www.hl7.org/events/wgm012014/.

Background

IMPORTANT: Registration

To attend the Connectathon, every participant must register for the WGM using the link above. (Registration link will be added as soon as it's available.) When registering, select the Connectathon option, indicating whether you're participating as a Participant or Observer (see below).

Now that FHIR is close to publishing as an official standard and is becoming more stable, registration costs are increasing to be in line with other aspects of the WGM.

This year, there is room for up to 90 participants and up to 10 observers, so hopefully we will not run short of space. However, early registration is encouraged so you can participate in discussions on clarifying Connectathon scenarios and to better support Connectathon planning. Once you are registered, you will be contacted by a member of the FHIR Management Group to collect information including:

• what track(s) you expect to participate in
• whether you'll be working on a client and/or server
• whether you'll be using XML and/or JSON
• whether you're working as part of a team (and if so, who's on it)

and any other information needed to help manage the Connectathon execution.

What is a Connectathon?

A Connectathon is an opportunity to see how a specification behaves when the rubber hits the road. Many implementers come together in a single room and, over the space of a couple of days, make use of the HL7 FHIR specification to share clinical data in ways that reflect real-world usage. It's a chance to experiment, to test, to discuss implementation strategies and to have significant influence on the development of the FHIR standard. After participating in a Connectathon, you'll have an excellent sense of if, when and where and how your organization will want to make use of FHIR.

A Connectathon is *not* a demo (though there will be opportunities to demonstrate - see below). A Connectathon is also not a certification process (though as FHIR becomes more stable, HL7 is exploring that as a possible future component.) You will receive no certificate of accomplishment, though (with your permission), your organization will be listed as a Connectathon participant on the HL7 wiki and you'll receive a prized ribbon noting your involvement that you can wear proudly for the remainder of the WGM.

Connectathon Process

The connectathon will be held over 2 days - the Saturday and Sunday prior to the HL7 Working Group Meeting.

Saturday is a full day, and is intended for participants to test and develop software in an informal way. Test servers will be available (actually, they are already - FHIR Test Servers ), but some participants may bring other servers along depending on the actors they are fulfilling. Sunday is the morning only, and has 2 parts:

• the formal testing part
• a 'mini-showcase' session where participants can demonstrate their work to the group, if they choose.

Participating and Observing

Attendees to the Connectathon must register as either a Participant or as an Observer.

Participation means developing software that makes use of the FHIR standard. The software can be written in any language and may implement any scenario from any of the identified tracks (see below). Participation does *not* mean your software has to work perfectly (or at all), nor must it complete all scenarios in a given track. Participants are encouraged, though not required to demonstrate what they've accomplished to other Connectathon participants during the demonstration portion of the Connectathon on Sunday morning. In addition, there will be an opportunity to demonstrate their accomplishments to the HL7 community at large at the joint FHIR/Tooling/Application Implementation & Design (formerly RIMBAA) session on Tuesday evening. Participants *are* expected to participate in decisions around lessons learned and provide feedback based on their use of the specification.

Observers are those who wish to observe the activities of the Connectathon but won't actually be writing code. As such, they don't get the discount HL7 provides for those who are helping polish the FHIR specification by putting it into practice. However, they will have the opportunity to watch many developers exercising the FHIR specification and will get a sense for the implementability, maturity and readiness of the FHIR specification. That said, learning by doing is always more effective, so if you're now an architect or manager who hasn't coded in ages, you might consider this as an opportunity to polish up your rusty skills, improve your Connectathon experience and save a bit of the registration fee to boot.

Important: An essential part of the Connectathon experience is that it must be safe to fail. This means that participants and observers commit to keeping the activities of the Connectathon private to the Connectathon. Feel free to blog, tweet and share your own successes and failures, but please don't discuss the activities of other participants without their permission.

Preparation

The degree of preparation required for the Connectathon depends on several things:

• What track you're implementing
• Whether you're implementing client or server
• Whether you have existing code that provides user interface, persistance and/or other layers
• Degree of development experience

Developers with some degree of experience have completed a client application supporting Track 1 with no prior preparation at all and very little familiarity with the FHIR specification. All development was completed during the Connectathon. Implementing a server or more advanced tracks will greater up-front development. On the other hand, they'll provide more in-depth knowledge of the FHIR specification.

At minimum, participants should do the following prior to arrival:

1. Have reviewed the tracks and decided what you intend/hope to implement (if reality intervenes and you arrive with less than planned, that's ok)
2. Fill in your information in this Connectathon Google document
3. Have a functioning development environment. Hotel bandwidth is shared, so try to have a local copy of anything "big".
4. Have at least a passing familiarity with the [FHIR specification]
5. Provide a Conformance resource instance describing the actual (or intended) functionality of your system. (Servers must return this resource when queried. Clients may email a copy to Connectathon organizers)

Keep in mind that the FHIR specification is under evolution. Agreed changes are being applied based on ballot feedback from the DSTU ballot. A version of the specification will be frozen early in December. Test servers should be up-to-date shortly there-after. (Announcements will be made on the http://www.hl7.org/myhl7/managelistservs.cfm as well as being sent to any registered participants.

If you have any questions or concerns, please send them to one of the Connectathon organizers:

• David Hay, Orion Health
• Brian Pech, Kaiser Permanente
• Lloyd McKenzie, Gordon Point Informatics

Execution

Tracks

The connectathon is organized into four separate tracks. Each track is targeted at different types of participants. While participation in multiple tracks is possible, we expect most participants will follow a single track. Each track involves two or more actors. Participants must indicate which actor(s) they intend to support. Each track is broken up into a number of related scenarios. Participants are encouraged to support all scenarios in a track. However, they may choose to limit their scope to a subset of the scenarios.

Track 1 - Patient management

The scenarios in this track are intended for new implementers to the FHIR specification. It should require the least amount of preparation. It provides an opportunity to use the RESTful operations and to work with a resource that will be a key element of almost all FHIR implementations. The scenario covers:

• search
• 'CRUD'
• history
• extensions

Pre-requisites: none

Actors

• Patient Client: A system that creates, updates and queries the patient (and typically displays patient data in a user interface)
• Patient Server: A system that stores and exposes patient data in response to requests

Scenario 1.1 - Register a new patient

Process

• Action: Patient Client creates a new patient and save to Patient Service. The client can choose to assign the Id or must extract the id from the server response.
• Precondition: Patient does not exist in service prior to action
• Success Criteria: Patient created correctly on server (use browser to inspect Patient)
• Bonus point: The Patient resource has an extension

Scenario 1.2 - Update a patient

Process

• Action: Patient Client updates the patient created in scenario #1 and updates to Patient Service. The patient is retrieved by Id.
• Precondition: Patient has been created
• Success Criteria: Patient updated on server (use browser to inspect Patient)
• Bonus Point #1: Update a patient that has extensions, but leaving the extension untouched.
• Bonus Point #2: Update a patient that has extensions, and update the extension also.

Scenario 1.3 - Retrieve Patient history

Process

• Action: Patient Client searches the Patient Service for the history of a Patient
• Precondition: There is a patient that has at least one update
• Success Criteria: Patient's history displayed in interface. (use browser to query Patient Service)
• Bonus point: The UI allows the user to display previous versions of the Patient

Scenario 1.4 - Search for a patient on name

Process

• Action: Patient Client searches the Patient Service for patients with a given name
• Precondition: Patients with that name (or name part) have been created
• Success Criteria: Patients are displayed in interface. (Use browser query to confirm)
• Bonus point: Use the paging parameters to control the number of records returned and navigate through them

Track 2 - Documents

This scenario is more advanced and involves working with multiple resources packaged together into documents. It includes several sub-tracks, some of which include the use of resources supporting IHE's draft Mobile Health Documents (MHD) specification (the FHIR implementation of XDS).

Note: All of the scenarios below assume that you have retrieved the patient resource from the server you are querying, as you will need the patient id in most of them. And just a hint: when retrieving a separate resource for a patient, you are actually performing a query against that resource (usually) against the 'subject' or 'patient' property. so, to get patient conditions (or problems) you would use a search like GET [base-url]/Condition?subject:Patient=123

Actors

• Document Client: An actor that can submit and retrieve FHIR documents
• Document Server: This actor extends Patient Client to search, retrieve and display patient-related documents

Scenario 2.1 - Document Submission

Process

• Action: Document Client produces a document and submits it as a feed to the /mailbox of the Document Consumer
  • The Document Server registers the document as a Binary resource
  • The Document Server creates a DocumentReference entry pointing to the resource on the
  • Note: The document must include a Patient, at least one Provider, at least one List and at least 2 of the following 4 resources: AllergyIntolerance, Condition, MedicationStatement, Procedure. These resources might be created directly by the submitting client or might have been retrieved from one or more servers that supports these resources.
• Precondition: The patient associated with the created document exists on the server
• Success Criteria: A DocumentReference for the resource exists, pointing to the document as a Binary resource
• Bonus point: Client digitally signs the document and the Server verifies the signature

Scenario 2.2 - Document Search

Process

• Action: Document Client retrieves a list of documents for a patient by using the 'search' operation on the DocumentReference resource, then retrieves a particular document pointed to by the DocumentReference from /Binary and displays it
• Precondition: One or more documents (with accompanying references) exists for the Patient
• Success Criteria: Selected document is displayed
• Bonus point: Client verifies the signature

Scenario 2.3 - Document Decomposition

Process

• Action: Document Client sends a document to the [baseurl] for a Document Server, causing the server to treat the document as a transaction and split the document into its constituent resources, making them available for query and the various resource end-points.
• Precondition: None (if the patient doesn't exist, it should get created)
• Success Criteria: Resources from document available for direct retrieval
• Bonus point: Some of the resources in the document are updated versions of resources that have already been sent to the repository

Scenario 2.4 - Document Recomposition

Process

• Action: Document Client requests a document bundle from a Document Server based on a specific Composition (referenced by id)
• Precondition: The Composition and referenced resources exist on the server
• Success Criteria: A document bundle is received by the client and displayed
• Bonus point: Server attempts to reconstitute the document such that the signature remains valid

Track 3 - Devices

This track is sponsored by the Healthcare Devices Work Group. The focus of the track is to ... [todo]

Actors

• Device: Todo (feel free to change name too)
• Device Intermediary: Todo (feel free to change name too)
• Clinical Repository: Todo (feel free to change name too)

Scenario 3.1 - ????

Process

• Action: Actor does something with Other Actor
• Precondition: Todo
• Success Criteria: Todo
• Bonus point: Todo (or drop)

[Add additional scenarios as appropriate.]

Track 4 - Experimental

This track provides an opportunity for interested implementers to exercise additional aspects of the FHIR specification. In some cases they may build on prior tracks, in other cases they're a separate track. Each experimental scenario is an independent sub-track. Additional tracks can be added based on the desires of Connectathon participants. To add an additional experimental track, at least two (and preferably 3 or 4) independent Connectathon participants must express interest in testing a particular set of FHIR-related functionality and define the proposed Connectathon scenario. This information can be sent to the #Connectathon Organizers. They will review the proposed scenario and add and announce the additional track. Proposed experimental tracks should be announced no later than Dec. 31, 2013 and preferably earlier to maximize the opportunity for other implementers to participate.

Experimental Scenario 4.1 - Secure Connection

This scenario is intended to be used as an "add-on" to scenarios from other tracks. It adds on the expectation that HTTP communications occur over HTTPS and transactions are authenticated using OAuth.

Actors

• Authenticating Client: Todo (feel free to change name too)
• Resource Owner: The system responsible for approving an access request
• Authorization Server: The system that authenticates the client's identity and provides a token allowing access to a resource
• Resource Server: The system that provides the resource (i.e. a FHIR server)

Note: We expect most Connectathon participants to implement either the Authenticating Client or Resource Server actors. At least one Resource Owner and Authorization Server will be made available at the Connectathon. (Though if you want to bring additional ones, go for it)

Process

• Action: Todo
• Precondition: Todo
• Success Criteria: Todo
• Bonus point: Todo

Experimental Scenario 4.2 - Security Audit Recorded

This scenario is intended to be used as an "add-on" to scenarios from other tracks. It leverages the SecurityEvent resource to allow recording audit information and reporting based on security relevant audit events recorded.

Actors

• Audited System: The system (client, server, or other) that records that an auditable event has happened using SecurityEvent
• Audit Repository: The server that records audit data (many servers may perform both roles)
• Audit Reporter: The client that, with authorization, uses the SecurityEvent to report/alarm/alert

Record Audit Event Process

• Action: Audited System records a SecurityEvent in the Audit Repository
• Precondition: Audited System has some security relevant event happen that it needs to record
  • e.g., A FHIR Server receives a query or update request to some resource (or receives a document or message) and acts on or rejects the request.
• Success Criteria: Audit record for event is recorded (verify with browser)
• Bonus point: Audit records are maintained on a distinct server from the one being audited

Report on Audit Event Process

• Action: Audit Reporter Queries on SecurityEvent in the Audit Repository
• Precondition: Audited Repository has some SecurityEvent records
• Success Criteria: Something useful is done with the resulting SecurityEvent resources returned. (e.g. Accounting of Disclosures Report)
• Bonus point: Audit Reporter combines events from multiple Audit Repository

Experimental Scenario 4.3 - Claims Messaging

In this scenario, a Claim message is sent to the inbox of an adjudicator and a Adjudication response message is returned. (Note: both of these resources are in draft state and are not part of the DSTU.

Servers

Publicly Available FHIR Servers for testing

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)