GithubHelp home page GithubHelp logo

fdawgs / yh-fhir-listeners Goto Github PK

View Code? Open in Web Editor NEW
7.0 1.0 5.0 85.35 MB

Yeovil Hospital's Mirth Connect FHIR Listener channel for use with InterSystems' TrakCare PAS (v2020 MR6.11)

License: MIT License

JavaScript 87.63% TSQL 12.19% Shell 0.19%
nhs mirth-connect mirth fhir intersystems trakcare somerset somersetft yeovil-hospital

yh-fhir-listeners's Introduction

Note This repository is unmaintained as of 2023-05-03 as I am no longer employed by Somerset NHS Foundation Trust.

Yeovil Hospital - SIDeR FHIR Listener endpoints

GitHub Release Build Status code style: prettier

Yeovil Hospital's Mirth Connect FHIR Listener channel for use with InterSystems' TrakCare PAS (v2020 MR6.11)

Overview

Purpose

This repo outlines the steps that have been taken to provide the technical deliverables required by the SIDeR programme, alongside the issues that were encountered during development, and how to deploy the resulting Mirth Connect channel.

Logs documenting the work undertaken to deploy these endpoints can be found in docs/worklogs.

The intended audience for this page are team members of the Solutions Development team at Yeovil Hospital, alongside technical partners and developers from other stakeholders in the programme should they wish to use this and adapt it to implement in their own systems.

This documentation is written under the assumption that the reader has prior experience using Mirth Connect.

Background

NHS Somerset (SOMICB) started the SIDeR project to link up all main clinical and social care IT systems used in Somerset to improve and support direct care. Black Pear Software Ltd. (BP) is the technical partner that supports the project.

Stakeholders (as of 2022-11-01) are:

Deliverables

Care Connect RESTful FHIR API endpoints

Black Pear have built a single-page web application for a shared care record, which will retrieve data relating to a patient from each stakeholder that can do so, and amalgamate it into this record. The record is not stored in a cache anywhere and is built on the fly. Care providers can then access this record through a contextual link (an embedded link within the PAS). Clients using the web app need to be able to make GET requests to RESTful HL7® FHIR® API endpoints to retrieve a set of seven FHIR resources that adhere to their respective NHS Care Connect API profiles to populate the record.

Contextual link

A contextual link needs to be added to our PAS to allow care providers access to the shared record. Refer to Interoperability patterns - Contextual launch in the SIDeR wiki for more information.

Prerequisites

Setup

This Mirth Connect channel has been tested on a Mirth Connect instance (v3.12.0) running on Windows 10 and Windows Server 2019, with an instance of SQL Server 2019 being used as the database backend for Mirth Connect.

Perform the following steps before deployment:

  1. Download and extract the latest release asset
  2. Navigate to the extracted directory
  3. Install the FHIR Connector extension (dist/fhir-3.12.0.yh001.zip) in Mirth Connect
  4. Import the FHIR Listener channel (dist/FHIRListener.xml) into Mirth Connect
  5. Declare variables listed in the channel description, in the configuration map
  6. Run the SQL queries found in dist/sql to create lookup tables

Known issues and caveats

Issues with InterSystems' TrakCare PAS (used by YH) and staff misuse of the PAS have affected how the data is presented in the endpoints and how searches can be performed.

Data quality

  • AllergyIntolerance resources:
    • Unable to provide SNOMED codes for allergies and intolerances in AllergyIntolerance resources due to there being free text inputs in TrakCare
    • Low recordings of allergy and intolerance data in TrakCare:
      • 350,513 non-deceased patients with records in TrakCare as of 2020-11-19
        • 34,405 patients have ‘No Known Allergy’ recorded (9.8%)
        • 13,139 patients have one or more allergies recorded (3.7%)
    • Due to the above issues, Paul Foster (CCIO at YH) on 2020-11-19 suggested we do not provide AllergyIntolerance resources (functionality is still present in the channel, however)
  • Condition resources:
    • Unable to provide Condition resources as conditions are held in SimpleCode, not TrakCare
  • DocumentReference resources:
    • Unable to provide DocumentReference resources as these are held in Patient Centre, not TrakCare
  • Encounter resources:
    • Discharge/end dates for outpatient Encounter resources are not provided due to poor data quality. Staff in outpatients misuse these input fields in TrakCare to mark when “all admin has been completed for that outpatient encounter” and not when the encounter has finished
    • Unable to provide clinician contact details for Encounter resources due to the following:
      • In TrakCare a care provider has a mobile number field against them, but it is rarely populated
      • There is no internal contact number field in TrakCare
      • If you want to reach say, a gynaecology consultant, you need to manually search a list on YH’s intranet for their secretary’s extension number, and there is no indication as to how current the list is
      • Teams do not have a contact number
  • Patient resources:
    • Unable to provide SNOMED codes for religious affiliation as these are not in TrakCare (NHS Data Dictionary coding is provided, however)
    • Unable to provide GP surgery/organisation name value for inline Organization FHIR resource as this data is also not held in TrakCare; using GP consultant name as a placeholder
    • A sizeable number of patient records without postcodes

Search saveats

  • Every search request to a FHIR resource endpoint that is NOT the Patient FHIR resource endpoint MUST have a patient search parameter, this is to stop intentional or unintentional DOS attacks due to long-running SQL queries:
    • GET [baseUrl]/AllergyIntolerance?criticality=[code] will return a 500 error
    • GET [baseUrl]/AllergyIntolerance?patient=[id]&criticality=[code] will work

This is due to YH not having direct control over the underlying databases of the PAS, so cannot add indexes or make appropriate performance tweaks to support searches without also filtering by a patient.

Contributing

Contributions are welcome, and any help is greatly appreciated!

See the contributing guide for details on how to get started. Please adhere to this project's Code of Conduct when contributing.

Acknowledgements

  • Adam Wiles (YH) - Procedure FHIR resource advice
  • Anthony Smith (YH) - Logo design
  • David Suckling (YH) - TrakCare database table structure and frontend support
  • Dunmail Hodkinson (BP) - HL7 FHIR STU3 specification adherence and best practices advice
  • George Dampier (YH) - MedicationStatement FHIR resource advice
  • Jessica Male (YH) - TrakCare frontend support
  • Julian Matthews (SFT) - Bug reports
  • Jon Simpson (YH) - MedicationStatement FHIR resource advice
  • Neil Hayes-Webster (YH) - SQL query optimisation
  • Nicolas Noblet (YH) - SQL query optimisation, TrakCare database table structure advice
  • Will Jehring (BP) - HL7 FHIR STU3 specification adherence advice

License

yh-fhir-listeners is licensed under the MIT license.

yh-fhir-listeners's People

Contributors

dependabot-preview[bot] avatar dependabot[bot] avatar fdawgs avatar github-actions[bot] avatar greenkeeper[bot] avatar imgbotapp avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

yh-fhir-listeners's Issues

Read request to MedicationStatement endpoint takes up to 170 seconds to return results

Describe the bug

Making a GET request to the MedicationStatement endpoint takes an excessive amount of time (avg 170 seconds) to return results.

To Reproduce

Steps to reproduce the behavior:

  1. Make GET request to [baseUrl]/MedicationStatement/[id]

Expected behavior

For the requested resource to be returned in less than 5 seconds, which is the time is takes to return a result when making a read request for AllergyIntolerance, Patient, and Flag resources.

Desktop (please complete the following information)

  • OS: Windows
  • Version Windows 10

Additional context

The excessive time is due to the content of the dynamic WHERE clause in the SQL used to retrieve this data.

Read request to Flag FHIR resource endpoint results in error 400

Describe the bug

Read request to Flag FHIR resource endpoint results in error 400.

To Reproduce

Steps to reproduce the behavior:

  1. Make GET request to following [baseUrl]/Flag/[id]
  2. See error

Expected behavior

A single Bundle FHIR resource to be returned with a single Flag FHIR resource inside.

Desktop (please complete the following information)

  • OS: Windows
  • Version Windows 10

Read request to Encounter endpoint takes up to 50 seconds to return results

Describe the bug

Making a GET request to the Encounter endpoint takes an excessive amount of time (avg 50 seconds) to return results.

To Reproduce

Steps to reproduce the behavior:

  1. Make GET request to [baseUrl]/Encounter/[id]

Expected behavior

For the requested resource to be returned in less than 5 seconds, which is the time is takes to return a result when making a read request for AllergyIntolerance, Patient, and Flag resources.

Desktop (please complete the following information)

  • OS: Windows
  • Version Windows 10

Additional context

The excessive time is due to the content of the dynamic WHERE clause in the SQL used to retrieve this data.

Read request to MedicationStatement FHIR resource endpoint results in error 400

Describe the bug

Read request to MedicationStatement FHIR resource endpoint results in error 400.

To Reproduce

Steps to reproduce the behavior:

  1. Make GET request to following [baseUrl]/MedicationStatement/[id]
  2. See error

Expected behavior

A single Bundle FHIR resource to be returned with a single MedicationStatement FHIR resource inside.

Desktop (please complete the following information)

  • OS: Windows
  • Version Windows 10

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.