Page tree
Skip to end of metadata
Go to start of metadata

Proposals due by : November 30, 2019

Justification and Objectives

In one of the first initiatives of Australia’s National Digital Health Strategy – Safe, Seamless, and Secure, the Australian Digital Health Agency partnered with eHealth NSW and the Sydney Children’s Hospitals Network to establish the National Children’s Digital Health Collaborative.

This innovative program was set up in April 2017, bringing together Australia’s leading experts in children’s health to identify a number of strategic digital health projects for funding by the Australian Digital Health Agency (ADHA). This transformative, national partnership aims to improve the health and wellbeing of all Australian children and young people.

As part of this, the Collaborative is undertaking important work that forms the first step in creating a more comprehensive digital health record for every child born in Australia. It will do this by expanding on the existing capabilities that exist within national health infrastructure within Australia including demonstrating the use of a FHIR server to facilitate the interaction with, and sharing of, child health information between health care providers and health care consumers.

The objectives of this track are as follows:

  • Test and seek feedback from a broad set of Australian and international implementers on the usability of the proposed FHIR implementation guide.
  • Increase awareness of the proposed implementation guide and allow vendors to gain early experience in implanting against it.
  • Test the logic and capabilities within the FHIR server against multiple different implementations.

This track will use 3.0.2 version of FHIR with emphasis on the Australian National Child Digital Health Implementation Guide (http://build.fhir.org/ig/hl7au/au-fhir-childhealth/)

Clinical input requested (if any)

No clinical input is required however clinical participation is welcomed.

Related tracks

CSIRO Primary Health Care track

Proposed Track Lead

Nichol Hill (nichol@ncctech.com.au)

Expected participants

Shovan Roy, Blair Thompson, who else????

Track Orientation

TBC at a convenient time, suggest mid January?

System Roles

FHIR Client (Health Provider): Interacts with the FHIR Server to exchange Child Health information regarding one or more children within context of the provision of health care by a health provider. This role would normally be played by a CIS in the context of talking to the FHIR Server (National Child Data Hub)

FHIR Client (Consumer App): Interacts with the FHIR Server to exchange Child Health information regarding one or more children within the context of a Parent or Carer for the children. This role would normally by played by a consumer application

FHIR Server (National Child Data Hub): The FHIR server supports the receipt and supply of information to both client types mentioned above. A server will be supplied for the track however participants interested in implementing server capabilities are welcome to participate.

FHIR Server (Health Provider): Supports the use of SMART on FHIR apps within clinical practice to collect and manage Child Health Information. This role would normally be played by a Clinical Information System or EMR in the context of embedding a SMART on FHIR app.


Scenarios

Scenario 1 - FHIR Client (Consumer App) Login to FHIR Server and retrieve list of Patients

Action: Application will follow a SMART on FHIR launch sequence (including Authorization Code Grant) to authenticate with the FHIR Server (National Child Data Hub) and will request to retrieve a list of patient resources.

Precondition: None

Success Criteria: Application is able to follow SMART on FHIR flow and retrieve a list of patient resources.

Bonus point: Ability to link to Scenario 2 below.

Scenario 2 – FHIR Client (Consumer App) Retrieve a summary list of Health Check Assessments that have been performed for a child

Action: Application will request a summary list of health heck assessment using a get /$docucument-view custom operation with parameters to request a summary list of health check assessments. Parameters will include identification of a specific child patient rescource.

Precondition1: Request must be made against a specific patient resource and therefore the patient resource must exist in the FHIR server and the requestor must be able to identify that resource either via the list of patients returned using scenario 1 or  using samples directly supplied as part of the track.

Precondition2: While not strictly a precondition should the summary list be requested for a child that has not had any health check assessments performed the result will be a document with an empty reason.

Success Criteria: Application receives a Questionnaire Response in a document that contains a summary list of health check assessments for the requested child.

Bonus point: Ability to link to Scenario 3 below.

N.B. No authentication will be required to perform this scenario within the track

Scenario 3 – FHIR Client (Consumer App) Retrieve the details of a Health Check Assessments that has been performed for a child

Action: Application will request a specific health check assessment using a get /$docucument-view custom operation with paraments to request an individual health check assessments. Parameters will include identification of a specific child patient resource and a specific health check.

Precondition1: The requested health check must exist in the fhir server and the requestor must have the details of a specific assessment. These are either obtained using scenarios 1 and 2 above or using samples directly supplied as part of the track.

Success Criteria: Application receives a Questionnaire Response that contains a detailed view of the requested health check assessment.

Bonus point:

N.B. No authentication will be required to perform this scenario within the track

Scenario 4 – FHIR Client (Health Provider) supply the details of a Health Check Assessments that has been performed for a child

Action: Client will supply the content of a health check assessment to the FHIR Server (National Child Data Hub) for a specific child as an attested document

Precondition1: The child must already exist as a patient resource in the FHIR server

Success Criteria: FHIR Server (National Child Data Hub) receipts and persist the document with no validation errors.

Bonus point:

N.B. No authentication will be required to perform this scenario within the track


Scenario 5 – FHIR Client (Health Provider) retreive the details of a Health Check Assessments that has been performed for a child

Action: Client will query the FHIR Server (National Child Data Hub) for details on a specific health check assessment.

Precondition1: The queried health check assessment must already exist in the FHIR Server (National Child Data Hub)

Success Criteria: FHIR server returns a health check assessment as a document.

Bonus point:

N.B. No authentication will be required to perform this scenario within the track


Scenario 6 – FHIR Server (Health Provider) launches a SMART on FHIR assessment form and retrieves its output.

Action: FHIR Server (Health Provider) will launch an external SMART on FHIR app using the SMART on FHIR launch sequence and use this form to capture structured child health data.

Precondition1: FHIR Server (Health Provider) must support the SMART on FHIR launch sequence including authorization.

Success Criteria: FHIR Server (Health Provider) supplies data and is able to have returned data from the SMART on FHIR app.

Bonus point:


TestScript(s)


Security and Privacy Considerations


  • Integrations with the FHIR Server (National Child Data Hub) (Scenarios 1-5) and access to the SMART on FHIR application (Scenario 6) will be over HTTPS.
  • Scenario 1 will require using oAuth as a client part of the SMART on FHIR launch sequence.
  • Scenario 6 will require using oAuth as a server part of the SMART on FHIR launch sequence.



  • No labels