Møte 24 i FHIR fagforum

Dato: 2024-06-12
Klokkeslett: 1300-1500
42 personer innom møtet virtuelt

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

Agenda: Nordic base profiling

Info from HL7 Norway and welcome to fagforum, Thomas og Øyvind 10 min
Finnish base profiles, Mikael Rinnetmäki (HL7 Finland) 25 min
Danish base profiles, Michael Johansen (MedCom) 25 min
Swedish base profiles, Daniel Karlsson (E-hälsomyndigheten) 25 min
Norwegian base profiles, Thomas T Rosenlund (Helsedirektoratet) 10 min
New base profiles for AuditEvent, Trond Elde (DIPS AS), 15 min
Discussion 10 min

Presentasjoner

HL7 Norge

1 million kroner til HL7 Norway.

Finnish base profiling, Mikael Rinnetmaki

Finland should start base profiling because all the other Nordic countries are doing it.
SMART app launch framework
27 different profiles, 11 ext, 1 codesystem
Current work in Finland
- Appointment
- Terminology server
Kanta, Finnish PHR
- API for patient facing apps
- Prescription data
- Appointments data
Harmonization of the different nordic profiles
- Harmonized view of the resource types
- QA report for the combined profiles in each country
- Tool based approach on validating example resources on each

Questions

Smart app profiling, why do you profile it in Finland, any missing parts?
- Quite large spec international, documents the minimal effort needed to start building SMART apps
Security framework the same across nations
- It’s described elsewhere
- European legislation EIDAS for example

Danish core profiles, Michael Johansen

HL7 Denmark, Michael Johansen
How to profile in HL7 Denmark
Status on profiling, what resources
Recommendations, procurement and using versions of FHIR
Organization of work in HL7 Denmark
DK core SIG
- Actual profiling
Structured data capture
FHIR services, IPA and SMART on FHIR
How we work
- Medcom is steward
Core vs Base profiles
- Denmark core profiles are core on the national level
- Base profiles are maintained within the projects
  - Medcom use base profiles for all message types
- In Denmark Core profile is less restricted than a base profile
DK-core profiles version 3.2
- 7 resources
- Basic observation (vital signs)
  - LOINC codes in vital signs, are these the vital signs we use in the hospitals in Denmark
  - Choose basic observation instead
  - Share the discussion and rationale for this choice
- Need for who produced a specific lab report (ext)
Code systems and valuesets
- Expansion of the international valuesets
DK-core supports more version
Current work on:
- ServiceRequest
- PractionerRole
Project showcase
- 9 projects
- only 3 use DK-core
  - Medcom messaging - May 26th in production (west half of Denmark)
  - Telemedicine infrastructure (FUT)
  - Municipality Gateway (KL gateway)
  - Some projects starte before dk-core
Procurement recommendations
- HL7 FHiR is under ongoing development
- Documented guideance on procurement
Future work, maintenance
- Encounter
- DiagnosticReport
- Consent

Questions to Michael

Q: Michael: can you talk about your process for creating a new SIG? Where does the initiative come from, how many participants or interest do you require before officially starting a new SIG? A: HL7 Denmark discussion concluded that sub-groups was needed. SIGS do the work but have no authority.

Q: The base/core profile choice are quite different from Norway Q: Vital signs recommendation, problems in Norway

Swedish base profiles, Daniel Karlsson

Swedish base profiles 1.0.0
- March 2023
- Org, patient, practitioner, pract role
- extensions
Base profile work group is started up again
Current task forces
- Organization
- Medication
- Alert info
- Translation
- CodeSystems
Coordination meetings
- monthly open to everyone
Task forces
- Agile work resolve a set of issues
Standard extension to base profiles, but they could not be made mandatory
Alert information
Translation - building Swedish language pack
Profiling harmonization
- EHDS and Xt-EHR
- Investigation into use of HL7 Europe and IPS profiles
  - IPS (currently) somewhat restricted to cross border use-cases

Norwegian base profiles, Thomas T Rosenlund

Strategy
Processes
Principles
Best practices

New base profiles for AuditEvent, Trond Elde

Logging
Standardized way for logs from different organizations to be exposed and standardized across organizations.
Norwegian Trust framework (Tillitsrammeverk) Helsepersonellets attest
Who is accessing, Why access the data and What patient

Questions for Trond

Q: Question about audit event: The EHDS Regulation will bring new requirements on audit logging. Is this known to the project, and have any European or international formats been analyzed for this purpose?

Q: I would have the same question regarding the BALP by IHE specifically. https://profiles.ihe.net/ITI/BALP/ Basic Audit Log Patterns (BALP) - Basic Audit Log Patterns (BALP) v1.1.3

Questions

Q: What is the definition for Base Profile? Or Core Profil? Q: Kristine Aasen partly stole my thunder Since lately I have been seeing mentions (linked to few more ambitious new/updated national initiatives) about “classifying” official profiles as Base vs. Baseline vs. Core and how these relate to each other (and to more use-case-centric FHIR development). Thoughts anyone ? Is there some use, relevance etc. in having these as spelled-out “levels of conformance” in (national) profile hierarchy ? A:

Kari Heinonen (Ekstern) I might be totally wrong, sorry, but I think recent FI eIDAS webinar mentioned something about required EU-citizen identifier (of course healthcare might be a different case) having actually encountered “resistance” at EU-level. The compromise calling for some form of “patient matching” based on name, address, birthdate etc. Which does not make any sense at all to me but hey, it’s EU legislation

This is where legislation in different countries differ a lot, regarding identification of a Person/Patient.
- And it’s not just how patient is identified nationally but also maybe if this method is allowed to be used cross-border even if it could (technically) be …

Mikael Rinnetmäki (Ekstern)
Regarding financial resources, in my opinion all Nordic HL7 affiliates could adopt the financial model that HL7 Finland uses, with both membership fees and project fees. HL7 Finland’s project fee scales with the size of the organization (specified by amount of people involved in healthcare IT integrations). That gives the affiliate some resources that can be used to fund a FHIR ambassador and to dedicate resources to profiling work, etc.

[14:03] Mikael Rinnetmäki (Ekstern) Kristine Aasen (gjest) (Unverified) What is the definition for Base Profile? Or Core Profil?

Sheridan Cook has been leading a great initiative to get these better described within HL7 International. See, for instance, workshop material from FHIR DevDays 2023: https://www.devdays.com/wp-content/uploads/2023/08/230609_SheridanCookIsaacVetter_Navigating-National-and-International-Expectations-Roundtable-For-A-Better-Way-Forward-v2.pdf
[14:04] Mikael Rinnetmäki (Ekstern) Danielle captures my understanding of the current consensus in her message in Zulip: https://chat.fhir.org/#narrow/stream/392078-National-IGuides/topic/National.20Cores.20.26.20Extension.20Registries/near/443387995

“In AUS we have AU Base & AU Core. The Base is definitional and is used to define AU realm concepts. It adds to what is available from the FHIR standard including extensions and terminology and data type profiles like our national identifier. In some ways it acts like an AU extension pack. AU Core defines a set of conformance requirements that enforce a set of ‘minimum requirements’ on the Australian localised concepts from AU Base through cardinality constraints, Must Support & Obligation, required/extensible binding strengths, and capability statements.” [14:05] Mikael Rinnetmäki (Ekstern) In short: base is more informational, core specifies more strict requirements. like 1 [14:09] Thomas Tveit Rosenlund Absolutely agree on this definition. Itwe could rename our Norwegian domain profiles to Norwegian core?

[14:09] Kari Heinonen (Ekstern) For placement of “baseline” to this see: https://build.fhir.org/ig/HL7-Canada/ca-baseline/#base-vs-baseline-vs-core Home - Canadian Baseline v1.1.0 [14:11] Mattias Colliander (Ekstern) All developers of course like to stack abstractions on abstractions, but is it clear why separating base and core is a win? I get the explanations, but I would like to see example (or real) scenarios where the split is explicitly needed, as a way to make the “why” clearer for the non-FHIR-geeks.

In Finland, I’d say a core would refer to requirements related to Kanta, the national healthcare IT infrastructure. They have some requirements for data elements that would not be necessary or might not even make any sense in other contexts of data sharing. On the other hand, the Kanta specifications explicitly prohibit sending some elements that are valuable or required in other use cases.

In this case base profiles would apply to all use cases, core profiles to the ones related to the national infrastructure.

Another aspect is the mandate for the body specifying the profiles. In Finland, the group specifying the base profiles did not feel they had any mandate to require any aspects of FHIR use, the main goal of the base profiles is to inform people on how things have already been implemented and which ways have been proven to work. The profiles encourage interoperability, but do not enforce it.

[14:19] Kristine Aasen (gjest) Since I work on master data on medicinal products I thaught Base Profile was another name for “master data profiles” (…Definition Profiles) [14:21] Trond Elde (Ekstern) I don’t see presentation? Only me? [14:24] Andy Harrison (Ekstern) Have all countries now moved primarily to FSH and IGPublisher on GitHub? [14:24] Kari Heinonen (Ekstern) Mikael Rinnetmäki (External) Another aspect is the mandate for the body specifying the profiles. In Finland, the group specifying the base profiles did not feel they had any mandate to require any aspects of FHIR use. The main goal of the base profiles is to inform people on how things have already been implemented and which w…

On the other hand I don’t think similar “clean split of mandate” as in Finland is common ? Or even used somewhere else at all ?

[14:26] Michael Johansen (Ekstern) FSH and IGPublisher on GitHub is used in Denmark [14:27] Espen Stranger Seland (Ekstern) And if you don’t like our principles, we have others laugh 2 heart 1 like 1 [14:27] Mikael Rinnetmäki (Ekstern) Andy Harrison (External) Have all countries now moved primarily to FSH and IGPublisher on GitHub?

I believe some are still mainly using Forge and Simplifier.

Also in Finland Kela author their specifications with Forge and publishes them in Simplifier.

HL7 Finland has transitioned to using FSH and GitHub. [14:29] Kristine Aasen (gjest) What are the difference between Substance and SubstanseDefintion? [14:29] Daniel Karlsson (Ikke bekreftet) HL7 Sweden is using the IG publisher tool set, but my agency is using Simplifier for publication and a mix of Forge and IG Publisher [14:30] Kristine Aasen (gjest) Daniel Karlsson (Ikke bekreftet) HL7 Sweden is using the IG publisher tool set, but my agency is using Simplifier for publication and a mix of Forge and IG Publisher

Which benefits do you see by using Simplifier?

[14:31] Øyvind Aassve (Ekstern) Jeg må videre til et annet møte. Takk for veldig gode presentasjoner og diskusjoner! [14:32] Kristine Aasen (gjest) How should a need of a new profile be handeled? [14:32] Daniel Karlsson (Ikke bekreftet) Kristine Aasen (Inte verifierad) Which benefits do you see by using Simplifier?

Above my paygrade…

laugh 1 [14:32] Kari Heinonen (Ekstern)

Kristine Aasen What are the difference between Substance and SubstanseDefintion? Please create account in zulip (https://chat.fhir.org) - there’s a lot of good material about FHIR Medication Knowledge Module (among others) [14:33] Daniel Karlsson (Ikke bekreftet) …but mainly that we use one tool for publishing, and we started with Simplifier back in 201x like 1 [14:34] Mikael Rinnetmäki (Ekstern) Kristine Aasen (gjest) (Unverified) How should a need of a new profile be handeled? Thomas Tveit Rosenlund this might have been to you?

[14:27] Espen Stranger Seland (Ekstern) And if you don’t like our principles, we have others laugh 2 heart 1 like 1 [14:27] Mikael Rinnetmäki (Ekstern) Andy Harrison (External) Have all countries now moved primarily to FSH and IGPublisher on GitHub?

I believe some are still mainly using Forge and Simplifier.

Also in Finland Kela author their specifications with Forge and publishes them in Simplifier.

Which benefits do you see by using Simplifier?

Above my paygrade…

laugh 1 [14:32] Kari Heinonen (Ekstern)

like 1 [14:37] Thomas Tveit Rosenlund If it is a proposal for a national base or domain profile you can contact HL7 Norway, usually Øyvind Aassve the leader of the Nowegian Technical Steering committee. [14:38] Thomas Tveit Rosenlund Less detailed profiling needs could also be proposed by issues on Github (no-domain or basisprofiler) or you can have an open disussion on the Norwegian FHIR chat (chat.fhir.org) [14:41] Ingvar Sørlien Question about audit event: The EHDS Regulation will bring new requirements on audit logging. Is this known to the project, and have any European or international formats been analyzed for this purpose? like 1 [14:42] Mikael Rinnetmäki (Ekstern) I would have the same question regarding the BALP by IHE specifically. https://profiles.ihe.net/ITI/BALP/ like 2 Basic Audit Log Patterns (BALP) - Basic Audit Log Patterns (BALP) v1.1.3 [14:42] Kristine Aasen (gjest) Thomas Tveit Rosenlund If it is a proposal for a national base or domain profile you can contact HL7 Norway, usually Øyvind Aassve the leader of the Nowegian Technical Steering committee.

Meanwhile we will use the profile Basic, but we think we need a specific profile for the Grouping of Administrable Products (administrerbare legemidler)by the PhPID. It is useful to have “generic profiles” like Task and Basic, but they are not optimal for all kind of entities. [14:43] Daniel Karlsson (Ikke bekreftet) About the vital signs international profiles, see https://build.fhir.org/observation-vitalsigns.html#10.1.17.0.0.1 The LOINC codes are not really used as “ordinary” LOINC codes, but as “magic values” for interoperability. It is expected that a more detailed LOINC (or even better a SNOMED) code would be added (if needed). like 2 [14:43] Kristine Aasen (gjest) Thomas Tveit Rosenlund If it is a proposal for a national base or domain profile you can contact HL7 Norway, usually Øyvind Aassve the leader of the Nowegian Technical Steering committee.

And this should be an international profile.

[14:44] Kari Heinonen (Ekstern)

Kristine Aasen Meanwhile we will use the profile Basic, but we think we need a specific profile for the Grouping of Administrable Products (administrerbare legemidler)by the PhPID. It is useful to have “generic profiles” like Task and Basic, but they are not optimal for all kind of entities. I assume you are aware of some “issues” about PhPID ? More than happy to share what little I know of FHIR Medication stuff and IDMP in zulip [14:45] Thomas Tveit Rosenlund Daniel Karlsson (Ikke bekreftet) About the vital signs international profiles, see https://build.fhir.org/observation-vitalsigns.html#10.1.17.0.0.1 The LOINC codes are not really used as “ordinary” LOINC codes, but as “magic values” for interoperability. It is expected that a more detailed LOINC (or even better a SNOMED) code woul…

And what SNOMED concept makes sense in Norway have been debated for so long unfortunately.

[14:45] Kristine Aasen (gjest) I also see that we will need Norwegian profiles for pricing and reimbursment on medicinal products. [14:46] Daniel Karlsson (Ikke bekreftet) SNOMED on FHIR did work on this (ages ago), and is expected to be one among <75367002 |Blood pressure (observable entity)| [14:46] Ingvar Sørlien Mikael Rinnetmäki (Ekstern) I would have the same question regarding the BALP by IHE specifically. https://profiles.ihe.net/ITI/BALP/ Good question. Do I understand correctly that BALP is mainly defining Volume 3, and complementary to RESTfull ATNA which is specific to Volume 2?

[14:49] Thomas Tveit Rosenlund Daniel Karlsson (Ikke bekreftet) SNOMED on FHIR did work on this (ages ago), and is expected to be one among «75367002 |Blood pressure (observable entity)|

Absolutely, the Norwegian and Danish SNOMED experts was not impressed by the mapping work from that group, and also there was development of valuesets for metadata about the observations…

[14:49] Kristine Aasen (gjest) Kari Heinonen (Ekstern) I assume you are aware of some “issues” about PhPID ?

We see some issues about global PhPID, but we in NoMA thogether with the regional health autorities are planning for a Norwegian PhPID.

[14:51] Daniel Karlsson (Ikke bekreftet) Thomas Tveit Rosenlund (Inte verifierad) Absolutely, the Norwegian and Danish SNOMED experts was not impressed by the mapping work from that group, and also there was development of valuesets for metadata about the observations…

Hmm, why didn’t they raise the issues they had then….

[14:56] Kari Heinonen (Ekstern) Kristine Aasen We see some issues about global PhPID, but we in NoMA thogether with the regional health autorities are planning for a Norwegian PhPID.

Nice - actually I have been wondering a good while why no national versions have been piloted. Since the algorithmic workflow of PhPID just requires some common terminology to exist. And the hash-keys can easily be kept separate (by e.g. .system) in the case we ever get the WHO-UMC ones. It won’t be global but nationally it works just the same.

[14:56] Espen Stranger Seland (Ekstern) Also the ATNA Audit Trail (for IHE, also FHIR I guess) like 2 [14:57] Kari Heinonen (Ekstern) For Good Holiday Fun I highly recommend looking into “Australian Core Data for Interoperability” work (half a year of meetings and webinars leading to official release 1 few days ago) about Must Supports and Obligations like 1 [14:58] Reza Baharmand (Ekstern) Everyone, thank you all