Short Description

Test and validate the functionality of our Implementation guide with real world vendors. Broadly, our objective is to prototype the exchange of ophthalmic data represented in validated FHIR resources  (Observations, Conditions, Procedures, Medications and DiagnosticReports) between EHRs and diagnostic devices. This addresses a fundamental interoperability problem and daily pain point for ophthalmologists, who rely on both diagnostic test results (generated by devices) and clinical information (contained within EHRs/EMRs) to make diagnostic and management decisions.

The following 2 technical scenarios are based on 2 corresponding and relevant clinical use cases. 

  • Scenario 1 seeks to demonstrate the transmission of validated FHIR resources from and EHR/EMR >> PACS
  • Scenario 2 seeks to demonstrate the transmission of validated FHIR resources from a PACS >> EHR/EMR (DICOM objects)

Proving this capability can be facilitated by the FHIR artefacts within our implementation guide will demonstrate its functional utility in solving a real world interoperability problem. 

Long Description

Now an 'imaging-dependent' specialty ophthalmology (and optometry), indispensably rely on data that is captured, stored and visualisable in various digital systems. Given these systems are often either physically separated (sometimes in different rooms), or only viewable through different software/PACS interfaces, routine point of care decisions are made by through manually and/or mentally integrating these data. 

The practicing clinicians ideal future state is one where these (currently) disparate systems are enabled to exchange and display data seamlessly in a semantically interoperable manner.

Examples of new diagnostic technology that augment the quality clinical practice, decisions and outcomes, as well as the nature of research include:

  • Automated perimetry: the testing a patients visual field - most frequently used in glaucoma assessments, but also has relevance other, less common, but important pathologies)
  • Optical coherence tomography: this near infra-red laser is primarily used to evaluate retinal disease (such as, most commonly, macular degeneration and diabetic retinopathy), and has an increasingly relevant role in the detection and monitoring of glaucoma. Through a single image captured of the back of the eye, it enables 3-dimensional visualisation of retinal architecture in single digit microns (by analogy, similar to a CT scan.) 

These examples of diagnostic tests are unique within the imaging/DICOM realm This is primarily because in performing/undergoing one of these tests, the devices not only generate an image/series of images/collection of data points, the manufacturer software also natively derives critical and clinically significant algorithmically-derived quantitative post-capture observations. For example, an OCT device will measure retinal thickness in various anatomical regions and present these to the clinician; when combined with the patients clinical history and examination findings (recorded and historically stored in the EHR/EMR - such as visual acuity and intra-ocular pressure), these device-outputs are fundamental to patient management decisions and recommendations made by the clinician.

Further, given that macular degeneration, diabetic retinopathy and glaucoma are 3 or the 4 leading causes of blindness globally, facilitating interoperability between the results of these diagnostic devices and EMR/EHR clinical and demographic data is an essential need for ophthalmic interoperability. Beyond enhancing daily practice, harmonising this data also has and will continue to enable unprecedented research into disease and ongoing accelerated development of sight-saving therapies artificial intelligence-driven screening and diagnosis.

Success for this connectathon is to illustrate IG Resource validity and capacity for interoperable data exchange as a robust and functional proof of concept. As a first in kind, the initial objective is to submit the iteratively refined IG for formal HL7-FHIR balloting in September '21. Thereafter, through sequential cycles the goal is to expand the IG's utility to enable additional interoperability needs (use cases) described on our confluence page, and continue to deepen community stakeholder engagement, development, adoption and validation. 

Type

Test an implementation guide

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

Patient care

Track Lead(s)

Ashley Kras (ashleylkras@gmail.com); Warren Oliver (woliver@oculo.com.au)
Track Lead Email(s) ashleylkras@gmail.comwoliver@oculo.com.au

Related Tracks

FHIR Version

FHIR R4

Specification(s) this track uses

Connectathon FHIR IG to be used - linked here (draft - ongoing WIP)

Artefacts of focus

We will primary be using the following Resources: Condition, Observation, Procedure, Medical, ServiceRequest and DiagnosticReport.

Validating a number of specialty-specific value-sets and code-systems will also be essential to achieving a successful outcome (as defined below.) Examples include: device-generated observations and specific devices used (eg - tonometers that measure intra-ocular pressure). 

Expected participants

Expect: >10-15

Participants / vendors confirmed below (additional / final list pending):

Heidelberg Engineering (Device)

Zeiss (Device)

Medisoft (EHR)

Oculo (tele-ophthalmology platform)

Topcon (Device manufacturer)

Wynk (EHR)

Multiple ophthalmologists (domain experts)

Endorsement (& participation):

NEI (national eye institute) - ophthalmic subsidiary of the NIH

Zulip stream

https://chat.fhir.org/#narrow/stream/238885-Opthalmology/topic/stream.20events

Track Details

Our prep work is being collaboratively collated in this google doc

Scenarios

Scenario Step 1 Name:

EHR > PACS

Action:

  1. Produce a map (see below) of EMR data with FHIR resource data that can show how FHIR resources could be generated by an example EMR. 
  2. Based on clinical scenarios, use postman to push example resources of Patient, Observation, Procedure, Condition, DiagnosticReport, Medication to public FHIR Server. 
  3. Check that all data sets have arrived in the public FHIR server.
  4. Validate the resources against the implementation guide (Validator tool).
  5. From PACs the user can see the list of Observations, Procedures, Conditions within a screen in the PACs

(Detailed in the gdoc above)

Precondition:  

EHR the data contains elements relevant data from the patient history 

Success Criteria:  

Validation of the ophthalmic FHIR Resources contained within our IG (particularly, those relevant to the clinical scenario outlined)

Demonstration of successful exchange by proving the Resources can be received and displayed by the designated PACS

Bonus point:


TestScript(s):

This will be baked into gdoc above +/- repository


Security and Privacy Considerations: