201601 Data Access Framework (DAF)

DAF Patient, DAF Condition, and DAF Allergies

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

Submitting WG/Project/Implementer Group

Infrastructure and Messaging (I&M)

Justification

This is a logical next step to FHIR connectathon Track 1 - Patient access that conforms to a specific profile.

Its purpose is to provide a the next step for folks creating the simple FHIR client for accessing a patient. 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.

The Data Access Framework (DAF) profiles have had some testing in outside organizations (e.g. Argonaut) and this is another opprotunity to progress the profile up the Maturity Model.

Proposed Track Lead

Coordinator: Nagesth Bahsyam (Dragon)

Expected participants

The expected participants are those implementing DAF profiles, vendors planning to implement FHIR/DAF profiles for 2015 API certification criteria, vendors who are attending a Connectathon for the first time and want to participate, and folks that participated in the Argonaut Sprints in the fall of 2015.

Roles

FHIR Client

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

FHIR Server

Enable the retrieval of the various resources using the following Operations: READ, vREAD, SEARCH

Steps

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 Spefication.
• Patient resource in the Spefication.
• Java client sample.
• .net client sample.
• Publicly Available FHIR Servers for testing.

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/OrlandoJan2016/Connectathon11/Track1-Patient

TestScript Definitions

The TestScript resources in this folder represent all of the possible variations** within the tests; i.e. JSON vs. XML content, client vs. server resource id assignment, and bonus vs. no bonus features.

**This representation of the Track 1 - Patient tests is not meant to be definitive and complete. This is one example of how these tests can be defined in the current DSTU2 format of the TestScript resource. Constructive feedback, suggestions and criticisms are welcome.

Based on these testing variations, the following TestScript definitions are available - one for each variation:

FHIR Resource ID Assigned by the Client

• track1-patient-base-client-id-json -- JSON Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with client assigned resource id.
• track1-patient-base-client-id-xml -- XML Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with client assigned resource id.
• track1-patient-bonus-client-id-json -- JSON Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and client assigned resource id.
• track1-patient-bonus-client-id-xml -- XML Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and client assigned resource id.

FHIR Resource ID Assigned by the Server

• track1-patient-base-server-id-json -- JSON Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with server assigned resource id.
• track1-patient-base-server-id-xml -- XML Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with server assigned resource id.
• track1-patient-bonus-server-id-json -- JSON Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and server assigned resource id.
• track1-patient-bonus-server-id-xml -- XML Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and server assigned resource id.

Conventions Used

The execution of the TestScript resources contained in this folder are constrained by the following conventions:

Fixtures - All resource reference values can be either url paths or local local file system paths. The convention for these TestScript resources use local file system paths where the execution engine is expected to resolve this path based on the following:

• Leading '/' character - this is resolved as an absolute path based on a known root path.
• No leading '/' character - this is resolved as a relative path based on the location of the TestScript resource file.