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

FHIR Connectathon 8

From HL7Wiki
Jump to navigation Jump to search

Introduction

This page describes the eighth FHIR Connectathon that will be held on Saturday January 17 (9am - 5pm++) and the morning (9am - 12.30pm) of Sunday January 18, 2015 in San Antonio prior to the HL7 Working Group Meeting (see http://www.hl7.org/events/wgm012015/).

Location

The meeting will be held in Maverick at the host hotel, Hyatt Regency San Antonio on the Riverwalk, San Antonio, TX.

Google page: FHIR Connectathon, 2015 January San Antonio

Themes

This connectathon will have 3 separate themes

  • Basic patient management
    • The patient resource is well defined, and these scenarios are intended for a user new to FHIR to interact with it at a basic level. it covers:
    • search
    • 'CRUD'
    • history
    • extensions
  • Patient Access to Data (DAF/Argonaut/Meaningful Use data Access suite)
  • Experimental: Profiles and Conformance


Note: at every connectathon, participants attend and test functionality other than that described in the scenarios.

Note also that the connectathon will be based on the version of FHIR posted at [1]

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 where participants can demonstrate their work to the others

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.
  • Register to attend the WGM, and make sure to select the Connectathon option when you do
  • Optionally add your details below (in the 'Registered Participants' section) to indicate the scenarios you intend to participate in

Space at the venue is limited, so please register 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

Registered Participants

  • Furore / Ewout Kramer.
    • server, all scenarios
  • Gevity / Lloyd McKenzie.
    • client scenario 2
  • SMART Platforms / Nikolai Schwertner
    • SMART on FHIR server and apps
  • VA / Dave Carlson
    • client scenario 2, iOS mobile app using SMART on FHIR
  • Crucible / Jason Walonoski
    • test tool focused on interoperability
  • HealthConnex / Brian Postlethwaite
    • spark server / .net client in several contexts/apps
    • client scenario 1, maybe some appointments/questionnaires
  • AEGIS.net, Inc. / Richard Ettema
    • WildFHIR client and server; scenario 1, CDS Immunization Forecasting with FHIR messages
  • Oridashi / Brett Esler
    • Hiasobi Servers / track 2 + track 1 (read-only)
  • VA / Duane DeCouteau
    • DSTU2 Vaadin Touchkit Mobile Client, HAPI Server Implementation, and Security Labeling Service

Connectathon Planning Team


Test servers

Grahame's server Brett's server Hapi DSTU2

Connectathon tracks

This section lists the scenarios that are proposed for this connectathon. More detail will be added when approved. The scenarios are grouped into 3 tracks. Track 1 is for those new to FHIR and requires minimal preparation in advance of the connectathon (at least for client applications). Tracks 2 and 3 are focused on particular implementation activities with FHIR and exercise a more complete set of behavior designed to reflect a full production experience - preparation in advance will be required.

Note that this track - as with all tracks - will use the candidate 'DSTU-2' version of FHIR as described here. If you've been to a connectathon before and done this track, then you may need to change your code, as there has been many important changes to the specification.

Track 1 - Patient

If creating a client, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.

Pre-requisites: none


1. Register a new patient

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

>>Note: the requirement for the client to assign the Id has been relaxed. However, if the server assigns the Id, then the client will need to be able to retrieve the Id from the server response or by a patient query.

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: There is a patient that has at least one update
  • Success Criteria: Patient's 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)

Some help links:


Track 2 - Patient Access to Data

Track 2 consists of exercising a single operation: Fetch Patient Record. A server puts up a service that responds to the request 

 GET [base]/Patient/[id]/$everything

The server returns all information associated with the selected patient record - both data and documents. All the resources should be valid according to Meaningful Use as described for the Argonaut Project. Clients are able to retrieve the patient record, and display it usefully to a patient (e.g. as part of a patient portal, for instance). Clients are welcome to perform analysis etc on the patient record, but this is not explicitly part of the connectathon.

Both Servers and Clients taking part in Track 2 should at least support finding a patient (#4 for track #1), and, of course, security, most likely through SMART on FHIR, but neither of these are required for the connectathon (just in the interests of practicality).

Note: The argonaut project anticipates granular access to the patient record, not just a single record download of an entire record. However in order to limit the testing load, we are focusing a single interaction - this will put the weight of testing on the content and meaningful use, not just the API surface.

  • Example of fetching a patient record: (todo)
  • Terminology service that supports MU value sets: (todo)
  • Example Data sets: (todo)

1. Consume the 'Fetch Patient Record' operation (Client)

  • Action: Call a server exposing the 'Fetch Patient Record' operation (Currently this is only the 'health Intersections' server)
  • Precondition: Patient has been queried and the patient Id known
  • Success Criteria: Data returned and exposed in a UI
  • Bonus point: Update some of the data and demonstrate the change.


2. Expose the 'Fetch Patient Record' operation (Server)

  • Action: Expose an endpoint supporting the 'Fetch Patient Record' operation
  • Precondition: Also expose the patient query endpoint. Have patient data available.
  • Success Criteria: A client can call the operation and display the data
  • Bonus point: Support update

Track 3 - Experimental: Profiles and conformance

This track explores interoperability between conformance tooling. It is a repeat of the same track held at the Chicago meeting, but based on the changes to FHIR that occurred as outcomes of that connectathon.

There are 3 parts to this track:

  • generating profiles and valuesets
  • getting a server to test conformance
  • implementing a process (server or client) that tests for conformance

The track also explores the use of profile tags.

1. Creating Profiles and Value Sets

This is for any process that produces Profiles and/or value sets

  • Create a profile and/or valuesets
    • the method of creation is not fixed - it can be by hand, by some conversion process from other formats, or by some tool to profile the content
  • The profile should have these properties:
    • Profile on Observation
    • fix observation.name to a limited set of LOINC codes
    • fix observation.value to a particular type
    • fix observation.value.units
    • fix one or more other attributes to max cardinality ..0
    • fix the value of reliability and status
  • upload (create/update) the created resources on a registry
    • must get profile/value set references correct on the registry
  • create pass and fail resources, and test them against the profile using the FHIR validation tool (from FHIR DSTU downloads)

For an example of the kind of profile that is intended, see [[2]] (on server as [[3]])

2. Getting a server to test conformance

  • Given a set of observation resources (zip file to be posted here)
  • and a profile (see below)
  • submit the resource for validation using the validation operation on a server
    • there are no rules about how the submission is prompted
    • the server http://fhir.healthintersections.com.au/open is available, and should be the first system to test on, other servers from #3 below should be tested too
    • the validation operation requires that the profile be tagged with the full URL of the profile *on the server being tested*
    • the client must process the return response correctly (pass | fail, not be mislead by hints and warnings
  • the profile master is here (link to be provided). Consult the server administrator for the correct profile tag for the test profile. on the health intersections server, this is the full parameters for checking the resource ([[4]]) against the profile:
<Parameters xmlns="http://hl7.org/fhir"> 
 <parameter>
   <name value="profile"/>
   <valueUri value="Profile/patient-uslab-uslabpatient"/>
 </parameter>
 <parameter>
 <name value="resource"/>
 <resource>
  <Patient xmlns="http://hl7.org/fhir">
   <id value="uslab-example1"/>
    <text>
     <status value="generated"/>

    </text>
    <extension url="http://hl7.org/fhir/ExtensionDefinition/us-core-race">
     <valueCodeableConcept>
      <coding>
       
     </coding>
    </valueCodeableConcept>
   </extension>
   <extension url="http://hl7.org/fhir/ExtensionDefinition/us-core-ethnicity">
    <valueCodeableConcept>
     <coding>
       
     </coding>
    </valueCodeableConcept>
   </extension>
  <identifier>
   <use value="usual"/>
   <system value="urn:oid:2.16.840.1.113883.3.72.5.30.2"/>
   <value value="18547545"/>
  </identifier>
  <name>
   <use value="official"/>
   <family value="Lerr"/>
   <given value="Todd"/>
   <given value="G."/>
   <suffix value="Jr"/>
  </name>
  <gender value="male"/>
  <birthDate value="2012-06-07"/>
  <deceasedBoolean value="false"/>
  <address>
   <use value="home"/>
   <line value="123 North 102nd Street"/>
   <line value="Apt 4d"/>
   <city value="Harrisburg"/>
   <state value="PA"/>
   <postalCode value="17102"/>
   <country value="USA"/>
  </address>
  </Patient>
 </resource>
</parameter>
</Parameters>

3. Server Validation

  • host a Profile and value set registry
  • provide an implementation of the validation operation (at the resource level, no need to implement it at the instance level)
  • correctly process profile tags on the validation operation
  • correctly validate the submitted resource against the identified profile
    • pass|fail outcome must match those produced by the FHIR validation tool (from FHIR DSTU downloads)

Servers

Publicly Available FHIR Servers for testing

Should I come only for the Connectathon?

Coming for the connectathon alone has value - many implementers have attended just for the Saturday/Sunday and been happy. However, if you're already on-site, there's a lot of other FHIR-related activities to participate in that may further increase your return on investment

FHIR User Group

Subsequent to the actual connectathon (i.e. Sunday PM) the "Application Implementation and Design (AID)" HL7 User Group will meet to discuss FHIR implementation approaches and design patterns. You're invited to share your 'lessons learned' with others in the FHIR implementation community, or to listen to other FHIR implementers.

  • See AID Sunday PM Agenda for details.
  • Please contact Rene Spronk to get hold of a slot on the AID agenda - we do appreciate you sharing your ideas and experiences.

FHIR Tutorials

There are 4 tutorials scheduled through-out the week

  • Mon pm - Introduction to FHIR
  • Tue am - FHIR for Architects
  • Tue pm - FHIR Profiling
  • Wed am - Intro to FHIR Development

Detailed descriptions are available in the WGM brochure

Working Group session

HL7 WGMs are where a lot of the development work on FHIR happens. Numerous work groups will be considering FHIR change proposals, working on FHIR profiles and resources and debating other aspects of FHIR implementation. As well, there will be meetings of the FHIR Governance Board and FHIR Management Group discussing policies relating to FHIR. There are often ad-hoc meetings at breakfast, lunch and after-hours to discuss items of interest such as tooling, new domains, particular technical issues, etc.

The final agenda won't be determined until very close to the meeting (and will evolve somewhat throughout the course of the week), however you can take a look at the [[5]] from the May WGM to get a sense of the breadth of discussions that will be taking place. FHIR runs full bore from Monday to Friday (capping off with the clinical connectathon on Friday), so regardless of what days you're present, there will likely be something of interest.

Participating in the WGM is a good way to get a sense of the people involved in building the spec, to form relationships, to get more deeply involved in the FHIR community and to influence how the standard evolves.

Other References

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