201704 Patient Track

Return to April 2017 Value-Based Care FHIR Mini-Connectathon

Patient

Pre-Requisites

For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction.

Level 1 - Introduction - New Participants/Systems

This has been and will remain the primary purpose of this track and provides a 'friendly introduction' for those new to FHIR. Attendees participate in this track using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR. It is quite feasible to complete the client side of the track within a day with only knowledge of a development environment and little to no previous FHIR knowledge. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.

Pre-connectathon testing is encouraged, but not required, where the participants can utilize the existing Publicly_Available_FHIR_Servers_for_testing.

Testing and test reporting at the Connectathon event will be self-attested using the Results tab of the Tracking Spreadsheet (link TBD) and primarily involve peer-to-peer execution between known FHIR clients and/or servers.

Submitting WG/Project/Implementer Group

FHIR Management Group (FMG)

Justification

This is the Patient Track testing that is included in all FHIR Connectathons.

This track provides new participants with a friendly introduction to FHIR, using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Coordinator: Howard Edidin

Expected participants

Level 1

• Many of the new participants which typically make up 30% or more of Connectathon attendees.
• Additional participants

See the Tracking Spreadsheet

Roles

FHIR Client

This actor initiates the processing requests that enable the creation, deletion, manipulation and retrieval of Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search.

(Example FHIR Client CapabilityStatement here)

FHIR Server

This actor receives, processes and responds to the requests for creation, deletion, manipulation and retrieval of Patient resource instances. The implementation of this actor would normally provide for a repository storage mechanism along with corresponding maintenance and retrieval capabilities of the Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search.

(Example FHIR Server CapabilityStatement here)

Scenarios

Level 1 - Introduction - New Participants/Systems

The following scenarios represent the basic scenarios that participants will work to implement during the Connectathon event. Execution of these scenarios is expected to be performed with the other participants of this track as well as the Publicly_Available_FHIR_Servers_for_testing.

1. Register a new patient

Action: FHIR client creates a new patient and save to FHIR server. The client can assign the Id.

Precondition: Patient does not exist in FHIR server prior to action

Success Criteria: Patient created correctly on FHIR server (use browser to inspect Patient)

Bonus point: The Patient resource has an extension

>>Note: the resource Id can either be created by the client or the server (depending on the capability of the server). 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: FHIR client updates the patient created in scenario #1 and updates to FHIR server. The patient is retrieved by Id.

Precondition: Patient has been created

Success Criteria: Patient updated on FHIR 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: FHIR client searches the FHIR server 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 to query FHIR server)

Bonus point: The UI allows the user to display previous versions of the Patient

4. Search for a patient on name

Action: FHIR client searches the FHIR server 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)

5. Delete a patient

Action: FHIR client deletes the patient with a given id

Precondition: a Patients with that Id has been created

Success Criteria: Subsequently querying for the patient - either searching by name or by Id - fails.

Help Links

Here are some links to assist implementers:

• REST API in the Specification.
• Patient resource in the Specification.
• Open_Source_FHIR_implementations.
• Publicly Available FHIR Servers for testing.
• Step by step tutorial and sample projects.

TestScript(s)

The supporting TestScripts and corresponding fixtures have been committed to the FHIR SVN repository at: http://gforge.hl7.org/svn/fhir/trunk/connectathons/SanAntonioJan2017/Connectathon14/Patient-01-Intro, and http://gforge.hl7.org/svn/fhir/trunk/connectathons/SanAntonioJan2017/Connectathon14/Patient-02-Formal (NOTE: use 'anonymous' as the username and your email address as the password)