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
 
(56 intermediate revisions by 16 users not shown)
Line 1: Line 1:
 
== Introduction ==
 
== 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/).
 
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/).
 +
 +
==IMPORTANT: Registration==
 +
 +
'''Sorry, but the available space for Connectathon has been filled''' and we are unable to accept further formal registrations. We are maintaining a list of people who would like to attend if there are cancellations, so contact any of the connectathon organizers if you want to be on this list.  Another option is to participate remotely (even from the same hotel!). Again, please contact us if you wish to do this...
 +
 +
Our apologies for the inconvenience, interest in FHIR is growing at a very rapid rate!
 +
 +
Although less convenient than the WGM - there will be a connectathon in Australia as part of the [[http://www.ihic2013.org.au IHIC]] event in October this year - if you can't get into the WGM event, why not come to IHIC and have a holiday in Australia - and New Zealand - at the same time?
 +
 +
<!--
 +
Unlike previous sessions, this connectathon requires pre-registration and the payment of a small fee.  In theory, you could show up and do your registration on-site, but that'll make life complicated for the connectathon organizers, so pre-registration would be much appreciated.  (Pre-registration typically shuts down roughly one week prior to the start of the WGM.)  Non-registered participants will not be permitted in the room.  This means that you must register even if you only wish to observe.  Observing isn't nearly as much fun though and connecting to FHIR is easy, so why not dust off those old coding skills and play a little?
 +
 +
The WGM registration site can be found [[http://www.hl7.org/events/wgm092013/regform.cfm|here]]
 +
 +
To register for the 2-day connectathon, you only need to pay for the Saturday attendance ($50 USD).  That will cover breakfast & breaks on Saturday and breakfast on Sunday.  If you want the Sunday lunch, then you'll need to register for Sunday as well (also $50).
 +
 +
In addition to the formal registration process, please follow the instructions section below titled "enrollment"
 +
-->
 +
 
===Location===
 
===Location===
 
To be announced
 
To be announced
Line 27: Line 46:
 
* the formal testing part
 
* the formal testing part
 
* a 'mini-showcase' session where participants can demonstrate their work to the group, if they choose.
 
* a 'mini-showcase' session where participants can demonstrate their work to the group, if they choose.
 +
 +
 +
[https://docs.google.com/spreadsheet/ccc?key=0Ah7sZzoC9bPRdEhUcEV3czQ0ZE9BS0xITENMZzZiZHc#gid=1 Link to Google spread sheet with participant details]
 +
 +
 +
[https://docs.google.com/spreadsheet/ccc?key=0Ah7sZzoC9bPRdG1fazVuSDZLTW5MMmtWUUhIdk5rTVE#gid=0 Australian IHIC Link to Google spread sheet with participant details]
  
 
= Enrollment =
 
= Enrollment =
−
If you or your company are interested in participating in the connectathon, please do the following.
+
 
 +
If you or your company are interested in participating in the connectathon, please do the following (in addition to the mandatory registration step above).
 
*Read the '''[http://hl7.org/fhir FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.
 
*Read the '''[http://hl7.org/fhir FHIR Specification]''' and the '''[[ FHIR | FHIR wiki ]]''' if you haven't already done so, to become familiar with the concepts.
 
*Read the '''scenario descriptions''' below.   
 
*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.
+
*Either update the "Registered Participant" section below or send an '''email expressing interest''' containing the same sort of information to any of the Connectathon Planning team below and we'll put it on the wiki for you.  While none of the information need be written in stone, having an idea of who's coming and what they're doing is quite helpful in planning how to organize the sessions, lay out the room, etc.
  
−
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.
+
Space at the venue is limited to about 30 attendees, and preference will be given to those who are actually participating in the technical event, but observers are welcome if space permits. Note that the $50 charge still applies to observers, so given how easy it is to consume FHIR resources, why not give it a try?
  
 
For any queries, either contact a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]
 
For any queries, either contact a member of the planning team, or post your question in the [http://lists.hl7.org/fhir FHIR list server]
Line 40: Line 66:
 
= Connectathon Planning Team =
 
= Connectathon Planning Team =
 
*[mailto:david.hay25@gmail.com David Hay], Orion Health
 
*[mailto:david.hay25@gmail.com David Hay], Orion Health
−
*[mailto:brian.pech@kg.org Brian Pech], Kaiser Permanente
+
*[mailto:brian.pech@kp.org Brian Pech], Kaiser Permanente
 
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd
 
*[mailto:grahame@healthintersections.com.au Grahame Grieve], Health Intersections Pty Ltd
 +
 
== Registered Participants ==
 
== Registered Participants ==
−
<!--
+
Please indicate: Organization, number of participants and, if possible what tracks and scenarios you'll be pursuing, whether building client, server or both, and what platform/language you'll be developing with.  If you've got a website, feel free to include that too.
−
* Health Intersections / Grahame Grieve.  
+
 
−
* Furore / Ewout Kramer.  
+
* Health Intersections / Grahame Grieve. 1 participant. All tracks, scenarios as server. Platform: Delphi / MSSQL / AWS + Java CCDA
 +
* Furore / Rob Mulders, Ewout Kramer. Our server supports track 1 (patient) & 2 (phr) but not the authentication track (3).
 
* Gordon Point Informatics / Lloyd McKenzie.
 
* Gordon Point Informatics / Lloyd McKenzie.
 
* Orion Health / David Hay.  
 
* Orion Health / David Hay.  
 
* Blue Wave / Hugh Glover  
 
* Blue Wave / Hugh Glover  
−
-->
+
* Healthwise / Tom St Clair & Brian Scheller. Track 1 - Patient scenarios
 +
* West Health / Todd cooper - device resources as server
 +
* YouCentric / Andy Stechishin, Dennis Rodriguez, Lorraine Constable. Track 2 as server, possibly track 3
 +
* Ringholm / Rene Spronk (ad hoc testing, using Tcl script language)
 +
* NProgram / Rik Smithies (server, client (as test harness), .net, xslt, hacking) / www.nprogram.co.uk/fhir
 +
* GE Healthcare / John Moehrke & Keith Boone -- Scenario C: Accounting of Disclosures
 +
* Dynamic Health IT / Jeff Robbins
 +
* Sysmex NZ Ltd / David Fallas. - DiagnosticReport & DeviceObservation
 +
* AEGIS.net Inc / Richard Ettema & Mario Hyland (Interopguy) - Track 1+ - test harness: AEGIS Developer Integration Lab (DIL)
 +
* Josh Mandel / [http://smartplatforms.org SMART Platforms]. PHR track, with with delegated authorization according to the [http://blue-button.github.io/blue-button-plus-pull/ BlueButton REST API]. Platform: Grails (Java/Groovy), MongoDB.  '''Open-source FHIR implementation''' :
 +
** https://api.fhir.me "SMART on FHIR" Server | [https://github.com/jmandel/smart-on-fhir Source]
 +
** https://apps.fhir.me "FHIR Starter" App Launcher | [https://github.com/jmandel/fhir-starter Source]
 +
* Interfaceware / Rolim Cabrita. Track 1 & 2, patient and document consumers
 +
* Oridashi / Brett Esler. Track 1 & 2, patient provider and summary x 2 systems (remote participant)
 +
* Mohawk College / Justin Fyfe - scenario 1, consumer (iOS) & server (C#, PostgreSQL. Also a PIX manager and PDQ supplier. Patient resource is profiled http://cr.marc-hi.ca:8080/fhir/0.11/Profile/@pix-fhir)
 +
* Zynx Health / Claude Nanjo - Track 2. (Track 1 completed and incorporated into Java API Client JUnit Tests)
 +
* Knapp Consulting Inc. / Paul Knapp - Track 1 Client (REST, c#), Client and light server for Http exchange (c#)
 +
* Corepoint Health / Brian Lind & Dennis Palmer - FHIR Server and potentially Client
 +
* Dept. of Veteran Affairs / Duane DeCouteau - Experimental Tracks - Healthcare Classification System & Security Label Services
 +
* Health IQ / John Reynolds. 1 participant. Track 1
  
 
== Actors ==
 
== Actors ==
Line 85: Line 132:
 
==== 1. Register a new patient ====
 
==== 1. Register a new patient ====
  
−
* Action: (Patient Demographics consumer) creates a new patient and save to Patient Service. The client assigns the Id.
+
* 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
 
* Precondition: Patient does not exist in service prior to action
 
* Success Criteria: Patient created correctly on server (use browser to inspect Patient)
 
* Success Criteria: Patient created correctly on server (use browser to inspect Patient)
 
* Bonus point: The Patient resource has an extension
 
* 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 ====
 
==== 2. Update a patient ====
Line 101: Line 150:
  
 
* Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
 
* Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
−
* Precondition: Patients with that name have  been created
+
* Precondition: There is a patient that has at least one update
 
* Success Criteria: patients history displayed in interface. (use browser query Patient Service)
 
* 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
 
* Bonus point: the UI allows the user to display previous versions of the Patient
Line 113: Line 162:
 
=== Track 2 - Personal Health Record ===
 
=== Track 2 - Personal Health Record ===
 
Pre-requisites:  
 
Pre-requisites:  
−
# 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.
+
# 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. Note that the conformance resource is used both by clients and servers - Servers use it to say what their capabilities are, and Clients use it as a statement of what their expectations (or requirements) are.
−
# RESTful servers and clients must implement the oAuth framework for user identification
 
  
−
==== 5. Basic PHR ====
+
 
 +
Background
  
 
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
 
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 ===
+
All of the scenarios below assume that you have retrieved the patient resource from the server you are querying, as you will need the patient id in most of them. And just a hint: when retrieving a separate resource for a patient, you are actually performing a query against that resource (usually) against the 'subject' or 'patient' property. so, to get patient conditions (or problems) you would use a search like GET [fhirServer]/condition/search?subject._id=sample
−
* ''To be developed:'' Repeat query from scenario 5 but with security in place governing whether the service will accept the query ???
+
 
 +
See [[FHIR Connectathon 4 Tags]] for tags that are used to modify the behavior of the FHIR API during the connectathon.
 +
 
 +
==== 5. Search for a patient on name ====
  
−
<!--
+
* Action: (Patient Demographics consumer) searches the patient Service for patients with a given name
−
=== document / xds scenarios ===
+
* Precondition: Patients with that name have  been created
−
* search for documents from xds registry (xdsEntry2) for a patient
+
* Success Criteria: patients displayed in interface. (use browser query to confirm)
−
* update an exsting document
+
 
−
* show document versions
+
Note: This is a duplicate of the scenario in Track 1, as the patient id is required for all subsequent scenarios
−
* create and submit a new document
+
 
 +
==== 6. Retrieve Patient Condition list ====
 +
 
 +
* Action: Retrieve all the condition resources for a given patient
 +
* Precondition: The patient identifier is known
 +
* Success Criteria: Conditions are retrieved and and displayed in a UI
 +
* Bonus point: the UI indicates whether the condition has been modified since it was first created
 +
 
 +
==== 7. Create Patient Condition ====
 +
 
 +
* Action: Create a new condition for a patient
 +
* Precondition: The patient identifier is known. The Condition you are adding does not already exist. (Hint: you will need to do a query of some sort first)
 +
* Success Criteria: After adding the Condition, a subsequent query for that patients conditions will return it
 +
* Bonus point: Save the condition using both JSON and XML formats
 +
 
 +
==== 8. Submit CDA document and document reference ====
 +
 
 +
* Action: Save a CDA document (will be supplied) as a binary resource, and also save a DocumentReference resource that refers to it. The server will assign the id of the binary resource.
 +
* Precondition: The patient identifier is known.
 +
* Success Criteria: Both binary and DocumentReference resources can be retrieved using direct GET queries
 +
* Bonus point 1: Use both a bundle and separate calls to save the resource
 +
* Bonus point 2: Update the document with a new version
 +
 
 +
==== 9. Display simple patient summary ====
 +
 
 +
* Action: Retrieve the core clinical resources for a patient and display in a summary page that would be suitable for a clincian overview. Resources to be retrieved and displayed (The display is at the discretion of the developer, with the simplest option being to use the narrative against each resource):
 +
** Condition
 +
** MedicationPrescription
 +
** Alert
 +
** AllergyIntolerance
 +
** Encounters
 +
** Known Documents
 +
** Known CarePlans
 +
* Precondition: The patient identifier is known.
 +
* Success Criteria: Both binary and DocumentReference resources can be retrieved using direct GET queries
 +
* Bonus point 1: Allow the user to retrieve and display a document from the document list
 +
* Bonus point 2: Allow any of the resources to be updated or added to
 +
 
 +
==== 10. Upload Device data ====
 +
 
 +
* Action: submit a DeviceObservation resource to a server
 +
* Precondition: The patient identifier is known.
 +
* Success Criteria: The DeviceObservations can be retrieved from the server
 +
* Bonus point 1: retrieve DeviceObservations for a patient
 +
 
 +
=== Track 3 - Basic PHR with Security ===
  
−
? do we also want scenarios directly against a /document endpoint rather than /xdsentry2 ?
+
This track is a duplicate of Track 2. with the proviso that all connections use SSL, and the user has been authenticated using oauth. (see http://www.hl7.org/implement/standards/fhir/security.htm). Currently, only Grahames server supports this.
−
-->
 
  
 
== Servers ==
 
== Servers ==
Line 140: Line 236:
  
 
* Other FHIR Connectathons:  
 
* Other FHIR Connectathons:  
−
**[[FHIR Connectathon 1]] (Sep 8, 2012)
+
**[[FHIR Connectathon]] (Sep 8, 2012)
 
**[[FHIR Connectathon 2]] (Jan 12/13, 2013)
 
**[[FHIR Connectathon 2]] (Jan 12/13, 2013)
 
**[[FHIR Connectathon 3]] (May 4/5, 2013)
 
**[[FHIR Connectathon 3]] (May 4/5, 2013)
 
**[[FHIR Connectathon 4]] (Sep 21/22, 2013)
 
**[[FHIR Connectathon 4]] (Sep 21/22, 2013)
 
[[Category:FHIR Connectathons]]
 
[[Category:FHIR Connectathons]]

Latest revision as of 22:25, 26 October 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/).

IMPORTANT: Registration

Sorry, but the available space for Connectathon has been filled and we are unable to accept further formal registrations. We are maintaining a list of people who would like to attend if there are cancellations, so contact any of the connectathon organizers if you want to be on this list. Another option is to participate remotely (even from the same hotel!). Again, please contact us if you wish to do this...

Our apologies for the inconvenience, interest in FHIR is growing at a very rapid rate!

Although less convenient than the WGM - there will be a connectathon in Australia as part of the [IHIC] event in October this year - if you can't get into the WGM event, why not come to IHIC and have a holiday in Australia - and New Zealand - at the same time?


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.


Link to Google spread sheet with participant details


Australian IHIC Link to Google spread sheet with participant details

Enrollment

If you or your company are interested in participating in the connectathon, please do the following (in addition to the mandatory registration step above).

  • 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.
  • Either update the "Registered Participant" section below or send an email expressing interest containing the same sort of information to any of the Connectathon Planning team below and we'll put it on the wiki for you. While none of the information need be written in stone, having an idea of who's coming and what they're doing is quite helpful in planning how to organize the sessions, lay out the room, etc.

Space at the venue is limited to about 30 attendees, and preference will be given to those who are actually participating in the technical event, but observers are welcome if space permits. Note that the $50 charge still applies to observers, so given how easy it is to consume FHIR resources, why not give it a try?

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

Please indicate: Organization, number of participants and, if possible what tracks and scenarios you'll be pursuing, whether building client, server or both, and what platform/language you'll be developing with. If you've got a website, feel free to include that too.

  • Health Intersections / Grahame Grieve. 1 participant. All tracks, scenarios as server. Platform: Delphi / MSSQL / AWS + Java CCDA
  • Furore / Rob Mulders, Ewout Kramer. Our server supports track 1 (patient) & 2 (phr) but not the authentication track (3).
  • Gordon Point Informatics / Lloyd McKenzie.
  • Orion Health / David Hay.
  • Blue Wave / Hugh Glover
  • Healthwise / Tom St Clair & Brian Scheller. Track 1 - Patient scenarios
  • West Health / Todd cooper - device resources as server
  • YouCentric / Andy Stechishin, Dennis Rodriguez, Lorraine Constable. Track 2 as server, possibly track 3
  • Ringholm / Rene Spronk (ad hoc testing, using Tcl script language)
  • NProgram / Rik Smithies (server, client (as test harness), .net, xslt, hacking) / www.nprogram.co.uk/fhir
  • GE Healthcare / John Moehrke & Keith Boone -- Scenario C: Accounting of Disclosures
  • Dynamic Health IT / Jeff Robbins
  • Sysmex NZ Ltd / David Fallas. - DiagnosticReport & DeviceObservation
  • AEGIS.net Inc / Richard Ettema & Mario Hyland (Interopguy) - Track 1+ - test harness: AEGIS Developer Integration Lab (DIL)
  • Josh Mandel / SMART Platforms. PHR track, with with delegated authorization according to the BlueButton REST API. Platform: Grails (Java/Groovy), MongoDB. Open-source FHIR implementation :
  • Interfaceware / Rolim Cabrita. Track 1 & 2, patient and document consumers
  • Oridashi / Brett Esler. Track 1 & 2, patient provider and summary x 2 systems (remote participant)
  • Mohawk College / Justin Fyfe - scenario 1, consumer (iOS) & server (C#, PostgreSQL. Also a PIX manager and PDQ supplier. Patient resource is profiled http://cr.marc-hi.ca:8080/fhir/0.11/Profile/@pix-fhir)
  • Zynx Health / Claude Nanjo - Track 2. (Track 1 completed and incorporated into Java API Client JUnit Tests)
  • Knapp Consulting Inc. / Paul Knapp - Track 1 Client (REST, c#), Client and light server for Http exchange (c#)
  • Corepoint Health / Brian Lind & Dennis Palmer - FHIR Server and potentially Client
  • Dept. of Veteran Affairs / Duane DeCouteau - Experimental Tracks - Healthcare Classification System & Security Label Services
  • Health IQ / John Reynolds. 1 participant. Track 1

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 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: 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. Note that the conformance resource is used both by clients and servers - Servers use it to say what their capabilities are, and Clients use it as a statement of what their expectations (or requirements) are.


Background

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

All of the scenarios below assume that you have retrieved the patient resource from the server you are querying, as you will need the patient id in most of them. And just a hint: when retrieving a separate resource for a patient, you are actually performing a query against that resource (usually) against the 'subject' or 'patient' property. so, to get patient conditions (or problems) you would use a search like GET [fhirServer]/condition/search?subject._id=sample

See FHIR Connectathon 4 Tags for tags that are used to modify the behavior of the FHIR API during the connectathon.

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

Note: This is a duplicate of the scenario in Track 1, as the patient id is required for all subsequent scenarios

6. Retrieve Patient Condition list

  • Action: Retrieve all the condition resources for a given patient
  • Precondition: The patient identifier is known
  • Success Criteria: Conditions are retrieved and and displayed in a UI
  • Bonus point: the UI indicates whether the condition has been modified since it was first created

7. Create Patient Condition

  • Action: Create a new condition for a patient
  • Precondition: The patient identifier is known. The Condition you are adding does not already exist. (Hint: you will need to do a query of some sort first)
  • Success Criteria: After adding the Condition, a subsequent query for that patients conditions will return it
  • Bonus point: Save the condition using both JSON and XML formats

8. Submit CDA document and document reference

  • Action: Save a CDA document (will be supplied) as a binary resource, and also save a DocumentReference resource that refers to it. The server will assign the id of the binary resource.
  • Precondition: The patient identifier is known.
  • Success Criteria: Both binary and DocumentReference resources can be retrieved using direct GET queries
  • Bonus point 1: Use both a bundle and separate calls to save the resource
  • Bonus point 2: Update the document with a new version

9. Display simple patient summary

  • Action: Retrieve the core clinical resources for a patient and display in a summary page that would be suitable for a clincian overview. Resources to be retrieved and displayed (The display is at the discretion of the developer, with the simplest option being to use the narrative against each resource):
    • Condition
    • MedicationPrescription
    • Alert
    • AllergyIntolerance
    • Encounters
    • Known Documents
    • Known CarePlans
  • Precondition: The patient identifier is known.
  • Success Criteria: Both binary and DocumentReference resources can be retrieved using direct GET queries
  • Bonus point 1: Allow the user to retrieve and display a document from the document list
  • Bonus point 2: Allow any of the resources to be updated or added to

10. Upload Device data

  • Action: submit a DeviceObservation resource to a server
  • Precondition: The patient identifier is known.
  • Success Criteria: The DeviceObservations can be retrieved from the server
  • Bonus point 1: retrieve DeviceObservations for a patient

Track 3 - Basic PHR with Security

This track is a duplicate of Track 2. with the proviso that all connections use SSL, and the user has been authenticated using oauth. (see http://www.hl7.org/implement/standards/fhir/security.htm). Currently, only Grahames server supports this.

Servers

Publicly Available FHIR Servers for testing

Other References

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