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

FHIR Connectathon 10

From HL7Wiki
Jump to navigation Jump to search

Introduction

(This page is under construction and contains information that is still subject to update and correction.) This page describes the tenth FHIR Connectathon that will be held on Saturday Oct. 3 (9am - 5pm++) and the morning (9am - 12.30pm) of Sunday Oct. 4, 2015 in Atlanta, GA prior to the HL7 Working Group Meeting (see http://www.hl7.org/events/wgm102015/).

Location

The meeting will be held at the host hotel, Sheraton Atlanta, Atlanta, GA.

Important notes:


Sunday

Please note lunch is not included for Sunday with the Connectathon registration fee.

Themes

This connectathon will have 6 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
  • Terminology Services
  • Financial Resources
  • EHR record lifecycle architecture
  • Structured Data Capture
  • Scheduling


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 DSTU-2 QA version of FHIR which will be 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

Each stream has a coordinator. The nominated coordinator's responsibilities:

  • In the lead up to the connectathon: track participants, respond to queries about scenarios, connect participants to each other
  • During the connectathon act as a test mediator / progress tracker
  • track emergent issues that should be fed back to the committees

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

  • National E-Health Transition Authority (NEHTA) / Reuben Daniels
    • Track 2 - Terminology Services

Connectathon Planning Team


Test servers

Grahame's server

Brett's server

Hapi DSTU2

AEGIS DSTU2

HealthConnex DSTU2

CMS BlueButton DSTU2

Spark - Furore's server DSTU2

The Health 2.0 Conference has a FHIR Hackathon happening this weekend. I have created a sandbox on AWS to support that effort. Documentation for the Hackathon is here: BlueButton on FHIR Hackathon information

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 have been many important changes to the specification.

Track 1 - Patient

Coordinator: David Hay

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 - Terminology Services

Coordinator: Rob Hausam (There is a dedicated skype chat for terminology services - Contact Rob to be included - skype id rhausam)

Service Providers

For service providers, implement the following operations from http://hl7.org/fhir/2015May/terminology-service.html:

  • $expand
  • $validate-code (note: there's a set of typos on the terminology service page where this operation is called "validate" but its actually "validate-code" - editorial oversight)
  • $lookup
  • $translate (note: there's a typo on the terminology service page where the example has '$validate' not '$translate')

Service providers are not required to implement all this functionality - it's a lot to do. For new implementers, start at the top and work down (generally)

(note for participants in the first terminology services connectathon: this stream builds on the previous connectathon by adding $lookup and $translate)

There's a fairly specific test script with detail descriptions of scenarios at http://gforge.hl7.org/svn/fhir/trunk/connectathons/Paris2015/tx_test_script.xml (for anonymous access, use 'anonymous' with our email as a password). Implementers are not required to implement the full script and pass those particular tests, though it is encouraged to be able to do so

note about the test script: you need a version of Sprinkler to execute it (details to be provided). It looks like a resource, and there is a proposal to actually add it as a resource. On the other hand, we'll be considering alternative proposals in Paris as well as that format. Or you can use any other kind of http based test service; there's nothing magic there.

Client Consumers

Any one of

  • do a value set expansion of one of the value sets in the spec
  • validate a code using the spec against a FHIR value set, a v2 value set, or LOINC or snomed CT
  • look up a display for a code (most appropriate for v2/FHIR conversion)

At least one server supports all these operations (http://fhir-dev.healthintersections.com.au). Other servers, including the Apelon server (http://fhir.ext.apelon.com:8081/DtsOnFhirDemo) will support some of those operations


Track 3 - Financial Management

Coordinator: Paul Knapp

The details of this track can be found here: Connectathon9_Financial.

In summary the test scenarios are:

  1. Submit a Claim via REST (Create), Retrieve a ClaimResponse (Get)
  2. Submit a Claim via WSI Web Services and Receive a ClaimResponse
  3. Retrieve deferred ClaimResponse via ProcessRequest


Track 4 -EHR record lifecycle architecture

Coordinator: Gary Dickinson

An EHR, PHR or other trusted system manages record entries, most often as persistent evidence of patient health and provision of healthcare services. When FHIR is implemented natively, record entries may contain one or more resources.

Record entries have a lifespan (period of retention) often based on legal, regulatory and/or policy requirements. During the record entry lifespan, one or more record lifecycle events may occur. For purposes of this Connectathon, focus will be on resource creation(C), update(U) and read(R). See the FHIR Record Lifecycle Event Implementation Guide (DSTU-2) for additional details: http://hl7.org/fhir/ehrsrle/ehrsrle.html

FHIR AuditEvent and Provenance resources are designed to capture vital authenticity and accountability metadata. For this Track, it is recommended to:

  • Create AuditEvent resource (AuditEvent.object.reference) at each lifecycle event when resource content is created(C), updated(U) or read(R).
  • Create AuditEvent resource (AuditEvent.object.reference) for other events, such as query, transmit/submit/send, receive/retrieve.
  • Create Provenance resource (Provenance.target) at each lifecycle event when resource content is created(C) or updated(U).

Track 4 has no scenarios of its own instead it adds applicable accountability and authenticity metadata (via FHIR AuditEvent and Provenance) to resources in other Track scenarios.

Track 1 Bonus Points

  • Scenario 1: Add AuditEvent and Provenance to Patient Create; Apply digital signature (extra bonus)
  • Scenario 2: Add AuditEvent and Provenance to Patient Update; Apply digital signature (extra bonus)
  • Scenario 3: Add AuditEvent for Patient Query
  • Scenario 4: Add AuditEvent for Patient Query

Track 3 Bonus Points

  • Scenario 1: Add AuditEvent and Provenance to Claim Create; Apply digital signature (extra bonus); Add AuditEvent for ClaimResponse Receive
  • Scenario 2: Add AuditEvent and Provenance to Claim Create; Apply digital signature (extra bonus); Add AuditEvent for ClaimResponse Receive
  • Scenario 3: Add AuditEvent to ClaimResponse Receive

Track 5 Bonus Points

  • Scenario 5A/1: Add AuditEvent and Provenance to Questionnaire Create; Apply digital signature (extra bonus)
  • Scenario 5A/2: Add AuditEvent for Questionnaire Submission
  • Scenario 5A/3: Add AuditEvent for Questionnaire Query
  • Scenario 5A/4: Add AuditEvent and Provenance to Questionnaire Update; Apply digital signature (extra bonus)
  • Scenario 5A/5: Add AuditEvent for Questionnaire data element Query
  • Scenario 5B/1: N/A
  • Scenario 5B/2: Add AuditEvent and Provenance to QuestionnaireAnswer Create; Apply digital signature (extra bonus); Add AuditEvent for Questionnaire Submission
  • Scenario 5B/3: Add AuditEvent and Provenance to QuestionnaireAnswer Update; Apply digital signature (extra bonus)
  • Scenario 5C/1: N/A
  • Scenario 5D/1: Add AuditEvent and Provenance to Questionnaire data element Create; Apply digital signature (extra bonus)
  • Scenario 5D/2: Add AuditEvent for Questionnaire data element Query
  • Scenario 5D/3: Add AuditEvent and Provenance to Questionnaire data element Update; Apply digital signature (extra bonus)

Track 6 Bonus Points

  • Scenario 6A/1: Add AuditEvent and Provenance to Appointment Create; Apply digital signature (extra bonus)
  • Scenario 6A/2: Add AuditEvent for Appointment Submission
  • Scenario 6B/1: Add AuditEvent for Slot Query
  • Scenario 6B/2: Add AuditEvent and Provenance to Appointment Create; Apply digital signature (extra bonus); Add AuditEvent and Provenance to Slot Update
  • Scenario 6B/3: Add AuditEvent and Provenance to Slot Update; Apply digital signature (extra bonus)
  • Scenario 6C: TBD
  • Scenario 6D: TBD


Track 5 - Structured Data Capture

Coordinator: Lloyd McKenzie

Track 5A - Forms

Objective: Test the form creation language defined by the SDC specification 1. Create an SDC-conformant form

  • Action: SDC Form Designer creates a new Questionnaire instance that is conformant with the SDC Questionnaire profile
  • Precondition: none
  • Success Criteria: Form passes validation against the Questionnaire schema and the Questionnaire schematron, and is identified as valid against the SDC Questionnaire profile by the FHIR profile validation tool
  • Bonus Point: Define a Questionnaire that includes conditional display
  • Bonus Point: Define a Questionnaire that includes special rendering/style requirements
  • Bonus Point: Define contained or independently persisted value sets

2. Submit form

  • Action: SDC Form Designer submits Questionnaire to an SDC Form Manager for storage
  • Precondition: Questionnaire has been defined, form designer knows base URL for form manager
  • Success Criteria: Questionnaire is sorted on Form Manager server

3. Query forms

  • Action: SDC Form Filler or SDC Form Designer searches an SDC Form Manager for Questionnaires using one or more of the SDC-supported search criteria
  • Precondition: Questionnaires are available on the SDC Form Manager
  • Success Criteria: Set of matching Questionnaires is returned
  • Bonus Point: Make use of sorting and paging parameters

4. Update form

  • Action: the SDC Form Designer revises an existing Questionnaire previously stored in the SDC Form Manager submits an update
  • Precondition: A version of the Questionnaire exists on the SDC Form Manager and the Form Designer
  • Success Criteria: A new version of the Questionnaire exists on the SDC Form Manager. The original version remains accessible via a history query
  • Bonus Point: Handle collision detection using e-tags

5. Data elements

  • Action: the SDC Form Designer allows the form author to search for an appropriate data element on an SDC Data Element Registry and link to that data element from a question before storing the Questionnaire
  • Precondition: A set of DataElements are available for query
  • Success Criteria: A Questionnaire exists on an SDC Form Manager having questions linked to DataElements

Track 5B - Completed forms

Objective: Test the ability to render, navigate, and capture data based on forms defined using SDC syntax

1. Render SDC form for input

  • Action: SDC Form Filler converts the definition of an SDC Questionnaire into a user interface that can solicit data from a human
  • Precondition: SDC Questionnaire has been retrieved
  • Success Criteria: Human can fill out the form populating the questions and groups within the Questionnaire
  • Bonus Point: Enforce conditional display while the user populates the Questionnaire
  • Bonus Point: Render the Questionnaire taking into account the special rendering/style requirements
  • Bonus Point: Provide appropriate interfaces to select from referenced value sets

2. Record answers

  • Action: SDC Form Filler subsmits completed QuestionnaireAnswers to an SDC Form Receiver
  • Precondition: SDC Questionnaire has been received and populated
  • Success Criteria: QuestionnaireAnswers instance is available for query on the SDC Form Filler
  • Bonus Point: Store a partially-completed QuestionnaireAnswers
  • Bonus Point: Validate that the QuestionnaireAnswers instance is valid against the Questionnaire and referenced ValueSets

3. Update answers

  • Action: SDC Form Filler retrieves QuestionnaireAnswers instance and associated Questionnaire and displays the Questionnaire with data populated for update
  • Precondition: SDC Questionnaire and QuestionnaireAnswers instances are available for query
  • Success Criteria: Revised QuestionnaireAnswers instance is stored on SDC Form Receiver reflecting user's edits
  • Bonus Point: Ensure conditional display rules are enforced based on already populated data

Track 5C - Form Population

Objective: Test ability to pre-populate/auto-populate forms

1. Pre-populate a form

  • Action: SDC Form Filler invokes the $populate operation on an SDC Form Manager passing a Questionnaire id and a CCDA instance
  • Precondition: SDC Form Filler has retrieved an SDC Form referencing DataElements which contain xpath mappings to a CCDA document where the specificed paths exist in the test CCDA instance
  • Success Criteria: The SDC Form Filler receives a QuestionnaireAnswers instance with the matching questions populated
  • Bonus Point: SDC Form Filler renders content appropriately following conditional display values-including the hiding populated elements that aren't allowed to be displayed

Track 5D - Data Elements

Objective: Test SDC curation requirements

1. Record Data Element

  • Action: SDC Data Element Curator records a new data element in an SDC Data Element Registry
  • Precondition: None
  • Success Criteria: The data element is now available in the SDC Data Element Registry for query
  • Bonus Point: Create a complex data type (one with components)

2. Query Data Elements

  • Action: SDC Data Element Curator searches an SDC Data Element Registry for DataElements matching a set of search criteria
  • Precondition: The SDC Data Element Registry has data elements available for query
  • Success Criteria: The SDC Data Element Curator receives a set of matching data elements
  • Bonus Point: Make use of paging and sort parameters

3. Update Data Element

  • Action: SDC Data Element Curator makes revisions to an existing DataElement in an SDC Data Element Registry
  • Precondition: DataElement exists in SDC Data Element Registry
  • Success Criteria: Revised version is posted to the registry

Track 6 - Scheduling

Coordinator: Brian Postlethwaite

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.

Specification Page: Appointment AppointmentResponse Schedule Slot

Pre-requisites: none

Track 6A - Create Appointment

Objective: Test that appointments can be created with FHIR and understood

1. Create an appointment

  • Action: Create an appointment resource and store on a server
  • Precondition: none
  • Success Criteria: Appointment passes validation against the Appointment schema and schematron
  • Bonus Point: Define an Appointment with multiple participants
  • Bonus Point: Define an appointment with a Location
  • Bonus Point: Define an Appointment with varied Participant statuses
  • Bonus Point: Define an Appointment against multiple slots

2. Submit appointment

  • Action: create an appointment with status of proposed or pending, and participant statuses of needs-action
  • Precondition: able to create an appointment
  • Success Criteria: appointment is able to be retrieved and has these statuses set

Track 6B - Check Schedule

Objective: Test the ability to interrogate a schedule to book an appointment 1. Query a server for a schedule/slots

  • Action: tbd
  • Precondition: tbd
  • Success Criteria: tbd
  • Bonus Point: tbd

2. Create appointment against a slot

  • Action: tbd
  • Precondition: tbd
  • Success Criteria: tbd
  • Bonus Point: tbd

3. Update Slot to mark status

  • Action: tbd
  • Precondition: tbd
  • Success Criteria: tbd
  • Bonus Point: tbd

Track 6C - Appointment Responses

Objective: Test ability to handle appointment responses

  • Action: tbd
  • Precondition: tbd
  • Success Criteria: tbd
  • Bonus Point: tbd

Track 6D - Cancelling an appointment

Objective: Test workflow for an appointment cancellation 1. tbd

  • Action: tbd
  • Precondition: tbd
  • Success Criteria: tbd
  • Bonus Point: tbd

Servers

http://wiki.hl7.org/index.php?title=Version_2_-_FHIR_Mapping_Scenarios (Supporting the messaging interoperability paradigm)

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 (see the list of tutorials at the bottom of this page)

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 for Specifiers
  • 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 [[2]] 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_10&oldid=105232"