Nordic MyData Infrastructure Pilot for Wallets and AI
Exploring the intersection of International Patient Summary, Artificial Intelligence, and Digital Wallets
Sensotrend participated on the MyData Global pilot involving the Nordic Hubs for the project on Nordic communities and innovation for digital empowerment in the age of AI.
The Nordic Hubs project was launched in 2025 with support from Nordic Culture Point to strengthen collaboration between MyData communities in Denmark, Finland, Sweden, and Norway. Building on the outcomes of the Oslo inception meeting in June 2025, the project seeks to translate shared priorities on data governance, digital literacy, and human-centric use of AI into concrete, cross-border pilot activities.
The three pilots, developing literacy, technical infrastructure, and governance frameworks, were selected to align with project objectives while ensuring mutual reinforcement between literacy, governance, and infrastructure dimensions. Each pilot is designed to be led by one hub, with contributions from all partners, and to generate insights and outputs that will inform policy, public engagement, and European discussions on digital empowerment.
The Infrastructure Pilot for Wallets and AI built on the idea that individuals can and should be seen as the ultimate curators and custodians of their information, including health information.
In all of the Nordic countries, people have for years had access to their electronic health records through patient portals. However, the access has been limited to viewing only. People can view their data on the portal, but are not offered the choice to download their information in structured format or to use apps or artificial intelligence to analyse their data.
This is now changing. In Finland, the centralised health data repository Kanta opened application programming interfaces (APIs) for apps to connect to individuals health data in 2024. The emergence of both general-purpose and health-focused AI tools has increased the demand for structured health data to being available.
Today, most health data is scattered across different healthcare providers in primary and secondary healthcare, occupational healthcare, social care, and furthermore split between public and private providers. Most of the health and wellbeing data produced by individuals themselves live in cloud services of device manufacturers. Currently nobody has access to all of the data, but the individual has the best chance of getting that access. The upcoming regulation for the European Health Data Space (EHDS) in the EU enforces this idea by giving individuals new rights to access their health data.
In the future, rather than each individual having to ask for access to their own health data, healthcare organisations may ask the patient for continuous, real-time access to the health data of the individual. In this scenario, the individual is the source of the data and the curator of master data set, and other parties will have access to the data and may hold their own copies of pieces of the data.
This was the underlying premise of the project.
During the execution of the project, also general purpose AI tools evolved and more wide-spread use of these tools helped generate initial evidence of their usefulness and value. Early signs indicate that conversational artificial intelligence can really help individuals understand their health and specific conditions better.
Healthcare professionals have limited time and resources to care for any individual patient. A conversational AI agent may help the individual understand their condition on their own time and pace. AI can provide valuable information and insights on both common and rare conditions, in a language tailored for each individual. AI can also offer a valuable second opinion.
Yes, these tools may hallucinate, but they can also point to a right direction. Today, it is still important that individuals verify correctness of any insights from other sources.
All of the companies involved were already working on products and services relevant to this use case and are also involved in other projects. The technical development of the products and services is expected to continue in those projects. The companies used this project as an opportunity to step outside the confines of those projects, to implement a concrete use case in the MyData realm, and to collaboratively explore what possibilities artificial intelligence and digital wallets currently offer for person-centric data management, and which bottlenecks currently exist.
Most of the funding for this project was spent on communication and collaboration between the project partners, testing interoperability of the services, and to any adjustments that needed to be made to the products and services.
An International Patient Summary (IPS) document is an electronic health record extract containing essential healthcare information about a subject of care. As specified in the standard ISO 27269, it is designed to support the use case scenario for unplanned, cross-border care but it is not limited to that.
There are two technical alternatives available to implement the ISO 27269 International Patient Summary document, described in the HL7 CDA IPS IG and the HL7 FHIR IPS IG. Basically, these are two equivalent but technically very different implementations of the CEN and ISO IPS standard, using the foundational HL7 CDA and HL7 FHIR standards, respectively. See further information on the IPS at international-patient-summary.net.
This project focused on the HL7 FHIR IPS standard as the output. This project explored ways in which artificial intelligence can be used to consolidate data from various sources, including existing patient summary documents and other raw health data in a structured format, and to help patients compose a single coherent patient summary document curated by the patient. The project also explored ways in which artificial intelligence can be used to translate patient summary documents from one human language into another.
Digital wallets can be used to collect, manage, and share digital credentials: digitally signed, structured documents. A digital wallet can help its user to store and share many kinds of personal information, like permits, licenses, proof of education, and skills etc. Most digital wallets are mobile apps, but a wallet can also be a server-based application with a web front end.
A user of a digital wallet would benefit from an IPS document as a digital credential, since the wallet provides a simple way to store and share the information.
This project explored ways to
transform an IPS document into a digital credential
acquire the credential into a digital wallet
share the credentials from the wallet.
There are various formats, protocols, identification methods, signature algorithms, revocation mechanisms, etc., related to digital credentials and wallets. The interoperability of digital wallets and credential agents (software used to issue and request credentials) requires that the involved parties agree on which standards are used and how. This project proposes a set of standards suited for sharing the IPS documents as digital credentials.
While the target group for the Patient Summary application and the Digital Wallets are essentially all individuals, the target group for the results of this pilot project are technology providers and healthcare institutions interested in learning how artificial intelligence can be used to consolidate health data from various sources and to compose a coherent patient summary documentation, and how digital identity wallets can be used to share the information or to verify the authenticity of a document or a person sharing the document.
The first objective of the project was to demonstrate how artificial intelligence can be used to consolidate health data from various sources and formats into a coherent patient summary document conformant with the international standard.
The second objective was to explore ways in which digital identity wallets can be used to store and to share patient summary documents.
The project started with collecting data from different sources: scraping data from patient portals and utilising structured data in CDA format obtained through an information request.
Those pieces of data were then converted to HL7 FHIR format utilising various AI tools. Furthermore, the process involved inclusion of data from the patient. This is information like the patient story and advance directives, and also descriptive summaries for each of the sections in the summary document, in patient's own voice.
All of the phases where data was reformatted and where AI was used were recorded in provenance information included in the document.
The correctness of the resulting data was verified through multiple methods:
The resulting IPS document and all individual elements were checked by a person involved in creation of the IPS specifications.
The validity of the IPS document was checked with the FHIR validator tools.
Conformance with both the IPS specification and the upcoming European Patient Summary (EPS) specification was verified both at the EHDS Plugathon and at the 2026 May HL7 FHIR Connectathon event.
In addition to the patient summary fully authored by the patient, the same mechanism for crafting the patient summary document was tested with proper HL7 FHIR API access to several electronic health record systems both in the EHDS Plugathon and in the FHIR Connectathon.
Trust is often mentioned in discussions around sharing of health data, especially in scenarios where patients act as sources, curators, or couriers of data. In many cases it is accepted that the patient is the most trustworthy source of data (for instance, regarding experienced symptoms and circumstances, advance directives, and personal goals in life). In some other cases, often when financially incentivised to, a healthcare organisation may not trust data originating from another organisation or a clinician may not trust information recorded by another clinician, even from within the same organisation.
There is a subset of use cases where trust can be increased with digital signatures that verify that a piece of data originates from a certain source and has not been tampered with. The healthcare interoperability community is still coming up with best practices in this area, and no method has yet achieved universal adoption.
One proposed mechanism especially suited for the international patient summary and digital identity wallets is the Selective Disclosure for JWTs (SD-JWT) specification.
The SD-JWT specification allows an individual to get their health information (or a part of it) from a healthcare provider cryptographically signed in a way that allows sharing parts of that data further, so that the integrity of those parts stays guaranteed.
This mechanism suits the scenario where an individual composes their own patient summary document from multiple sources. Each piece of data can preserve the digital signature of the origin.
An open question is whether healthcare providers or any other data sources will adopt the technology and start providing health information to individuals in a digitally signed format. There is also a possibility for a third party to offer this functionality as a service for multiple healthcare providers, so that the providers themselves do not need to invest in the technology.
The project explored the SD-JWT specification and its applicability to the foreseen use case.
Results show that technical implementation of signing a set of data, selecting a subset of that data to be shared further, sharing the subset, extracting the resulting information and verifying the signature can all be implemented in a straightforward way.
Explore the FHIREDACTION demo case and technical playground to see selective disclosure of patient summary sections and elements in action.
A digital wallet certainly is not a place to store all health information, but both a full patient summary and parts of it can be stored to a digital wallet as credentials.
While both the overall technical specifications and early wallet implementations seem mature enough for creating and sharing credentials, there is great uncertainty on what should be specified as a credential. The entire patient summary? The vaccination records section? Each separate vaccination? Each allergy? The set of identified allergies? Furthermore, it is unclear who should be the party responsible for creating these specifications to ensure global interoperability.
The project experimented with credentials and wallets by crafting a technical specification to both the patient summary as a whole and to each of the sections of the summary as separate credentials. We further implemented the specifications and build a playground in which you can fetch patient summaries from Epic's development environment and store information derived from the summaries as credentials to a wallet, and then present the credential to a service asking for it.
The project proved that even a patient summary with a decent size can fit into a wallet and can be shared from a wallet.
The project proved it is possible to create technical specifications for credentials related to patient summaries, and to implement those specifications in an interoperable way.
Play around in a full scenario of fetching a patient summary from an EHR, storing it to a digital wallet as a credential, and presenting the credential when requested on the interactive playground.
In the Nordics, individuals have for years had the possibility to view their health data on patient portals. However, they have not been offered a choice to download their information in structured electronic format so that it could be analysed by various apps and AI tools.
A grassroot movement is working on changing this. There is already an implementation through which individuals can use an AI agent to build personalized data access APIs to the Danish Sundhed.dk portal, to access their own information through standard HL7 FHIR APIs. At a recent Vitalis Hackathon 2026 event, the Agentic Patient Access track extended the support to other Nordic portals.
Also this method of data access was tested to work with the patient summary app.
