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

FHIR Connectathon 3

From HL7Wiki
Jump to navigation Jump to search

Introduction

This page describes the third FHIR connectathon that will be held on Saturday May 4 and the morning (9am - 12.30pm) of Sunday May 5 2013 in Atlanta, Georgia prior to the HL7 Working Group Meeting (see http://www.hl7.org/events/wgm052013/).

Location

As noted in the HL7 WGM Meeting Application, both Saturday and Sunday sessions will be held in Atlanta 3 room downstairs.

Themes

This connectathon will have 3 separate themes

Basic patient scenarios that will be tested

The patient resource is reasonably well defined, and these scenarios are intended for a user new to FHIR to interact with it at a basic level. It will include scenarios that cover:

  • search
  • 'CRUD'
  • history
  • extensions

Document scenarios

These scenarios are to test and validate the document management capability of FHIR. The document resource (either as a separate endpoint or using bundles) is less 'exercised' than patient resources, and is more complex. These scenarios are intended for people who have some familiarity with FHIR already, and also have the purpose of validating that the overall design of FHIR documents is fit for purpose. Some of the scenarios assume the use of the xdsEntry2 resource to store and retrieve documents, others will act directly against document resource endpoints.

Specification evolution

These are scenarios that are used by the core team to test assumptions made when developing the specification itself. They are intended for those with a good understanding of FHIR, and who don't mind the constant change that occurs during these scenarios.

Connectathon Organization

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.

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.
  • Send an email expressing interest to any of the Connectathon Planning team below. Be sure to include a link to your product's website (if available) and to state which scenarios your product will be engaged in.

Space at the venue is limited to 30 attendees, so please register your interest as soon as possible. Preference will be given to those who are actually participating in the technical event, but observers are welcome if space permits.

For any queries, either contact a member of the planning team, or post your question in the FHIR list server

Connectathon Planning Team

Registered Participants

  • Health Intersections / Grahame Grieve.
  • Furore / Ewout Kramer.
  • Gordon Point Informatics / Lloyd McKenzie.
  • Orion Health / David Hay.
  • YouCentric / Andy Stechishin, Dennis Rodriguez, Lorraine Constable - patient scenarios
  • NProgram / Rik Smithies - patient scenarios
  • Blue Wave / Hugh Glover - client actors
  • HealthFire / Jean Duteau & Joginder
  • Chuck Jaffe / Observer
  • Robert Hausam / Observer
  • Lantana / Dale Nelson - document / observer
  • (remote) Brett Esler / Patient Provider, Document Repository, Patient Demographics Feed
  • Odysseas Pentakalos / Observer

Attendees

Saturday

  • Grahame Grieve - Health Intersections
  • Lloyd McKenzie -
  • Ewout Kramer - Furore
  • David Hay - Orion health
  • Patrick Lloyd - Icode systems
  • Lorraine Constable - Constable Consulting
  • John Mohrke - GE Healthcare
  • Mike Davis - Dept Veterans Affairs
  • Kathleen Connor - Dept Veterans Affairs
  • Brian Park -
  • Claude Nanjo - Zynx Health
  • Polim Cabrita - Interfacewre
  • Hugh Glover - Blue Wave
  • Rik Smithies - National Programme
  • Farrah Darbonze -
  • Dale Nelson -
  • Mat Coolidge - Clinical Applications
  • Brett Esler - Oridashi (Remote)
  • Eliot Muir (evening only) - Interfaceware
  • Dave Shaver (evening only) - Corepoint Health

Sunday

  • Grahame Grieve - Health Intersections
  • Lloyd McKenzie -
  • Ewout Kramer - Furore
  • David Hay - Orion health
  • Colin Cabrita - interfaceware
  • Andy Stechishin
  • Dennis Rodriguez
  • Mat Coolidge
  • Kathleen Connor
  • Mike Davis - VA
  • John Moerke- GE Healthcare
  • Mead Walker
  • Eliot Muir - Interfaceware
  • Joginder Madre - Duteau Design
  • Jean Duteau - Duteau Design
  • Mike Henderson - Eastern Informatics
  • Dale Nalson - Lantana group
  • Rob Hausam
  • Hugh Glover - Blue Wave
  • Claude Nanjo
  • Anil Luthra - Opis consulting
  • Gil Alterovitz - MIT

Actors

  • Patient Consumer
    • this actor uses the patient/person information in a document registry to provide patient search/context
  • Patient provider
    • a server that stores patient resources
  • Document Creator
    • an actor that can create a FHIR document
  • Document Consumer
    • this actor extends Patient Consumer to search, retrieve and display patient-related documents
  • Document Repository
    • this actor provides server support for patient, person, XdsEntry, XdsFolder resources + Binary resources. For a bonus, XdsEntry2 should also be supported
  • Document Registry
    • this actor subscribes to one or more repositories using atom feeds for patient/person/XdsEntry/XdsFolder + bonus: XdsEntry2
  • Patient demographics feed
    • This actor generates creates/updates/link/unlink for patient and person information (default for this, person and patient example resources from the specification)
  • Document provider
    • This actor pushes documents to a repository and/or a registry (for the purposes of the connectathon, the registry ignores binaries)
  • XDS Bridge
    • This is a document provider that functions by accepting XDS.b submission sets, and converting them to FHIR batches

Scenarios

List of proposed scenario's

This section lists the scenarios that are proposed for this connectathon. More detail will be added when approved

1. Register a new patient

  • Action: (Patient Demographics consumer) creates a new patient and save to Patient Service. The client assigns the Id.
  • 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

2. Update a patient

  • Action: (Patient Demographics consumer) 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.

3. Retrieve Patient history

  • Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
  • Precondition: Patients with that name have been created
  • Success Criteria: patients history displayed in interface. (use browser query Patient Service)
  • Bonus point: the UI allows the user to display previous versions of the Patient

4. Search for a patient on name

  • Action: (Patient Demographics consumer) searches the patient Service for patients with a given name
  • Precondition: Patients with that name have been created
  • Success Criteria: patients displayed in interface. (use browser query to confirm)

document / xds scenarios

  • search for documents from xds registry (xdsEntry2) for a patient
  • update an exsting document
  • show document versions
  • create and submit a new document

? do we also want scenarios directly against a /document endpoint rather than /xdsentry2 ?

Servers

Publicly Available FHIR Servers for testing

Other References

Report

On the Saturday/Sunday of the weekend preceding the Atlanta Working Group Meeting, the FHIR group held its third connectathon.

The concept of ‘connectathon’ – where developers from many parts of the sector get together and test their ability to interoperate has a long history in IT. One of the first mentions I found was a 3 day workshop that the IAB (Internet Activities Board) held in 1985 to describe and discover the capabilities of a new standard – TCP/IP.

This was followed a few years later in 1988 at the ‘Interop Trade Show’ where 50 companies and 5000 developers got together in a more formal way to thoroughly test this protocol. The rest, as they say, is history.

Within healthcare IT of course, IHE (Integrating the Healthcare Enterprise) have long used the concept of connectathon as they developed their ‘profiles’ of the use of standards developed by other Standards Development Organizations, and it cannot be doubted that this has contributed significantly to the success and the widespread use of IHE profiles such as ATNA, XDS, XDM, XCA and XDR that forms the backbone of the ‘Direct’ messaging protocol and eHealth Exchange (formerly NwHIN-Exchange) that are an important part of Meaningful Use in the US.

As the FHIR standard was starting to take shape in HL7, the core team put forward the idea that HL7 should also use this concept as a way of advancing the standard as rapidly as possible (after all, it has ‘Fast’ in its name). Their thoughts were that this forum would allow the ‘early adopters’ a chance to ensure that FHIR would meet its goal of being an implementer friendly standard, as well as being semantically robust, and this has certainly been the case. FHIR connectathons were held in Baltimore (September 2012) and Phoenix (January 2013) with the focus of these events predominantly on the ‘infrastructure’ aspects of FHIR – details of the REST interaction, structural aspects of the resources and so on. The FHIR connectathons are also partially “hackathons”, where developers get together and write code, also proving another dimension of “Fast”.

The most recent connectathon itself was held on the Saturday and the Sunday morning, with the Saturday being more of a ‘hackathon’ to help participants tune their software and the Sunday being the more formal testing against a set of Scenarios relating to interaction with the Patient resource (although this was nowhere near as formal as the IHE events due to the newness of the standards). The scenarios were:

  • Register a new patient
  • Update a patient
  • Retrieve patient history
  • Search for a patient by name

There were over 20 attendees (the room was completely full) on both days. In addition there were 2 remote attendees – who demonstrated remarkable fortitude in remain awake for Atlanta time! From these people there were 3 groups had servers that could service 1 or more of the scenarios, and there were 7 participants that completed 1 or more of the client scenarios.

Some observations/thoughts on the event, and implications for the next event in September.

  • The ‘infrastructural’ components of FHIR (i.e. the basic resource structure, REST interfaces/query mechanism, bundle structure) are sufficiently stable now that they don't need to be a focus of connectathon’.
  • We’re seeing an increasing number of organizations attending – vendors and health organizations – as well as interested individuals. In addition, about half the people present have been at all the events so far.
  • The use cases for the next event need to be more ‘business/clinical’ focussed. We can assume the infrastructure and, to a slightly lesser extent, the resources themselves, but we need to be thinking/testing how they support real-world requirements.
  • Our organization for the event needs to continue to become more rigorous. We need to move beyond the more informal ‘ad-hoc’ hackathon approach to the more formal approach – once we’re past DSTU for example, certification becomes something we need to pay real attention to.
  • We need to continue to recognize and support the different reasons why people attend these events:
    • Just observing to see what all the fuss is about
    • Trying out the basics of FHIR
    • Being formally tested against the scenarios
    • Pushing the development of the standard itself.
  • We need to have the Scenarios being tested defined as early as possible – along with the test data – so that people have plenty of time to prepare.
  • And we need a way for people who have put a lot of work into preparing for these events to showcase their efforts (as IHE do) – perhaps as a separate event at the Working Group Meeting where the regular attenders (those not mad enough to come on the weekend before) and also see the progress being made.

In summary, the connectathon was a great event and those attending have all given us good feedback. The next one will be in Boston, and it’s going to be really important to register early, as space is limited and we would like know – and possibly alter – the Scenarios based on who attends, and what actors they intend to support. We’re currently thinking that PHR and security (oAuth as profiled by IHE-IUA) are going to be the focus this time around. We’ll be sending out notices as planning becomes concrete and we look forward to another great event! There will also be a connectathon at the Sydney IHIC conference, in October for those who find it difficult to travel to the US.

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Connectathon_3&oldid=75571"