Møte 20 i FHIR fagforum

  • Dato: 2023-10-18
  • Klokkeslett: 1300-1500
  • 52 personer innom møtet (+3 i møterommet)

FHIR fagforum (FFF) er et åpent forum om bruk og implementering av HL7 FHIR i Norge. FFF er åpent for alle.

Agenda: FHIR R5

  1. Welcome, Thomas Tveit Rosenlund, Direktoratet for e-helse (5 min)
  2. Info fra HL7 Norge Øyvind Aassve, Sykehuspartner (5min)
  3. Epic FHIR capabilities and global implementation experience Sam Echevarria and Cody Bloom, Epic (60 min)
  4. Helseplattformen og FHIR, Eigil Gotaas, A2/Helseplattformen (30 min)
  5. Q&A

Presentasjoner

Intro and HL7 Norway

  • no-basis
  • Høringssvar on the adverse reaction information model
  • Terminology binding in the FHIR IG’s and handling of valuesets
  • Topics for courses and seminars
  • Workflow for FHIR harmonization in projects using FHIR

Epic FHIR capabilities and global implementation experience

  • Sam Echevarria working with implementation of FHIR for hospitals in the Netherlands
  • Epic is a EMR supplier from the US
  • Helseplattformen uses Epic
  • One global codebase
  • Interoperability toolkit -
    • Messaging, API’s, document sharing, workflow and data migration
  • FHIR first for API development
  • Query response against the database - different datapoints supported
  • 1300 unique apps integrate with Epic FHIR API’s 40 milliarder oppslag i året
  • 400+ FHIR API’s
    • Includes create and update
  • JSON tech
    • OAuth 2.0 - authorization
    • SMART on FHIR - app launch framework
    • Open IDConnect - identfication
    • SMART on FHIR EHR launch framework -
  • Other uses of FHIR
    • Bulk FHIR data
    • FHIRCast - context sync -
    • Other exchange patterns - messaging etc.
    • Based on actual use-cases
  • Open.epic.com - documentation of all FHIR API’s that Epic supports
    • fhir.epic.com
    • Free sandbox for testing and development
    • System ownership

DISCLAIMER - not a development roadmap

  • FHIR as the technical approach - primary
    • Modernize
    • Unify
    • Solve open needs - things not solved well today by older standards
    • Combinations
  • IPA - International Patient Access
    • Patients access to patient data
    • FHIR base based on IPA
    • DK-Core considers IPA dependencies
    • Vulcan
    • Nordics on FHIR - engage in IPA work
  • Incorperate IPA
    • New mechanisms
  • IPS - International Patient summary
    • Perspective currently focus on IPA in Epic
  • FHIR R5 - General advice
    • R4 has most support
    • R5 is currently best for greenfield development - in need of the latest updates and features
  • SMART 2.0
    • security enhancements and grenular scopes
    • Smart 1 scopes: “patient/Observation.read”
    • Subresources - different kinds of Observations
      • no support for this granularity in v1
    • granular scopes with “?category=vital-signs”

Perspective from FHIR globally

  • Use the right tool for the task at hand
    • FHIR does not solve all interoperability needs
    • How to choose the right tool
  • Enterprise Data warehose population
    • keep up to date on a nightlybasis
    • EDW stors data as FHIr resources
      • Not good use case
      • How to keep the data up to data up to date, FHIR Bulk could work
    • EHR <-> ordering and result
      • Existing solutions exists and works good
      • Ordering and resulting API’s is not a good fit
      • existing messaging works good and does not need replacing.
  • Integration design
    • Don’t devlop in a vacuum
    • well behaved to consider, safety, security, privasy and reliability
  • The FHIR profiling
    • Profile prolification - Data science approach
    • The profile explosion can be a problem
      • ePrescribing as example
    • Diverge as little as possible
      • example resources
      • Conformance rules
      • mustsupport /other tools in the standard
    • Artifacts - do they give enought information to implementers
      • Automated test tools
      • Realistic expectiations
        • years not months - collaboration and hard work
  • A global effort
    • Needs engagement from different groups
    • Engage in HL7 Norway, nordics on fhir and hl7 int.

Questions

  • Are you planning to support R5?

  • Perhaps Helseplattformen could do a presentation some time about their thoughts and support for SMART-on-FHIR and we could work together to get some demos of SMART-apps in the Helseplattformen environment?

  • Can you comment on how widespread services with CDS Hooks interfaces are?

  • Have you ever hit limitations of the Card structure and wished you could have more structure in the response you received? Do you have a real-world example that uses Card extensions?

  • Answer: Just FYI if you want to read more about our support for that, you should be able to access this: https://vendorservices.epic.com/Article?docId=clinicaldecisionsupport Home - Vendor Services you do have to create a free account though

  • Q: The global codebase does it cause any problems with development in different juristictions?
  • Answer: Is it possible to harmonize the use cases across jurisdictions.

FHIR in Helseplattformen

  • Helseplattformen first release is mostly based on existing national standards, not much FHIR but implemented
    • SFM medication
    • helsenorgeno booking
    • ScreenIT tarmscreening
    • Implemented using biztalk integrations
  • Lessons learned
    • Extensive use of extensions in some Norwegian FHIR IG’s
    • Use of codesystems
  • SFM - experience
    • A lot of Norwegian specific extensions - for example for defining the FEST information model
      • Examples:
        • FEST
        • Organization info
        • Allergy intolerance - timestamp information
        • SFM medication - information ends up in extensions
    • Makes re-use of code from global codebase difficult
  • The definition of the coding of the medication prescribed is not well defined/precise
  • Helsenorge
    • Fewer extensions
    • Needs common national work on appointment types, the codesystems used in helsenorge is not specific enough for spesialisthelsetjenesten
  • ScreenIT koloskopi screening
    • Registry reporting - populating data warehouse?
    • Create a lot of extensions that makes the resources really complex
    • Probably better as a Questionnaire instead of bundled FHIR resources.
  • A more successfull approach to using FHIR
    • FHIR as a standard information model
    • OMOP common data model for use in structuring research data
      • FHIR based structure?
  • Adapt solutions to standard instead of standard to existing solutions
    • FHir information model is based on 30+ years of integration work
  • Needs more focus on Codesets/valusets
    • needed for precision, decision support and actual interoperability
    • Use international standards when possible (SNOMED, LOINC, etc)
    • When no codesets are defined you need translation (expensive)
  • A lot of international standardizations work without Norway participating (Dagens medisin)

Q&A

  • Q: Intention of SFM is to hold eResept information and also PLL including medical adverse effect and interactions. Is it possible to do a perfect mapping to FHIR, it is not greenfield.
  • A: We try to adapt FHIR to the existing information models, we might need to develop map differently or we get locked in today’s information structure.

  • Comment: How to move towards the international standards.

  • Q: Mappings directly to standard FHIR medication statement - might be lossy. Would it solve some problems with interoperability and might solve implementation issues.