The document summarizes a FHIR x Nuts hackathon that took place from April 21-25, 2023. The hackathon involved 9 organizations, 6 EHR vendors, and 2 standards organizations. They demonstrated and tested the scalable secure FHIR stack for use cases like medical referrals and multidisciplinary team consultations. The stack provides security, scalability, and is infrastructure independent. Next steps include further implementing the stack for other standards and use cases.
VIP Call Girls Sector 67 Gurgaon Just Call Me 9711199012
FHIR x Nuts Hackathon Showcases Secure Data Exchange
1. FHIR x Nuts hackathon
End presentation
HL7 Netherlands WGM
21st of April 2023
2. Today
● Welcome and introduction
● Healthcare professional perspective
● General info hackathon
● BgZ x Nuts testing environment demo
● BgZ x Nuts use case & demo
● Conclusions
Second half: in depth
● Scalable Secure FHIR stack
● Technical details & Technical AMA
● Detailed next steps
3. Welcome by HL7-NL: Rob Mulders
FHIR in a nutshell
● Fast Healthcare Interoperable Resources
● HL7 international
● Free and open healthcare data API
● With modern (web) standards
● JSON/XML, HTTP, REST
● Familiar to new generation of developers
● Easy to implement the basics
● Dutch API strategy
● “FHIR-Besluit” of Dutch Ministry of Health
4. Welcome by : Marlene Gigase
The Nuts community consists of an increasing number of parties that believe it is
important to achieve fast, scalable, cheap, safe and privacy-friendly data
exchange in healthcare.
The parties in the Nuts community facilitate each other and work together pre-
competitively to realize data exchange based on (inter)national open standards.
5. Community
Nuts Community develops a layer of trust
on top of the Internet,
deployable for many applications
not limited to the healthcare domain
11. Transforming from curing disease to fostering
health as the starting point of the system
Essential to focus on:
(1) prevention and healthpromotion,
(2) collaboration, coördination and direction
(3) innovation and pleasure in work for
healthprofessionals
Supported by open standards
12.
13. Perspective from the healthcare professional:
David Smitz (dentist)
Communication is 70 % of the care we deliver. Shortage of healthcare providers and staff.
Today (referral flow)
- 50 procent of time lost in security and bad
communication
- Referral via Secure mail
- Manual document transfer
- Phone communication for confirmation
Tomorrow (after the Hackathon)
- Secured, frictionless and seamless
communication with trusted partners
- Futureproof adaptable system
- Hacking proof
14. General info hackathon
- 5 days
- 9 organizations
- 6 ehr vendor/healthcare organizations
- 1 test environment vendor organization
- 2 supporting standards organizations
- an actual international event
- Hvala vam! 🇸🇮
- Hotel de Witte Bergen in Hilversum & Live broadcast April 21, 3:30 p.m. via
Nuts Community channel
23. 🏥
ZBC
1
1. Patient is in treatment in a private clinic (ZBC)
with EHR Medicore by Tenzinger
24. 🏥
ZBC
1
2. Patient is referred from ZBC
to dentist
- Dentist uses PMS add-on by Kiesz
- Referall from Tenzinger EHR to Kiesz EHR
- Workflow Task according to TA NP
- Notification mechanism according to TA NP
- Dentist views/imports referral data (BgZ) as registered
by ZBC
🏥
Dentist
referral
25. 🏥
ZBC
1
3. Patient collects referral
data (BgZ) from dentist
- Patient uses his PHR by Drimpy (PGO)
- Flow according to MedMij agreement set
🏥
Dentist
👨
📱
collect
referral data
3
26. 🏥
ZBC
1
4. Intake of patient at dentist
- Patient informs dentists that there are more
useful data holders (like GP).
- Patient registers consent for GP to share
health data with dentist, in his PHR (PGO)
from Drimpy.
- This step can be used at any given moment if
wanted/needed
🏥
Dentist
👨
📱
3
register consent
extra data
holders
4
27. 🏥
ZBC
1
5. Patient is referred to
general hospital
- General hospital uses EHR by Nexus
- Physician of general hospital views/imports
health data as registered by dentist
🏥
Dentist
👨
📱
3
4
🏥
General
hospital
referral
5
28. 5. Patient is referred to general hospital
Video: incoming referral 0m00s - 01m00s
https://drive.google.com/file/d/1Q8XRJXpaaT7HFISJoLmASIAQ4LX0fY0V/view?u
sp=share_link
29. 🧑⚕️
🏥
ZBC
1
6. Physician of general hospital places patient
on MDT-consultation
- MDT-platform Vitaly by Parsek
- MDT consisting of physicians of 3
hospitals and 1 dentists views
- health data as registered by
general hospital
- pdf/a as registered by
general hospital
- dicom imaging data as
registered by dentist
🏥
Dentist
👨
📱
3
4
🏥
General
hospital
5
🧑
🏽⚕️
👨
🏿⚕️
👩
🏼
Transmural MDT
place on
MDT
6
30. 6. Physician of general hospital places patient on MDT-
consultation
Video: 1m00s - 02m52s
https://drive.google.com/file/d/1Q8XRJXpaaT7HFISJoLmASIAQ4LX0fY0V/view?u
sp=share_link
31. 🧑⚕️
🏥
ZBC
1
7. Referral to university hospital (UMC)
- Physician from general hospital
uses Parsek MDT-app to refer
patient to university hospital
(UMC)
- University hospital (UMC) uses
Firely-server
- Physician of UMC views/imports
health data (BgZ) as concluded by
MDT and registered by general
hospital
🏥
Dentist
👨
📱
3
4
🏥
General
hospital
5
🧑
🏽⚕️
👨
🏿⚕️
👩
🏼
Transmural MDT
6
🏥
UMC
referral
7
7
32. 7. Physician of general hospital places patient on MDT-
consultation
● Video 2m52s - 06m51s:
https://drive.google.com/file/d/1Q8XRJXpaaT7HFISJoLmASIAQ4LX0fY0V/vie
w?usp=share_link
33. 🧑⚕️
🏥
ZBC
1
8. Patient undergoes surgical procedure and is discharged,
Physician of UMC gives feedback to MDT after surgery
- Physician from UMC put patient
on MDT
- University hospital (UMC) uses
Firely-server
- MDT uses Parsek
🏥
Dentist
👨
📱
3
4
🏥
General
hospital
5
🧑
🏽⚕️
👨
🏿⚕️
👩
🏼
Transmural MDT
6
🏥
UMC
7
7
8
8
34. 8. Patient undergoes surgical procedure and is discharged, Physician of
UMC gives feedback to MDT after surgery
● Video 06m51s-07m27s:
https://drive.google.com/file/d/1Q8XRJXpaaT7HFISJoLmASIAQ4LX0fY0V/vie
w?usp=share_link
36. Deliverables of this hackathon (1)
1. the Healthcare professional & patient :
a. real-time availability of data in structured way
b. no need for overtyping
c. safe & easy to scale & highly flexible : future-oriented
2. the Payer :
a. can expect much less costs for infrastructure because Nuts-node is Open Source and under the
auspices of the vendor, and the Internet is used as the infrastructure & highly scalable
3. the Ministry :
a. important step in implementing the national Action plan Healthcare-ICT -market
b. example how it successful can work using open standards and community based development
37. Deliverables of this hackathon (2)
1. Illustrated the power of the Scalable Secure FHIR stack* for use cases:
a. Medical care referral (BgZ-referral)
b. MDT consultation (MDO)
2. Tested and created specifications for the scalable implementation of the
Twiin Technical Agreement Notified Pull (TA NP)
3. Enthused new national and international vendors for the Scalable Secure
FHIR stack
4. Prepared for the LSP x Nuts hackathon in May 2023
5. We had a lot of fun!
* Learn more about the Scalable Secure FHIR stack in the next slides!
38. Conclusions
This week we used the Scalable Secure FHIR stack
to build a scalable implementation of the secure exchange of FHIR-data:
The Scalable Secure FHIR stack:
- is already being implemented for birthcare, long term care and
medication data exchange
- works for viewing home care data by GP’s
- works for two extra use cases after this hackathon
- medical care referral (BgZ-referral)
- MDT consultation (MDO)
- is infrastructure independent
* Except MedMij use cases
DID
VC
TLS
openid4vc
FHIR data
FHIR API
Sum of national and European
regulations and visions
Let’s make the Scalable Secure FHIR stack the de
facto standard for all FHIR-data exchanges*
39. Scalable Secure DICOM stack
The parts of the stack that provide scalability and
security are data-agnostic!
DID
VC
TLS
openid4vc
DICOM
Let’s make the Scalable Secure DICOM stack the de
facto standard for all DICOM-data exchanges!
40. Scalable Secure OpenEHR stack
The parts of the stack that provide scalability and
security are data-agnostic!
DID
VC
TLS
openid4vc
OpenEHR
Let’s make the Scalable Secure OpenEHR stack the
de facto standard for all OpenEHR-data exchanges!
41. Scalable Secure RDF stack
The parts of the stack that provide scalability and
security are data-agnostic!
DID
VC
TLS
openid4vc
RDF
Let’s make the Scalable Secure RDF stack the de
facto standard for all RDF exchanges!
42. Scalable Secure OMOP stack
The parts of the stack that provide scalability and
security are data-agnostic!
DID
VC
TLS
openid4vc
OMOP
Let’s make the Scalable Secure OMOP stack the de
facto standard for all OMOP exchanges!
43. Scalable Secure <<your favorite data standard>> stack
The parts of the stack that provide scalability and
security are data-agnostic!
DID
VC
TLS
openid4vc
<<your favorite
data standard>>
Let’s make the Scalable Secure <<your favorite data
standard>> stack the de facto standard for all
<<your favorite data standard>> exchanges!
47. National and European regulations and visions converge
towards 1 technical interoperability stack of standards:
data
- FHIR as mandatory data standard for all health
data exchanges in the Netherlands (“FHIR besluit”,
MinVWS dd. 28th March 2023)
FHIR data
FHIR API
48. National and European regulations and visions converge
towards 1 technical interoperability stack of standards:
trust
- eIDAS2’s ARF as mandatory architecture
framework for identification & authentication in
Europe
- “Twiin x Nuts” as a basis for linking health data
infrastructures (“Landelijk dekkend netwerk van infrastructuren”,
MinVWS dd. 13th of April 2023)
DID
openid4vc
VC
DID
VC
TLS
49. The Scalable Secure FHIR Stack (SSF)
DID
VC
TLS
openid4vc
DID
VC
TLS
OAuth
This week’s menu!
FHIR data
FHIR API
FHIR data
FHIR API
Sum of national and European
regulations and visions
50. The Scalable Secure FHIR Stack (SSF)
DID
VC
TLS
openid4vc
DID
VC
TLS
OAuth
This week’s menu!
v5.1
v5.x
(expected
end 2023)
FHIR data
FHIR API
FHIR data
FHIR API
Sum of national and European
regulations and visions
51. The Scalable Secure FHIR Stack (SSF) is already being
implemented at large scale
- Birthcare: implementation running for
80% of hospitals, birthcare ultrasound centers, midwives
- Long term care: implementation running for
~100 of elderly care, disabled care organizations and hospitals
- Medication: implementation running in two regions including
EHR market leaders for GP’s and pharmacists
- Hospital/ clinic: implementation running in one region including
FHIR market leader for academic hospitals
52. The Scalable Secure FHIR Stack (SSF) is already being
implemented at large scale
- Birthcare: implementation running for
80% of hospitals, birthcare ultrasound centers, midwives
- Long term care: implementation running for
~100 of elderly care, disabled care organizations and hospitals
- Medication: implementation running in two regions including
EHR market leaders for GP’s and pharmacists
- Hospital/ clinic: implementation running in one region including
FHIR market leader for academic hospitals
network care
network care
patient transfer
patient referral
53. The Scalable Secure
FHIR stack (SSF stack)
is infrastructure-
independent In the LSP x Nuts hackathon the
SSF stack is being implemented
in the LSP-infrastructure
55. Next steps
1. Keep on building
2. Keep on promoting the use of international open standards for both data and trust
3. Stop thinking about how to create scalable secure FHIR healthcare exchanges: align with national and European regulations
and visions and use the Scalable Secure FHIR stack
4. Collaborate with partners to further enhance the specifications of BgZ x Nuts
5. Collaborate with partners to build/enhance more use cases
using the Scalabe Secure FHIR stack:
a. Secondary use (Health-RI)
b. Regional Viewer (Cumuluz)
c. CareTeam (share information about the composition of individual health networks, IKNL & CareCodex)
d. Questionnaires (share questionnaires between organizations and between organizations and citizens, IKNL & CareCodex)
e. Medication (view an integrated actual medication overview and update when necessary, MO-programme)
f. Imaging (DICOM+FHIR, NVVR)
g. Home care (GP can read home care records, Actiz)
h. Dental Care (health data exchange for dentists, KNMT)
i. Paramedic Care (health data exchange for physiotherapists and other paramedics, PPN)
j. Mental Care (De Nederlande GGZ)
k. General Practitioner (NHG, LHV)
l. or come up with your own use case!
56. Are you ready to create interoperability?
If you represent one of the highlighted organizations
or your name is Ernst Kuipers
or you just want to actively contribute to interoperability
please contact: info@nuts.nl
60. 1. Patient is in treatment in a private clinic (ZBC) with EHR Medicore by Tenzinger
2. Patient is referred from ZBC to dentist. Dentist uses PMS add-on by Kiesz
a. Dentist views/imports referral data (BgZ) as registered by ZBC
3. Patient collects referral data (BgZ) from dentist using his PHR by Drimpy (PGO)
4. Intake of patient at dentist: Patient informs dentists that there are more useful data holders (like GP). Patient
registers consent for GP to share health data with dentist in his PHR (PGO) from Drimpy.*
a. Option : Dentist views health data at GP
5. Patient is referred to general hospital with EHR by Nexus
a. Physician of general hospital views/imports health data as registered by dentist
6. Physician of general hospital places patient on MDT-consultation (transmuraal MDO) : MDT-platform Vitaly by
Parsek
a. MDT consisting of physicians of 3 hospitals and 1 dentists views
i. health data as registered by general hospital
ii. pdf/a as registered by general hospital
iii. dicom imaging data as registered by dentist
7. Physician from general hospital uses Parsek MDT-app to refer patient to university hospital (UMC) that uses Firely-
server
a. Physician of UMC views/imports health data (BgZ) as concluded by MDT and registered by general hospital
8. Patient undergoes surgical procedure and is discharged
* This step can be used at any given moment if wanted/needed
62. 1. Patiënt is onder behandeling in een Zelfstandig Behandelcentrum (ZBC) met XIS: het EPD Medicore van
Tenzinger
2. Patiënt wordt doorverwezen van ZBC naar tandarts met XIS : open source XIS OpenDental van Kiesz
a. Tandarts raadpleegt BgZ-gegevens zoals vastgelegd door ZBC
3. Patiënt haalt bij de tandarts de verwijsgegevens (Bgz) op vanuit zijn PGO van Drimpy
4. Intake van patiënt bij tandarts: Patiënt laat weten dat er meerdere relevante bronhouders (huisarts) zijn, en geeft in
PGO toestemming aan deze bronhouders (huisarts) om hun data te delen met tandarts
a. Optie : Tandarts raadpleegt gegevens bij n bronhouders/huisarts
5. Patiënt wordt doorverwezen naar algemeen ziekenhuis met XIS van Nexus
a. Arts algemeen ziekenhuis raadpleegt gegevens bij tandarts
6. Arts algemeen ziekenhuis plaatst patiënt op transmuraal MDO : MDO-platform Vitaly van Parsek
a. MDO team met artsen van 3 ziekenhuizen en tandarts raadplegen
i. BgZ-gegevens
ii. bijbehorend beeld
iii. pdf/a
7. Patiënt wordt doorverwezen naar academisch ziekenhuis met FHIR-applicatie van Firely
a. Arts academisch ziekenhuis raadpleegt BgZ-gegevens
8. Patiënt wordt geopereerd en ontslagen.