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

2 Day Virtual event to help advance the implementation of FHIR in Australia and New Zealand facilitating open interoperability

When: 23rd/24th November 2021

Where:

Join Zoom Meeting

https://hl7-au.zoom.us/j/89870088679?pwd=bU1aVnJBQkFPS0g4MTBEVkhIbm8zUT09

Meeting ID: 898 7008 8679
Passcode: 730377


How much: Free Registration https://www.eventbrite.com.au/e/inaugural-hl7-fhir-trans-tasman-connectathon-registration-193185943357

Connecting Spreadsheet:  https://bit.ly/30GPeba

Master of ceremonies: Dr David Hay

There will be some opening presentations, followed by the Connectathon Tracks, and then closing with a summary session to see how we all progressed integrating!

PERMISSIONS: this area can now be edited by any user logged into confluence; please add child pages and material as needed for sharing

Agenda

(all times in Australian Eastern Daylight Time)

Tuesday 23rd November

TimeDescriptionPresenter
9:00amWelcome from HL7 NZ and HL7 AUPeter Jordan, Kate Ebrill
9:10amWhat happens at a virtual ConnectathonDr David Hay
9:15amGetting to know who is in a virtual roomKylynn Loi
9:20amIntroduction to IPS TrackPeter Jordan
9:50amIntroduction to FHIR Smart App Launch TrackBrian Postlethwaite
10:20amIntroduction to Smart Cards TrackGrahame Grieve
10:50amBreak
11:00amConnectathon tracks commence
12:00pmIntroduction to FHIR tutorialDr David Hay
2:00pmIntroduction to FHIR Terminology ServicesJim Steel

Wednesday 24th November

TimeDescriptionPresenter
9:00amQuick debriefTrack Leads
9:15amConnectathon Tracks resume
3:00pmClosing PlenaryMC Isobel Frean
3:00pmReport back, show & tell on what has been achievedDr David Hay - facilitator
3:30pmFHIR Terminology Services and OMOPDr Michael Lawley
3:50pmCommunity Workers in Rwanda enabled through SNOMED CT and FHIRDr Matthew Valentine
4:10pmFrom Data Mess to Data Bliss Using SNOMED CT and FHIRDr Blake Mumford
4:30pmQ&A
4:50pmClosing survey and wrap up
5:00pmClose


Breakout Sessions... https://docs.google.com/spreadsheets/d/185bb1lEANogpuGkInu2GOtpEyy9cebdJR5va8xt_j4E/edit#gid=0


Connectathon Tracks:

SMART Health Cards

Smart Health Cards are a way to share clinical facts about a patients health with the patient, in a way that any system can verify that the statement fact has not been altered. An obvious immediate use is for covid vaccination certificates, but they have many other uses.

The Smart Health Card track will be suitable for three kinds of participants: technical developers producing or consuming smart health cards, or interested business/policy folks who want to understand the smart heath card eco-system it's uses and limitations. In addition to an ongoing working session around producing and validating/verifying smart health cards, and working with consumer and technical grade tooling for smart health cards, we'll have several informal updates from Australian, US and global implementers and stake holders, along with time for discussion. 

Tools/Collaterol for Smart health Cards:

Scenarios

  • Producer: for a given Patient with a known email address, and two covid vaccinations, produce a certificate and send it to that address by email (actually use the email of a consumer participant)
  • Reader: given a card arriving in email, transfer it to your system (manually ok, but bonus for scanning the QR code), verify the signature and correctly display the information 
  • Business Analyst / Consumer: Given a card arriving in email, read the card and verify it with a consumer grade application, and read the information using a decoding tool. Bonus: as a group, describe a workflow for using Smart Health Cards to speed admission to a crowd event that is vaccinated people only

Provisional Schedule for the two days:

Day 1

  • 11:00am Smart Card Welcome (survey track) + introductions + setting scene
  • 11:15am Tools Demo
  • 12:00 Implementer report: US adoption experience
  • 12:30 Lunch break
  • 13:15 Progress Reports
  • 13:45 Open Issue: Use of smart cards for covid test reports (includng personal RAT testing)
  • 14:30 Implementer Report: report on experience from Sydney LHC
  • 15:30 Open Issue: Coding Vaccines for Australian Use
  • 16:30 Check-in prior to ending for the day

Day 2

  • 9:15 Check in / agenda for the day
  • 10:00 Implementer Report: Consumer software provider
  • 10:45 Open Issue: Card Revocation
  • 11:15 Open Issue: Key Aggregation
  • 12:00 Implementer Report: US implementer
  • 12:30 Lunch
  • 13:30 Check in – agenda for last session + report back on workflow
  • 14:00 Implementer Report: Australian agent for the Commons Project
  • 14:45 Assemble report back

Notes about the schedule:

  • this is still subject to revision as availability is confirmed
  • all times are approximate - the real purpose of the track is to support implementers get smart health cards working, and there's plenty of gaps for detailed technical discussion / troubleshooting, or to discuss other issues

International Patient Summary (IPS)

Short Description

This track will test the creation and exchange of patient summary data across jurisdictions (Australia & NZ and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification.  

Long Description

This track will test the creation and exchange of patient summary data across jurisdictions and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification.  The track will focus on the primary theme of cross-border IPS document bundle data exchange, with additional sub-themes:

  • Pilot implementations of multiple jurisdictions (e.g., GDHP) for cross-border IPS document bundle data exchange
  • Test implementation of proposed Patient resource $summary operation (multiple servers, including Terminz)
    • Can generate an IPS instance for a patient based on existing data and a set of rules
    • Rules can be server-defined (default) or specified by parameter
    • Need to answer the “relevant” question for what data to include
  • Enhanced IPS instance testing leveraging the Inferno testing tool (MITRE)
      • One or more FHIR server(s) for demonstrating and testing IPS data exchange are included
    • Using this testing tool suite should enable increased and more consistent Connectathon participation and facilitate further and more rapid progress across the multiple testing events with the continuing development of the IPS specification (FHIR IG and profiles) and IPS implementations

General track goals include:

  • Create greater understanding of the IPS and its potential use in cross-border exchanges in our Region
  • Promote the sharing of experiences in regional IPS implementations to date
  • Identify gaps and pitfalls in the IPS IG specification - with particular focus on the continued use of the MedicationStatement resource
  • Discuss semantic interoperability challenges (e.g. national editions of SNOMED CT and national medicines terminologies)

An open approach will be followed, expecting attendees to actively participate in the selection and definition of the tests to be performed and topics to be discussed, beyond those suggested by the track leaders.

Track Lead(s)

Peter Jordan, pkjordan@xtra.co.nz

Brett Esler, brett.esler@oridashi.com.au

FHIR Version

R4

Specification(s) this track uses

CI (Continuous Integration) Build (the suggested primary IPS specification version for testing)

http://build.fhir.org/ig/HL7/fhir-ips/index.html


Available servers for IPS testing/exchange

  • Terminz (NZ Test Server)

    https://terminz.azurewebsites.net/fhir

    Will now accept (and save) POSTs of IPS Bundles that satisfy the following criteria...

    • Bundle.Type == Bundle.BundleType.Document
    • Composition.Type.coding.system="http://loinc.org" and code="60591-5" 
    • Contains one Composition and one Patient Resource
    • Contains at least one of each of these resources - AllergyIntolerance, Condition and MedicationStatement.
    • Includes at least one Patient.Identifier with populated system and value elements (these are used for persistence and $summary request purposes)

    The $summary operation is also provisionally defined at https://terminz.azurewebsites.net/fhir/OperationDefinition/Patient-summary

    An example request using this operation...

GET https://terminz.azurewebsites.net/fhir/Patient/$summary?profile=http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips&identifier=https://standards.digital.health.nz/ns/nhi-id|NNJ9186&_format=json

Note these input parameters:

Profile - the canonical URL of the IPS Bundle (this is mandatory as a means of distinguishing the IPS from other patient summary types)

Identifier - a token containing the naming system URI (in the above example the NZ National Health Index) and the identifier instance (NHI Number)

Further example NHI Numbers of test IPS instances held on Terminz are AAA1234, JMG7692, JMG7706, ZZZ0121, ZZZ0130 and ZZZ9994

Artifacts of focus

We're planning to focus this time on the IPS Bundle and Composition, for IPS document exchange, plus the IPS profiles for the required Medication, Allergy and Problems sections and the recommended Immunization and Lab Results sections (plus Patient).

IPS "base" profiles

IPS Bundle: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Bundle-uv-ips.html

IPS Composition: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Composition-uv-ips.html

IPS Medication: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Medication-uv-ips.html

IPS MedicationStatement: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-MedicationStatement-uv-ips.html

IPS MedicationRequest: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-MedicationRequest-uv-ips.html

IPS AllergyIntolerance: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-AllergyIntolerance-uv-ips.html

IPS Condition: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Condition-uv-ips.html

IPS Immunization: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Immunization-uv-ips.html

IPS Observation - Results (Laboratory): http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Observation-results-laboratory-uv-ips.html

IPS DiagnosticReport: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-DiagnosticReport-uv-ips.html

IPS Patient: http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Patient-uv-ips.html

Zulip stream

IPS Connectathon Testing Stream (multiple topics)

Track Details

IPS Storyboards

  • International travel and unplanned care in a different country/territory
  • Data exchange for clinical care in limited resource environments (LMIC)

IPS Roles

IPS Document Creator

Creates or updates a FHIR IPS document (Bundle containing a Composition and supporting resources) from source data. The source data likely will be existing data on a FHIR server, but this can be done using whatever means are appropriate, including manual creation, assembling documents from other resources, transforming from a CDA IPS document, etc. Submits that document to a FHIR server. Optionally a document creator may digitally sign the document (but this is not expected at this time).

IPS Data Source

Creates or Update FHIR IPS resources (e.g. allergies, vaccination data) to be used for creating or updating a FHIR IPS document. The source data likely will be existing data on a FHIR server, but this can be done using whatever means are appropriate, including manual creation, assembling documents from other resources, transforming/extracting data  from a CDA IPS document, etc. Submits those resources to a FHIR server. 

IPS Document Consumer

Retrieves a FHIR IPS document and/or individual component resource instances created by the Document Creator, or the Data Source, from the FHIR server and does one or more of the following: a) validates the document and/or component resource instances against the IPS Clinical Document profile, b) displays the document and/or discrete data components in a browser (or by other means), c) translates the coded and/or narrative data to a different language for display, or d) translates the coded data to different code system(s) used in a jurisdiction that is different from the source.

IPS Document Processor

Uses a FHIR IPS document and/or individual component resource instances for the purpose of creating/updating other kinds of IPS based documents as for example vaccination certificate.

Candidate Scenarios

For all scenarios below, participants are expected to provide their own content for the documents (obviously nothing with PHI should be used at a public Connectathon). If participants don't have readily available content, they are encouraged to create documents that mimic the content in IPS or other patient summary sample files.

The following scenarios describes few of the many situations that can be realized and tested:

  1. Create and submit an IPS document bundle (bundle end point)

Action: User creates a FHIR IPS document consisting of a Composition resource with narrative sections, bundled with Patient (Composition.subject) and Practitioner (Composition.author) and the additional supporting component resources containing the summary clinical data.

User then POSTs the document to a FHIR server, by using the bundle end point.

Precondition: none, but existing resources may be used.

Success Criteria: Bundle is successfully submitted to a FHIR server. Consumer in Scenario 4 can display the document and render all attested content

2. Create and submit an IPS document bundle (base end point)

Action: User creates a FHIR IPS document consisting of a Composition resource with narrative sections, bundled with Patient (Composition.subject) and Practitioner (Composition.author) and the additional supporting component resources containing the summary clinical data.

User then POSTs the document to a FHIR server, by using the base end point.

Precondition: used resources are not

Success Criteria: all of the resources that the IPS bundle contains are processed as individual resources. Consumer 4 can ask to generate a new IPS bundle by using the $document operation.

3. Submit an IPS composition and retrieve the IPS by using the $document operation

Action:

  • Step 1: Create a Composition resource
  • Step 2: Ensure the subject, author, and custodian references point to valid Patient, Practitioner, and additional clinical resources.
  • Step 3: POST the Composition to a FHIR server
  • Step 4: Check the operation outcome to ensure it was successful
  • Step 5: Call $document (persistent option) on the Composition to get a full document Bundle back,

Precondition: all referenced resources are owned by the FHIR server generating the IPS

Success Criteria: The IPS Bundle is successfully generated and made persistent by the FHIR server.

3a. Retrieve the IPS by using the $summary operation

Action:

The $summary operation is also provisionally defined at https://terminz.azurewebsites.net/fhir/OperationDefinition/Patient-summary

  • Step 1: Review requirements from the Available Servers (see above)
  • Step 2: Call the $summary operation on one of the available servers

Precondition: The IPS Bundle is already present on the target FHIR Server

Success Criteria: The IPS Bundle is successfully retrieved from the FHIR server.

4. Display an IPS document and/or individual component resources

Action: User retrieves an IPS document and/or discrete component resources from the FHIR server and displays the data in a web browser (or by other means).

Precondition: An IPS document exists on the target FHIR server.

Success Criteria: Document is successfully displayed.

5. Translate (or map) the narrative and coded data

Action: the consumer retrieves an IPS (or some of the used resources) and possibly using FHIR terminology services translate the narrative and coded data into different language(s) for display or to other code systems appropriate for different jurisdictions.

Precondition:

Success Criteria: a translated display for a codeable element, or a code mapped into another code systems appropriate for different jurisdictions is shown.

6. Update an IPS document and/or individual component resources

Action: 

  • the data source POST/PUT new or updated components to the FHIR server
  • the Creator retrieves an IPS (or some of the used resources) and uses these data to update the IPS
  • the Creator PUT the new IPS Composition 

Precondition: An IPS document exists on the target FHIR server.

Success Criteria: An updated IPS is made available for usage in the Server.

7. Process an IPS document and/or individual component resources

Action: the processor retrieves an IPS (or some of the used resources) and uses these data to generate other IPS-based document as for example Vaccination Certificates.

Precondition: An IPS document exists on the target FHIR server.

Success Criteria: a translated display for a codeable element, or a code mapped into another code systems appropriate for different jurisdictions is shown.

TestScript(s)

No test scripts have been defined at the present time.

Security and Privacy Considerations

These are important considerations as IPS implementations are progressing.  No specific security expectations or requirements have been defined at the present time - but the proposed International Patient Access (IPA) IG specification may help to provide a model and a means for addressing these issues .


FHIR SMART App Launch - Australia

The FHIR SMART App Launch capacity permits launching applications (typically from 3rd parties) from EHRs providing patient and practitioner context along with the link to the EHR's FHIR endpoint.

There are several pages covering how HL7 Australia has proposed to extend the international specification (notably how to get at the practitioner's Australian Medicare provider number).

Project: AU FHIR Smart App Launch

FHIR SMART App Launch Walkthrough

FHIR SMART App Launch Australian Profile - EHR Launch

During the connectathon we would like to see multiple hosts and smart apps be developed/tested.

Brian Postlethwaite from Telstra Health has developed a SMART Test App that can be used,

And the argorun project has a test web host that can be also used to run your apps - however that does not provide the Australian context.

Telstra Health may have some other Smart apps and hosts to test, and hope to see many more.

RoleDescription
FHIR SMART App Launch Host

An application that can launch a SMART App Client providing it's FHIR Server API and Identity Service

Scenario 1: Launch the test app, view the launch details

Scenario 2: Verify the PKCE was verified correctly

Scenario 3: Verify that the patient/practitioner/practitioner role details

Scenario 4: Verify that the Identity Token was signed by the NASH Certificate and contains the correct properties

Scenario 5: Verify that application scopes were correctly enforced and querying the Host FHIR API was secured correctly

Scenario 6: (Bonus) Support writing some data back to the FHIR API from a FHIR SMART Client app

FHIR SMART App Client

A Web application that can be launched by a SMART App Launch Host

Scenario 1: Be launched by a FHIR SMART App Host, retrieve the Hosts Identity endpoints and authenticate/authorize with the Host's FHIR API

Scenario 2: Retrieve the Patient/Practitioner context provided in the token

Scenario 3: Extract some data from the host's FHIR API based on the patient/practitioner in context

Scenario 4: (Bonus) Write some content back to the host's FHIR API

  • No labels

2 Comments

  1. Videoconference details:

    Join Zoom Meeting
    https://hl7-au.zoom.us/j/89870088679?pwd=bU1aVnJBQkFPS0g4MTBEVkhIbm8zUT09

    Meeting ID: 898 7008 8679
    Passcode: 730377



    1. thanks Michael Lawley I was looking for that!