201701 Patient Track Proposal

Return to January 2017 Proposals

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: TBD

Step by step tutorial and sample projects: https://github.com/furore-fhir/fhirstarters

Submitting WG/Project/Implementer Group

FHIR Management Group (FMG) in association with Patient Care (PC)

Justification

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

Its purpose is to provide a way for those new to FHIR to participate using a simple scenario that can be met with limited domain knowledge, and by those who have not have 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 - no previous FHIR knowledge.

While it can help the Patient resource progress along the Maturity Model, this is a secondary objective as the Patient resource has already had substantial exposure both at connectathons and in the wild.

Proposed Track Lead

David Hay See Connectathon_Track_Lead_Responsibilities

Report

As this track is intended as a 'friendly introduction' to FHIR, there wasn't any real changes proposed - though it was noted that there is some ambiguity in the spec concerning the response header that should be used by the server to indicate the location of a newly created resource - this can be 'Location' or 'Content-Location' - and the client needs to check for both. A Tracked has been raised suggesting clarification.

There were 17 different client/server tests, the majority of them successful. Both clients and servers were developed (or completed) on the day, and the participants felt that the event was useful for them.

We did have an impromptu tutorial at the start of the event going over the basics of FHIR that was well received and maybe something that we should consider holding next time as well.

Expected participants

Unknown in this case. New participants typically make up 30% or more of Connectathon attendees.

Roles

FHIR Client

Enable the creation and retrieval of the Patient resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.

FHIR Server

Support the receiving and processing of the Patient resource operations: create, history, read, search and update.

Scenarios

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

5. Delete a patient

Action: (Patient Demographics consumer) 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.
• Java client sample.
• .net client sample.
• Publicly Available FHIR Servers for testing.

TestScript(s)

The supporting TestScripts and corresponding fixtures will be committed to the FHIR SVN.