This wiki has undergone a migration to Confluence found Here

FHIR Connectathon 3

From HL7Wiki
Jump to navigation Jump to search


This page describes the second 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


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 - ), 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.


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.
  • Orion Health / David Hay.
  • Furore / Ewout Kramer.
  • Gordon Point Informatics / Lloyd McKenzie.
  • YouCentric / Andy Stechishin, Dennis Rodriguez


  • 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


List of proposed scenario's

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

patient scenarios

  • for a core patient resource
    • search for patient by name
    • retrieve single patient
    • update patient
    • retrieve patient history
    • retrieve specific version of patient
  • as above, but for a patient profile that has extensions

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 ?

Scenarios from previous connectathon for review

Register a patient

  • Action: (Patient Demographics feed) creates or updates patient and person to (Document Registry)
  • Precondition: Patient/Person does or does not exist on Document Registry (both conditions)
  • Success Criteria: Patient/Person updated correctly on server (use browser to inspect person and patient)
  • Bonus #1: testing for patient linking/unlinking

Submit a document

  • Action: (Document Provider) creates or updates documents to (Document Repository)
  • Precondition: Document Does not exist on document repository
  • Precondition: Patient/Person already exists on registry
  • Success criteria: document updated correctly on server (use browser to inspect) (check folders as well)
  • bonus: use XdsEntry2

Find a patient

  • Action: (Patient Consumer) searches and finds patient record on (Document Registry). Search by name, gender, date of birth
  • Success Criteria: patients can be found an displayed

Find a document

  • Action: (Document Consumer) searches and finds documents on (Document Repository) or (Document Registry). Search by code, type, author, folder
  • Action: (Document Consumer) retrieves document
  • Success Criteria: documents can be found, retrieved, an displayed


Publicly Available FHIR Servers for testing Also: for the duration of the connectathon, David Hay's server is

Other References