Møte 19 i FHIR fagforum

  • Dato: 2023-08-30
  • Klokkeslett: 1300-1500
  • 60 personer innom møtet

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. FHIR R5, Grahame Grieve, Health Intersections/FHIR product director (90 min)
  3. Q&A

Presentasjoner

FHIR R4, R5 and R6

  • There is no official position about wether you should adopt it or not.
  • What is R5, dealing with versions of FHIR

Overview of changes in R5

  • Complete rework of Subsciption framework
  • Rework the type framework
  • Move extension to a new package
  • RESTful API an Search clarifications
  • New renamed and deleted resources
  • Moved many code systems and valuesets to terminology.hl7.org
  • Added operations for large resources
  • Added the ability to define additional bindings on elements

Subscription framework rework

  • Publish subscribe pattern in FHIR like websub, pub/sub
  • Reusable topics across systems
    • Deleted resources are handled
  • Servers choose what to support
  • Optimized implementations
  • Server driven workflows
  • The changes are back-ported to R4 (minus topics)
    • A separate R4 IG for implementing R5 subscriptions in R4 implementations

Rework the type framework

  • Formal definitions for base types

More extensions to a new package

  • Frequency of updates to Extensions was tstarting to become a real problem
  • Stil integrated into the nav structure of the standard
  • Will be published more often
    • 3 times a year
  • Also includes the translations between R4/R5 - so we can fix them

RESTful API and Search clarification

  • RESTFUL api is normative, so there is no breaking changes
  • Adding clarfification language
  • Making conformance expectations clearer
  • Please review the changes

Continued to develop base resources

  • New renamed and deleted resources
  • Patient summary is getting pretty stable
  • Genomics and so forth

Code systems and value set so terminology.hl7.org

  • Validator to validate Valuesets not from the FHIR
  • Did not move vs/cs used in requred bindings
  • The packages hl7.terminology.r[x] is always in scope
  • More reuse in v2/CDA etc

Operations for Large resources

  • Group an list can get very big
  • Resources >1MB
  • Large resources are engineering challenges
    • Memory bandwith etc.
  • Large resources affect transaction delay’s
  • Define operations for
    • is entry in set
    • add entry to set
    • remove entry from set
  • Can be implemented on R4 servers

Additional bindings

  • Coded elements have one binding
  • Sometimes, one binding is not enough
    • Required bindings for restrited use contexts
    • Document current binding/ components of value sets
    • Provide useful UI subsets
    • Reduce the need for slicing (hard work for everyone)
  • R5 allows you to add additional bindings
  • Backported to R4 using extensions
  • IPS uses this backport

Changes

  • Most changes are in response to implementation feedback
  • Consent have som really big changes
  • Some of these changes will hit some implementers hard
    • You should read R5 before implementing R4
    • The R5 is the answer from the community about how to implement things

Converting between versions

The R5 pages have compare to old version, and also a diff page

  • You can see the differences between versions
  • R4/R5 Transforms using FHIR mapping language
    • Tested using examples for resources in the FHIR spec
    • To R4 and R5 and back
  • The transforms are not used much

Multiple release of FHIR

  • Versioning is expensive

What version is this resource?

  • Not stated in every resource
  • Version is a property of the context, not the data in the resource
  • Resources might be correct in multibple versions
  • The capabilitystatement of the server states the version that are supported by the server
    • CapabilityStatement can state a different FHIr version different from the FHIR version of the Capabilitystatement
  • Explicit in profiles and implementation Guides
    • These may be properties fo resources or properties of the context
    • Resources can conform to many profiles
    • A resource can state conformance to a profile (Resource.meta.profile element)
  • Version numbering semantic versioning
    • Careful definition of minor change and patch definitions
    • R4B work lead to not using minor for ballot version
    • Use labels for your own versioning
  • You can verion every resource in a package independently but that is not encourage’d
    • IG-publisher can impose common version on all resources
  • Versioning extensions
    • References in extension.url are not versioned
    • Breaking changes in extension definitions are not supported
  • Cross-version extensions
    • Adopt element in an earlier version
    • Examples on hl7.org/fhir/versions.html#extensions
  • Basic resource can be used - painful should not be used
  • Cross version extensions
  • Versioning software tools
    • FHIR internal tooling stack is mature
    • Validator does not assume a specific language

Converting between versions

  • Only support fully for conformance resources
  • Internally IG publisher is R5
  • Version independent logic
  • Simples apporach is create multiple end-points
    • problem logical records get multiple url’s
  • Single end-point, multiple versions
    • state the version you want in the request
    • The server have to be able to convert resources between versions
  • Persisting multiple versions
    • Store resources with known
      • Store resources as you get them (and convert on the fly if needed)
      • Store resorurces in your preferred version (and convert if needed)
      • Extract information into a store (relational database)
      • Or do all three tings at once
  • Documentation strategy
    • Simple different documentation for different versions
    • Complex different versions in the same documentation
  • Some IG’s have different versions

Questions

  • Still debating weather we should make R5 version of Norwegian base profiles
    • Won’t do it before we have actual demand for an R5 version from implementers
    • Planning to release two different IG’s

  • Answer: two different versions in one IG only when there are no breaking changes, difficult to have two different IG’s with unconflicting requriements. You will have two different IG’s that needs maintaining

  • Understandable that HL7 doesn’t come with a general recommendation for or against moving from R4 to R5.
    • Do you see a commitment in the community to make the tooling and related projects work with R5 anyway? For example, will/does the CQL framework have implementation of the R5 resources?
    • Is it likely that cloud providers will support R5 in their managed FHIR solutions? Google, Amazon, Microsoft Azure?These could stop us from moving to R5, even if we wanted. Answer:
    • HL7 tooling will support R5 fully
    • CQL community have no commitment for R5 releases

Should you move to R5?

  • Do you need the new things in R5
    • Have they been or could they be backported
  • How much does it cost
    • how big is your eco-system, whats your change overhead
  • For most existing trading systems, cost/benefit says don’t change
  • But don’t ignore R5: there is a lot fo clarifications and changes

R6

Make patient core (base resources) “Normative”

  • R6 transition should be worthwile

Most are going to hold out of R5 and move to R6 when it is published and stable

  • Normative - forward compatibility
    • bi-directonal interface this is difficult to define and decide
    • Difficult to agree on clean definition
    • A lot of people are treating R4 as normative
  • Normative tasks
    • Market survey to confirm our decisions
  • Change existing processes to secceed in getting normative
  • Improve definitions around breaking changes and make implementers expectations clearer
  • Decide what to be made normative

Supporting implementers

  • Support scaling the ecosystem internationally
    • 88 countries and growing quickly
  • Continue to improve tools that support the eco-system
    • Validator, simplifier, terminology servers, sushi, publising tools
  • 800 IG’s throug publishing infrastructure
  • work with regulators - building relationships and trust

There is no need to move to R5 simply because it is there (but please read it)

  • Will alwasys be torn between versions
  • Move to R5 because your gains outnumbers your cost
    • Need clear justification for moving to R5

Q&A

  • Mikael Rinnetmäki: How about IG authors? Multiple versions or one multi-version IG?
  • Mikael Rinnetmäki: We still don’t have a really good view on how we should best support multiple versions in parallel. Wider adoption of R5 would give us more experience. Right?
  • Mikael Rinnetmäki: (Yes, I understand that even that point might not justify the cost.)
  • Adam Kover: A good excuse that the developer in me likes very much, but probably not enough to justify the cost, as you say
  • Mikael Rinnetmäki: For me as a developer of a trivial app it’s absolutely not a big problem, even financially, to support all versions.
  • Mikael Rinnetmäki: For me as an IG author, the problem seems to be there…
  • Ingvar Sørlien: Do you see a chance that R4 actually will be a “perpetual” version of FHIR with backports? Like DICOM never progresses from 3.0.
    • Absolutely possible, don’t like it, but it’s definitely a possibility
    • R6 should be the perpetual version, and hopefully can work this out with the stakeholders (ONC for example)
  • Adam Kover: Wouldn’t that mean the end of FHIR though? Then in 10 years Standard X comes along and replaces FHIR. So to prevent that it it still important to improve FHIR, even if not all versions are implemented.
    • Started out with a 5 + 5 + 5 year timespan - something better would come along (after 15 years)
    • Compared to REST, API, JSON - FHIR is relatively heavy
    • Far more important than tech is the community - FHIR works because of the large and enthusiastic community
      • FHIR is better because of the community, nothing better on the horizon at the moment
      • This might be a project for the rest of my life, not what I imagined
  • Mikael R: OpenEHR?
    • OpenEHR are figuring out how to coexist, not a replacement for FHIR
  • Øyvind: OpenEHR for internal side of things and FHIR for interoperability
    • FHIR and OpenEHR is Head to head in clinical data repo space
    • OpenEHR more about internal data repo than interoperability
  • Øyvind: FHIR by it’s interop capability taking over more from OpenEHR
    • Open EHR is problem orientation, system function is the main problem
    • FHIR have data transfer as the main problem, Transfer could be from now to later, that is also transfer
    • One valid way to do it is to use OpenEHR to solve problems by system design, talking with OpenEHR about common path and understanding
  • Øyvind: Developing FHIR valueset from working with OpenEHR community
    • The OpenEHR community use FHIR valueset and terminology services
    • OpenEHR should define how to use FHIR for terminology definitions
    • FHIR terminologyservices is the way to do terminology definition