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

Difference between revisions of "FHIR Connectathon 4"

From HL7Wiki
Jump to navigation Jump to search
Line 118: Line 118:
 
==== 5. Basic PHR ====
 
==== 5. Basic PHR ====
  
Using FHIR interfaces to support the basic functionality of a Personal Health Record is an important milestone for FHIR, as it indicates that there are sufficient resources to be able to do something 'useful! This scenario shows how this functionality can be supported using FHIR interfaces and resources. It is documented  
+
Using FHIR interfaces to support the basic functionality of a Personal Health Record is an important milestone for FHIR, as it indicates that there are sufficient resources to be able to do something 'useful! This scenario shows how this functionality can be supported using FHIR interfaces and resources. It is documented here: http://hl7.org/implement/standards/fhir/usecases.htm#phr
 
 
 
 
http://hl7.org/implement/standards/fhir/usecases.htm#phr
 
  
 
=== 6. Crude PHR with Security ===
 
=== 6. Crude PHR with Security ===

Revision as of 20:45, 18 June 2013

Introduction

This page describes the fourth FHIR connectathon that will be held on Saturday September 21st and the morning (9am - 12.30pm) of Sunday September 22nd 2013 in Cambridge, Massachusetts prior to the HL7 Working Group Meeting (see http://www.hl7.org/events/wgm092013/).

Location

To be announced

Themes

This connectathon will have 2 separate themes

Basic 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

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 about 30 attendees, registration will be managed by HQ, and there will be a nominal charge - details to follow. 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

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


Connectathon tracks

This section lists the scenarios that are proposed for this connectathon. More detail will be added when approved. The scenarios are grouped according to two tracks. Track 1 is for those new to FHIR and requires minimal preparation in advance of the connectathon (at least for client applications). Track 2 is for those with some experience with the use of FHIR (or willing to devote up-front time to connectathon preparation) and exercises a more complete set of behavior designed to reflect a full production experience.

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

Track 2 - Personal Health Record

Pre-requisites:

  1. RESTful servers must return a valid, accurate conformance resource instance in response to a metadata or options request. Clients must provide a valid and accurate conformance resource instance to the connectathon organizers no later than day 1 of the connectathon.
  2. RESTful servers and clients must implement the oAuth framework for user identification

5. Basic PHR

Using FHIR interfaces to support the basic functionality of a Personal Health Record is an important milestone for FHIR, as it indicates that there are sufficient resources to be able to do something 'useful! This scenario shows how this functionality can be supported using FHIR interfaces and resources. It is documented here: http://hl7.org/implement/standards/fhir/usecases.htm#phr

6. Crude PHR with Security

  • To be developed: Repeat query from scenario 5 but with security in place governing whether the service will accept the query ???


Servers

Publicly Available FHIR Servers for testing

Other References